plan-authoringlisted

The trigger lives in the `plan-ceremony` stance. This is the contract. ## Why this exists A plan has two audiences and they are not the same reader. - **The reviewer reviews the approach.** System design, steps, and the decisions that are theirs — in one screen, before they read anything else. - **The implementing agent executes it.** Paths, sequencing, edge cases, evidence. One document written for both produces the 884-line file the reviewer gets lost in. So a plan is one file with a hard seam: a **Review Card** above the first `---`, an **Addendum** below it. **Failure test:** if the reviewer has to scroll to learn what is being built, the plan has failed, however good the work behind it is. ## The Review Card Everything above the first `---`. **Target 50 source lines, hard cap 70**, diagram included. The one thing allowed to push past 70 is a full `## Decisions for the reviewer` block — three lines each, five maximum. Never cut a real decision to hit a budget. Not an introduction to the plan — the whole plan at review altitude. These sections, this order. Do not rename them, do not add to them, do not fold one into another. 1. **`# <title>`** — 1 line. What gets built, as a noun phrase. Not a sentence. 2. **Verdict blockquote** — at most 4 lines. Two sentences, what this builds and the mechanism, then one metadata line: Effort · Risk · Blast radius. 3. **`## At a glance`** — 7 bullets. Outcome · Approach · Touches · New deps · Not in scope · Exit test ·