@nurix/etna 0.20.25 → 0.20.26

package/data/harnesses/code/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/code/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.

package/data/harnesses/code/skills/documentation/templates/system.md

@@ -1,143 +1,59 @@
 # System Documentation (docs/architecture/systems/{system}.md)
 
-Truth document. Use for: **one machine that spans packages** — exactly how it works, end to end, in one place. One file per machine, named for the machine (`docs/architecture/systems/update-engine.md`). It states the machine's model and its whole path: what enters it, every stage it passes through, what it writes, what re-drives it when it stalls, and what a reader sees at the far end.
+Truth document. Use for: **one machine that spans packages**, which a person cannot point at — the walk, the egress, the ingest, the settlement, a gate, a sweep, a door an agent calls. One file per machine, named for the machine. A thing a person navigates to is a feature document, even when it owns tables; a unit of distribution is a package document.
 
-**A system document's globs win by specificity.** Its `owns:` names the subtrees and exact files the machine is made of — `packages/studio/src/server/execution/**`, `packages/ui/src/shared/harnessVocabulary.ts` — and those are narrower than the package document's `packages/studio/**`, so the system takes them and the package keeps the residue. That is the whole mechanism: **the package document is the residual owner and the system document is the specific one**, and nothing needs to be subtracted by hand. A machine confined to one package still gets a system document if the machine is the thing worth stating; it is the *narrower glob* that makes it a system, not the package count.
+**A document is read by people, and its footer is for the agent** (`references/style-guide.md` § Documents are read by people). A system document explains a machine to a person: what it is for, why it is split where it is split, how it behaves from the outside, what it guarantees at the far end, what re-drives it when it stalls. Its stages, tables, routes, frames, bindings and files are the code graph's (`docs/architecture/systems/knowledge-layer.md`), not a hand-typed tour. The body names code only at a cross-cutting seam another machine or feature would not find from its own files.
 
-**Two rules bind the globs.** 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. And every glob **matches at least one file on disk** at `status: active`; projected globs are permitted only at `draft` and are confirmed when the document flips. Because a system's `owns:` list is long and hand-assembled, re-glob it whenever the machine's code moves — a stale entry here silently un-owns real code back to the package document, which does not describe it.
+**A system document's deepest layer is the machine's behaviour across packages** (`references/style-guide.md` § Shape — the model first, the detail after): the order it runs in, the sequence and state diagrams at role level, the invariant that holds at each place where parts meet, and what re-drives a stall. That layer is earned because no single file shows a cross-package flow. It stops before per-function steps, tables, columns and routes.
 
-**How this differs from its neighbours — and the mistake this template exists to prevent.** A **feature** document covers one capability or one page a person names and owns that surface's globs. A **package** document covers one unit of distribution and owns what is left of its tree. A **system** document covers a *machine*: something with an entry, stages, state and an outcome, which a person does not open and cannot point at. **The failure mode is a system document written as a giant feature document** — a tour of screens and what each button does, at ten times a feature doc's length. The test is mechanical: if the subject can be named by an address a person navigates to, it is a feature; if it can be named only as a verb over the product's own nouns — the walk, the egress, the ingest, the settlement — it is a system. A system document says what a surface *renders from* and links to the feature document for what the surface looks like; it never describes the surface.
+**A system document's globs win by specificity.** Its `owns:` names the subtrees and exact files the machine is made of, narrower than the package glob. Two documents never claim a path at equal specificity; every glob matches a file on disk at `status: active`.
 
-**Required vs optional.** Required in every system document: the **frontmatter**, the **opening statement** (what the machine is, then what this document states end to end), the **boundary paragraph** (what this document does not restate, and which document holds each part), the **machine diagram**, at least one **stage section**, **Files**, and **Related**. Everything else is optional. Do not add a section because it seems owed — a stage the machine does not have is a section that will be filled with something untrue.
-
-System documents are long by nature, because the point is that the whole machine is in one place — roughly 300 to 1000 lines. Length is earned by stages, never by restating a neighbour: every paragraph that could have been a link to the document that owns it is the genre's characteristic waste.
+**Required:** the frontmatter, the opening paragraph (the machine defined in its first sentence, what enters, what it leaves behind), the **boundary paragraph** (what this document does not decide, and which document does — subjects with owners, never bare links), **Why it exists**, **How it works**, **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 lint rules of the feature template apply. Sixty to a hundred and sixty lines.
 
 ```yaml
 ---
-owns:                                              # required — the machine's subtrees and exact files; narrower than the package glob
+type: system                                     # required tooling key
+status: active                                   # required — draft = the machine as a whole does not run
+objects: [run, run ledger, settlement]           # required — the objects this machine owns or moves
+owns:                                            # required until the graph computes ownership — narrower than the package glob
   - packages/{pkg}/src/{machine}/**
-  - packages/{pkg}/src/routes/{machine}.ts
-  - packages/{other}/src/shared/{machine}Vocabulary.ts
-keywords: [machine name, its nouns, its verbs]     # required — discovery terms: the machine's own vocabulary, the table and route names
-status: active                                     # required — active | draft | deprecated
-applies:                                           # optional — the decisions and doctrine this machine is BOUND by (obligation, not a bibliography)
+applies:                                         # optional — decisions and doctrine this machine is BOUND by
   - docs/architecture/decisions/AD-0NN-{slug}.md
-  - docs/architecture/common/{doctrine}.md
-type: system                                       # required tooling key — genre stamp; preserve on edits, never narrate
 ---
 ```
 
