taubyte-scope-routing
Scope Routing
Website when logically appropriate (default bias)
When planning a new project or greenfield work, include a website resource (explicit repo strategy per taubyte-resource-creation) if a browser UI is a natural part of the product. Examples: todo/board/chat/calendar apps, CRUD or admin dashboards, landing + authenticated app, games or interactive demos, docs or portal meant to be opened in a browser, or any brief that says “app”, “UI”, “frontend”, “SPA”, or “site” without restricting scope to the API.
Skip the website only when the project is clearly non-browser or the user opts out: headless API / microservice only, webhooks, PubSub / workers only, CLI or library deliverable, pure integration backend, or the user explicitly asks for API only, no UI, or backend only.
If both API and website apply, prefer the full-stack row in the scope matrix (often Frontend app + tau new website plus Backend app for database / libraries / functions). Log website_decision: include | skip, with a one-line reason, in taubyte-context-log.
Scope matrix
- Project / global (default for many tasks):
project,domain,website,library— and standalone function or website work when the user does not ask for multiple applications or named app boundaries. - Application-scoped (requires selected application when doing this work):
application,service,database,storage,messaging,smartops. function: treat as project-level for simple, single-function (or function-only) tasks without a named application or multi-context brief; treat as application-scoped only when the user ties work to an application, or the task is multi-app / multi-context, or the CLI clearly requires an application for the next commands.- Full-stack (website + HTTPS API + database/library): plan multiple applications (common pattern: Frontend for the site, Backend for
libraries,databases, andfunctionsthat reference the library). Website YAML lives under the Frontend app;database/ library-backedfunctionYAML under Backend. Samedomainsreference on site + functions when same-origin/api/*is desired. Seetaubyte-reference-index→ Full-stack worked example.
Rules
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