execution-plan-reviewlisted

# execution-plan-review Present the per-issue ordering and execution assignments as one table, absorb the user's revisions, and keep the GitHub issues — the single source of truth cold agents read — in sync. ## Steps ### 1. Render the table from the issues, not from memory Fetch every issue in the milestone (`gh issue list --milestone ... --json number,title,body`) and parse the `## Execution` blocks. The table: | Issue | C | Depends on | Runs after | Build model | Effort | Validate | fableplan first? | Plan effort | |---|---|---|---|---|---|---|---|---| (Show **Validate** as the effective `<model> · <effort>` the pipeline will dispatch, derived entirely from the `[C<score>]` band: `Opus 5 · medium` at 0–9, `Opus 5 · high` at 10–40, `Opus 5 · xhigh` at 41–60, `Fable 5 · medium` at 61–80, `Fable 5 · high` at 81 and above or when the prefix is missing (this is the one inline copy in this file; the `validate-issue` step 6 band table is the authoritative source). Neither half is stampable — reject any request to stamp a `Validate model:` or `Validate effort:` line. When an issue carries a legacy stamped `Validate effort`, show it marked `ignored` — e.g. `Opus 5 · medium (stamped high ignored)` — for the same reason an inert Plan effort stays visible, and offer to strip it. Validate effort is band-derived and Plan effort defaults to high when an issue's block omits the line — show the effective value. Show Plan effort as `—` on a `fableplan first: No` issue only when it stam