@vaubaan/harness 1.3.0 → 1.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/NOTICE CHANGED
@@ -1,4 +1,4 @@
1
- Vaubaan Coding Agent Harness (@vaubaan/harness)
1
+ Vaubaan harness (@vaubaan/harness)
2
2
  Copyright 2026 Vaubaan
3
3
 
4
4
  This product is licensed under the Apache License, Version 2.0.
package/README.md CHANGED
@@ -2,190 +2,307 @@
2
2
 
3
3
  **Project conventions as code.**
4
4
 
5
- Define once how your project is built — architecture, code quality, decisions, workflow. Claude Code, Codex and OpenCode follow it, and linters keep it honest.
5
+ Write down once how your project is built — its architecture, decisions, quality rules and workflow. Claude Code, Codex and OpenCode read the same conventions, and linters tell you when code and docs drift apart.
6
6
 
7
- 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).
7
+ [![npm](https://img.shields.io/npm/v/@vaubaan/harness)](https://www.npmjs.com/package/@vaubaan/harness)
8
+ [![CI](https://github.com/vaubaan/harness/actions/workflows/ci.yml/badge.svg)](https://github.com/vaubaan/harness/actions/workflows/ci.yml)
9
+ [![License: Apache-2.0](https://img.shields.io/badge/license-Apache--2.0-blue)](./LICENSE)
8
10
 
9
- ## What is this
11
+ ```bash
12
+ npx -y @vaubaan/harness init .
13
+ ```
10
14
 
11
- The CAH ships:
15
+ ---
12
16
 
13
- - 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).
14
- - 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.
15
- - **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.
16
- - Support for **project skills** (`docs/skills/*.skill.md`): domain skills versioned with the project, discovered and rendered automatically on `init`.
17
- - **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).
18
- - **14 mechanical linters** run in CI that block any PR creating detectable doc drift.
19
- - A **companion CLI** `vaubaan-harness {init | update | uninstall | check | lint | render}`.
17
+ ## Why
20
18
 
21
- 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.
19
+ Coding agents are fast, but they don't know your project. So you end up:
22
20
 
23
- ## Quick start
21
+ - repeating the same instructions in every session;
22
+ - maintaining a `CLAUDE.md`, an `AGENTS.md` and an OpenCode config that slowly disagree;
23
+ - discovering that the agent changed behavior the docs still describe the old way.
24
24
 
25
- Install:
25
+ The harness puts your conventions where they belong — in versioned docs inside the repo — and renders them into the native format of each agent. One source of truth, every engine, checked on every turn.
26
26
 
27
- ```
28
- npm install --save-dev @vaubaan/harness
29
- ```
27
+ ## Quick start
30
28
 
31
- Or harness the current directory directly, without installing:
29
+ Requires Node.js 20 or later.
32
30
 
33
- ```
31
+ ```bash
34
32
  npx -y @vaubaan/harness init .
35
33
  ```
36
34
 
37
- Check a project's layout:
35
+ This renders, for each engine:
38
36
 
39
37
  ```
40
- npx vaubaan-harness check .
38
+ AGENTS.md # how to work in this project (all engines)
39
+ CLAUDE.md # imports AGENTS.md for Claude Code
40
+ .claude/ # agents, skills, commands, Stop hook
41
+ .codex/ .agents/skills/ # agents, skills, Stop hook
42
+ .opencode/ # agents, commands, Stop hook plugin
43
+ .harness-manifest.json # what was written, for update/uninstall
41
44
  ```
42
45
 
43
- Run the linters in CI:
44
-
45
- ```
46
- npx vaubaan-harness lint
46
+ All of these are **generated and gitignored**. What you commit is your `docs/` folder. Add these entries to `.gitignore`:
47
+
48
+ ```gitignore
49
+ # generated by @vaubaan/harness
50
+ AGENTS.md
51
+ CLAUDE.md
52
+ .claude/
53
+ .codex/
54
+ .agents/
55
+ .opencode/
56
+ .mcp.json
57
+ .harness-manifest.json
58
+ .harness-overrides/
59
+ # Stop hook retry state and skill reports
60
+ .harness/
61
+ .vaubaan/
47
62
  ```
48
63
 
49
- Render the harness into a target directory (all engines by default):
64
+ `npx @vaubaan/harness check .` tells you if an entry is missing.
50
65
 
51
- ```
52
- npx vaubaan-harness init <target-dir>
53
- ```
54
-
55
- To deploy only a subset:
66
+ Then open your agent and ask it to fill the gaps:
56
67
 
57
68
  ```
58
- npx vaubaan-harness init <target-dir> --engines=claude-code,codex-cli
69
+ /doc-audit # what's missing or stale in your docs
70
+ /spec # write the spec of a subsystem, guided
71
+ /decision # turn an implicit choice into an ADR
59
72
  ```
60
73
 
61
- `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.
74
+ > [!NOTE]
75
+ > `init` never overwrites a file it did not write. If you already have a hand-written `AGENTS.md` or `CLAUDE.md`, it stops and lists them: move their content into `docs/`, or keep them as yours with `--preserve AGENTS.md`. Existing `.claude/settings.json`, `.mcp.json` and `.opencode/opencode.json` are merged entry by entry, with a backup.
62
76
 
63
- To enable an MCP server (default: none):
77
+ ## How it works
64
78
 
65
79
  ```
66
- npx vaubaan-harness init <target-dir> --with-mcp=context7
80
+ docs/ your conventions, versioned in Git
81
+ │ spec · decisions · handbook · tests · workflow · quality
82
+ │
83
+ ▼ init
84
+ AGENTS.md .claude/ .codex/ .opencode/
85
+ │ generated for each engine, gitignored
86
+ │
87
+ ▼
88
+ Claude Code · Codex · OpenCode read the same conventions, write the code
89
+ │ ▲
90
+ │ end of each turn │ report: what drifted
91
+ ▼ │
92
+ linters (Stop hook) ────┘
93
+ │
94
+ ▼
95
+ CI same checks on every pull request
67
96
  ```
68
97
 
69
- `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).
98
+ 1. **Your docs are the conventions.** A small, fixed layout under `docs/` says what the project does, why it's built that way, and how it actually works today.
99
+ 2. **The harness renders one pivot format into each engine's native layout.** Agents, skills and commands are written once and land where each engine looks for them.
100
+ 3. **Linters keep docs and code in sync.** At the end of each agent turn, a Stop hook runs them; if something drifted, the agent gets the report and fixes it before handing back. The same linters run in CI.
70
101
 
71
- **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.
102
+ The work order every agent follows is: **understand the docs → fill the gaps → code → update the docs → commit.**
72
103
 
73
- `init` also writes a `.harness-manifest.json` at the project root. To update an existing installation, inspect the plan and then apply it:
104
+ ## Your docs
74
105
 
75
106
  ```
76
- npx vaubaan-harness update <target-dir> --dry-run --json
77
- npx vaubaan-harness update <target-dir>
107
+ README.md # pitch, quick start
108
+ docs/
109
+ spec/<subsystem>.md # what and why — tech-agnostic
110
+ decisions/<slug>.md # ADRs: Context, Decision, Consequences, Rejected alternatives
111
+ handbook/<feature>.md # how it actually works today (tracks the code it describes)
112
+ tests/integration-tests.md # core scenarios
113
+ tests/e2e-tests.md
114
+ workflow/coding-workflow.md # CI, branches, PRs, release
115
+ quality/code-quality.md # optional — your code-quality rules
116
+ skills/*.skill.md # optional — your own domain skills
78
117
  ```
79
118
 
80
- `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.
81
-
82
- 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).
83
-
84
- 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.
85
-
86
- `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).
87
-
88
- The manifest, `.agents/`, the engine subdirectories, `AGENTS.md` and `CLAUDE.md` must be gitignored (`gitignore-harness` checks this).
89
-
90
- Preview the render without touching a production directory:
91
-
92
- ```
93
- npx vaubaan-harness render --out=/tmp/preview # all engines
94
- npx vaubaan-harness render --engines=opencode --out=/tmp/preview
119
+ Handbooks and test plans declare the code they describe in a `tracks:` frontmatter field. When that code changes and the doc doesn't, the drift linter notices.
120
+
121
+ Every file has a template and a writer skill, so you rarely start from a blank page.
122
+
123
+ ## What's included
124
+
125
+ **4 agents** — rendered side by side; you pick one when you start a session.
126
+
127
+ | Agent | Role |
128
+ |---|---|
129
+ | `planning` | Turns a request into an implementation plan; drafts missing specs and test plans first. |
130
+ | `coding` | Implements a feature in doc-first order: docs, code, doc update, commit. |
131
+ | `review` | Audits a diff or codebase and returns an actionable verdict, including doc gaps. |
132
+ | `merge` | Merges (PR + tag) and makes sure a final ADR records the decision. |
133
+
134
+ **9 skills**, each with a slash command:
135
+
136
+ | Command | Skill | What it does |
137
+ |---|---|---|
138
+ | `/doc-audit` | `doc-audit` | Audits completeness and freshness of all doc pillars. |
139
+ | `/drift` | `drift-detector` | Finds where docs no longer match the code. |
140
+ | `/spec` | `spec-writer` | Guided writing of a tech-agnostic spec. |
141
+ | `/decision` | `decision-record-writer` | Writes an ADR, spotting implicit decisions in your diff. |
142
+ | `/handbook` | `handbook-writer` | Documents how a feature is actually implemented. |
143
+ | `/test-plan` | `test-plan-writer` | Keeps integration and e2e test plans up to date. |
144
+ | `/workflow` | `workflow-writer` | Documents CI, environments, PR process, branches, release. |
145
+ | `/readme` | `readme-writer` | Keeps the README in sync with the code. |
146
+ | `/clean-code` | `clean-code-guardian` | Reviews code quality against your `docs/quality/` rules. |
147
+
148
+ **14 linters** — mechanical checks, fast enough to run on every turn.
149
+
150
+ <details>
151
+ <summary>See the list</summary>
152
+
153
+ | Linter | Checks |
154
+ |---|---|
155
+ | `readme-presence`, `readme-sections` | `README.md` exists and has a title and a quick start. |
156
+ | `doc-layout`, `cardinal-files` | The `docs/` folders and required files exist. |
157
+ | `spec-has-content`, `spec-tech-agnostic` | Specs exist and don't name frameworks or vendors. |
158
+ | `decision-schema` | Each ADR has its four sections. |
159
+ | `adr-no-tracks`, `orphan-decisions` | ADRs stay frozen and are referenced somewhere. |
160
+ | `frontmatter-tracks`, `tracks-drift` | Tracked paths exist; docs aren't older than the code they track. |
161
+ | `cross-links` | Links between docs resolve. |
162
+ | `gitignore-harness` | Generated files stay out of Git. |
163
+ | `quality-schema` | `docs/quality/code-quality.md` has its sections, if you use it. |
164
+
165
+ </details>
166
+
167
+ ## Engine support
168
+
169
+ | | Claude Code | Codex | OpenCode |
170
+ |---|---|---|---|
171
+ | Agents | `.claude/agents/` | `.codex/agents/*.toml` | `.opencode/agents/` |
172
+ | Skills | `.claude/skills/` | `.agents/skills/` | reuses the above |
173
+ | Slash commands | ✓ | — invoke skills by name | ✓ |
174
+ | Stop hook | `.claude/settings.json` | `.codex/hooks.json` | plugin (1.x and 2.x) |
175
+ | Hook runs after | workspace trust | project trust **and** hook approval (`/hooks`) | — |
176
+ | MCP (opt-in) | `.mcp.json` | `.codex/config.toml` | `.opencode/opencode.json` |
177
+
178
+ Only use one engine? `--engines=claude-code` (or `codex-cli`, `opencode`, comma-separated).
179
+
180
+ ## Adopting it on an existing project
181
+
182
+ You don't have to write all the docs on day one.
183
+
184
+ - **See where you stand:** `npx @vaubaan/harness lint` lists what's missing, with the skill that fixes each item.
185
+ - **Let the agent do the first pass:** `/doc-audit`, then `/spec`, `/handbook` and `/decision` on the parts you touch.
186
+ - **Pause the Stop hook while you bootstrap:** `HARNESS_LINT_DISABLE=1`, or install without it: `init . --no-stop-hook`. When a retry makes no progress, the hook lets the turn end.
187
+ - **Back out anytime:** `npx @vaubaan/harness uninstall .` removes what `init` wrote. Your own files, and config entries you edited, are left in place.
188
+
189
+ ## Use it in CI
190
+
191
+ ```yaml
192
+ # .github/workflows/docs.yml
193
+ name: docs
194
+ on: [push, pull_request]
195
+ jobs:
196
+ lint:
197
+ runs-on: ubuntu-latest
198
+ steps:
199
+ - uses: actions/checkout@v4
200
+ - uses: actions/setup-node@v4
201
+ with:
202
+ node-version: 22
203
+ - run: npx -y @vaubaan/harness lint
95
204
  ```
96
205
 
206
+ `lint` exits non-zero on errors. Use `--format json` for machine-readable output and `--pillar <name>` to check a single pillar.
97
207
 
98
- ## Lint configuration
208
+ ## Commands
99
209
 
100
- 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.
210
+ | Command | What it does |
211
+ |---|---|
212
+ | `init <dir>` | Render the harness into a project. Re-run it to change engines (`--engines`), MCP servers (`--with-mcp`) or the Stop hook (`--no-stop-hook`). |
213
+ | `update [dir]` | Re-render with the installed version, keeping your settings. `--dry-run --json` previews. |
214
+ | `uninstall <dir>` | Remove what `init` wrote, leaving your own files in place. |
215
+ | `lint` | Run the linters. |
216
+ | `check <dir>` | Quick layout check: doc folders and `.gitignore`. |
217
+ | `render --out <dir>` | Preview the render somewhere harmless. |
101
218
 
102
- Supported formats (via [cosmiconfig](https://github.com/cosmiconfig/cosmiconfig), first one found is used):
219
+ Run them with `npx @vaubaan/harness <command>`. If the package is installed in the project (`npm i -D @vaubaan/harness`), that uses the local version; otherwise `npx` downloads it (`-y` skips the confirmation prompt).
103
220
 
104
- | File | Format |
105
- |---------|--------|
106
- | `package.json` (`"harness"` key) | JSON |
107
- | `.harnessrc` | JSON |
108
- | `.harnessrc.json` | JSON |
109
- | `.harnessrc.yaml` / `.harnessrc.yml` | YAML |
110
- | `harness.config.js` / `harness.config.cjs` | JS |
221
+ ## Configuration
111
222
 
112
- Example `.harnessrc.json`:
223
+ <details>
224
+ <summary><b>Ignore paths in lint</b></summary>
225
+
226
+ `node_modules/` and `dist/` are ignored by default. Add more in `.harnessrc.json` (or `.harnessrc`, `.harnessrc.yaml`, `harness.config.js`, or a `"harness"` key in `package.json`):
113
227
 
114
228
  ```json
115
229
  {
116
230
  "lint": {
117
- "ignore": [
118
- "vendor/**",
119
- "packages/legacy/**",
120
- "apps/*/build/**"
121
- ]
231
+ "ignore": ["vendor/**", "packages/legacy/**"]
122
232
  }
123
233
  }
124
234
  ```
125
235
 
126
- Or directly in `package.json`:
236
+ Patterns use [fast-glob](https://github.com/mrmlnc/fast-glob#pattern-syntax) syntax and add to the defaults.
127
237
 
128
- ```json
129
- {
130
- "harness": {
131
- "lint": {
132
- "ignore": ["vendor/**"]
133
- }
134
- }
135
- }
238
+ </details>
239
+
240
+ <details>
241
+ <summary><b>Local overrides</b></summary>
242
+
243
+ Try a custom agent, skill or command without forking, in a gitignored `.harness-overrides/` folder:
244
+
245
+ ```
246
+ .harness-overrides/
247
+ agents/ *.agent.md
248
+ skills/ *.skill.md
249
+ commands/ *.cmd.md
250
+ disable.yaml # disable: [readme-writer, workflow-writer]
136
251
  ```
137
252
 
138
- 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.
253
+ Overrides are personal and disposable. Skills meant for the whole team go in `docs/skills/`, which is versioned. See [overrides loading](./docs/handbook/overrides-loading.md).
139
254
 
140
- ## Development
255
+ </details>
141
256
 
142
- ### Local setup
257
+ <details>
258
+ <summary><b>MCP servers</b></summary>
143
259
 
144
- ```bash
145
- git clone https://github.com/vaubaan/harness.git
146
- cd harness
147
- npm install
148
- ```
260
+ None by default. `init . --with-mcp=context7` adds [Context7](https://github.com/upstash/context7) (library documentation) to each engine's MCP config. Codex only loads project config in a trusted project.
149
261
 
150
- ### Running tests
262
+ </details>
263
+
264
+ <details>
265
+ <summary><b>Updating</b></summary>
151
266
 
152
267
  ```bash
153
- npm test # run all tests once
154
- npm run test:watch # watch mode
268
+ npm i -D @vaubaan/harness@latest
269
+ npx @vaubaan/harness update . --dry-run --json # preview
270
+ npx @vaubaan/harness update .
155
271
  ```
156
272
 
157
- ### Lint & typecheck
273
+ `update` keeps your engines, hook preference, MCP entries and hook edits. Generated files you modified are reported instead of overwritten: move the change to `.harness-overrides/`, or keep the file as yours with `--preserve AGENTS.md`. A backup is written outside the project before any change. Details: [updating a project](./docs/handbook/project-update.md).
158
274
 
159
- ```bash
160
- npm run lint # biome check
161
- npm run lint:fix # biome auto-fix
162
- npm run typecheck # tsc --noEmit
163
- ```
275
+ </details>
164
276
 
165
- ### Full CI gate
277
+ ## FAQ
166
278
 
167
- ```bash
168
- npm run ci # typecheck + lint + test + build + lint:harness
169
- ```
279
+ **Does it phone home?** No. No telemetry, no daemon. It writes files and runs linters locally.
170
280
 
171
- ### Submitting a PR
281
+ **Do I need all three engines?** No. Everything is rendered for all three by default because it costs nothing, but `--engines` narrows it.
172
282
 
173
- 1. Branch from `main` using the convention `<kind>/<short-slug>` (e.g. `feat/my-feature`, `fix/readme-typo`, `test/linter-x`).
174
- 2. Run `npm run ci` locally — CI will reject if it fails.
175
- 3. Open a PR against `main`; a maintainer reviews and merges.
283
+ **Can I write my docs in another language?** Prose, yes. The linters look for English section headings (`## Context`, `## Decision`…); French headings are also accepted.
284
+
285
+ **Does it work in a monorepo?** Run it at the repository root and use `lint.ignore` for sub-projects you don't want checked.
286
+
287
+ **Is this tied to Vaubaan?** No. Vaubaan builds it and uses it on its own projects — including this one, which is harnessed by itself.
176
288
 
177
289
  ## Documentation
178
290
 
179
- - Full spec: [docs/spec/coding-agent-harness.md](./docs/spec/coding-agent-harness.md)
180
- - Decisions: [docs/decisions/](./docs/decisions/) — architecture choices and historical decisions
181
- - Handbook: [docs/handbook/](./docs/handbook/)
182
- - Tests: [docs/tests/](./docs/tests/)
183
- - Workflow: [docs/workflow/coding-workflow.md](./docs/workflow/coding-workflow.md)
291
+ - [Spec](./docs/spec/coding-agent-harness.md) — what the harness is and why
292
+ - [Decisions](./docs/decisions/) — architecture choices and their alternatives
293
+ - [Handbook](./docs/handbook/) — how each part works today
294
+ - [Test plans](./docs/tests/) and [workflow](./docs/workflow/coding-workflow.md)
295
+ - [Changelog](./CHANGELOG.md)
184
296
 
185
297
  ## Contributing
186
298
 
187
- 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).
299
+ Issues and pull requests are welcome. Setup, conventions and the doc-first workflow are in [CONTRIBUTING.md](./CONTRIBUTING.md); security reports go through [SECURITY.md](./SECURITY.md).
300
+
301
+ ```bash
302
+ git clone https://github.com/vaubaan/harness.git && cd harness
303
+ npm ci && npm run ci
304
+ ```
188
305
 
189
306
  ## License
190
307
 
191
- [Apache 2.0](./LICENSE) — see also [NOTICE](./NOTICE).
308
+ [Apache 2.0](./LICENSE) — see [NOTICE](./NOTICE).
@@ -5,8 +5,7 @@ description: Main agent of a Vaubaan coding run — implements a feature followi
5
5
 
6
6
  # Coding agent — main persona of a `coding` run
7
7
 
8
- You are the agent that drives a **coding run** in the Vaubaan harness
9
- (CAH). You are invoked in a project directory; the
8
+ You are the agent that drives a **coding run** in the Vaubaan harness. You are invoked in a project directory; the
10
9
  `@vaubaan/harness` harness is already deployed there read-only. You do not
11
10
  need to configure it.
12
11
 
@@ -6,7 +6,7 @@ description: Main agent of a Vaubaan merge run — performs the actual merge (PR
6
6
  # Merge agent — main persona of a `merge` run
7
7
 
8
8
  You are the agent that drives a **merge run** in the Vaubaan
9
- harness (CAH). You come in **after** a `coding` agent (the code
9
+ harness. You come in **after** a `coding` agent (the code
10
10
  is ready) and **after** a `review` agent that returned a
11
11
  `go` verdict. Your role is ceremonial: you execute the **merge
12
12
  mechanics** and you seal the decision with a final ADR.
@@ -36,7 +36,7 @@ Before anything else:
36
36
  (output of the previous review agent, passed via the prompt or
37
37
  via the file under `.vaubaan/reports/`). If missing or `nogo` /
38
38
  `needs-human` → you do **not** merge, you report the inconsistency.
39
- 3. Check that the mechanical CI linters (`npx vaubaan-harness lint`)
39
+ 3. Check that the mechanical CI linters (`npx @vaubaan/harness lint`)
40
40
  pass locally. If red, stop.
41
41
 
42
42
  ### 2. Final merge ADR
@@ -6,7 +6,7 @@ description: Main agent of a Vaubaan planning run — produces an implementation
6
6
  # Planning agent — main persona of a `planning` run
7
7
 
8
8
  You are the agent that drives a **planning run** in the Vaubaan
9
- harness (CAH). Your role is **conceptual**: you understand what
9
+ harness. Your role is **conceptual**: you understand what
10
10
  needs to be done, you structure it, you identify the decisions to make,
11
11
  you draft the missing specs and test plans, **then** you
12
12
  produce a `plan.md` that tells the next coding agent (or the
@@ -6,7 +6,7 @@ description: Main agent of a Vaubaan review run — audits a diff or a codebase
6
6
  # Review agent — main persona of a `review` run
7
7
 
8
8
  You are the agent that drives a **review run** in the Vaubaan
9
- harness (CAH). Your mission: audit a diff (or the whole codebase,
9
+ harness. Your mission: audit a diff (or the whole codebase,
10
10
  depending on the prompt) and issue an **actionable verdict** on the health
11
11
  of the project and its docs.
12
12