-> A system document carries no `module:` — a machine that spans packages belongs to no single
-> bounded context, and labelling it with one asserts a boundary it crosses by definition.
-> `last-reviewed:` is optional tooling metadata: preserve it, never narrate it.
-
 ```
 # {The machine}
 
-{One paragraph that defines the machine in its own first sentence — bold the term being defined —
-then says what this document states, in the order the body states it. The enumeration is the
-contract: a reader who wants one stage finds it by reading this sentence. Where the machine's
-purpose is easier stated as an outcome, lead with `**Goal:**` and one sentence instead.}
-
-{One paragraph: the boundary. What this document does **not** restate, and which document holds
-each part — the neighbouring systems, the package documents whose residue this sits inside, the
-feature documents that render from it, the common-plane doctrine it obeys, the decision records
-behind its shape. Name each with a link and the subject it holds. This paragraph is what keeps the
-document from growing into its neighbours.}
-
-```text
-{The machine diagram. One fenced block, drawn as the thing flows — entry at the top or left,
-each stage a box or a labelled arrow, the durable writes named, the re-drive path shown returning.
-Label the arrows with what crosses them, not with verbs. This is the picture a reader holds while
-reading the rest, so it carries the machine's real names — routes, tables, classes, files — and
-not generic boxes.}
-```
-
-{Optional, and worth its line whenever the body names paths: "Every path below is relative to
-`packages/{pkg}/src/{dir}/` unless it names another package."}
+{The machine defined in its first sentence — bold the term — then what it takes in, what it leaves behind, and what a reader sees at the far end. Plain words.}
 
-{Optional: a reading order for a long document — "§ X is the data; § Y is the code that reads it;
-§ Z is what re-drives it" — where the section list is not self-evidently a sequence.}
+{The boundary paragraph: what this document does not decide and which document does.}
 
-## The shape
+## Why it exists
 
-{Optional. Where the machine has parts a reader must hold at once before any stage makes sense,
-name them in one table before the stages begin.}
+{Why this is one machine and not two, what it deliberately is not, the constraint that shaped it.}
 
-| Part | Where | What it holds |
-| --- | --- | --- |
-| {Entry} | `routes/{x}.ts` | {thin, tenancy first} |
-| {Ledger} | `{machine}/ledger.ts` | {the durable row} |
+## How it works
 
-## {Stage sections — one per stage, in the order the machine runs them}
+{The machine's behaviour from the outside, in the order it runs, in plain words: what starts it, what it does at each step as a person would describe it, what it writes that outlives it, what re-drives it, what it refuses. Terms of art introduced on first use. Code named only at a seam.}
 
-{The body, and the only genre where the section order is decided for you: the machine's own order.
-Entry, then each stage, then what is written durably, then what re-drives a stalled one, then what
-reads the result. Name each section for its stage in the product's own vocabulary. Within a
-section, state the mechanism and its reason: what the code does, what it refuses, and why it
-refuses that rather than something else. Tables for rosters (routes, columns, frames, states,
-bindings); prose for a rule and the defect it prevents. Never paste an implementation — a
-signature, a state list, a wire shape, a table's columns.}
+## What was decided
 
-## Tests
+{Themed paragraphs; alternatives named only where a reader would reach for them.}
 
-{Optional. What proves this machine, and what each suite pins — a `Suite | Pins` table. Include it
-where the machine has a suite of its own; omit the heading where the coverage lives in the package
-documents' suites.}
+## What it promises
 
-## Files
+{Checkable guarantees and refusals, grouped; what holds at the far end; what a stalled run gets.}
 
-| Path | Role |
-| --- | --- |
-| `packages/{pkg}/src/{machine}/{file}.ts` | {what it holds, by name — the exports a reader is looking for} |
+## Known gaps
 
-{One row per file this document owns — the roster is the `owns:` list, made readable. Close with
-the inverse: "Read here, owned elsewhere:" naming the paths the body describes but another document
-claims, each with the document that claims it. That closing line is what stops a system document
-from quietly annexing the code it reads.}
+{One paragraph, only when needed.}
 
-## Related
+## For the agent
 
-- [AD-0NN — {the ruling}](../decisions/AD-0NN-{slug}.md) — {the decision behind this shape, the options weighed}
-- [`{neighbour}.md`]({neighbour}.md) — {the machine on the other side of this seam}
-- [`{feature}.md`](../../features/{feature}.md) — {what a person sees of this machine}
-- [`{doctrine}.md`](../common/{doctrine}.md) — {the cross-cutting contract this machine answers to}
+Objects: {…}. Code roots {…} — directories, one per package the machine spans. Seams {…} by name. Checklist `tests/{system}.md`. See also {neighbour} ({why}). No tables, routes or symbol rosters — those are the graph's.
 ```
 
