pressure

The user has provided a plan path as the argument after $pressure. Treat that argument as <PLAN>. read doc/loom/knowledge. then read <PLAN> (the plan file) and explore the codebase. Your task is to pressure-test the plan: hunt for omissions, wrong assumptions, missing wiring, unhandled edge cases, and any step an executor could not complete from the plan alone. Validate every finding against the actual code before reporting it — cite file:line evidence; drop any finding you cannot ground. ⚠️ <PLAN> IS BEING EDITED WHILE YOU WORK. A second reviewer is folding its own findings into the same file concurrently, and your review is read only after it finishes. So: anchor every finding to a symbol, stage id, or section heading — NEVER to a line number in <PLAN>, which will have drifted by the time anyone acts on it. Re-read <PLAN> immediately before writing your report and drop any finding that has already been fixed. Cover ALL of these dimensions. The first two are the highest-yield failure classes on record. 1. CROSS-PLAN CONTRACTS. List the sibling plans in the plan's directory (PLAN-*, IN_PROGRESS-*, DONE-*) that share files, symbols, or seams with this plan, and read them. For every upstream surface this plan consumes, verify the exact symbol/signature/exporting module against committed code first, else against the sibling's stage YAML (artifacts/wiring/acceptance) — NEVER against the sibling's prose: a capability promised only in a sibling's overview is built by no stage; ...