Review brief: temporary static sites implementation plan

You are an independent second reader of an implementation plan for the CARLOS platform (this repository). Read cold and adversarially.

Plan: docs/superpowers/plans/2026-09-26-temporary-static-sites.md at the commit named in the prompt. Spec it implements: docs/superpowers/specs/2026-09-25-temporary-static-sites-design.md (rev 9). The spec was reviewed by you over nine rounds and accepted, and the product owner has approved it. Do not re-review the design. Its rulings (§1) and mechanisms are fixed.

What to check

The plan will be executed task by task by implementers who see only their own task. Check:

1. Fidelity. Does each task implement the spec's mechanism as written? Flag any place where the plan weakens, reorders or omits something the spec requires, especially the orderings (§6 restore steps, §5 expire steps, settle-first, the tripwire rules) and every row of the §3 and §4 refusal tables.
2. Will it compile and pass? Code in the plan is written against this repo but has not been compiled. Check signatures, imports, receiver types, helper names and test fixtures against the real code. Cite file:line.
3. Cross-task consistency. Names and types a later task consumes must match what an earlier task produces.
4. Tests that would pass for the wrong reason, or that do not exercise the ordering or race they claim to.
5. Existing behaviour broken. Box code must not change, and no bucket object may change shape. Flag any existing test the plan would break without saying so.

Output

A numbered list of findings. Give each one a severity (P1 means the build is wrong or a spec guarantee is lost, P2 means wrong behaviour or a test that proves nothing, P3 means clarity), the task and step, the evidence with file:line, and a concrete fix. Then give a one-line verdict: accept or revise. Do not rewrite the plan, and leave out praise.

In later rounds you will be given your earlier findings files. Start with a disposition table, then list only new findings.