Harness Configurator: stack → tools and DoD

The whole Harness Engineering series describes not tools but ROLES: 'module-boundary linter', 'dead-code finder', 'strict types'. That's deliberate — a role is the same on any stack, while the concrete tool inside it differs. This keeps the guide untied to one language, and any team plugs in its own. The configurator materializes this: it takes the abstract roles from the rollout plan and assembles a concrete setup for the chosen stack. It's essentially an interactive version of the environment.md from Phase 0 (the audit) — the very tool-selection table every later phase leans on. Except here it also hands you ready artifacts on the spot. Keep one thing in mind from the start: the tool in a cell is an example to choose, not the law. You make the final choice yourself and pin it once in ADR 0001-tool-selection.

Below is the configurator itself. Pick a stack at the top, then three tabs. 'Tools' — a role → concrete-tool table for your stack with a short reason why the role matters and a phase tag (a Phase 3 barrier or a Phase 5 GC check). 'DoD by phase' — a compact Definition of Done checklist across every rollout phase from 0 (audit) to 8 (scaling out): it shows what must be done at each step. 'Templates' — ready artifacts for the chosen stack: an AGENTS.md skeleton with the sensors already filled in, a pre-commit config and an ExecPlan template. Each can be copied or downloaded as a file. Switch the stack and the table and templates rebuild for it. This is the 'pick your bet → get a ready setup for your stack' from the series funnel.

The main selection mistake is to grab one popular tool and declare it the law of the universe. Each role has its own class of bugs, closed by a separate barrier. ESLint doesn't catch import cycles the way madge does; tsc doesn't replace a boundary linter. So the table is a set of separate roles, not a 'one-tool setup'. Second rule: pick a role by the class of bugs you actually need to catch, not by hype. If the repo has no import cycles, don't drag in madge for show: an empty barrier only slows the build and gets disabled fast. One real role with a configured tool beats seven proposed 'for later'. And whatever no off-the-shelf tool covers (your own project rule — 'no infra imports in the domain layer') you close with a custom check script in the same pre-commit + CI combo.

The 'Templates' tab gives three artifacts, and each is a working draft, not theory. The AGENTS.md skeleton already has a sensors section with the stack's tools filled in, working rules, a Definition of Done and the retrieve rule for the lessons-ledger — you just fill the placeholders about the project itself. The pre-commit config shows the combo: formatter, linter, boundaries and a type-check on the diff. The ExecPlan template is for tasks longer than a working day. The key nuance baked into the templates: barriers are enforced mechanically, not 'by discipline'. pre-commit runs on the diff (fast, before the commit), and CI repeats it all on the full base — bypassing with --no-verify won't work. And about tests in the DoD: no coverage mandate (that's Goodhart — the agent writes fake tests for the number). Instead, test-integrity: the agent may not weaken, delete or skip existing tests, and that's checked by diff in CI. Coverage is a health signal, not a target.

# AGENTS.md — sensors section (auto-filled from the matrix for your stack)
## Sensors (Definition of Done — all must be green)
- boundaries: <module-boundary linter>     # e.g. dependency-cruiser / import-linter
- types:      <strict type checker>         # e.g. tsc --strict / mypy --strict
- dead code:  <dead-code finder>            # e.g. knip / vulture
- tests green; test-integrity — do NOT weaken / delete / skip existing tests
  (checked by diff in CI). Coverage is a SIGNAL, not a target.
Enforcement: <pre-commit orchestrator> on commit (diff), CI on the full base.

The configurator is the last link in the series funnel. First, at the entrance, you pick a development mode (A / B / B+ / C) — how much AI the project even needs. If it's B+ or C (the agent writes code, a harness is needed), you come here, pick a stack and get a ready setup: which barriers to set, what counts as done per phase, and which files to start from. Then follow the series map: phase by phase, from the audit to scaling out. The configurator doesn't build the harness for you — it removes the pause of 'which tool closes this role on my stack' and 'where do I even start'. The real work — configuring barriers, describing layers, accumulating lessons — you do via the phase recipes. Head back to the hub for the full map and the rollout order.