Challenge Plan 2

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

Round 2 of plan-challenge. Given how much this matters, trace through the plan again from a different angle. Be sure you've done all the research and followed every thread. 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 2

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

## Inline at the top of your response

1. **Read back your prior turns in this conversation.** List every angle used so far (original plan + round 1). Format: `Angles used: [round 0: X], [round 1: Y]`.
2. **Pick a third angle** not on that list. Say which one and why it's likely to surface different problems than rounds 0 and 1.

The angle must be genuinely different. If round 1 was "where data flows and what happens when something fails" and you pick "where data flows and how this code talks to its neighbours", that's the same lens with a different label. Pick something structurally different (for example: hostile inputs, future discoverability, outside services).

Then re-examine the plan from that third 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.
- Edge cases at boundaries: empty state, max scale, concurrent operations, partial failure, rollback, network loss.
- Non-functional concerns: performance, accessibility, security, observability, cost, deploy ordering.
- Neighbouring systems that produce or consume the same data and aren't mentioned.
- Future-state: what breaks when this code feels unfamiliar six months from now?
- 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)

Same contract as round 1: edit the `docs/plans/` file this conversation drafted, record resolutions in the "Demoted-claims tracking" table, defer human-territory claims with `[NEEDS HUMAN-R2: <one-line ask>]` markers (plain English in chat), and refuse to edit anything other than plan files. If no plan file exists, surface the findings in chat so they aren't lost.

## Self-check before posting

Same checklist as round 1: line cap (20 source lines; 6-8 when clean), no sub-categorized headers, no count-justifying listings, no bare confidence declarations, no cross-round commentary or forward-looking framing, no jargon-stacked labels. Violation found means rewrite, not ship-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, edit the plan, then surface the diff summary in the mandatory format:

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

## No-rubber-stamp guard

If M=0 AND your reasoning reads similar to round 1, you've rubber-stamped. Go again with a real new angle before responding.

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

Round 2 is where angle rotation historically fails: in the project Foundry grew out of, the measured five-round curve found zero in round 2 precisely because the angle repeated round 1 under a different name. The read-back step at the top (list the angles used so far, in writing) exists to make that repeat visible before the round starts.