Summary and open work

About the point in time this series describes

This series is a record based on the harness environment as it existed at the time of writing (file contents, run logs, file counts). The harness has kept evolving since this series was written, so quoted file contents, counts, and procedures may differ from the current state. The focus of this series is the design ideas (five-facet separation, verification gates, growth discipline) rather than the specific values.

As the final chapter of this series, this organizes everything covered so far into a 3-tier summary, the state of the 4 Quality metrics, open items, and the road ahead.

9.1. 3-tier summary

The core in three layers:

What the current harness is

A harness rebuilt by independently porting nrslib/takt's Faceted Prompting (5-concern separation) + 8 design principles onto Claude Code as orchestrator (takt-inspired), which has kept growing under discipline via usage-driven additions ever since the zero-rebuild.

• 5 concerns = Persona (agents/) / Policy (rules/) / Instruction (skills/) / Knowledge (knowledge/ + repos/<repo>/) / Output Contract (output-contracts/)
• hooks are not a facet but the enforcement layer (Computational Sensors)
• The asymmetry of "easy add / hard delete" that once ballooned it to a few-hundred-file scale is flipped: friction at the entrance, pull at the exit
• The zero-rebuild compressed it sharply, and it keeps growing again via usage-driven addition since, though hooks tend to grow ahead of the other facets (reflecting deterministic backing of Inferential Guides)

How it operates

A /spec-design to freeze the spec + a /autodev to drive the subagent chain — the autonomous-dev flow.

• /spec-design: human + AI co-author acceptance criteria (pass conditions = test oracle); SHA-pinned in state.md on approval
• /autodev: orchestrator (main agent) drives the ⓪'-⑤ verification-gate loop
  • ① architect → ①' plan-reviewer → ② human approval → ②' compose story → ③ developer (impl in worktree) → ④ auditor → ⑤ ff merge
• Each review phase has the VERDICT: PASS|FAIL output contract; grep '^VERDICT:' fail-closed branching
• The learning version is /smi-auto-dev (preserve quality gates and stack G1/G2/G3 understanding gates)

Why it operates this way

Because Claude Code has no composer.

• Composing every facet via Read paths probabilistically silent-drops
• Split delivery by criticality into 3 tiers: gating facets inline + hooks / Instructions preload / Knowledge index + on-demand
• Norm-delivery to subagents is structurally guaranteed by no-path-scope (= always loaded) + absolute-path injection
• Important norms get the Inferential Guide + Computational Sensor (hook) pair for deterministic enforcement

9.2. State of the 4 Quality metrics

The 4 Quality metrics (Task Resolution Rate / Code Churn Rate / Verification Tax / Defect Escape Rate) referenced in this series, as of now:

Metric	Current	Open items
Task Resolution Rate	Qualitative: autodev flow completed several tasks (palindrome-check / anagram-check / fizzbuzz-cli, and more) including VERDICT-FAIL bounces	Monthly base definitions (completions / aborts / bounces aggregated) not implemented
Code Churn Rate	Qualitative: minimal rework on completed tasks (no fix-ups after done.md is set)	Post-merge churn (commit rate of fixes after merge) not measured
Verification Tax	Qualitative: compressed context cost via "grep VERDICT only," not reading full review.md	Average tokens / phase counts / human attention budget per task not measured
Defect Escape Rate	Qualitative: 10-case verbatim transcription of spec table (anagram-check) etc. blocks internal leakage	Monthly count of "defects discovered after merge" not aggregated

Overall, qualitatively improving but no quantitative monthly measurement yet.

Priority order for implementation:

1. Task Resolution Rate is most basic; base definitions (autodev completions / bounces / stagnation triggers) are clear
2. Verification Tax with context cost (token usage) measurement enables per-subagent cost breakdowns
3. Code Churn Rate and Defect Escape Rate require post-merge observation (1 week / 1 month) — hard to verify in scratch repos (autodev-smoke)

These will likely be folded in along with deployment to work repos (9.3).

9.3. The road ahead

Open items and direction:

Road 1: monthly automation of the 4 Quality metrics

Aggregate the metrics from the previous section on the same monthly cadence as /harness-prune. Implementation requirements:

• Aggregate over state.md / done.md / review.md in handoff dirs
• Count VERDICT FAILs / bounces / error_signature stagnation flags
• Split the base into "completions" and "aborts," report each metric as a ratio
• To avoid self-bloat, keep the measurement skill separate from /harness-prune (e.g. /harness-metrics or /harness-prune --metrics)

