ceo-orchestration 1.0.0

package/.claude/adr/ADR-015-reflexion-v2-outcome-loop.md

@@ -0,0 +1,248 @@
+# ADR-015: Reflexion v2 — Outcome Loop + Top-K Cap + Index
+
+## Status: ACCEPTED (2026-04-13)
+
+## Context
+
+Reflexion v1 (PLAN-003 Item A, Sprint 3) shipped lessons CRUD +
+ranking + benchmark-driven writes. It had no feedback loop: lessons
+accumulated but the framework never learned which ones helped. PLAN-006
+debate round 1 (R-VP4) flagged that v1 fails the 10× scale rule — at
+10k lessons, per-spawn cross-archetype scoring becomes O(n) file walk
+with regex parsing.
+
+PLAN-006 Phase 4 (ADR-015 + ADR-017) closes this gap **partially** —
+outcome tracking + top-K cap + index in Sprint 6; pruning is advisory
+only (see ADR-017).
+
+## Decision Drivers
+
+- **10× scale**: spawns at 10k lessons must not spend O(n) on every
+  prompt build. Must cap work and use an index.
+- **Signal, not sampling**: hit_count/miss_count are integer counters
+  written on each benchmark application — no stats estimation needed.
+- **Reversibility**: outcome tracking is additive (new fields on
+  Lesson), does not delete existing lessons, does not break v1 format.
+- **Observability**: every outcome emits an audit event
+  (`lesson_outcome`) so `audit-query.py lessons` can surface health
+  over time.
+
+## Options Considered
+
+### Option A: Statistical prior (Bayesian beta) — per-lesson posterior
+
+- **Pros:** proper handling of sample size; principled down-weighting
+  of low-signal lessons.
+- **Cons:** complexity; requires tracking prior; fails PLAN-006's
+  stdlib-only constraint without dependencies.
+
+### Option B: Integer counters + threshold rule (chosen)
+
+- **Pros:** simple; stdlib-only; n<3 → use neutral weight 1.0; n≥3 →
+  weight = 0.5 + hit_rate (range [0.5, 1.5]); confirmed winners
+  outrank untested, confirmed losers down-rank below untested.
+- **Cons:** coarse; no confidence interval.
+
+### Option C: No outcome loop (status quo)
+
+- **Pros:** zero cost.
+- **Cons:** Reflexion can't learn from outcomes; lessons grow unbounded
+  in utility-weighted influence.
+
+## Decision
+
+**Option B.** Integer counters + piecewise hit-rate weighting + hard
+top-K cap + `lessons/index.json`.
+
+### Schema extension
+
+`Lesson` dataclass adds:
+- `hit_count: int = 0` — successes attributed to this lesson
+- `miss_count: int = 0` — failures attributed to this lesson
+- `last_outcome_at: str = ""` — ISO 8601 of most recent hit/miss
+
+`Lesson.hit_rate()` returns `None` when `n < 3` (low-signal guard)
+and `hits / n` otherwise.
+
+### Ranking formula (PLAN-006 Phase 4)
+
+```
+score = archetype_match × scope_overlap × recency_decay × hit_weight
+
+hit_weight:
+  - 1.0 if hit_rate() is None (untested, n<3)
+  - max(0.1, 0.5 + hit_rate()) otherwise
+```
+
+Piecewise weighting:
+- Untested (n<3): hw = 1.0
+- Proven winner (hr=1.0): hw = 1.5 → **outranks untested**
+- Neutral (hr=0.5): hw = 1.0
+- Confirmed loser (hr=0.0): hw = 0.5 → **down-weighted below untested**
+
+Floor at 0.1 prevents total suppression — ADR-017 handles deletion.
+
+### Top-K cap
+
+```python
+def get_top_k(archetype, keywords, k=50, base_dir=None) -> List[Lesson]:
+    # Hard ceiling: K ≤ 50 regardless of caller request
+```
+
+`rank_lessons` (v1 API) delegates to `get_top_k(..., k=3)` — preserves
+injection-path budget. `get_top_k` with K=50 is used by future callers
+(Sprint 7 confidence gate, dashboards).
+
+### Scaling envelope
+
+This design is valid up to **N=5000 lessons**. Beyond that:
+- Full directory scan cost dominates even with top-K cap
+- Index lookup needs to be keyed (current index is flat list)
+- Revisit with new ADR
+
+### Audit emission
+
+`_lib/audit_emit.emit_lesson_outcome()` — action `lesson_outcome`.
+Per SPEC/v1/audit-log.schema.md §Additivity, adding a new action
+literal bumps MINOR but keeps `event_schema` value `"v2"` (matches
+ADR-011 pattern).
+
+### Index file
+
+`lessons/index.json` regenerated on every `write_lesson` /
+`record_outcome` call, under existing filelock. Structure:
+
+```json
+{
+  "generated_at": "2026-04-13T...",
+  "lesson_count": N,
+  "lessons": [
+    {"id": "...", "archetype": "...", "scope_tags": [...],
+     "hit_count": X, "miss_count": Y, "created_at": "..."}
+  ]
+}
+```
+
+Sprint 6 consumers: `prune-lessons.py` (walks index for candidates).
+Sprint 7 consumers: faster `get_top_k` without full file reads.
+
+## Consequences
+
+### Positive
+
+- Lessons can be **ranked by evidence**, not just recency + scope.
+- Proven winners rank above untested; confirmed losers rank below.
+- Top-K cap bounds per-spawn work regardless of corpus size.
+- Index file pre-aggregates for dashboards + pruning.
+- `lesson_outcome` events give time-series view of lesson health.
+
+### Negative
+
+- Benchmark runs must decide `hit | miss` classification — ambiguous
+  outcomes (partial pass) currently bucket as hit. Sprint 7 may add
+  `partial` class.
+- Two files written per outcome (lesson JSON + index.json) doubles
+  filelock traffic. Measured: negligible at N<1000.
+- Tests rely on `hit_rate()` low-signal guard (n<3). If the threshold
+  changes, tests update.
+
+### Neutral
+
+- Schema is forward-compat: old readers ignore `hit_count` / `miss_count`;
+  new readers tolerate missing fields (default to 0).
+
+## Blast Radius
+
+- `.claude/scripts/lessons.py` (EXTENDED: Lesson dataclass +3 fields;
+  new `record_outcome`, `get_top_k`, `build_index` functions; ranking
+  weighted by hit_rate)
+- `.claude/hooks/_lib/audit_emit.py` (+1 function `emit_lesson_outcome`)
+- `.claude/scripts/tests/test_lessons_v2.py` (NEW, 15 tests)
+- Index file: `$CEO_LESSONS_DIR/index.json` (NEW artifact, regenerated
+  on write/outcome)
+
+**Reversibility:** HIGH. All additive. Revert = remove new functions +
+ignore the extra Lesson fields (old Lesson() calls still work).
+
+## Amendment 2026-04-14 — Sprint 9 Phase 3 (Architect path closure)
+
+Sprint 8 Phase 3 wired the Agent Architect to INJECT top-K lessons into
+new squad drafts, but no consumer existed to record whether those
+lessons helped. Sprint 9 Phase 3 closes the loop with session_id
+correlation + undo CLI + back-compat for pre-Sprint-9 events.
+
+### Session-correlated inference rule
+
+The Architect-execute window attribution is tightened from "10-minute
+window only" to **"10-minute window AND session_id equality"**.
+Without session_id match, the outcome is NOT recorded — this
+prevents attribution attacks via unrelated vetos that happen to fire
+in the same 10 minutes.
+
+```
+def infer_outcome(session_id, spawn_end, events):
+    # Returns "hit" or "miss"
+    for e in events:
+        if e.session_id != session_id: continue       # MUST match
+        if not (spawn_end <= e.ts <= spawn_end + 10min): continue
+        if e.action == "veto_triggered": return "miss"
+        if e.action == "confidence_gate" and e.fail_count > 0:
+            return "miss"
+    return "hit"
+```
+
+Implementation: `.claude/hooks/emit_architect_outcome.py` (separate
+file — cleaner than widening `check_agent_spawn.py`).
+
+### New fields on `lesson_outcome` events
+
+Per PLAN-009 P3.5:
+
+- `consumer: "architect" | "benchmark"` — closed enum, see
+  `lessons.VALID_CONSUMERS`. New values require SPEC amendment.
+- `inference_mode: "window-only" | "session-correlated" | ""` —
+  Sprint 9+ Architect paths emit "session-correlated"; older
+  benchmark paths emit `""` (pre-Sprint-9 legacy).
+- `window_duration_seconds: int` — attribution window (0 = n/a).
+- `session_end_reason: "timeout" | "explicit" | "unknown" | ""`.
+
+### Back-compat for pre-Sprint-9 events (A23)
+
+Events emitted before Sprint 9 lack the `consumer` field. Consumers
+of the audit log MUST parse missing `consumer` as `"benchmark"`
+(single-consumer era default). This is documented in
+`SPEC/v1/audit-log.schema.md` v2.2.2.
+
+### Undo CLI (P3.3)
+
+`lessons.undo_outcome(lesson_id, consumer)` ships as an admin-facing
+escape hatch for reversing a bad attribution. Decrements the larger
+of (hit_count, miss_count) by 1; emits `lesson_outcome_undone` event
+(schema v2.3, `_KNOWN_ACTIONS` amended).
+
+### Known bypass — window-only records under session ambiguity
+
+Pre-Sprint-9 `lesson_outcome` events have `inference_mode=""` or
+missing. Under session ambiguity (multiple overlapping sessions in
+the same 10-min window), window-only records can be attributed
+wrongly. Sprint 9 marks these as dirty signal and EXCLUDES them by
+default from `audit-query architect-outcomes` — use
+`--include-window-only` to opt in.
+
+## References
+
+- PLAN-006 §Phase 4
+- PLAN-006/debate/round-1/vp-engineering.md §R-VP4 (10× scale)
+- PLAN-006/debate/round-1/consensus.md §K2
+- PLAN-009 §Phase 3 P3.1-P3.6 + debate consensus.md §C4/A7/A23
+- ADR-011 — Event stream v2.1 additive-action pattern
+- ADR-017 — SUPERSEDED by ADR-020 (Sprint 9)
+- ADR-020 — Lesson pruning policy v2
+- ADR-018 v1.1 — Claim grammar
+- ADR-019 — Confidence gate enforcement lifecycle
+- Shinn et al. 2023 — Reflexion: Language Agents with Verbal
+  Reinforcement Learning
+
+## Enforcement commit
+
+`043de3bfa120` (retrofit — PLAN-050 Phase 2 / PLAN-045 F-06-03; this anchors the file's introduction commit, not a runtime-behavior commit. For ADRs whose decision was wired into hooks/scripts in a later commit, amend this line manually.)

package/.claude/adr/ADR-016-spawn-token-tracking.md

@@ -0,0 +1,179 @@
+# ADR-016: Spawn Token Tracking — Contract and Null Semantics
+
+## Status: ACCEPTED (2026-04-13)
+
+## Context
+
+The v2 audit log schema already declared nullable `tokens_in` /
+`tokens_out` / `tokens_total` fields on `agent_spawn` events (see
+`SPEC/v1/audit-log.schema.md` §"v2"). But until Sprint 6, every
+emitter wrote them as `null` — no code actually extracted token
+counts from spawn responses.
+
+PLAN-006 debate round 1 (R-SB4) flagged ambiguity: "null-allowed" in
+JSON admits **three states** — field absent, field present as null,
+field present with integer. Without a contract declaring which state
+means what, each consumer reimplements the null check differently
+(some treat absent as "pre-field-exists era", some as "adapter couldn't
+report", etc.).
+
+Plan also flagged (R-SB8) that the original Phase 5 wording implied
+the fields were new; they already existed in the schema. The actual
+work is writer-side: populate the fields from spawn response data.
+
+## Decision Drivers
+
+- **Adapter portability.** Claude uses `usage.input_tokens`; Gemini
+  uses `usageMetadata.promptTokenCount`; OpenAI uses `usage.prompt_tokens`.
+  The extractor must probe multiple shapes without guessing.
+- **Consumer ergonomics.** `audit-query.py tokens` must be able to
+  distinguish "we don't know if this emitter supported tokens" from
+  "emitter supports tokens but couldn't extract on this record".
+- **Fail-open.** Token extraction is observability; never blocks the
+  user session. Any exception → (None, None).
+- **No SPEC version bump.** Semantics amendment is additive to the v2
+  schema documentation — consumers that don't read the amendment still
+  work (they just can't distinguish absent-vs-null).
+
+## Options Considered
+
+### Option A: Required field (always integer), adapters estimate 0 when unknown
+
+- **Pros:** simplest consumer logic.
+- **Cons:** "0 tokens" is semantically wrong when we don't know;
+  skews aggregates; indistinguishable from "spawn used zero tokens"
+  (genuinely possible for cached responses).
+
+### Option B: Optional nullable, absence == "older emitter" (chosen)
+
+- **Pros:** 3-state distinction lets operators measure adapter
+  coverage (what % of spawns have token data) separately from
+  aggregate volume; forward-compatible with new adapters.
+- **Cons:** consumers must handle 3 states; misread as "null means
+  zero" is possible (mitigated by SPEC doc + `audit-query.py tokens`
+  reference implementation).
+
+### Option C: Always integer with sentinel (-1) for "unknown"
+
+- **Pros:** avoids null in JSON.
+- **Cons:** -1 is not semantically "unknown" — it's a negative count.
+  Breaks tolerance matrix for consumers that validate `value >= 0`.
+
+## Decision
+
+**Option B.** Optional nullable, always-present-when-emitter-supports-it.
+
+### Extractor: `_lib/tokens.py`
+
+```python
+from _lib import tokens
+
+tin, tout = tokens.extract_tokens(event.tool_response)
+# tin, tout are each Optional[int] — None when shape is unknown
+```
+
+### Probe order (fail-over down the list)
+
+1. `tool_response.usage.input_tokens` + `output_tokens` (Claude, Anthropic SDK)
+2. `tool_response.usage.promptTokenCount` + `candidatesTokenCount` (Gemini nested)
+3. `tool_response.usage.prompt_tokens` + `completion_tokens` (OpenAI-ish)
+4. `tool_response.usageMetadata.*` (Gemini top-level)
+5. `tool_response.totalTokens` (legacy Claude — output-only)
+6. None, None (unknown)
+
+### Emitter contract
+
+Emitters that call `extract_tokens` MUST always set the key in the
+emitted record, even when the value is None:
+
+```python
+tin, tout = tokens.extract_tokens(event.tool_response)
+entry = {
+    ...,
+    "tokens_in": tin,       # int or None — key ALWAYS present
+    "tokens_out": tout,     # int or None — key ALWAYS present
+    "tokens_total": tokens.total_tokens(event.tool_response),
+}
+```
+
+Emitters that don't call `extract_tokens` (pre-ADR-016 code) leave
+the keys absent — consumers interpret absence as "older emitter".
+
+### Consumer contract
+
+Per `SPEC/v1/audit-log.schema.md` §"tokens_* field semantics":
+
+| State | Meaning |
+|---|---|
+| Key absent | Pre-ADR-016 emitter |
+| Key present, null | Post-ADR-016 emitter, extraction failed |
+| Key present, integer ≥ 0 | Extracted count |
+
+Consumers MUST NOT sum null values; MUST NOT treat absent as 0 for
+aggregation purposes.
+
+### Reference implementation
+
+`audit-query.py tokens` — groups by skill / subagent_type / day, reports:
+- `totals.tokens_in` / `tokens_out` / `tokens_total`
+- `totals.spawns_with_tokens` / `spawns_without_tokens`
+- Per-group breakdowns
+
+`spawns_without_tokens` combines both "absent" and "null" states —
+Sprint 7 may split these into separate counts when Gemini adapter
+reaches real parity.
+
+## Consequences
+
+### Positive
+
+- Adapter coverage becomes measurable (`spawns_with_tokens /
+  total_spawns`).
+- Aggregates stay correct (null values never corrupt sums).
+- Three-state semantics match how the audit log already handles
+  `event_schema` (absent = v1, present = v2+).
+- New adapters plug into `extract_tokens` by adding a probe without
+  modifying the emitter wiring.
+
+### Negative
+
+- Consumers with 2-state (null-or-int) logic still work but can't
+  distinguish adapter-upgrade-era from adapter-cant-extract. This is
+  acceptable for most dashboards; the distinction matters only for
+  adapter-quality measurement.
+- Probe order is opinionated. A new adapter with a different shape
+  (e.g. named fields) requires code change to `_lib/tokens.py`. This
+  is the same trade-off as every adapter contract in the framework.
+
+### Neutral
+
+- No SPEC version bump. Amendment is documentation-only; the v2
+  schema declared these fields nullable already.
+
+## Blast Radius
+
+- `.claude/hooks/_lib/tokens.py` (NEW, ~120 LOC)
+- `.claude/hooks/tests/test_tokens_lib.py` (NEW, 23 tests)
+- `.claude/scripts/audit-query.py` (+1 sub-command `tokens`, ~70 LOC)
+- `.claude/scripts/tests/test_audit_query_tokens.py` (NEW, 6 tests)
+- `SPEC/v1/audit-log.schema.md` (+§tokens_* field semantics)
+- `.claude/hooks/audit_log.py` — wires `_lib/tokens.py` into emitted
+  record (Phase 5b, separate commit — depends on Phase 1 migration)
+
+**Reversibility:** HIGH. Extractor is additive; emitter-side wiring
+is one line added to `build_entry` in `audit_log.py`; consumer-side
+is a new sub-command. Revert = remove these paths, no data migration.
+
+## References
+
+- PLAN-006 §Phase 5a, §Phase 5b
+- PLAN-006/debate/round-1/staff-backend-engineer.md §R-SB4, §R-SB8
+- PLAN-006/debate/round-1/consensus.md §K4, §C8
+- ADR-005 — Event stream v2 foundation
+- ADR-011 — Event stream v2.1 (injection_flag — precedent for additive
+  actions without schema version bump)
+- `SPEC/v1/audit-log.schema.md` §"tokens_* field semantics"
+
+## Enforcement commit
+
+`e31edc1e5e4e` (retrofit — PLAN-050 Phase 2 / PLAN-045 F-06-03; this anchors the file's introduction commit, not a runtime-behavior commit. For ADRs whose decision was wired into hooks/scripts in a later commit, amend this line manually.)

package/.claude/adr/ADR-017-lesson-pruning-policy.md

@@ -0,0 +1,193 @@
+# ADR-017: Lesson Pruning Policy — Advisory Sprint 6, Bounded Execute Sprint 8
+
+## Status: SUPERSEDED by ADR-020 (2026-04-14)
+
+> **Current policy lives in [ADR-020](./ADR-020-lesson-pruning-policy-v2.md).**
+> This ADR is retained as historical record. See ADR-020 §ADR-017
+> supersede for the migration rationale (PLAN-009 Phase 2 C8/A5).
+
+### Historical status
+
+- ACCEPTED 2026-04-13 (Sprint 6, v1)
+- AMENDED 2026-04-13 (Sprint 8, bounded execute)
+- SUPERSEDED 2026-04-14 (Sprint 9, ADR-020)
+
+## Sprint 8 Amendment (bounded execute)
+
+PLAN-008 Phase 4 enabled `--execute` with **three safeguards** instead
+of the "post-FPR-measurement" gate the original version required. The
+debate round 1 consensus on PLAN-008 (VP Engineering R-VP1 HIGH) was
+explicit that enabling execute without a measured FPR baseline would
+be a governance violation. The chosen response:
+
+1. **Env-gate:** `--execute` refuses with exit 10 unless
+   `CEO_PRUNE_EXECUTE=1` is set. Opt-in per invocation prevents
+   accidental pruning from automated runs.
+2. **Per-invocation cap:** `--max-archive N` (default 3) limits the
+   blast radius of any single run. Even if the threshold is wrong,
+   damage is bounded.
+3. **Restore companion:** `.claude/scripts/lesson-restore.py` ships
+   in the same sprint, reversing the archive move. `lesson_restored`
+   event emitted per restore.
+
+**Honest framing:** Sprint 8 does NOT claim FPR has been measured.
+Sprint 8 enables execute *as the mechanism for collecting FPR
+baseline data* — archival events + their later restoration (true
+positive or false positive per operator review) are the data
+source. The original "post-FPR-measurement" gate is now worded as:
+post-FPR-measurement, Sprint 9 decides whether to lift the cap or
+remove the env-gate. If measured FPR > 5%, this ADR re-opens and
+execute is rolled back.
+
+The preview path (`--execute --plan-only`) and per-batch receipt
+file (`prune-receipt-<ISO>.json`) were added per debate consensus
+C9 (Staff Backend) so repeated operator runs are auditable even
+across wall-clock-dependent record_outcome() drift.
+
+Sprint 8 implementation details in `.claude/scripts/prune-lessons.py`.
+
+---
+
+## Context (original, Sprint 6)
+
+## Context
+
+PLAN-006 original Phase 4 bundled Reflexion outcome tracking AND
+auto-pruning into a single ADR. PLAN-006 debate round 1 (R-VP3) split
+them: outcome tracking (counters) is additive + reversible; auto-
+pruning is **irreversible** data operation on accumulated context. If
+the outcome signal is noisy (R-VP3 + Q3 open question), auto-pruning
+silently deletes lessons that took dozens of spawns to accrue.
+
+VP Engineering cited the skill's rule: irreversible + high-blast →
+ADR first + advisory-then-blocking pattern (same as confidence gate,
+coverage gate).
+
+This ADR documents the pruning policy. Sprint 6 ships it **dry-run
+only**; Sprint 7 measures false-positive rate (FPR), then decides
+whether to enable enforcing mode.
+
+## Decision Drivers
+
+- **Irreversibility.** Deleted lessons can't be recovered except from
+  git history. A noisy signal that flags 30% of lessons as "losers"
+  would evaporate the corpus.
+- **Signal maturity.** Sprint 6 is the FIRST sprint with outcome
+  data. No empirical basis for threshold selection yet.
+- **Consistency.** Mirrors confidence gate (Sprint 6 advisory, Sprint
+  7 decide-to-block) and coverage gate (Sprint 5 measure-only,
+  Sprint 6 enforce).
+
+## Options Considered
+
+### Option A: Auto-prune in Sprint 6 when hit_rate < 0.3 at n≥5
+
+- **Pros:** keeps corpus curated; acts on signal immediately.
+- **Cons:** no FPR evidence; a confirmed-miss lesson might be correct
+  advice that consistently arrives in wrong contexts (scope issue,
+  not content issue); deletion bypasses review.
+
+### Option B: Archive-not-delete, advisory-only Sprint 6 (chosen)
+
+- **Pros:** reversible (archived lessons can be restored); builds
+  FPR evidence; aligns with confidence-gate + coverage-gate cadence;
+  operator reviews candidates before Sprint 7 decision.
+- **Cons:** delays actual corpus curation by one sprint; requires
+  separate `--execute` gate in Sprint 7.
+
+### Option C: Delete immediately at much stricter threshold (n≥20, hit_rate<0.1)
+
+- **Pros:** very conservative; low FPR.
+- **Cons:** at N<5000 lessons in practice, threshold rarely triggers;
+  effectively does nothing; doesn't solve the "curate corpus" goal.
+
+## Decision
+
+**Option B.** Advisory-only `--dry-run` in Sprint 6. No code path
+deletes or archives lessons. CLI flag `--execute` raises
+`NotImplementedError` (exit code 10).
+
+### Prune criteria (Sprint 6 dry-run)
+
+A lesson is a **candidate** when:
+- `hit_count + miss_count >= 5` (minimum sample size)
+- `hit_rate < 0.3` (heavy miss bias)
+
+Sprint 6's `prune-lessons.py --dry-run` identifies candidates +
+emits to stdout (human or JSON) + exits 0. No files modified.
+
+### Archive-not-delete (Sprint 7 plan)
+
+When Sprint 7 enables `--execute`, the behavior is:
+1. Copy lesson JSON to `$CEO_LESSONS_DIR/archive/<lesson_id>.json`
+2. Emit audit event `lesson_archived` (new v2 action)
+3. Remove from active `lessons/` directory
+4. Restore path documented: copy back from archive + rebuild index
+
+**Never delete** — archive only. Git history is a secondary recovery
+layer; the primary restore path is `archive/`.
+
+### FPR measurement (Sprint 7)
+
+Before enabling enforcement, Sprint 7 operator reviews a sample of
+candidate lessons and classifies each:
+- True positive: lesson was genuinely wrong / stale
+- False positive: lesson was correct but misapplied to wrong context
+
+FPR threshold to enable enforcement: `FPR ≤ 15%`. If higher, the
+threshold (sample size or hit_rate cutoff) tightens, or enforcement
+stays deferred.
+
+### Minimum sample size rationale
+
+`n >= 5` chosen because:
+- Binary outcomes with n<5 have very wide confidence intervals
+- At n=5, 1/5 = 0.2 is below 0.3 threshold (catches clear losers)
+- At n=5, 2/5 = 0.4 is above 0.3 (avoids flipping on a single outcome
+  swing)
+
+## Consequences
+
+### Positive
+
+- No corpus destruction in Sprint 6.
+- Operator sees candidates and can override / investigate before
+  enforcement.
+- Mirrors the advisory-then-blocking pattern already proven in the
+  framework (coverage gate, confidence gate).
+- `prune-lessons.py --json` output feeds dashboards without side-effects.
+
+### Negative
+
+- Sprint 6 ships the CLI but does not curate the corpus. If the
+  corpus grows noisy before Sprint 7 ships enforcement, ranking in
+  `get_top_k` already down-weights losers (via ADR-015 hit_weight
+  formula), so user-facing injection is minimally affected.
+- `--execute` flag is a visible "not implemented" surface — must be
+  maintained until Sprint 7 implements it properly.
+
+### Neutral
+
+- `find_candidates()` function is reusable by dashboards (future
+  audit-dashboard panel, optional).
+
+## Blast Radius (Sprint 6 scope)
+
+- `.claude/scripts/prune-lessons.py` (NEW ~120 LOC, dry-run only)
+- `.claude/scripts/tests/test_prune_lessons.py` (NEW, ~10 tests)
+
+**Reversibility:** ABSOLUTE. Sprint 6 does not mutate any lesson. If
+Sprint 7 enforcement is never built, Sprint 6 shipped a useful
+advisory tool that ages gracefully.
+
+## References
+
+- PLAN-006 §Phase 4
+- PLAN-006/debate/round-1/vp-engineering.md §R-VP3
+- PLAN-006/debate/round-1/consensus.md §K1
+- ADR-015 — Reflexion v2 outcome loop (companion)
+- Sprint 7 plan (TBD) — FPR measurement + enforcement decision
+
+## Enforcement commit
+
+`043de3bfa120` (retrofit — PLAN-050 Phase 2 / PLAN-045 F-06-03; this anchors the file's introduction commit, not a runtime-behavior commit. For ADRs whose decision was wired into hooks/scripts in a later commit, amend this line manually.)