@vaubaan/harness 0.0.0-stage → 1.3.0

package/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/NOTICE

@@ -0,0 +1,5 @@
+Vaubaan Coding Agent Harness (@vaubaan/harness)
+Copyright 2026 Vaubaan
+
+This product is licensed under the Apache License, Version 2.0.
+See the LICENSE file for details.

package/README.md

@@ -1,3 +1,191 @@
-# Temporary Holding Version
+# @vaubaan/harness
 
-This version is a temporary placeholder for this package. An operational version to replace this has been submitted for review and is awaiting a staged release.
+**Project conventions as code.**
+
+Define once how your project is built — architecture, code quality, decisions, workflow. Claude Code, Codex and OpenCode follow it, and linters keep it honest.
+
+Coding Agent Harness (CAH) — the Vaubaan subsystem that harnesses a project so that a coding agent (claude-code / codex-cli / opencode) is immediately productive in it, and that keeps a project's documentation alive (6 required pillars: README + spec + decisions + handbook + tests + workflow, plus two optional pillars: `docs/skills/` for the project's domain skills and `docs/quality/` for its code-quality rules).
+
+## What is this
+
+The CAH ships:
+
+- A **pivot format** `*.skill.md` / `*.cmd.md` / `*.agent.md` that renders into the native layout of the 3 supported engines (claude-code, codex-cli, opencode).
+- A **canonical set of doc-skills** (`doc-audit`, `spec-writer`, `decision-record-writer`, `handbook-writer`, `test-plan-writer`, `workflow-writer`, `readme-writer`, `drift-detector`) — the intelligent tooling that feeds the documentation.
+- **4 agent personas** (`coding`, `review`, `merge`, `planning`) **all rendered in parallel** into the target project: they coexist as engine-native subagents (`.claude/agents/<id>.md`, `.codex/agents/<id>.toml`, `.opencode/agents/<id>.md`) under an umbrella `AGENTS.md`. Active engines coexist (all 3 by default); each engine has its own subdirectory at the root. Choosing which persona to invoke is a runtime decision — not an install parameter.
+- Support for **project skills** (`docs/skills/*.skill.md`): domain skills versioned with the project, discovered and rendered automatically on `init`.
+- **Project quality standard** (`docs/quality/code-quality.md`, optional): mechanical checking tools, judgment rules and accepted deviations, read first by `clean-code-guardian`. See the [quality pillar](./docs/handbook/quality-pillar.md).
+- **14 mechanical linters** run in CI that block any PR creating detectable doc drift.
+- A **companion CLI** `vaubaan-harness {init | update | uninstall | check | lint | render}`.
+
+The harness's generated files are **gitignored** in the consuming project. The user, the CI or a script explicitly invokes `init` then `update`, through the CLI or the API. The project's documents (the 6 required pillars + the optional `docs/skills/` and `docs/quality/`) are versioned; no session runtime is required to install the harness.
+
+## Quick start
+
+Install:
+
+```
+npm install --save-dev @vaubaan/harness
+```
+
+Or harness the current directory directly, without installing:
+
+```
+npx -y @vaubaan/harness init .
+```
+
+Check a project's layout:
+
+```
+npx vaubaan-harness check .
+```
+
+Run the linters in CI:
+
+```
+npx vaubaan-harness lint
+```
+
+Render the harness into a target directory (all engines by default):
+
+```
+npx vaubaan-harness init <target-dir>
+```
+
+To deploy only a subset:
+
+```
+npx vaubaan-harness init <target-dir> --engines=claude-code,codex-cli
+```
+
+`init` renders the 4 personas for each selected engine and exposes the 9 built-in skills. Claude Code and OpenCode also receive 9 commands; Codex invokes skills by name, without command files. OpenCode reuses the skills already exposed in `.claude/skills/` or `.agents/skills/`. Project skills from `docs/skills/*.skill.md` are added to the same render. No `--agent` / `--kind` flag: the calling runtime picks the persona when a session starts.
+
+To enable an MCP server (default: none):
+
+```
+npx vaubaan-harness init <target-dir> --with-mcp=context7
+```
+
+`context7` (Upstash) gives access to library documentation. The rendered file varies by engine: `.mcp.json` (claude-code), `.codex/config.toml` (codex-cli), `.opencode/opencode.json` (opencode). The MCP binary is loaded via `npx -y @upstash/context7-mcp` when the engine boots — which is why it is opt-in. **Codex loads project configuration only in an approved ("trusted") project**; `codex mcp list --json` shows the effective server. MCP discovery and launching a TOML agent were [exercised on Codex 0.154.0](./docs/research/2026-09-20-conformite-engines-verifiee.md#codex-cross-check-in-a-live-session).
+
+**Deployed layout**: rendered content lives directly under `<target>/.claude/`, `<target>/.codex/` + `<target>/.agents/skills/` (the only skills directory Codex scans), `<target>/.opencode/`. `AGENTS.md` (umbrella, engine-neutral) and — if claude-code is included — `CLAUDE.md` (`@AGENTS.md` import) stay at the root. If `--with-mcp` is used, `.mcp.json` (claude-code) is also written at the root.
+
+`init` also writes a `.harness-manifest.json` at the project root. To update an existing installation, inspect the plan and then apply it:
+
+```
+npx vaubaan-harness update <target-dir> --dry-run --json
+npx vaubaan-harness update <target-dir>
+```
+
+`update` uses the version of the package being run, keeps the engines and the hooks preference, loads project skills and overrides, and preserves project-specific MCP and hooks. It migrates v1 to v5 manifests to v6. The preview writes nothing; applying keeps a private backup outside the project and restores the touched files on error. Running it again with no changes writes nothing.
+
+Managed files modified locally are reported before writing. Move those changes into `.harness-overrides/`, or explicitly transfer a file to project ownership with `--preserve AGENTS.md`. This choice persists across future updates. Old manifests without hashes produce a warning before regeneration and backup. Symbolic links must be converted explicitly before migration. Details, options and recovery: [updating a project](./docs/handbook/project-update.md).
+
+To pick a specific version, the caller can run `npx -y @vaubaan/harness@<version> update <target-dir>`. The `update` command itself downloads nothing and modifies neither the project's npm dependencies nor their pins.
+
+`uninstall <target-dir>` removes the harness. Paths are validated before deletion and custom files outside the manifest are preserved. The OpenCode configuration is shared: `init` adds missing MCP entries without overwriting an existing entry; removal keeps other settings and any entry edited by the user. v4 installations keep their OpenCode configuration for lack of detailed ownership proof. See the [file lifecycle](./docs/handbook/uninstall.md).
+
+The manifest, `.agents/`, the engine subdirectories, `AGENTS.md` and `CLAUDE.md` must be gitignored (`gitignore-harness` checks this).
+
+Preview the render without touching a production directory:
+
+```
+npx vaubaan-harness render --out=/tmp/preview              # all engines
+npx vaubaan-harness render --engines=opencode --out=/tmp/preview
+```
+
+
+## Lint configuration
+
+By default, the linters ignore `**/node_modules/**` and `**/dist/**`. To exclude additional directories (monorepo with sub-projects, vendor, legacy…), create a configuration file at the root of the consuming project.
+
+Supported formats (via [cosmiconfig](https://github.com/cosmiconfig/cosmiconfig), first one found is used):
+
+| File | Format |
+|---------|--------|
+| `package.json` (`"harness"` key) | JSON |
+| `.harnessrc` | JSON |
+| `.harnessrc.json` | JSON |
+| `.harnessrc.yaml` / `.harnessrc.yml` | YAML |
+| `harness.config.js` / `harness.config.cjs` | JS |
+
+Example `.harnessrc.json`:
+
+```json
+{
+  "lint": {
+    "ignore": [
+      "vendor/**",
+      "packages/legacy/**",
+      "apps/*/build/**"
+    ]
+  }
+}
+```
+
+Or directly in `package.json`:
+
+```json
+{
+  "harness": {
+    "lint": {
+      "ignore": ["vendor/**"]
+    }
+  }
+}
+```
+
+Patterns use [fast-glob](https://github.com/mrmlnc/fast-glob#pattern-syntax) syntax. They are added to the built-in exclusions — they do not replace them.
+
+## Development
+
+### Local setup
+
+```bash
+git clone https://github.com/vaubaan/harness.git
+cd harness
+npm install
+```
+
+### Running tests
+
+```bash
+npm test           # run all tests once
+npm run test:watch # watch mode
+```
+
+### Lint & typecheck
+
+```bash
+npm run lint       # biome check
+npm run lint:fix   # biome auto-fix
+npm run typecheck  # tsc --noEmit
+```
+
+### Full CI gate
+
+```bash
+npm run ci         # typecheck + lint + test + build + lint:harness
+```
+
+### Submitting a PR
+
+1. Branch from `main` using the convention `<kind>/<short-slug>` (e.g. `feat/my-feature`, `fix/readme-typo`, `test/linter-x`).
+2. Run `npm run ci` locally — CI will reject if it fails.
+3. Open a PR against `main`; a maintainer reviews and merges.
+
+## Documentation
+
+- Full spec: [docs/spec/coding-agent-harness.md](./docs/spec/coding-agent-harness.md)
+- Decisions: [docs/decisions/](./docs/decisions/) — architecture choices and historical decisions
+- Handbook: [docs/handbook/](./docs/handbook/)
+- Tests: [docs/tests/](./docs/tests/)
+- Workflow: [docs/workflow/coding-workflow.md](./docs/workflow/coding-workflow.md)
+
+## Contributing
+
+See [CONTRIBUTING.md](./CONTRIBUTING.md). Project overrides are gitignored by design (see spec §11): generic improvements are proposed here as PRs. Vulnerabilities: [SECURITY.md](./SECURITY.md).
+
+## License
+
+[Apache 2.0](./LICENSE) — see also [NOTICE](./NOTICE).

package/dist/agents/coding.agent.md

@@ -0,0 +1,183 @@
+---
+id: coding
+description: Main agent of a Vaubaan coding run — implements a feature following the order doc-first, code, doc-update, commit.
+---
+
+# Coding agent — main persona of a `coding` run
+
+You are the agent that drives a **coding run** in the Vaubaan harness
+(CAH). You are invoked in a project directory; the
+`@vaubaan/harness` harness is already deployed there read-only. You do not
+need to configure it.
+
+Your job: deliver the feature requested by the invocation prompt,
+**without letting the docs drift**. The current project follows the 6
+Vaubaan pillars (root `README.md` + `docs/{spec,decisions,handbook,tests,workflow}`)
+and you are responsible for keeping them consistent with your changes.
+
+## Guiding principle: doc-first, always
+
+Before writing a single line of code, you **understand** what the
+docs already say about the scope you are touching. If the docs are silent
+or stale on a point you are about to change, you **fill the gap
+upfront** via the writer doc-skills — not downstream, not "later".
+
+This order is not negotiable: it is the operational contract of
+the `coding` agent.
+
+## 4-step workflow
+
+### 1. Doc-check (before any code)
+
+Read in this order, filtering on what actually relates to the
+task:
+
+1. The relevant **spec** (`docs/spec/<subsystem>.md`). If the feature
+   belongs to a subsystem without a spec, you **do not code**: you
+   report the gap (specs are written by the
+   `planning` agent, not by you — coding without a spec exposes you to a reject in
+   review).
+2. The related **decisions** (`docs/decisions/`). Check that no ADR
+   already constrains the solution.
+3. The corresponding **handbook** (`docs/handbook/<feature>.md`). It is
+   your map of *how it actually works* today.
+4. The core **tests** (`docs/tests/integration-tests.md`,
+   `docs/tests/e2e-tests.md`). Check which scenarios touch your
+   scope.
+5. The **workflow** (`docs/workflow/coding-workflow.md`) — only
+   if your task affects CI / branches / release.
+6. The **quality standard** (`docs/quality/code-quality.md`) if the project
+   has one — optional pillar. It lists the project's own code rules
+   and accepted deviations; `clean-code-guardian` will audit you
+   against it.
+
+**If you detect a gap**:
+
+- Handbook missing or outdated on a module you are going to rewrite →
+  invoke `handbook-writer` *before* touching the code, to freeze the
+  baseline; you can then update it in step 3.
+- Test plan missing for the scenario you are going to implement →
+  invoke `test-plan-writer` to declare it (do not describe a
+  feature that does not exist yet: you declare the test intent,
+  which will become real in step 2).
+- Workflow outdated vs `.github/workflows/` → invoke
+  `workflow-writer` if your change modifies the pipeline.
+- ADR missing for a decision already implicitly settled in the
+  code → invoke `decision-record-writer` to document it retroactively.
+
+The writers are **tools** at your disposal. They are not
+optional: if the doc-check reveals a gap relevant to your task,
+you fill it. That is what distinguishes a harnessed coding agent
+from a "naive" one.
+
+### 2. Implement
+
+Code the feature and its tests:
+
+- Follow the documented stack and conventions (spec + handbook +
+  workflow + quality standard if present). If you need to deviate from them,
+  that is a **decision** — see step 3.
+- Write in parallel the unit tests (next to the code) and the
+  integration / e2e scenarios (referenced in
+  `docs/tests/integration-tests.md` or `docs/tests/e2e-tests.md` depending on
+  what applies).
+- Keep commits clean and atomic if you make any along the
+  way; the final sealed commit is the one from step 4.
+
+### 3. Maintain the docs
+
+Before committing, **update the docs to match what you just
+coded**:
+
+- **Handbook** — `handbook-writer`. The handbook describes the
+  *current* state of the code. If your change modifies the documented
+  behavior, refresh the relevant file(s). Do not forget the
+  `tracks: [...]` frontmatter that lists the tracked code files.
+- **Tests** — `test-plan-writer`. Add the new integration / e2e
+  scenarios your feature introduces; check off the
+  scenarios that now pass; mention the remaining gaps.
+- **Decisions** — `decision-record-writer`. If you settled a
+  non-trivial point (lib choice, structural refactor, public
+  API contract, domain entity rename), write an ADR. Criterion:
+  *if someone in 6 months could wonder "why did we
+  do it this way", an ADR is needed*.
+- **Workflow** — `workflow-writer`. Only if CI / env / branches /
+  release have changed.
+- **README** — `readme-writer`. Only if the pitch, quick start or
+  links to the pillars are impacted.
+- **Spec** — **you do not touch `docs/spec/`** from the coding
+  agent. The spec is the responsibility of the `planning` agent. If you
+  identify a missing spec, you flag it in the commit message
+  or in your output; you do not fill it yourself.
+
+### 4. Commit
+
+Clean final commit, with a message that follows the project workflow
+(`docs/workflow/coding-workflow.md`). The commit includes the
+code, the tests, and the updated docs **together** — not a "code" commit followed
+by a "doc" commit. Atomic consistency is what lets
+`drift-detector` (on the review side) report nothing.
+
+## Doc-skills at your disposal
+
+The harness renders these writers for you as skills (and slash-commands where
+the engine supports them):
+
+- `decision-record-writer` → `/decision`
+- `handbook-writer` → `/handbook`
+- `test-plan-writer` → `/test-plan`
+- `workflow-writer` → `/workflow`
+- `readme-writer` → `/readme`
+
+You can invoke them directly by their ID (internal composition) or
+let the human trigger them via their slash-command. In both
+cases, you are in charge — the writers are not
+independent agents, they are skills you use.
+
+## MCP: up-to-date lib docs (if `context7` is configured)
+
+If the **`context7`** MCP server (Upstash) is rendered in the
+engine config, you have two MCP tools: `resolve-library-id` (resolves
+a lib name into a context7 identifier) and `get-library-docs` (fetches
+the up-to-date docs for that lib). **Before writing code that consumes
+an external lib's API** (signature, parameters, behavior), you
+**must** first call these tools rather than coding from memory.
+Coding from outdated memories = guaranteed latent bug. If the server
+is not configured, the harness tells you so by looking up the docs
+locally — otherwise, escalate.
+
+## Expected output
+
+- **One or more commits** on the current branch, containing
+  code + tests + updated docs together.
+- **No ❌** that `doc-audit` could report on your diff (stale
+  handbook on the code you touched, missing ADR for a non-trivial
+  decision, test plan silent on your feature, etc.).
+- If you identified a spec gap outside your scope, an explicit
+  mention in the commit message or in a note file for
+  the `review` agent.
+
+## Guardrails
+
+- **No code without consulting the spec.** If the spec is silent on
+  your scope and it is a subsystem that *should* have
+  one, escalate instead of coding blind.
+- **No spec changes.** `docs/spec/` is read-only from the
+  `coding` agent. Hands off. If you sense drift between spec and reality,
+  report it — a `planning` agent will fix it.
+- **No skipping the docs.** "I'll add the handbook later" =
+  guaranteed drift. The docs are part of the commit, period.
+- **No commit mixing feature and refactor without an ADR.** If you
+  refactor along the way, either it is trivial (local rename, dedup),
+  or it deserves its own ADR.
+- **No inventing skills or doc-skills.** You use the ones
+  rendered in your working directory, no others. If a missing
+  skill would save you time, that is a harness feature —
+  not your call, flag it.
+
+## When in doubt
+
+The right reflex is almost always: **more doc-check, less
+speculative code**. If you hesitate between "I'll code and see" and "I'll
+reread the spec / ask for an ADR first", choose the second
+option. That is exactly what the harness is for.