Road 2: deployment to work repos

The autodev flow in this series matured against a scratch repo (autodev-smoke). The next step is applying it to real work repos (company / customer).

Reasons for caution:

• Work repos are typically multi-repo (frontend / backend / shared-lib); the autodev SKILL's single-repo design (at the time of writing) needs multi-repo extension (= Phase 4-6 in immutable-popping-planet plan)
• Work repos are team-shared; project-init's personal-overlay variant (team assets untouched) needs a stable route
• Per-repo Policy must align with work-repo constraints (existing CI / lint / merge rules)

Direction:

1. Create the ~/.claude/repos/<repo>/ layer in a work repo via project-init's personal-overlay variant
2. Try /autodev on small single-task items (single-repo bug fixes)
3. Tackle multi-repo tasks after Phase 4-6 of immutable-popping-planet plan is implemented

Road 3: considering /harness-prune extensions

At the time of writing, /harness-prune detects 4 items (30-day-zero / size cap / orphan / dangling). The verbatim-drift detection covered in Chapter 8 was intentionally not added.

Future candidates:

• String-commonality between same-kind facets (auto-detect one-file-one-concern violations)
• Per-subagent 30-day spawn-count aggregation (role-usage visibility)
• Handoff-dir orphan detection (handoffs whose state.md isn't merged / aborted)

The discipline (fixed items, self-bloat prevention) on /harness-prune will likely make any additions land as separate skills.

9.4. Out of scope for this series

Items explicitly out of scope:

• multi-repo autodev: Phase 4-6 of immutable-popping-planet plan (task-centric redesign, cross-repo pass conditions) is not in this series. A separate series or ADR when implemented
• Full subagent run transcripts: out of consideration for length and context, summaries are in the body; full transcripts live in handoff dirs (readers can directly Read ~/.claude/repos/autodev-smoke/handoff/anagram-check/)
• Concrete per-repo Policy examples in work repos: not deployed yet
• Cross-model harness behavior comparisons (Opus / Sonnet / Haiku, and more): this series is verified on one specific model; cross-model reproducibility is not verified

9.5. Closing: why this was written

Final note on motivation.

As covered in Chapter 1, the pre-rebuild harness had swollen through a feedback loop of the four symptoms. After the zero-rebuild compressed it sharply, it has kept growing under discipline via usage-driven additions ever since — that is where this series stands (see Chapter 7 for details).

Full rebuild teaches: changing structure requires archiving accumulation once. Root symptoms that can't be reached by partial fixes can recur somewhere in the new harness. Writing this series after some time in actual operation, rather than right after bootstrap, was driven by:

• Wanting to document, as a concrete example, the fact that it did not stop at compressing once but kept moving via usage-driven additions (dispelling the illusion that "bootstrap achieves a perfectly stable number")
• Wanting to write after the post-bootstrap iteration cycles (the examples covered in Chapter 8) had exposed structural weaknesses
• Wanting to leave a rebuild snapshot that the author can self-review later

This series is the author's individual operation, not an industry standard. The word Faceted Prompting itself adopts an existing organizing axis, but what goes in which facet, how to structure the autodev flow, and the operational policies for each discipline are all the author's judgment. Read it less as a recipe and more as one example of what harness engineering can look like when actually run.

Series-wide takeaways

• The new harness independently ported nrslib/takt-derived Faceted Prompting (5-concern separation) + 8 design principles onto Claude Code, and keeps growing via usage-driven additions even after the zero-rebuild's compression (quantitative growth and qualitative bloat are kept separate)
• Subagent context loss structurally resolved by no-path-scoping + absolute-path injection
• Norms backed deterministically by the Inferential Guide + Computational Sensor pair
• Friction at entrance, pull at exit by the 5 disciplines structurally prevents re-bloat (inverted approval defaults to delete)
• Bootstrap can't be perfect. The ratchet cycle (problem-find → analysis → fix → verification) is what keeps it running

Running the harness reveals new failures over time. Structurally resolving them via ratchet, one at a time, is the essence of harness engineering. The next rebuild of the harness will use this series as the snapshot to compare against.

---

Thank you for reading to the end. Questions and corrections welcome via GitHub Issues.