@nurix/etna 0.20.25 → 0.20.26

package/data/harnesses/delivery/skills/documentation/templates/package.md

@@ -1,131 +1,65 @@
 # Package Documentation (docs/architecture/packages/{package}.md)
 
-Truth document. Use for: **one workspace package — what it is and how it behaves**. One file per package, named for the package's folder (`packages/cli/` → `docs/architecture/packages/cli.md`). It states the package's own machinery: its manifest and published identity, its build and entry point, its source layout, and every behavior of its tree that no system or feature document claims.
+Truth document. Use for: **one workspace package** — one unit of distribution: a manifest, a build, a binary, a bundle, a Worker. One file per package, named for its folder.
 
-**A package document is the residual owner of its own tree.** Its `owns:` is the whole package glob — `["packages/{name}/**"]` — and that glob is the *broadest* claim anything makes on those paths, so it loses to every narrower one. A system document naming `packages/{name}/src/server/runs/**` wins those files by specificity; a feature document naming `packages/{name}/src/surfaces/apps/**` wins those. What is left after every narrower claim is what this document describes, and it describes that exhaustively. **The residual claim is a promise of completeness, not of scope**: a package document with nothing left after the systems and features have claimed their subtrees is still owed — the manifest, the build, the entry, the layout, the test wiring and the deploy shape are always residual.
+**A document is read by people, and its footer is for the agent** (`references/style-guide.md` § Documents are read by people). A package document tells a person what the package is for, why it is its own unit, how it ships and to whom, how it is meant to be used, and what its consumers can rely on. Its manifest, build, entry, internal layout and test wiring are the code graph's (`docs/architecture/systems/knowledge-layer.md`), not a roster here.
 
-**Two rules bind the glob.** Neither genre may claim a path another document claims at **equal specificity** — equal-specificity overlap is an ownership conflict to resolve before either document ships, not a duplication to live with. And every glob **matches at least one file on disk** at `status: active`; a projected glob is permitted only at `draft`, and is confirmed when the document flips.
+**A package document's deepest layer is its public contract** (`references/style-guide.md` § Shape — the model first, the detail after): the commands and flags a person types, the exports another package imports, what is installed and where. For a CLI the flags *are* the promise, so they belong in How it is used. It stops before internal layout, build steps and which file holds what.
 
-**How this differs from its neighbours.** A **feature** document covers one capability or one page a person names, and owns that surface's globs. A **system** document covers one machine that spans packages, and owns the subtrees that machine is made of. A **package** document covers one unit of distribution — a manifest, a build, a binary or a bundle — and owns what is left of it. The unit is the package boundary, so if the subject you are writing about does not stop at a `package.json`, it is not this genre. Route it: one screen → feature; one machine crossing two packages → [system](system.md).
+**A package document is the residual owner of its own tree.** Its `owns:` is the whole package glob — the broadest claim on those paths, so it loses to every narrower system or feature claim. The one enumerable fact it declares is the ownership table: which subtrees other documents claim.
 
-**Required vs optional.** Required in every package document: the **frontmatter**, the **opening** (title, identity line, what the package is), the **ownership boundary** (what this document does not describe and which document does), at least one **behavior section**, **Files**, and **Related**. Everything else is optional — include a section only when the package has something real to put in it. A package with no test wiring of its own gets no verification section; a package that nothing else in the repo consumes says so in one line rather than growing a Consumers section. A short accurate document beats a full skeleton with empty headings.
-
-Package documents run long because they are exhaustive over their residue — roughly 150 to 600 lines is the working range, and the top of that range is a package holding an application, not a document that has lost discipline.
+**Required:** the frontmatter, the identity line, the goal line, **Why it exists**, **Ownership** (one paragraph or a table), **How it is used**, **What it promises**, **For the agent**. **What was decided** once any choice was made the code cannot explain. **Known gaps** only when there is one. Nothing else — the feature template's lint rules apply. Forty to a hundred and twenty lines.
 
 ```yaml
 ---
-owns: ["packages/{name}/**"]                      # required — the whole package tree, one glob; the residual claim
-keywords: [package-name, binary, build, entry]    # required — discovery terms: the npm name, the binary, the surfaces
-status: active                                    # required — active | draft | deprecated
-applies: [docs/architecture/common/api.md]         # optional — cross-cutting doctrine this package is BOUND by (obligation, not a bibliography); omit when none
-type: package                                     # required tooling key — genre stamp; preserve on edits, never narrate
+type: package
+status: active
+objects: [nustack cli, device credential]        # required — the objects this package designs or ships
+owns: ["packages/{name}/**"]                     # required until the graph computes ownership — the residual claim
+applies: [docs/architecture/common/api.md]       # optional
 ---
 ```
 
