Challenge Plan 1

---
name: 'challenge-plan-1'
description: 'Round 1 of plan-challenge.'
disable-model-invocation: true
---

Round 1 of plan-challenge. Are you sure you've done all the research and followed every thread needed to reach this conclusion? If not, keep going. Look for opportunities you might be missing.

## Guard: nothing to challenge

If no plan was presented in this conversation (no construct-the-plan run, no inline plan content, no plan file referenced), decline with: "No plan to challenge in this conversation. Draft one first with construct-the-plan, write the plan inline above this command, or name a plan file." Don't invent an imaginary plan to challenge.

## Guard: repeat invocation of round 1

If round 1 already ran earlier in this conversation, treat this invocation as a second pass of round 1 with a NEW angle from the angle list. Say it explicitly: "Round 1 invoked twice; treating as a new angle within round 1. Prior round 1 angle was X; this pass uses Y."

## Inline at the top of your response

1. **Say what angle you used in your original plan.** One line. Examples: "implementation feasibility", "data flow", "user story coverage", "happy-path correctness".
2. **Pick a different angle for this round** from the list below. Say which one and why.

Then re-examine the plan from that new angle. Don't stop until you've genuinely exhausted it.

## What to look for

- Assumptions baked into the plan that aren't validated against the codebase.
- Requirements you inferred but didn't confirm with the human.
- Stakeholders, users, or systems the plan doesn't account for (operators, future maintainers, downstream consumers).
- Edge cases at boundaries: empty state, max scale, concurrent operations, partial failure, rollback, network loss.
- Non-functional concerns the plan ignores: performance, accessibility, security, observability, cost, deploy ordering. If the plan touches UI drawing or animations, does it plan to measure real frame cost rather than reason about it?
- Neighbouring systems that produce or consume the same data and aren't mentioned.
- What happens six months from now when this code feels unfamiliar; is it discoverable?
- What hasn't been read yet that could invalidate the plan?

## Useful angles to rotate through

The canonical list lives in AGENTS.md § The challenge rounds:

- implementation
- where data flows and what happens when something fails
- how this code talks to its neighbours
- how this code talks to outside services
- config-file syntax and quoting pitfalls
- what unusual or hostile inputs would break this?
- what happens when shell scripts fail mid-pipeline?
- will this code be discoverable when it feels unfamiliar?
- is the sequence of steps right?
- where else does the same root cause apply?
- check whether the earlier rounds' fixes broke anything new
- does this convention reach every place the mechanism reaches?

Plan-stage additions:

- who reads this and how?
- are there requirements I'm assuming but haven't confirmed?
- what could go wrong with this approach?
- if this change causes problems, how do we revert cleanly?

## Plan auto-update (when M > 0)

If demoted claims exist (M > 0), edit the plan file directly to address them; don't just surface and wait for approval.

The plan file is the `docs/plans/` file this conversation drafted (or the one the human named). Edit only plan files; refuse to edit anything else from this round. For each demoted claim: address it directly in the plan (rewrite affected sections, add edge-case handling, refine specs), and record the resolution in the plan's "Demoted-claims tracking" table (create the table if it doesn't exist). For claims that genuinely need the human (taste, money, priorities): defer with an inline `[NEEDS HUMAN-R1: <one-line ask>]` marker at the relevant section, and translate it to plain English in chat.

**No plan file detected:** surface the findings in chat with an explicit "no plan file found; findings surfaced above so they aren't lost."

## Self-check before posting

- Line cap: over 20 source lines for the round's report means rewrite (6-8 lines when nothing was found).
- No sub-categorized findings headers ("Verified clean:", "Runtime behavior:"). One flat list or none.
- No count-justifying listings (the number IS the report; don't expand it into a parenthetical).
- No bare confidence declarations ("confidence is high" without cited angles).
- No cross-round commentary, no forward-looking framing ("the next round would cover...").
- No jargon-stacked labels; write sentences.

If you find a violation, rewrite. Don't ship it with a note.

## End your response with the structured report

> **Re-verified N claims, demoted M to uncertainty.**

If M > 0, list each demoted claim with a one-line reason. THEN edit the plan file per "Plan auto-update" above. THEN surface a diff summary in this MANDATORY format:

```
## Plan diff summary (round 1)
- Addressed: [claim summary] -> [edit made, file:section]
- Deferred [NEEDS HUMAN-R1]: [claim summary] -> [reason]
- Kept as-is: [claim summary] -> [reason]
```

Both the structured report AND the diff summary (when M > 0) MUST be present before declaring done.

## No-rubber-stamp guard

If you find yourself reporting M=0 with similar wording to your original plan, you've rubber-stamped. The angle wasn't genuinely different. Go again with a real new angle before responding. M=0 is acceptable ONLY when the new angle was genuinely different AND the re-trace exercised territory the original reasoning didn't.

## Rationale (recorded so future edits don't drift it)

In the project Foundry grew out of, a five-round chain's bug-catch curve ran 4, 0, 4, 3, 1: round 2 found zero because its angle accidentally repeated round 1, and every genuinely rotated round found the next layer. The value of a re-examination prompt isn't being more careful; it's forcing a fresh perspective. That's why this round opens by naming the original plan's angle and picking a different one.