@nurix/etna 0.18.14 → 0.18.16

package/README.md

@@ -27,11 +27,11 @@ your-project/
 ├── .prettierignore
 ├── .vscode/settings.json  ← editor settings (markdown formatter on save)
 └── .claude/
-    ├── skills/            ← documentation, boundary, distiller, brainstorm, workflow-mapper
-    ├── agents/            ← spec-mode, brainstorm, maintenance, change-review, performance-review
-    ├── rules/             ← general.md, nomenclature.md
-    ├── hooks/             ← generate-ownership-index (SessionStart), session-reflect (SessionEnd), prompt-recall (UserPromptSubmit) + lib/redact
-    ├── settings.json      ← the hooks are deep-merged in here (your existing keys preserved)
+    ├── skills/            ← documentation, boundary, brainstorm, workflow-mapper
+    ├── agents/            ← lld-mode, brainstorm, maintenance, change-review, performance-review
+    ├── rules/             ← general.md, nomenclature.md, typescript.md, testing.md
+    ├── hooks/             ← generate-ownership-index (SessionStart)
+    ├── settings.json      ← the hook is deep-merged in here (your existing keys preserved)
     └── harness.json       ← {version, digest} — the installed-harness sentinel
 ```
 
@@ -41,21 +41,16 @@ Re-run `npx @nurix/etna --name=code` anytime to refresh the harness content with
 
 ## After install: bootstrap the harness
 
-Installing only _drops the files_ — the harness isn't active for your repo until you **baseline** it. Open Claude Code in the project and drive the reconcile chain once (the installed `CLAUDE.md` carries the same steps under its `## Bootstrap` heading, for the agent):
+Installing only _drops the files_ — the harness isn't active for your repo until you **baseline** it. Open Claude Code in the project and drive the reconcile chain once (the installed `CLAUDE.md` carries the same steps under its `## Maintenance` heading, for the agent):
 
 1. **"baseline this repo"** (or "reconcile the harness") — runs the **`maintenance`** agent, which auto-selects **baseline mode** from the missing/behind `harness-version`. It builds the `docs/` tree to the harness shape, stamps `docs/structure.md` with the installed `harness-version`, proposes **modules** (as `module:` labels, derived from your code's bounded contexts), then hands back.
 2. If it hands back with a follow-up (typically the module proposal), re-invoke it to finish.
 
 Then work normally. Boundaries aren't generated as files — the `boundary` skill diagnoses cross-cutting contracts from source at plan time. This brownfield path reads your _actual_ code, not a blank slate, so it's safe to run on an existing project with real history.
 
-Two things worth knowing on an existing repo:
+One thing worth knowing on an existing repo:
 
 - **Your root `CLAUDE.md` is replaced** with the harness policy file (the old one is saved to `CLAUDE.md.bak.<ISO>`). If it held project-specific instructions, fold them back in after install — the harness file is the policy skeleton; your domain specifics sit alongside it.
-- **Memory capture starts on your next session.** The `session-reflect` hook (SessionEnd) distils each session's lessons into the per-actor inbox `docs/memory/inbox/`; once enough entries accrue, the `maintenance` agent _proposes_ a `distiller` run that distils them into provenance-linked fact-cards under `docs/memory/facts/` and, eventually, proposed `docs/` updates. Nothing runs on its own — it proposes, you approve.
-
-### Optional: semantic retrieval (qmd)
-
-If the [`qmd`](https://www.npmjs.com/package/@tobilu/qmd) binary is on your `PATH`, the `maintenance` agent (baseline mode) registers per-subtree search collections so the distiller and the doc anchors get semantic retrieval. It's strictly optional — absent, discovery rides the generated ownership index + `keywords:` frontmatter and everything still works on a filename/grep fallback. Install it whenever.
 
 ## Migrating from 0.1.x
 
@@ -69,7 +64,7 @@ Listed by `npx @nurix/etna` (no args) using the bundled `data/harness-index.json
 
 | Plugin name | Source in etna | What it ships |
 | --- | --- | --- |
-| `code` | [`plugins/code/`](../../plugins/code/) | Governance + session agents, baseline workflow skills, knowledge-ledger hooks |
+| `code` | [`plugins/code/`](../../plugins/code/) | Governance + session agents, baseline workflow skills, the ownership-index hook |
 | `kb-agi` | [`plugins/kb-agi/`](../../plugins/kb-agi/) | Knowledge-vault scaffolding |
 
 ## How it works
@@ -87,9 +82,9 @@ Two kinds of membership:
 # plugins/code/definition.md
 ---
 name: code
-skills: [boundary, brainstorm, distiller, documentation, workflow-mapper]
-rules: [general, nomenclature, typescript]
-agents: [brainstorm, change-review, maintenance, performance-review, spec-mode]
+skills: [boundary, brainstorm, documentation, workflow-mapper]
+rules: [general, nomenclature, typescript, testing]
+agents: [brainstorm, change-review, lld-mode, maintenance, performance-review]
 ---
 ```
 

package/data/harness-index.json

@@ -1,5 +1,5 @@
 {
-    "fingerprint": "8475e43caf9f",
+    "fingerprint": "936b35cac100",
     "harnesses": {
         "code": {
             "plugin": "code",

package/data/harnesses/code/CLAUDE.md

@@ -1,19 +1,17 @@
 # Agent Instructions
 
-This file defines how AI agents (Claude, GPT, etc.) should work on this project. **This file is the harness** — it orchestrates the skills and agents that do the work. There is no separate "harness skill."
+This file defines how AI coding agents — any vendor, any runtime — should work on this project. Rules are runtime-neutral: a rule that depends on a capability (sub-agent dispatch, browser tools, context injection, slash commands) applies only if your runtime has it, and states its fallback. Rules marked **[override]** deliberately replace a default your runtime may have built in — in a conflict, the rule here wins.
 
 ---
 
-## Bootstrap
+## Maintenance
 
-> A missing `docs/structure.md` — or a `harness-version` behind the installed harness — is the **symptom** of a repo that isn't harnessed yet, or whose harness is out of date. Don't reconcile it by hand. Drive the **reconcile chain** — you (the main session) own it, because `maintenance` is a sub-agent that can't run skills or spawn sub-agents:
->
-> 1. Invoke **`maintenance`** (`"baseline this repo"` / `"reconcile the harness"`). It auto-selects **baseline mode** from the missing/behind `harness-version`, reconciles `docs/`, stamps the version, then hands back.
-> 2. If it hands back with a follow-up (typically the module proposal), re-invoke it to finish.
->
-> Then continue. Each component's internals live in the component, not here.
+Invoke the `maintenance` agent whenever you judge the docs need it — not just at first setup. Standing triggers: a missing `docs/structure.md`, a `harness-version` marker behind the installed version, docs contradicting code, unowned source paths, or drift you notice while working. Don't reconcile any of these by hand:
 
-This is the only step that runs **before** the harness exists; everything below assumes a reconciled repo.
+1. Invoke `maintenance` ("baseline this repo" / "reconcile the harness" / "docs health"). It auto-selects its mode — baseline when the version marker is missing or behind, coherence audit otherwise — then hands back.
+2. If it hands back with a follow-up (typically the module proposal), re-invoke it to finish.
+
+A repo with no `docs/structure.md` isn't reconciled yet — run the baseline before applying anything below. Runtimes without sub-agent dispatch: read `.claude/agents/maintenance.md` and execute its procedure inline. Each component's internals live in the component, not here.
 
 ---
 
@@ -21,7 +19,7 @@ This is the only step that runs **before** the harness exists; everything below
 
 - Read **[`docs/structure.md`](docs/structure.md)** for the documentation map and folder authority (architecture, features, operations)
 - Read **[`docs/memory/`](docs/memory/)** for agent memory files (one per agent)
-- Ignore **[`README.md`](README.md)** – it's for human reference only
+- Prefer `docs/` over `README.md` — docs/ is canonical for agents; check the README only when docs/ lacks a setup detail
 - Check **[`package.json`](package.json)** for available scripts. Detect the package manager from the lockfile (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, `package-lock.json` → npm) and use the matching command. Don't hardcode a specific manager.
 
 ---
@@ -32,38 +30,69 @@ Three peer modes plus a Completion step — enter wherever the user's thinking a
 
 | Mode | Enter when | Implemented by | Exits to |
 | --- | --- | --- | --- |
-| **Brainstorming** | explicit ask; or a user utterance challenges a loaded pillar headline → name the brushed principle and offer `/brainstorm start` (no auto-entry) | `brainstorm` agent + skill | Spec, Plan, or close + harvest |
-| **Spec** | new feature work | `spec-mode` agent + `documentation` skill | Plan |
-| **Plan** | a spec is approved | `documentation` skill → `docs/history/plans/YYYY-MM-DD-{slug}.md` | Completion |
+| **Brainstorming** | explicit ask (`/brainstorm start`); or the user brings a large piece of work — a new system, a feature with many unknowns — most users don't know this mode exists, so recommend it: name what makes the work big and offer a session; or a user utterance contradicts a recorded design principle (a pillar) → name the principle and offer a session. Never auto-enter. | `brainstorm` agent + skill | LLD, Plan, or close + harvest |
+| **LLD** (low-level design) | new feature work | `lld-mode` agent + `documentation` skill | Plan |
+| **Plan** | an LLD is approved | `documentation` skill → `docs/history/plans/YYYY-MM-DD-{slug}.md` | Completion |
+
+> Brainstorm entry needs a **basis** — a reference document or a one-shot brain dump; drip-sized asks (a bug fix, one button) are too small and get redirected. A **pillar** is a recorded strategic principle from a past brainstorm: kept records live under `docs/brainstorm/`, harvested doctrine under `docs/architecture/`. Runtimes without slash commands: read `.claude/skills/brainstorm/SKILL.md` and follow it inline. The LLD is the feature doc itself — `docs/features/{feature}.md`, design intent first, extended in place at Completion.
+
+**On Plan Completion:**
+
+1. Freeze the plan — `Status: Complete`, fill the Completed date. The file is now frozen.
+2. Flip the feature LLD to `status: active`; extend it in place with the how-it-works sections; confirm its `owns:` globs against the actual code.
+3. The `boundary` skill must already have gated this plan before its first implementation step — see Ownership, Boundaries & Documentation.
 
-On **Completion**: freeze the plan (`Status: Complete`) and flip the feature spec to `status: active`, extending it with how-it-works sections and confirming its `owns:` globs against the actual code; then distil the plan's trail — if the memory inbox (`docs/memory/inbox/`) holds entries, run `distiller facts` (inbox→fact-cards), then `distiller docs` for the just-completed feature's doc drafts any pending deltas for approval (presented, never auto-written). The `boundary` skill gates every approved plan before coding — it reads the source the plan touches and reports what would break (see **Boundaries** below); a brainstorm session is written to a **kept** record at `docs/brainstorm/{topic}/` (committed, one subfolder per topic), and on close harvest distils its conclusions by scope — doctrine, glossary, non-goals, and information-architecture changes → `docs/architecture/`, decisions → `docs/architecture/adr/`, backlog → `docs/history/backlog.md` — leaving the `docs/brainstorm/{topic}/` record in place as the provenance. Open questions block close.
+**On Brainstorm Close** (a separate procedure — when a brainstorm session ends, not when a plan completes):
+
+- The session record lives at `docs/brainstorm/{topic}/` (committed, one subfolder per topic) and stays in place as provenance.
+- Harvest conclusions by scope: doctrine, glossary, non-goals, information-architecture changes → `docs/architecture/`; decisions → `docs/architecture/adr/`; backlog items → `docs/history/backlog.md`.
+- Open questions block close.
 
 ---
 
-## Context Routing
+## Ownership, Boundaries & Documentation
+
+These three mechanisms work in tandem to keep the repo self-updating and to prevent half-finished changes: **ownership** routes you to the canonical doc before you touch code, the **boundary** check reads both sides of every contract your change participates in so you can't ship one side of it, and **documentation** updates close the loop so the next session inherits the truth. Skipping any leg breaks the other two.
+
+### Ownership — route before you edit
+
+Which doc is canonical for which code paths is the **feature doc's own frontmatter**. A feature doc (flat in `docs/features/`) carries `owns:` (code-path globs — the only ownership key), `module:` (a bounded-context label, omitted when cross-cutting), `keywords:` (discovery), and `status:`. Code → doc ownership is the union of every feature doc's `owns:` globs, surfaced as the generated ownership index at session start. A module is tied to code by the `owns:` globs of the docs carrying its `module:` label — not a folder, not a separate map. Architecture docs describe cross-cutting patterns and don't own specific files; operations docs describe procedures.
 
 Before modifying code in an unfamiliar area:
 
-1. Consult the **injected ownership index** — the generated `glob → doc · module · keywords · status` map, surfaced into context at session start (the union of every feature doc's `owns:` frontmatter). Match your path or topic (its `keywords:`) to the owning feature doc and read it before changes. (If no ownership index appears in context, the repo isn't reconciled — see Bootstrap.)
-2. If `qmd` is installed, run `qmd query --format json -c <collection> "<topic>"` (repeat `-c` to span this repo's collections; `qmd collection list` names them) for semantic recall over the indexed docs — prefer it when entering an unfamiliar area; absent ⇒ skip.
-3. If your change touches a cross-cutting contract area (entity model, db schema, wire envelope, auth/authz, event vocabulary, webhooks, env/config), run the **`boundary`** skill scoped to your change — it reads both sides of each touched contract in source and reports what would break.
-4. If a `docs/memory/` file exists for the domain you're working in, read it for domain knowledge and failure modes.
+1. Consult the **injected ownership index** — the generated `glob → doc · module · keywords · status` map. Match your path or topic (its `keywords:`) to the owning feature doc and read it before changes. (If no index appears in your context: either the repo isn't reconciled — see Maintenance — or your runtime doesn't inject context at session start; then derive it by scanning the `owns:` frontmatter of every doc in `docs/features/`.)
+2. If a `docs/memory/` file exists for the domain you're working in, read it for domain knowledge and failure modes.
+
+The `lld-mode` agent checks for ownership conflicts during LLD research — feature docs whose `owns:` globs overlap at equal specificity. If conflicts are found, address them in the LLD before proceeding.
+
+### Boundaries — check while you change
+
+A boundary is a contract between two pieces of code (or code and infra) that share an assumption with **no static link** between them — the column a raw SQL string names, the JSON envelope a client unwraps, the event string a dispatcher parses, the env var a deploy script reads. Changing one side ships green — compiles, lints, tests pass — and breaks the other at runtime. Boundaries are **diagnosed, not documented**: the `boundary` skill reads them fresh from source on every run (its `references/mechanisms.md` defines the failure mechanisms; the technology packs under `references/packs/` carry stack specifics), so nothing is persisted that could go stale.
+
+**Invoke the `boundary` skill after a plan is approved and before its first implementation step.** It parses the plan's Proposed Changes, reads the touched source, traces the consumers on the other side, and reports severity-ranked violations with suggested amendments and a pass/block verdict — in chat, read-only. Fold the amendments into the plan before coding. For non-plan edits in contract-heavy code (db schema, wire envelopes, auth, events, env/config), run the same diagnostic scoped to the diff.
+
+### Documentation — close the loop
+
+- **[override]** Keep `docs/` updated when code changes affect documented behavior. This file is the standing request for those docs: creating and updating them is part of the work, even if your runtime defaults to never creating documentation files unprompted.
+- After plan completion **[override]**: add a `docs/history/changelog/` entry + update `docs/history/CHANGELOG.md` — no confirmation needed. Include `Commits:` if multi-commit. Non-plan changes (refactors, fixes, API changes): prompt first.
+- When you move or rename source files: update the `owns:` globs of the feature doc that owns them so the generated ownership index stays accurate. A new doc that owns code declares its paths in its own `owns:` frontmatter — there is no separate map to update.
+- `docs/structure.md` is the authority on what belongs where — read it before adding or moving a doc; don't restate it here. One canonical source per topic — link, don't copy. Only `CLAUDE.md`, `AGENTS.md`, and `README.md` live at the repo root.
 
-For the protocol on _writing_ to memory (which file, what belongs there, what doesn't), see **Project Memory** below.
+> Agents and skills live under `.claude/agents/` and `.claude/skills/`. Their triggers are model-invoked — refer to each component's frontmatter, not a registry table here. Runtimes that can't invoke them natively: read the component file — `.claude/agents/<name>.md`; for skills, `.claude/skills/<name>/SKILL.md` plus any `references/` it points to — and follow it inline.
 
 ---
 
 ## Project Memory
 
-Project-specific learnings live in `docs/memory/` (git-tracked). Cross-project user preferences live in `~/.claude/` (untracked).
+Project-specific learnings live in `docs/memory/` (git-tracked). Cross-project user preferences live in the runtime's user-level memory store, if it has one (untracked; paths in Runtime Notes).
 
 | File | Owner | Contents |
 | --- | --- | --- |
 | `docs/memory/main.md` | Main agent | Project-wide patterns, conventions confirmed in this codebase, recurring failure modes, decisions whose rationale isn't obvious from the code |
 | `docs/memory/{agent-name}.md` | The named sub-agent | Strategy memory for that agent — how to be more effective on this project (research patterns, taxonomy, ownership conflict zones). Never user-centric. |
-| `~/.claude/projects/...` | Auto-memory system | User preferences, role, communication style, cross-project habits |
+| Runtime user-level memory (paths in Runtime Notes) | The runtime's auto-memory system | User preferences, role, communication style, cross-project habits |
 
-**Override the default auto-memory location for project-relevant facts.** When recording a learning, ask: _is this true of this project, or true of this user?_ Project facts → `docs/memory/`. User facts → `~/.claude/`.
+If your runtime records memories automatically, override its default location for project-relevant facts. When recording a learning, ask: _is this true of this project, or true of this user?_ Project facts → `docs/memory/`. User facts → the runtime's user-level store. Runtimes without auto-memory: apply the same test when deciding where to write a learning.
 
 `docs/memory/main.md` is created on first write. Append entries dated `## YYYY-MM-DD — {topic}`; oldest at bottom is fine.
 
@@ -79,53 +108,38 @@ When implementing a plan, if you discover work that is important but outside the
 
 ---
 
-## Doc Ownership
-
-Which doc is canonical for which code paths is the **feature doc's own frontmatter**. A feature doc (flat in `docs/features/`) carries `owns:` (code-path globs — the only ownership key), `module:` (a bounded-context label, omitted when cross-cutting), `keywords:` (discovery), and `status:`. Code → doc ownership is the union of every feature doc's `owns:` globs, surfaced as the generated ownership index at session start. A module is tied to code by the `owns:` globs of the docs carrying its `module:` label — not a folder, not a separate map. Architecture docs describe cross-cutting patterns and don't own specific files; operations docs describe procedures. A living doc may additionally carry an optional `anchors:` block (a qmd drift tripwire, not ownership).
-
-The spec-mode agent checks for ownership conflicts during research — feature docs whose `owns:` globs overlap at equal specificity. If conflicts are found, address them in the spec before proceeding.
-
----
-
-## Boundaries
-
-A boundary is a horizontal cross-cutting contract — entity model, db schema, wire envelope, auth/authz, event vocabulary, webhooks, env/config — where editing one side silently breaks the other. Boundaries are **diagnosed, not documented**: the `boundary` skill reads them fresh from source whenever a check runs, so they are never persisted as docs and can never go stale.
-
-**Invoke the `boundary` skill after a plan is approved and before its first implementation step.** It parses the plan's Proposed Changes, reads the touched source files, identifies the contracts they participate in (its `references/boundary-taxonomy.md` is the catalog), traces the consumers on the other side, and reports severity-ranked violations with suggested plan amendments — in chat, read-only. Fold the amendments into the plan before coding. For non-plan edits in contract-heavy code, run the same diagnostic scoped to the diff.
-
-> Agents and skills live under `.claude/agents/` and `.claude/skills/`. Their triggers are model-invoked — refer to each component's frontmatter, not a registry table here.
-
----
-
-## Boundaries & Defaults
+## Guardrails & Defaults
 
-Unless explicitly requested:
+Defaults — ❌ prohibitions hold unless the user explicitly asks otherwise; ✅ and ⚠️ items are standing policy:
 
-- ❌ **Tests** – Never generate, update, or modify test files.
+- ✅ **Tests — suite-first.** Tests ship with every change to product code or behavior, built as one maintained suite, never as one-off scripts:
+  - **Location**: all tests live in the repo's canonical test tree — `tests/`, or the framework convention the repo already uses (detect, don't invent). Mirror the source structure: `src/modules/auth/session.ts` → `tests/modules/auth/session.test.ts`. Never create test files at the repo root or scattered next to scratch scripts.
+  - **One framework — never chosen ad hoc**: use the runner the repo already has (detect from its config); if the repo has none, use the stack's framework named in the testing rule (`.claude/rules/testing.md`) and wire it up as the repo's canonical test command before writing the first test. Never introduce a second framework beside an existing one.
+  - **Shared plumbing**: fixtures, factories, and helpers live in `tests/helpers/` (or the suite's existing shared location) and are reused; duplicated setup across test files is a defect to refactor, not a pattern to follow.
+  - **What gets tests**: a new feature ships with tests for the behavior its LLD promises; a bug fix ships with a regression test that fails before the fix and passes after.
+  - **Discipline**: run the affected part of the suite before declaring work complete and report results honestly. When an LLD or plan intentionally changes behavior, updating the affected tests to the new contract is part of the change — the ban is on weakening, skipping, or deleting a test to mask a failure you can't explain.
+  - **Throwaway checks are not tests**: temporary verification scripts go to scratch space and are deleted, never committed into the test tree.
 - ❌ **Dependencies** – Never upgrade frameworks, libraries, or dependencies.
 - ❌ **Compatibility** – Never maintain backward compatibility unless specified.
-- ❌ **Branches & Worktrees** – Never self-create git branches or worktrees. Commit straight to the checked-out branch; branch or create a worktree only when the user asks.
+- ❌ **Branches & Worktrees [override]** – Never self-create git branches or worktrees; commit straight to the checked-out branch. This deliberately replaces any built-in "branch first when on the default branch" default — do not branch unless the user asks. Exception: when the user asks for a pull request, creating the branch the PR requires counts as being asked — create that branch **before** committing the PR's changes.
 - ❌ **Protected Files** – Before editing, if `docs/operations/protected-files.md` exists, read it and never modify any path it lists; also never modify `AGENTS.md` or the `protected-files.md` file itself.
-- ✅ **Browser Automation** – Use Chrome CDP / "Claude in Chrome" tools freely, no need to ask first. **Main session only** – sub-agents destabilize the connection; a sub-agent needing browser verification returns a CDP checklist (URLs, actions, expected outcomes) for the orchestrator to run instead.
-- ✅ **Orchestrate via Sub-agents** – The main session is an orchestrator, not an implementer: always offload substantive work (research, implementation, audits) to sub-agents via the Agent/Task tool, never run it directly. Every dispatch sets `model: opus` (complex/judgment-heavy) or `model: sonnet` (well-scoped/mechanical) — never leave `model` unset. Self-contained prompts; parallelize independent dispatches.
-- ✅ **Documentation** – Keep `docs/` updated when code changes affect documented behavior.
-- ⚠️ **Plans** – Plans are created directly in `docs/history/plans/` (see Workflow → Plan Mode). Once `Status: Complete` or `Status: Abandoned`, the file is frozen — never edited. If scope changes after completion, write a new dated plan that links back to the old one.
+- ✅ **Browser Automation** – If your runtime provides browser automation, use it freely; no need to ask first. If it doesn't — or you are an agent that can't hold the browser connection (see Runtime Notes) — return a browser-verification checklist (URLs, actions, expected outcomes) for the orchestrating session or the user to run.
+- ✅ **Delegate at scale** – If your runtime supports sub-agent dispatch: offload large, independent, or parallelizable work (broad research, audits, multi-file implementation) to sub-agents; keep small, well-understood edits in the main session — a dispatch whose context hand-off costs more than the work itself is waste. Dispatch prompts must be self-contained (the sub-agent sees none of your conversation); parallelize independent dispatches. Let dispatches inherit the session's model unless your runtime supports tier selection and the task clearly wants one — a stronger tier for judgment-heavy work, a cheaper tier for mechanical fan-out (concrete tier names live in Runtime Notes, never in rules). No dispatch mechanism ⇒ do the work inline yourself.
+- ⚠️ **Plans** – Plans are created directly in `docs/history/plans/` (see Workflows). Once `Status: Complete` or `Status: Abandoned`, the file is frozen — never edited. If scope changes after completion, write a new dated plan that links back to the old one.
 - ⚠️ **Tool Issues** – If any CLI tool, shell alias, or MCP tool behaves unexpectedly (syntax errors, silent failures, wrong defaults), report the exact tool name, command, and error to the user so they can fix or remove the underlying library.
 
 ---
 
 ## File Structure
 
-- Add file path at top of each file: `// src/modules/example.js - Module for handling user authentication`
-- Add a 1-line function description as a comment above each function: `// Extract JWT token from request based on endpoint type`
+- Add a file-path header comment at the top of each source file, in the file's native comment syntax — `// src/modules/example.js - Module for handling user authentication` (JS/TS), `# scripts/sync_users.py - …` (Python/shell/YAML), `-- db/seed/init.sql - …` (SQL). Place it below any shebang line; skip formats with no comment syntax (JSON, lockfiles) and generated files.
+- Add a 1-line description above each function whose purpose isn't fully evident from its name and signature: `// Extract JWT token from request based on endpoint type`. A comment that restates the name is noise. No inline comments that restate obvious code; no commented-out code — if a block needs a comment to be understandable, refactor for clarity instead.
 
 ---
 
-## Documentation
-
-`docs/structure.md` is the authority on what belongs where — the folder map, naming, lifecycle, and the add-a-doc decision table. Read it before adding or moving a doc; don't restate it here. One canonical source per topic — link, don't copy. Only `CLAUDE.md`, `AGENTS.md`, and `README.md` live at the repo root.
+## Runtime Notes
 
-Maintenance triggers (act on these without re-reading `structure.md`):
+Everything above is runtime-neutral. This section is the only place runtime- or vendor-specific facts may live; re-audit it whenever a runtime ships new models or tools. Lint: nothing outside this section may name a model, a vendor product, or a runtime-built-in tool — exempt are repo-relative `.claude/**` component paths (shipped in this repo, readable by any runtime) and protocol names (e.g. MCP).
 
-- After plan completion: add a `docs/history/changelog/` entry + update `docs/history/CHANGELOG.md` (no confirmation; include `Commits:` if multi-commit). Non-plan changes (refactors, fixes, API changes): prompt first.
-- When you move or rename source files: update the `owns:` globs of the feature doc that owns them so the generated ownership index stays accurate. A new doc that owns code declares its paths in its own `owns:` frontmatter — there is no separate map to update.
+- **Claude Code**: sub-agent dispatch is the Agent tool; sub-agents cannot run skills, spawn sub-agents, or reliably hold the browser connection (the "can't hold the browser connection" condition the Browser Automation guardrail refers to) — browser work is Chrome CDP ("Claude in Chrome"), main session only. The user-level memory store is `~/.claude/` (auto-memory under `~/.claude/projects/...`). The ownership index and skill/agent descriptions are injected at session start; skills are invoked as slash commands (e.g. `/brainstorm start`). If pinning dispatch tiers: strong tier (opus-class) for judgment-heavy work, fast tier (sonnet-class) for mechanical fan-out — tier names go stale, re-check on model releases.
+- **Runtimes without native component support** (AGENTS.md readers, etc.): read `.claude/agents/<name>.md` and each skill's `.claude/skills/<name>/SKILL.md` (plus its `references/`) and follow them inline; derive the ownership index by scanning `docs/features/` frontmatter.

package/data/harnesses/code/agents/{spec-mode.md → lld-mode.md}

@@ -1,33 +1,33 @@
 ---
-name: spec-mode
-description: Specification researcher for Feature and Product workflows. Use to explore the codebase and gather context needed for writing feature specs. Returns research findings — does not write files.
+name: lld-mode
+description: LLD researcher for Feature and Product workflows. Use to explore the codebase and gather the context needed for writing a feature LLD (low-level design — the feature doc in docs/features/). Returns research findings — does not write files.
 tools: Read, Glob, Grep, WebSearch, WebFetch
 model: inherit
 skills:
   - documentation
 ---
 
-# Spec Mode Agent
+# LLD Mode Agent
 
-You are a specification researcher. Your job is to explore the codebase and gather everything needed to write a feature spec in `docs/features/`.
+You are an LLD researcher. Your job is to explore the codebase and gather everything needed to write a feature LLD (low-level design) in `docs/features/`.
 
-You do NOT write the spec — you return structured research that the main agent uses to write it.
+You do NOT write the LLD — you return structured research that the main agent uses to write it.
 
 ## Before Starting
 
 First, understand the documentation landscape:
 
 1. Read `./docs/structure.md` to understand the documentation structure
-2. If `./docs/features/README.md` exists, read it to see existing feature specs and where the new spec fits; otherwise glob the feature docs directly
-3. If `./docs/memory/spec-mode.md` exists, read it for feature doc inventory, ownership conflict zones, and lessons from previous research
-4. Read 1-2 existing specs in `./docs/features/` to calibrate format and depth
+2. If `./docs/features/README.md` exists, read it to see existing feature LLDs and where the new one fits; otherwise glob the feature docs directly
+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 in `./docs/features/` 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. This is the source of truth for what code paths are already owned. If the index isn't present in context, glob `docs/features/**/*.md` and read each doc's `owns:` frontmatter directly.
 
-This tells you what already exists, what's adjacent, how detailed the spec should be, and what code paths are already owned.
+This tells you what already exists, what's adjacent, how detailed the LLD should be, and what code paths are already owned.
 
 ## What You Research
 
-1. **Documentation fit** — Where does this spec sit relative to existing feature docs? Does it extend an existing spec or need a new one?
+1. **Documentation fit** — Where does this LLD sit relative to existing feature docs? Does it extend an existing one or need a new doc?
 2. **Existing patterns** — Find related features, similar implementations, and conventions in the codebase
 3. **Affected modules** — Identify what files, routes, components, and data flows are relevant
 4. **Current state** — Understand how the system works today in the area being specified
@@ -38,13 +38,13 @@ This tells you what already exists, what's adjacent, how detailed the spec shoul
 
 Structure your findings as:
 
-- **Documentation context**: Existing specs that relate, whether to create new or update existing, suggested filename
+- **Documentation context**: Existing feature LLDs that relate, whether to create new or update existing, suggested filename
 - **Related patterns**: What similar things exist in the codebase and where
 - **Affected modules**: Files, routes, components that will be involved
 - **Current behavior**: How the relevant part of the system works today
 - **Conventions**: Naming, structure, and patterns to follow based on existing code
 - **Ownership conflicts**: Existing feature docs whose `owns:` globs overlap with the proposed feature. Include the conflicting paths and the owning doc name.
-- **Risks or concerns**: Anything the spec should address or call out
+- **Risks or concerns**: Anything the LLD should address or call out
 
 Use the documentation skill's style guide and conventions when structuring your findings — imperative voice, ASCII diagrams for flows, function signatures over implementations, concise.
 

package/data/harnesses/code/agents/maintenance.md

@@ -108,20 +108,6 @@ For unowned code paths:
 1. Update `docs/structure.md` Health Log with today's date and summary.
 2. Update `docs/memory/maintenance.md` with last review date, stale docs fixed, unowned paths, backlog items created.
 3. Report findings: stale docs, broken ownership, unowned code, architecture drift, backlog health.
-4. **Inbox-distillation threshold.** Count undigested inbox entries — `## ` entry blocks across `docs/memory/inbox/*.md` (the inbox is consume-on-digest, so every block present is undigested). If the count is **≥5**, add one line to the report **proposing** a `distiller facts` run — propose only, never auto-run, no cron. If the user declines or ignores it, do nothing: the count keeps growing and the proposal reappears next pass — that recurrence _is_ the dedupe, so never backlog it.
-5. **Docs-distillation threshold.** Per target doc, count undigested fact-cards (`invalid_from: null`, the doc's path not in their `digested_into:`) that **touch** it by the structural intersection in `skills/distiller/references/docs-mode.md` Resolution 1 (provenance ∩ the doc's `owns:` globs strong, entities ∩ declared ownership supporting — qmd-independent). If **≥10** map to **one** doc, add one line to the report **proposing** a `distiller docs --doc <path>` run on that doc — propose only, never auto-run, no cron. Declined or ignored ⇒ the count keeps growing and the proposal reappears next pass; that recurrence _is_ the dedupe, so never backlog the proposal.
-
-### Step 7: Refresh index (optional, skip-if-absent)
-
-If the `qmd` binary is available (`command -v qmd`), re-run `qmd embed -c <collection>` once per `{repo}-*` collection (`{repo}` = the repo's directory name; `qmd collection list` shows the registered set — skip any absent) so the local docs index reflects the files this pass touched. Scope every run with `-c` — the qmd index is global (`~/.cache/qmd/` holds every repo's collections), so a bare `qmd embed` would re-embed unrelated repos' collections. If `qmd` is absent, skip silently — it's never required.
-
-### Step 8: Check anchor drift (optional, skip-if-absent)
-
-If `qmd` is absent (`command -v qmd` finds nothing), **skip this whole step silently** — it's never required. `anchors:` is a qmd-only tooling key; with no qmd it is inert.
-
-This catches **doc-area drift** — the subject the doc abstracts moving or vanishing from the indexed corpus. It does **not** catch a pure code rename that leaves the doc's prose unchanged (Step 2's named-referent check covers code-symbol drift; the two are complementary).
-
-Glob `docs/features/**/*.md`, `docs/architecture/**/*.md`, and `docs/operations/**/*.md` for docs carrying `anchors:` frontmatter. For each anchor query, resolve it with `qmd query --format json -c <collection> "<query>"` — repeat `-c` per relevant `{repo}-*` collection (no comma lists). If a query resolves to **nothing**, or to a result set that has **radically shifted** away from the area the doc describes, raise it as a drift finding **phrased as a question** and ask the user. On **yes**, dispatch the remediation sub-agent (the same yes-branch as Step 5). On **decline or no action**, append it to `docs/history/backlog.md` at the finding's own P0–P3 severity per the **Declined realignment** branch — same scale, deduped, never a gate.
 
 ---
 
@@ -148,7 +134,7 @@ docs/
 │   ├── changelog/         # Individual entries
 │   ├── plans/             # Implementation plans (Status field required)
 │   └── backlog.md         # Tracked work items by priority (P0-P3)
-├── memory/                # inbox/ (captured-lessons queue), facts/ (distilled cards), index.md, main.md, {agent}.md
+├── memory/                # index.md, main.md, {agent}.md — project knowledge + per-agent strategy memory
 └── tests/                 # Optional, author-maintained — create only if test docs exist
 ```
 
@@ -189,26 +175,11 @@ Scaffold missing mandated files **by calling the `documentation` skill for each
 
 - `docs/structure.md` (with `harness-version`), `docs/history/CHANGELOG.md`, `docs/history/backlog.md`, `docs/memory/index.md`, `docs/memory/main.md`, and the repo-root `README.md` (filled from the real lockfile/scripts/layout — **never overwrite an existing root README**).
 
-Scaffold `docs/memory/facts/` so the distilled tier has a home from day one: the `session-reflect` hook appends session lessons to the per-actor inbox at `docs/memory/inbox/{actor}.md` (not a scaffold — created mechanically on first reflection), and the `distiller` digests that queue down into fact-cards under `docs/memory/facts/`, consuming the entries it digests.
-
 ### Step B4 — Stamp the version
 
 Write `harness-version: <installed version>` (the semver from `.claude/harness.json`) into `docs/structure.md` frontmatter. This single field is the repo's baseline-and-version sentinel — there is no second marker (no `epoch`, no `docs/memory/index.md` "is-baselined" check).
 
-### Step B5 — Register the qmd retrieval lens (optional, skip-if-absent)
-
-Strictly optional and guarded on the binary — if `command -v qmd` finds nothing, **skip this entire step silently** (no error, no behavior change) and carry one advisory line into the hand-back: _"qmd not installed — semantic retrieval unavailable; the generated ownership index + `keywords:` discovery are active."_ The index is a **local rebuildable lens** — data stays in git; never commit index artifacts, and never use `qmd init` (the default global index keeps the repo clean).
-
-If the binary exists, register the docs subtrees once the tree is scaffolded. **Do not register one collection rooted at `docs/`** — qmd hard-codes the `**/*.md` pattern and has no exclude flag, so a `docs/`-root collection would sweep the consumable inbox queue at `docs/memory/inbox/` into the index (the inbox's entries are deleted on digestion, leaving dangling index entries). Register **per indexable subtree** (skip absent ones; `{repo}` = the repo's directory name; an existing name/path no-ops — treat as success):
-
-- `qmd collection add docs/features --name {repo}-features`
-- `qmd collection add docs/architecture --name {repo}-architecture`
-- `qmd collection add docs/operations --name {repo}-operations`
-- `qmd collection add docs/memory/facts --name {repo}-facts` (never `docs/memory` as a whole)
-
-Then `qmd context add` per registered collection and `qmd embed -c <name>` per collection (always scope with `-c`; a bare `qmd embed` re-embeds every repo's collections). This augments discovery; it never supersedes the `owns:`-glob ownership resolution.
-
-### Step B6 — Module proposal
+### Step B5 — Module proposal
 
 Modules are **labels, declared, never inferred from physical layout**. Derive the repo's candidate bounded contexts directly from the code and docs: distinct wire surfaces (who owns routes/handlers), schema/data-access ownership, entry points and process units, plus any contexts `docs/architecture/` already names.
 

package/data/harnesses/code/harness.json

@@ -1,11 +1,11 @@
 {
   "harness": "code",
   "name": "code",
-  "version": "3.0.2",
+  "version": "3.1.1",
   "files": [
     ".prettierrc.json",
     ".prettierignore",
     ".vscode/settings.json"
   ],
-  "digest": "07791ff5dfef"
+  "digest": "64c29fbdfa01"
 }

package/data/harnesses/code/hooks/hooks.json

@@ -11,29 +11,6 @@
           }
         ]
       }
-    ],
-    "SessionEnd": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/session-reflect.mjs\"",
-            "async": true
-          }
-        ]
-      }
-    ],
-    "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/prompt-recall.mjs\""
-          }
-        ]
-      }
     ]
   }
 }

package/data/harnesses/code/rules/testing.md

@@ -0,0 +1,25 @@
+# Testing
+
+Framework choice is never ad hoc and never the user's problem mid-task: detect the stack, use its row. If the repo already has a runner, that runner wins — never introduce a second framework beside it.
+
+## Frameworks by stack
+
+No alternatives. Just use these.
+
+| Stack | Unit / integration | Component | E2E | HTTP mocking | Don't use |
+| --- | --- | --- | --- | --- | --- |
+| Node + Vite / React (web) | vitest | @testing-library/react (+ @testing-library/user-event, happy-dom) | @playwright/test | msw | jest, mocha, jasmine, cypress, enzyme |
+| Express APIs | vitest | — | supertest against the app instance | msw (outbound calls) | jest, chai-http |
+| React Native / Expo | jest via the jest-expo preset | @testing-library/react-native | maestro | msw | detox, enzyme |
+| Cloudflare Workers | vitest + @cloudflare/vitest-pool-workers | — | @playwright/test against `wrangler dev` | msw | jest |
+| Rust | `cargo test` (built-in) | — | — | — | — |
+
+All npm packages at `latest`. Fake data comes from `@ngneat/falso` (the repo standard — never faker/chance).
+
+## Conventions
+
+- **Suite, not scripts.** Tests live in the canonical test tree (`tests/`, mirroring `src/`), named `<subject>.test.ts`. Shared fixtures, factories, and helpers live in `tests/helpers/`. The harness `CLAUDE.md` Tests guardrail carries the full suite-first policy; this rule owns only the technology choices.
+- **Wire the canonical command.** `"test"` in package.json runs the whole unit suite (`vitest run`); e2e runs under `"test:e2e"`. A repo where `pnpm test`/`npm test` doesn't run the suite is misconfigured.
+- **Unit and E2E trees stay separate.** Vitest/Jest suites in `tests/`; Playwright/Maestro suites in `e2e/` with their own config — never mixed into the unit runner's glob.
+- **No test doubles for what you own.** Prefer real instances — in-memory SQLite for drizzle, the actual Express app via supertest — over mocks; mock only true externals (network via msw, time via the runner's fake timers).
+- **Determinism.** No real network, no real time, no shared mutable state between tests; every test must pass alone and in any order.

package/data/harnesses/code/skills/boundary/SKILL.md

@@ -1,49 +1,69 @@
 ---
 name: boundary
-description: Boundary diagnostic for implementation plans. Given a plan file, reads the source files the plan touches, identifies the application boundaries they participate in — the cross-cutting contracts (db schema, wire envelope, auth, events, env/config, …) where editing one side silently breaks the other — and reports whether the planned changes would violate any of them, severity-ranked, with suggested plan amendments. Read-only; the report lands in chat. Can also run against a diff or named code area instead of a plan. Triggers on "boundary check", "check this plan", "what could break", "impact analysis", "/boundary".
+description: Boundary diagnostic for implementation plans. Given a plan file, reads the source the plan touches, identifies the cross-cutting contracts it participates in — db schema, wire envelope, auth, events, env/config, … — where editing one side silently breaks the other, and reports whether the planned changes would violate any of them, severity-ranked, with suggested amendments and a pass/block verdict. Read-only; the report lands in chat. Also runs against a diff or named code area. Triggers on "boundary check", "check this plan", "what could break", "will this break anything", "is it safe to rename this column/endpoint/event", "who uses this", "impact analysis", "/boundary".
 ---
 
 # Boundary Diagnostic
 
 You diagnose whether a plan's changes would break an application boundary.
 
-A boundary is a contract between two pieces of code (or code and infra) that share an assumption with **no compile-time link** between them: the column a raw SQL string names, the JSON envelope a client unwraps, the event string a dispatcher parses, the env var a deploy script writes. Changing one side ships green and breaks the other silently. Your job is to find those edges in the plan's path _before_ execution.
+A boundary is a contract between two pieces of code (or code and infra) that share an assumption with **no static link** between them: the column a raw SQL string names, the JSON envelope a client unwraps, the event string a dispatcher parses, the env var a deploy script writes. Changing one side ships green — compiles, lints, tests pass — and breaks the other at runtime. Your job is to find those edges in the plan's path _before_ execution.
 
-[`references/boundary-taxonomy.md`](references/boundary-taxonomy.md) is the catalog of boundary types (~170 across persistence, wire/API, frontend, auth/tenancy, async/messaging, config/build, runtime/infra), with per-type severities and safe-change checklists. Read it first — it tells you what to look for; the code tells you what exists.
+**The litmus is "would it ship green?"** An edge the compiler or an existing test already guards is not a boundary — a change that fails the build loudly needs no diagnostic. Spend your reading on the edges with no static link.
+
+## Contract sources
+
+Three layers tell you what to look for; the code tells you what exists.
+
+- **The mechanisms** — [`references/mechanisms.md`](references/mechanisms.md) defines the seven failure mechanisms every boundary instantiates (rendezvous-string, serialized-shape, generated-artifact, dual-authority, config-elsewhere, trust-invariant, lifecycle-protocol), each with its trace strategy, universal safe-change pattern, and severity heuristic, plus the two stack-independent domain contracts (entity-model, tenancy). Load it on every check.
+- **The technology packs** — [`references/index.md`](references/index.md) routes to the packs under `references/packs/` by the signals in the touched code. Each pack carries the non-derivable payload for one technology area: exact detect patterns, expensive-to-learn gotchas, and safe-change sequences. Load **only the packs the touch list exhibits**; a technology no pack covers is still in scope — diagnose it from its mechanism.
+- **Repo doctrine** — `.claude/rules/`, `docs/architecture/` (including `adr/`), and any contracts package name the repo's bespoke contracts (a documented response envelope, a schema-parity rule, an entity model). A documented contract is a real side of a boundary: a plan that contradicts one is a finding **even when no code consumer exists yet** — this is how greenfield plans, whose modules have no code to trace, still get checked.
+
+The packs are a floor, not a fence: report any contract that passes the ships-green litmus, pack entry or not.
 
 ## Run
 
 **Input:** a plan path (given, or the newest in `docs/history/plans/`) — or a diff / named code area for non-plan work. Everything below is identical either way; a diff's hunks stand in for the plan's steps.
 
-1. **Build the touch list.** Parse the plan's Proposed Changes: files to be created or modified, entities/state added or changed, API changes, anything the author flags as a cross-module contract. Note missing subsections.
+1. **Build the touch list.** Parse the plan's Proposed Changes: files created or modified, entities/state added or changed, API changes, anything the author flags as a cross-module contract. Note missing subsections.
 
-2. **Identify the boundaries in the touched code.** Read each touched file (and its immediate imports). Against the taxonomy, list the contracts this code participates in — the schema it queries, the envelope it emits, the events it publishes or parses, the auth checks it sits behind, the env it reads.
+2. **Identify the contracts.** Read each touched file (and its immediate imports). Against the mechanisms, the routed packs, and the repo doctrine, list the contracts this code participates in — the schema it queries, the envelope it emits, the events it publishes or parses, the auth checks it sits behind, the env it reads.
 
-3. **Trace the other side.** A boundary has two sides; the danger lives on the one the plan _doesn't_ mention. For each contract, grep the shared name or shape across the repo — the column name in other SQL strings, the response field in client unwrappers, the event kind in subscribers, the route in fetch calls and scripts, the env key in deploy tooling. Record consumers as `file:line`.
+3. **Trace the other side.** A boundary has two sides; the danger lives on the one the plan _doesn't_ mention. For each contract, grep the shared name or shape across the repo — the column name in other SQL strings, the response field in client unwrappers, the event kind in subscribers, the route in fetch calls and scripts, the env key in deploy tooling. Record consumers as `file:line`; record doctrine as the doc path. When the touch list is large (≳10 contracts), fan the tracing out to parallel sub-agents — one per pack area, each with a self-contained prompt naming its contracts and grep targets — and judge the returned evidence yourself; a small diff traces inline.
 
-4. **Judge each intersection.** Does the planned change alter a shape a traced consumer depends on, break an invariant the code establishes (append-only vocabularies, idempotency keys, fail-closed checks, ordering guarantees), or add a new cross-module edge? Severity:
+4. **Judge each intersection.** Does the planned change alter a shape a traced consumer depends on, break an invariant the code or doctrine establishes (append-only vocabularies, idempotency keys, fail-closed checks, ordering guarantees), or introduce a new cross-module edge? Severity:
    - **CRITICAL** — can corrupt persisted data, or open an auth/money path.
    - **HIGH** — silent cross-module breakage that would ship green.
    - **MEDIUM** — drift-prone coupling (string-matched, duplicated constants).
-   - **LOW** — smell. Loud, immediately-visible breakage caps at HIGH.
+   - **LOW** — smell. Loud, immediately-visible runtime breakage caps at HIGH.
 
 5. **Report in chat:**
 
    ```
    # Boundary check — {plan}
 
-   Touched files read: {N} · Boundaries identified: {N}
-   Violations: {N} ({critical}/{high}/{medium}/{low})
+   **Verdict: PASS | PASS WITH AMENDMENTS | BLOCK**
 
-   | # | Boundary | Planned change | Other side (file:line) | Severity |
+   Touched files read: {N} · Contracts identified: {N} · Consumers traced: {N}
+
+   ## Violations
+   | # | Boundary | Mechanism | Planned change | Other side (file:line or doc) | Severity |
+
+   ## New edges the plan introduces
+   | # | Contract | Sides | Hardening to fold into the plan |
+
+   ## Coverage
+   | Area touched | Contracts checked | Result |
 
    ## Suggested plan amendments
    ## Missing plan subsections
    ```
 
+   **BLOCK** = any CRITICAL. HIGH findings yield **PASS WITH AMENDMENTS** — fold the amendments into the plan before coding. Order amendments sequencing-first: many violations dissolve by reordering steps (expand-then-contract, migrate-before-code) rather than changing what ships — prefer that fix, drawn from the entry's safe-change sequence.
+
 ## Rules
 
 - **Read-only.** You never edit the plan, the code, or any doc. The user folds your amendments into the plan.
-- **Verify in source.** Never flag from plan text alone — read both sides of every boundary you report, and cite both as `file:line`.
-- **No consumer, no finding.** An intersection with no traced other side isn't a violation; at most note it as a new edge the plan introduces.
-- **A clean report is valid.** Zero violations means say so — don't pad.
+- **Verify in source.** Never flag from plan text alone — read both sides of every finding and cite them: code as `file:line`, doctrine as the doc path.
+- **No other side, no violation.** An intersection with no traced consumer and no doctrine behind it isn't a violation — it's a **new edge**: report it in its own section with the hardening its mechanism prescribes (version the cache key now, make the enum append-only now), so the fragile edge is born safe.
+- **A clean report is valid.** Zero violations means say so — the coverage table is the evidence it was checked, not skipped. Don't pad findings.