-> A package document carries no `module:` — a package is already a bounded unit, and a second label
-> for the same boundary is a thing to keep in sync for nothing. `last-reviewed:` is optional and,
-> like `type:`, is tooling metadata: preserve it, never narrate it.
-
 ```
 # {package-path} — {the one-line role}
 
-**Package:** `@scope/name` · **Ships as:** {a public npm package with one binary `x` / a private
-source-first workspace package / a Worker on {domain}} · **Source:** `packages/{name}`
-
-{One paragraph: what this package is and the job it does in the product. Name what it holds that
-nothing else does, and what it deliberately does not hold. Written for someone who has not opened
-the folder.}
-
-{One paragraph: the ownership boundary. This document is the residual owner of `packages/{name}/**`;
-these subtrees are claimed at higher specificity by these documents and are pointed at, not
-restated. Where the routing is more than a sentence, make it the table below instead.}
+**Package:** `@scope/name` · **Ships as:** {…} · **Source:** `packages/{name}`
 
-{Optional, and worth its line whenever the body names paths: "Paths below are relative to
-`packages/{name}/` unless they name another package."}
+{One sentence: the job this package does in the product, for whom.}
 
-## What is built and what is not
+## Why it exists
 
-{Optional — required in substance whenever some of the tree does not run. State plainly which
-halves exist and which do not, with the source evidence for each claim, and say what a reader who
-runs the unbuilt half will actually observe. A package whose subject as a whole does not run is
-`status: draft` and says so here; a scoped gap in a working package stays `active` and takes an
-UNBUILT marker at the section that describes the gap.}
+{Why it is its own unit, what it holds that nothing else does, what it deliberately does not hold, who consumes it, how and when it ships. Prose.}
 
-## Ownership — packages/{name}
+## Ownership
 
-{Optional — use the table form when more than two documents claim subtrees of this package.}
-
-**The package glob is the residual claim.** A system or feature document's `owns:` is more specific
-and wins by specificity, so this document describes only what none of them claims, and points to
-each for the rest.
-
-| Path | What it is |
-| --- | --- |
-| `src/index.ts` | {the residue: the entry, the dispatch, the layout} |
+This document is the residual owner of `packages/{name}/**`. Claimed at higher specificity:
 
 | Subtree | Stated and owned by |
 | --- | --- |
 | `src/{machine}/**` | [{system}](../systems/{system}.md) |
-| `src/surfaces/{x}/**` | [{feature}](../../features/{feature}.md) |
 
-## {Behavior sections — named for this package's own machinery}
+## How it is used
 
-{The body. There is no fixed section list, and inventing one would be a lie: what a CLI owes
-(commands, the store, the on-ramp) and what a UI package owes (the host port, the frame, the route
-zones, the component pool) share no headings. Name each section for the thing it describes and
-order them the way a reader meets them — identity and build first, then the surface, then what it
-writes, then how it is verified. Prefer a table wherever the content is a roster (commands, routes,
-exports, bindings, environment variables); prefer prose wherever the content is a rule and its
-reason. State mechanisms and contracts, never pasted implementations.}
+{What a person or another package does with it, in plain words — install, run, import, call — and what they see. Terms introduced on first use. Code named only at a seam.}
 
-## Tests
+## What was decided
 
-{Optional. What proves this package, and what each suite pins — a `Suite | Pins` table, or the
-commands a reader runs. A package whose verification is a build check names the check instead
-(`## Checks`, `## Build and test`); a package with no suite of its own says so in one line in the
-build section and carries no heading here.}
+{Themed paragraphs.}
 
-## Files
+## What it promises
 
-| Path | Role |
-| --- | --- |
-| `packages/{name}/package.json` | {the manifest: the bin, the exports, the scripts} |
-| `packages/{name}/src/index.ts` | {the entry} |
+{What a consumer can rely on and what the package refuses; checkable sentences, grouped.}
 
-{One row or bullet per file this document owns, with what it holds — the roster a reader uses to go
-from the document to the code. Close with the inverse where it helps: "Read here, owned elsewhere:"
-naming the paths the body describes but another document claims.}
+## Known gaps
 
-## Related
+{One paragraph, only when needed.}
 
-- [`{system}.md`](../systems/{system}.md) — {why a reader of this document would open that one}
-- [`{other-package}.md`]({other-package}.md) — {the seam between the two}
-- [`{doctrine}.md`](../common/{doctrine}.md) — {the cross-cutting contract this package answers to}
-```
-
-### The identity line
+## For the agent
 
-The bolded `·`-separated run under the title is what a reader checks first, and it answers three
-questions no body section should have to: **what is this called** on the registry or in the
-workspace, **how does it ship** (a public tarball, a private source-first package, a deployed
-Worker, a signed installer), and **where is its source**. A package that ships two artifacts names
-both. Add a `**Crate:**` or `**Deploys as:**` term where the package has one; drop any term that
-would restate the title.
+Objects: {…}. Commands {…} and exports {…} — the public contract. Code root `packages/{name}/`. Seams {…} by name. Checklist `tests/{package}.md`. See also {neighbour} ({why}). No file lists or symbol rosters — those are the graph's.
+```
 
 ### Marking what is decided and unbuilt
 
-Where the package holds code for a design that is decided and not built — or a surface whose other
-half does not exist — wrap the prose in a marker so the gap is machine-findable and its evidence
-travels with it:
-
-```
-<!-- UNBUILT:START — {what is decided, where it is decided (an AD or an owner ruling), and the
-source evidence that it is not built: the file that does not exist, the route that is not mounted,
-the binding that is not declared} -->
-{the prose describing the unbuilt half}
-<!-- UNBUILT:END -->
-```
-
-**A design that was decided *against* carries no marker.** A marker means the work is owed and
-absent; using one for a rejected design turns the register of debt into a register of opinions.
-Say in prose that it is not built and not owed, and name the decision that settled it.
+`<!-- UNBUILT:START — {…} -->` … `<!-- UNBUILT:END -->` around the prose for a decided, unbuilt half; a design decided *against* carries no marker.

package/data/harnesses/delivery/skills/documentation/templates/root-readme.md

@@ -1,104 +1,142 @@
-# Project Root README
+# Project Root README (/README.md)
 
-Truth document. Use for: the human-facing entry point at the repository root (`/README.md`) — what visitors and new contributors land on. Distinct from `docs/README.md` (the agent/doc index — see **docs/README.md (Documentation Root)** above). The two coexist; don't merge them.
+Truth document. Use for: the repository root `/README.md`. It opens outward — what the product does, for whom, and where it runs, in a user's terms — then turns inward for the team and coding agents: what state the repo is in, how it works, what its parts are and what must not break, then routes every other question into `docs/`. The outward part comes first because it is what a stranger reads; the inward part is longer because it is what the team uses. **It hosts nothing it can link to.** It is distinct from `docs/README.md`, which describes the folders of the docs tree, and from `CLAUDE.md` / `AGENTS.md`, the standing rules an agent loads. It points at both and restates neither.
 
-### Strategy
+### What it carries
 
-The root README answers, in order:
+Sections come in this order; 1 to 3 are the outward-facing first screen, 4 onward the inward page. Skip any section the repo cannot fill truthfully. Never pad it, and never leave a stub.
 
-1. **What is this?** — one to two sentences, no marketing claims
-2. **What do I get if I install it?** — capability families
-3. **What's it built on?** — terse stack list with versions
-4. **How do I run it?** — the three or four scripts that matter
-5. **How is it laid out?** — directory tree, one-liner per significant folder
-6. **How do I extend it?** — numbered contribution checklist
-7. **What state is it in?** — pre-publish, beta, stable, internal
+1. **Identity.** The H1 plus two or three sentences in a user's terms: what the product is, where it runs, and what using it is like.
+2. **What it does.** Two to four paragraphs, outward-facing: the core loop as a person meets it, what surrounds that loop, how the product follows the person across its surfaces, and who it is for, closing with what it deliberately is not. Plain words, no feature roster, no superlatives.
+3. **Where it runs.** One paragraph: the addresses, the distributed artifacts and where they are published, where identity comes from, and whether a self-hosted edition exists.
+4. **The turn.** A rule and one paragraph saying the rest is for the team and agents, with the scope line: what lives in this repo and what lives elsewhere.
+5. **State.** Optional: a one-line blockquote, present only while something repo-wide is true that a newcomer must know (frozen, mid-migration, mid-breaking-change on `dev`). It links the plan or runbook that owns the change. Say here which units publish and where, if any do.
+6. **How it works.** Three to six short paragraphs, or numbered stages, along the main request or data path: who arrives, what is built, where state lives, how the result leaves. Name a technology only where it explains a stage. End with a link to the system overview.
+7. **What is in the repository.** A sentence on how the tree is organised, then one table row per top-level unit (package, app, service), giving its path, what it is in one line, and its owning doc; the top folders that are not packages get a sentence each. This replaces the tree.
+8. **Rules that bite.** Optional. At most five one-line invariants, public/internal boundaries, never-edit paths (generated, protected) or non-goals, each linked to the doc that argues it.
+9. **Where to go.** An intent-to-destination table. Its last row is the one for agents.
+10. **Everyday commands.** Optional. At most four commands run on every change, ending at the gate a push must pass. First-run commands are never here.
 
-Skip any section that doesn't apply. Don't pad to fill the template.
+### What it leaves out
+
+| Left out | Lives in |
+| --- | --- |
+| Getting started, install, prerequisites, env files, first run, troubleshooting | `docs/operations/setup.md` |
+| Stack: technologies, what each is for, where its version is pinned | `docs/operations/setup.md` § Stack. Why it was chosen goes in `docs/architecture/` |
+| Directory or file tree | `docs/structure.md`, the only tree |
+| Daily loop, watch modes, per-package traps | `docs/operations/local-development.md` |
+| Contributing procedure, branch model, commit rules | `CLAUDE.md` and `docs/operations/` |
+| Feature list, news, "what's new", roadmap, changelog | `docs/features/`, `docs/history/` |
+| Badges, logos, images, screenshots, social links, sponsors, hand-written TOC, license text, superlatives | Nowhere. The outward sections are plain prose too. Agents cannot read them and the team does not need them. License is one line or absent |
 
 ### Writing rules
 
-- **Sentence-case headings.** "Getting started", not "Getting Started".
-- **Concrete over abstract.** Real versions, real paths, real commands. No "leverages cutting-edge…".
-- **The tagline answers "what is this?"** — not "why is it great?". Two sentences max.
-- **Tables for enumeration** (routes, commands, endpoints). **Bullets for families and categories.**
-- **Directory tree as a code block**, not a nested markdown list.
-- **Numbered checklist** for "how to add a thing" — readers should be able to follow it top-to-bottom without re-reading.
-- **Point to `docs/` for depth.** The root README links into deep docs; it doesn't host them.
-- **Detect the package manager from the lockfile** (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, otherwise npm) and write commands accordingly. Don't hardcode `npm` if the repo uses pnpm.
+- **Budget: between 60 and 140 non-blank lines, the outward part under a third of it.** Prose is welcome — How it works and Rules that bite read better as paragraphs than as rows — but past the ceiling a section is hosting content that belongs in a doc. Move it and leave the link.
+- **Every section is either a fact the reader acts on or a link.** If a section needs a paragraph, it needs a doc.
+- **One H1, then H2 sections, in plain Markdown.** Sentence-case headings, no emoji, no HTML layout, and no `#` comment lines inside code blocks (they parse as H1s).
+- **Relative links into the repo only.** Never an absolute repo URL. Never an external site as the home of a canonical doc.
+- **Link folders and mandated scaffolds, never rosters.** The allowed targets are folders, `docs/README.md`, `docs/structure.md`, `docs/operations/setup.md`, `docs/history/CHANGELOG.md`, `docs/history/backlog.md`, `CLAUDE.md` and the owning docs in the Map. A procedure is named only where a Where-to-go row needs it. Never list individual feature docs: the ownership index finds them.
+- **No tree.** The Map stops at top-level units and never lists files. Mark paths that look primary but are not, for example "`legacy/`: reference only, never edited".
+- **The Map is a coarse view of the ownership index, not a rival to it.** The Owning doc column names the doc that the index's `owns:` globs resolve to. When the two disagree the index wins, and the Map row is fixed in the same change.
+- **No version numbers and no dates.** Name the file that pins a version (`.nvmrc`, `packageManager`, `rust-toolchain.toml`). Write in the present tense, with no "coming soon" and no "as of".
+- **State rules, don't argue them.** One line each. The reasoning lives in the linked doc, and agent process rules stay in `CLAUDE.md`.
+- **Commands come from the repo.** Detect the package manager from the lockfile (`pnpm-lock.yaml` gives pnpm, `yarn.lock` gives yarn, otherwise npm). Use only scripts that exist, each with a trailing comment saying what it does.
 
 ### Template
 
 ```markdown
-# {package-name}
+# {Project name}
 
-{One- to two-sentence positioning. What it is and what scope it covers. No superlatives, no value claims.}
+{Two or three sentences in a user's terms: what the product is, where it runs, what using it is like.}
 
-## What's in the box
+## What it does
 
-- **{Family 1}** — {what's in it; a few specific items, comma-listed.}
-- **{Family 2}** — {what's in it.}
-- **{Family 3}** — {what's in it.}
+{The core loop as a person meets it: what they bring, what the product does, what they get back and what record it leaves.}
 
-The full surface lives in [`{path/to/public-index}`]({path/to/public-index}). ← optional pointer for libraries
+{What surrounds the loop: the capabilities a team needs to run it, named plainly.}
 
-## Stack
+{How it follows the person across surfaces: CLI, desktop, integrations, agents' doors.}
 
-- {Framework} {version} · {Language} {version}
-- {Build tool} {version}
-- {Other load-bearing deps}
+{Who it is for, and what it deliberately is not.}
 
-## Getting started
+## Where it runs
 
-\`\`\`bash
-{pm} install
-{pm} run dev        # what it does (port, URL)
-{pm} run build      # what it does
-{pm} run preview    # what it does (omit if not applicable)
-\`\`\`
+{Addresses; distributed artifacts and where they publish; where identity comes from; whether a self-hosted edition exists.}
 
-{Optional one-liner about first-run behavior — e.g., "Dev server lands on /playground."}
+---
 
-## {Runtime entry point} ← optional; e.g., "The playground", "CLI", "API endpoints"
+The rest of this page is for the team and for coding agents working in this repository. {What lives in this repo and what lives elsewhere.} {One sentence: the sections below route every other question into docs/.}
 
-{Brief description of the dev/runtime surface.}
+> **State:** {one line: what is in flux right now; which units publish where} → [{plan or runbook}](docs/history/{plans|migrations}/{file}.md) ← optional; delete when the flux ends
 
-| {Thing}              | {What it shows / does} |
-| -------------------- | ---------------------- |
-| `{route or command}` | {description}          |
+## How it works
 
-## Layout
+1. **{Stage}**: {what happens, naming the mechanism only where it explains the step}.
+2. **{Stage}**: {…}.
+3. **{Stage}**: {where state lives}.
+4. **{Stage}**: {the outbound effect: what is written, deployed or returned}.
 
-\`\`\`
-src/
-├── {entry-file}        # {purpose}
-├── {folder}/           # {purpose}
-│   └── ...
-└── {folder}/           # {purpose}
-\`\`\`
+{Optional, one sentence naming the seam everything passes through, e.g. "Every client reaches data through `{path}`; nothing else talks to the database."} The full account: [{system overview}](docs/architecture/{overview}.md).
+
+## What is in the repository
+
+{One or two sentences: the workspace shape and where each unit's design document lives.}
 
-## Adding a {primary unit}
+| Path | Role | Owning doc |
+| --- | --- | --- |
+| [`{packages/unit}/`]({packages/unit}/) | {one line: what it is and who consumes it} | [{doc}](docs/architecture/packages/{unit}.md) |
+| [`{packages/unit}/`]({packages/unit}/) | {one line} | [{doc}]({path}) |
+| [`{top-folder}/`]({top-folder}/) | {one line; "generated" or "reference only" where true} | — |
 
-1. {Drop the source under the right family/folder.}
-2. {Re-export from the public surface.}
-3. {Wire into the playground / example app / test harness so reviewers can see it render.}
-4. {Document any divergence from upstream in `docs/{...}`.}
+{One sentence each for the top folders that are not packages — `registry/`, `scripts/`, `docs/` — with their owning doc.} Where every doc lives: [docs/structure.md](docs/structure.md).
 
-## Styling ← optional; replace with whichever cross-cutting concern matters most
+## Rules that bite
 
-{Configuration notes that affect every consumer — design tokens, conventions, opt-outs.}
+{One sentence saying these are stated here and argued in the documents they point at.}
 
-## Status
+- **{Invariant}**: {the rule, one line}. → [{source}]({path})
+- **{Boundary}**: `{path}` is the only {public | published} surface; everything else is internal.
+- **{Never-edit paths}**: `{path}` is {generated by `{command}` | protected}; edit {the source} instead.
+- **Not here:** {a non-goal stated as a refusal}.
 
-{Pre-publish, beta, stable, internal-only. State the stability tier per surface — which APIs are contracts and which are experimental — so readers know what can be relied on.}
+## Where to go
 
-## License
+| I want to… | Go to |
+| --- | --- |
+| Set up a machine and run it the first time | [docs/operations/setup.md](docs/operations/setup.md) |
+| Work on it day to day | [docs/operations/{local-development}.md](docs/operations/{local-development}.md) |
+| Understand the design | [docs/architecture/](docs/architecture/) |
+| Change a feature | [docs/features/](docs/features/), found through the ownership index |
+| Change a contract ({db schema · wire envelope · auth · events · env}) | [{contract doc}]({path}), boundary-checked before the change |
+| Ship or release | [docs/operations/{deployment}.md](docs/operations/{deployment}.md) |
+| Place a new doc | [docs/structure.md](docs/structure.md) · [docs/README.md](docs/README.md) |
+| See what changed and what is open | [CHANGELOG](docs/history/CHANGELOG.md) · [backlog](docs/history/backlog.md) |
+| Work here as a coding agent | [CLAUDE.md](CLAUDE.md) ([AGENTS.md](AGENTS.md) for other runtimes): load before any edit |
 
-{License name — scope. e.g., "UNLICENSED — internal use only", "MIT".}
+## Everyday commands
+
+\`\`\`bash
+{pm} {typecheck}     # {what it checks}
+{pm} {test}          # {the unit suite, from a cold shell}
+{pm} {gate}          # {what a change must pass before it is pushed}
+\`\`\`
+
+`{pm} --filter <unit> run` lists a unit's own scripts.
+
+{License, one line, e.g. "UNLICENSED, internal use only."} ← optional
 ```
 
 ### Baseline scaffolding behavior
 
-The baseline audit **does** scaffold the project root README when missing. The risk this template guards against — template-shaped placeholders that look abandoned — is mitigated by the writing rules above: fill every section with concrete details from the repo (real package manager from the lockfile, real scripts, real layout, real status). Skip sections that genuinely don't apply rather than leaving stubs.
+The baseline **does** scaffold `/README.md` when it is missing, and it fills each section from the repo:
+
+- **Identity, What it does, Where it runs:** from the product charter and vision documents under `docs/architecture/common/` (what the product is, the core loop, who it is for), the package manifests (what publishes where), and the deploy config (addresses). Written in a user's terms; where the charter is missing, the baseline writes Identity only and raises a `note:` row for the rest.
+- **How it works:** from the system overview.
+- **Map:** from the workspace globs and the ownership index.
+- **Rules:** from `docs/operations/protected-files.md` and the architecture doctrine.
+- **Commands:** from the lockfile and the root scripts.
+- **Where to go:** only the rows whose targets exist.
+
+It drops every section it cannot fill concretely.
 
-**Never overwrite an existing root README** during a baseline. If one is present — even sparse or outdated — leave it untouched. Treat updates to a pre-existing root README as a separate, explicit request.
+**It never overwrites an existing root README.** If one is present, even sparse or outdated, the baseline leaves it untouched and raises a `note:` row proposing the reshape. Reshaping is a separate, explicit request. When it runs, each removed section moves in the same change: getting-started, install and env content and the Stack go to `docs/operations/setup.md`, a drawn tree becomes the Map (the tree itself stays in `structure.md`), and a contributing checklist goes to `docs/operations/`. Nothing is deleted without a home.

package/data/harnesses/delivery/skills/documentation/templates/setup.md

@@ -0,0 +1,138 @@
+# Setup (docs/operations/setup.md)
+
+Truth document, operations genre (`type: operations`). Use for: **the one-time path from a fresh machine to a first verified run.** It covers what the repo is built on, prerequisites, install, env files, local services, the first commands, proof that it works, and the failures a fresh clone hits. There is **one per repo**, always named `setup.md`, and it is a mandated scaffold. The root README's only setup content is a Where-to-go row linking it.
+
+It is distinct from `local-development.md`, the daily loop: watch modes, resetting state, per-package traps, the inner test cycle. Setup runs once per machine. Local development runs every session. Setup ends by handing off to it, and neither copies the other. Deploying is `deployment.md`.
+
+Required: **Goal**, **Stack**, **Prerequisites**, **Install**, **First run**, **Verify**. Optional, included only with real content: the audience fork, **Before cloning**, **Environment files**, **Local services**, **Reset**, **Common failures**.
+
+### Writing rules
+
+- **Never write a version a file already pins.** Each row names the pinning file (`.nvmrc`, `package.json` `engines` / `packageManager`, `rust-toolchain.toml`, `go.mod`) and the command that checks it. A typed number is a second source that drifts on the next bump.
+- **Stack is one row per layer.** Give the technology, what it is for in this repo, and where its version is pinned. Why it was chosen belongs to `docs/architecture/`, linked once. Don't repeat the dependency list: the manifests are the roster.
+- **One path, from the lockfile.** `pnpm-lock.yaml` gives pnpm, `yarn.lock` gives yarn, otherwise npm. Say how it is activated (`corepack enable`). Never write "or npm / yarn". Give a per-OS variant only where the commands really differ.
+- **Traps before commands.** Anything a fresh clone hits before the first command goes in Before cloning, not halfway down the steps: LFS, submodules, a required stub file, an access grant, a credential that has to be requested.
+- **Copy-paste runnable, one action per step, each with its expected outcome.** Run non-interactively where the tool allows it, so an agent can execute the step unchanged. "It should work now" is never a step.
+- **Script first, then document.** If a bootstrap script or task exists, it is the step, and the doc carries only the judgment around it. A setup sequence run often with no script gets a script.
+- **Env files as a table, never a variable dump.** One row per file: where it is copied from, what must be filled, where the values come from, whether it is required to boot. The variable contract is the example file and the code's env type, linked and never copied. Secret values never appear.
+- **Destructive commands state their blast radius where they appear:** what is deleted or truncated, whether it prompts, and the flag that skips the prompt.
+- **Verification is observable:** a health probe and its expected status, a URL and what it shows, a seeded login, a doctor command and its output, or the test command passing from a cold shell.
+- **Common failures are keyed by the exact error text,** followed by the cause and the fix, where the fix is a command or a file edit. Append a failure only once it has been root-caused, never as speculation.
+- **Per-package divergence is a subsection of this file.** A unit whose setup differs gets a `### {unit}` block under First run, or a row linking its own procedure. It never gets a second setup doc.
+
+### Template
+
+```markdown
+---
+type: operations
+---
+
+# Setup
+
+**Goal:** take a fresh machine from clone to a verified first run of {what runs: e.g. "the product Worker on :{port} and the web shell on :{port}, signed in as the dev fixture"}. Done once per machine; the daily loop is [`local-development.md`]({local-development}.md).
+
+{Optional audience fork: "Only running {the CLI / one package}? Stop after Install and see [`{procedure}`]({path})."}
+
+## Stack
+
+| Layer | Technology | For | Version pinned by |
+| --- | --- | --- | --- |
+| {Runtime} | {Node} | {what runs on it} | [`.nvmrc`](../../.nvmrc) |
+| {Server} | {framework · data layer} | {what it serves} | [`{package.json}`](../../{path}/package.json) |
+| {Client} | {framework · build tool · styling} | {which surfaces} | [`{package.json}`](../../{path}/package.json) |
+| {Tests} | {runners} | {unit · e2e} | {manifest} |
+
+Why these were chosen: [{system overview}](../architecture/{overview}.md).
+
+## Prerequisites
+
+| Tool | Version from | Check |
+| --- | --- | --- |
+| {Node} | [`.nvmrc`](../../.nvmrc) | `node -v` |
+| {pnpm} | `packageManager` in [`package.json`](../../package.json), via `corepack enable` | `pnpm -v` |
+| {Docker / Rust / wrangler / …} | {pinning file, or "any current"} | `{command}` |
+
+- **Access:** {repo, secrets store, cloud account, registry token, and who grants each}.
+
+## Before cloning ← delete if none
+
+- **{Trap}:** {what a fresh clone hits and the one command that clears it, e.g. `git lfs install`, `git submodule update --init`}.
+
+## Install
+
+\`\`\`bash
+git clone {url} && cd {repo}
+corepack enable
+{pm} install                  # expect: {what a clean install ends with}
+\`\`\`
+
+## Environment files ← delete if none
+
+| File | Copy from | Fill | Values come from | Required to boot |
+| --- | --- | --- | --- | --- |
+| `{path/.dev.vars}` | `{path/.dev.vars.example}` | {keys, or "every blank"} | {vault, the owner, a generated local value} | {yes / no} |
+
+The contract is [`{example file or typed Env}`](../../{path}). Read it before concluding a value is missing. {Which of these files are gitignored.}
+
+## Local services ← delete if none
+
+| Service | Start | Port | Ready when |
+| --- | --- | --- | --- |
+| {local DB / emulator} | `{command}` | {port} | `{probe}` returns {expected} |
+
+## First run
+
+1. Prepare local state.
+
+   \`\`\`bash
+   {pm} --filter {unit} {migrate-and-seed}   # expect: {output}
+   \`\`\`
+
+2. Start the {backend}.
+
+   \`\`\`bash
+   {pm} --filter {unit} {dev:server}         # expect: listening on :{port}
+   \`\`\`
+
+3. Start the {frontend / CLI}.
+
+   \`\`\`bash
+   {pm} --filter {unit} {dev}                # expect: {URL}
+   \`\`\`
+
+4. Open `{http://localhost:port}` and {sign in as `{seeded user}` / reach `{first screen}`}.
+
+## Verify
+
+- `{curl -fsS http://localhost:{port}/{health}}` returns `200` {and `{body}`}.
+- `{doctor or status command}` reports {expected}. ← keep whichever exists
+- `{pm} {test}` passes from this cold shell ({expected tail}).
+
+## Reset ← delete if none
+
+| Command | Deletes | Prompts? |
+| --- | --- | --- |
+| `{pm} {reset-script}` | {local state at `{path}`} | {yes; `{FORCE=1}` skips / no} |
+
+## Common failures
+
+- **`{exact error text}`.** {Cause.} Fix: `{command or file edit}`.
+
+## Next
+
+The daily loop and its per-package traps: [`local-development.md`]({local-development}.md). Deploying: [`deployment.md`](deployment.md). Standing rules: [`CLAUDE.md`](../../CLAUDE.md).
+```
+
+### Baseline scaffolding behavior
+
+The baseline scaffolds `docs/operations/setup.md` when it is missing and the repo has a lockfile and at least one runnable root script. It fills each section from the repo:
+
+- **Stack:** from the workspace manifests, one row per layer.
+- **Prerequisites:** from the pinning files.
+- **Install and First run:** from the root README's getting-started block (if one exists) and the root scripts.
+- **Environment files:** from every `*.example` / `.dev.vars.example` in the workspace.
+- **Verify:** from a health route, a doctor command or the test script.
+
+It leaves Common failures empty until a failure is root-caused, and it drops every section it cannot fill concretely.
+
+**It never overwrites an existing `setup.md`.** If the repo already has a first-run procedure under another name, the baseline proposes the rename with a `note:` row and does not create a second file.