taubyte-core-constraints
Core Constraints
Must-follow rules
- Never ask user to run setup commands manually; agent performs setup.
- Run CLI preflight (
taubyte-cli-prereqs) before all Taubyte operations. - For Dream/local, never run backend-contacting
taucommands before Dream is up and universe exists. - Use
dreamcommands directly; never usetau dream. - Use default universe
defaultunless user explicitly requests another. - After resource creation, push config (
tau push project --config-only) before relying on resource visibility. - After code changes, push code (
tau push project --code-only) and verify builds/logs. - Never set function timeout to
0; use valid durations (30s,1m, etc.). - HTTP functions: one function per path+method; never comma-separated methods.
- For functions/websites in automation, use empty template; for Go functions, include
--language Go. - Use matcher values for DB/storage SDK calls, not human-facing resource names or YAML filenames (
description/ basename are not runtime keys). The Go string must match YAMLmatch(and regex pattern whenuseRegex: true). Examples:match: appdata↔database.New("appdata");match: /todos↔database.New("/todos")— leading slash must match exactly. - Do not bypass failing
tau push projectwith direct git operations. - On Git Bash Windows for path-like flags, prefix with
MSYS_NO_PATHCONV=1. - Website
.taubyte/build.shmust be non-empty and must write deploy output to/out. - Verify project selection with
tau --json currentbefore resource mutations.
More from taubyte/skills
verifying-taubyte-functions
Verifies a Taubyte Go function locally via the `taubyte/go-wasi` Docker recipe (preferred over `tau build`, with tmpfs+bind-mount-ro to avoid root-owned artifacts in the source tree), and verifies a function actually serves on Dream by curling the gateway with the right `Host:` header (plus `/etc/hosts` mapping for `*.localtau`). Use when locally compiling a Go function to WASM, when smoke-testing a function before pushing, or when probing a Dream-hosted HTTP function from the laptop.
13creating-taubyte-resources
Creates Taubyte resources non-interactively via `tau new` for domain, website, library, function, application, database, storage, messaging, and service. Encodes the project-vs-application scope rule, the database `min < max` constraint, the website/library `--generate-repository` + import sequence, and the forbidden `--generated-fqdn-prefix` flag. Use when adding any resource to a Taubyte project's config repo.
13diagnosing-dream-builds
Diagnoses Dream local-cloud builds when `tau list/query builds` is empty or unreliable, by hitting the jobs HTTP endpoint directly (`GET /jobs/<project_id>`, `GET /job/<job_id>`) using the GitHub token from `~/tau.yaml`, then downloading logs with `tau query logs --jid`. Use when Dream builds appear silent, the build table is empty after `dream inject`, or you need raw job ids and logs for a failing build.
12installing-taubyte-tooling
Installs and verifies the prerequisites for any Taubyte workflow — Node.js, Docker (engine + running daemon), `@taubyte/cli` (the `tau` command), and `@taubyte/dream` (the `dream` command). Acts as a hard gate that runs before every other Taubyte skill, with OS-specific automated installs (winget / brew / apt-get) and explicit stop conditions when an install fails. Use on first-time machine setup, when `tau` or `dream` is missing or broken, when `docker info` fails, or when starting a fresh shell and you don't know if the toolchain is ready.
12pushing-taubyte-projects
Pushes Taubyte project changes via `tau push` — `tau push project [--config-only|--code-only]`, `tau push website <name>`, and `tau push library <name>` — with the rule that `--message` is required when `--defaults` is set, and the push-config-before-code ordering for resource-dependent changes. Also explains the `tau pull` "already up-to-date" non-zero-exit quirk. Use when pushing local changes to GitHub through `tau` (instead of raw `git push`), or when triggering remote-cloud webhooks / Dream injects after edits.
12starting-dream-locally
Starts a Dream local Taubyte cloud (multiverse) using either the newer `dream start` workflow or the older `dream new multiverse` workflow, and explains the default universe naming (`default` for `dream start`, `blackhole` for `dream new multiverse`). Use when bringing up, restarting, or daemonizing a local Dream cloud, or when `dream --help` shows a different shape than expected.
12