feat(skills): add 3-way adversarial plan-challenge phase to reflection orchestrators

After a plan/reflection is elaborated and before it executes, three fresh blind
sub-agents (correctness / robustness / simplicity) attack it on the big model;
the main loop RE-THINKS every aspect a BLOCKER lands (a named plan change, or
[deferred]) and re-challenges once if the plan materially changed. Advisory into
each skill's existing human gate — the human stays the decider.

- lib/challenge-plan.md — reusable phase: fail-safe (never fail open),
  severity-driven (any single-lens BLOCKER = must-address), RE-THINK loop
- agents/plan-challenger.md — challenger role (read-only, big-model per BDR-066)
- lib/tests/plan-challenger.test.sh — 41-assertion structure lock
- wired into 11 orchestrators: ship-feature/init-project/feat/bugfix (build-plan),
  onboard/audit-delta/code-clean (proposals), seo/geo/harden/web-validate (fix-bundle)

Hardened by dogfooding: 3 blind challengers reviewed this feature's own v1 plan
and caught 4 BLOCKERs (fail-open, consensus-buries-lone-finding, wrong model
tier vs BDR-066, false on-disk-plan premise) — all fixed here.
This commit is contained in:
Bastien Chanot
2026-07-17 22:51:50 +02:00
parent 23c8c290d7
commit 6bfc0543e5
15 changed files with 443 additions and 1 deletions
+19 -1
View File
@@ -119,11 +119,29 @@ TOTALS: <N blocking, N warn, N info>
If no issues found: report clean state and stop.
## STEP 3b — CHALLENGE THE SCOPE (before approval)
The STEP 3 report is the proposed cleanup scope — worth attacking before the
human approves it. It is still inline, so FIRST persist it to
`.claude/tasks/plans/<date>-<slug>-<HHMM>.md` (STEP 3 report format, one item
per line), then run `$HOME/.claude/lib/challenge-plan.md` with `PLAN` = that
file, `KIND` = `proposals`, `SCOPE` = the scanned target ($ARGUMENTS or repo
root), `CONSTRAINTS` = the STEP 1 project norms + the iron law (zero behavior
change). Three blind challengers ask whether these are the RIGHT items and what
the scan under- or over-scoped; the main loop RE-THINKS every aspect a BLOCKER
lands (a named scope change re-written into the report, or `[deferred <date>]`)
and re-challenges once if the scope materially changed. Feed the REVISED scope +
a CHALLENGE SUMMARY into STEP 4. Advisory — the human still approves per item.
## STEP 4 — VALIDATION GATE (interactive)
Present the report from STEP 3. Then ask:
Present the report from STEP 3 with the STEP 3b CHALLENGE SUMMARY. Then ask:
```
CHALLENGE SUMMARY (STEP 3b — 3 lenses):
BLOCKERs addressed : <n> — <finding → the named scope change that closes it>
Deferred (human-ack): <list | none>
Lenses returned : correctness / robustness / simplicity (NAME any that failed to return)
AskUserQuestion:
Approve which items for execution? (all / <item numbers> / clarify <item>)
```