-### The boundary paragraph is the genre's load-bearing section
-
-Systems overlap: they share tables, call each other, and render into the same surfaces. Without a
-paragraph that names the seams, two system documents describe the same stage from two angles and
-drift apart on the first change — and a reader has no way to tell which is authoritative. So the
-boundary paragraph is not a courtesy list of related reading; it is the statement of what this
-document is *not*, written specifically enough that a later editor can tell where to put a fact.
-Write it as a list of subjects with their owners — "the coordinator's tables, alarm and drive claim
-are `harness.md`; a run's ledger row and settlement are `generation-runs.md`" — never as bare
-links.
-
 ### Marking what is decided and unbuilt
 
-Where the machine has a stage that is decided and not built — a predicate that selects but never
-acts, a column that is written and never read, a door with no caller — 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 function with no caller, the route that is not mounted,
-the value written and never read} -->
-{the prose describing the unbuilt stage, and what runs in its place}
-<!-- UNBUILT:END -->
-```
-
-**State what runs instead.** A machine with a hole in it still works somehow, and the workaround is
-the fact a reader needs. **A design decided *against* carries no marker** — a marker means the work
-is owed and absent, so using one for a rejected design turns the register of debt into a register
-of opinions.
-
-### `status: draft` on a system
-
-A system document is `draft` when the **machine as a whole** does not run — the code is on disk and
-nothing reaches it. Say so in the first section, in plain words, with the evidence: which halves
-exist, which do not, and what a reader who invokes it actually observes. A scoped gap in a working
-machine is not a draft: the document stays `active` and takes an UNBUILT marker at the stage that
-has the hole.
+Where a stage is decided and not built, wrap its prose in `<!-- UNBUILT:START — {what, where decided, the evidence it is not built} -->` … `<!-- UNBUILT:END -->` and say in What it promises what runs instead. A design decided *against* carries no marker.

package/data/harnesses/delivery/agents/lld-mode.md

@@ -21,7 +21,7 @@ Map the documentation landscape — what exists, what is adjacent, how detailed
 2. Locate the repo's feature-doc layer from `structure.md` — the standard shape is `./docs/features/`, but a repo may document components under their own subject folders. Read that layer's index if it has one; otherwise glob for docs carrying `owns:` frontmatter
 3. If `./docs/memory/lld-mode.md` exists (or the legacy `./docs/memory/spec-mode.md`), read it for feature doc inventory, ownership conflict zones, and lessons from previous research
 4. Read 1-2 existing feature LLDs from that layer to calibrate format and depth
-5. Consult the **injected ownership index** (the generated `glob → doc · module · keywords · status` map — the union of every feature doc's `owns:` frontmatter) to build the ownership map. It is the source of truth for what code paths are already owned. If the index isn't present in context, glob the docs tree (excluding `docs/history/`) and read the `owns:` frontmatter of every doc that declares it.
+5. Consult the **injected ownership index** (the generated `glob → doc · module · objects · status` map — the union of every feature doc's `owns:` frontmatter) to build the ownership map. It is the source of truth for what code paths are already owned. If the index isn't present in context, glob the docs tree (excluding `docs/history/`) and read the `owns:` frontmatter of every doc that declares it.
 
 ## What You Research