feat(recipe-report): restructure page — priority-sorted wire table w/ CVE column, addendum, per-recipe changes

New page order: short lead -> the full wire table (sorted by priority-to-address,
CVE recipes first, new CVEs count column) -> Addendum (bullets of real special
issues, omitted if clean) -> Security Bulletin -> per-recipe "What changed".

- recipe-report.py: _table() gains a CVEs column + recipe-name linking; new
  _changes() helper; render() reordered; docstring SPEC SHAPE updated
  (cve/addendum/changes added, needs_attention/routine removed).
- recipe-report/SKILL.md + example-spec.json: new procedure, spec shape, and
  gold-standard template (2026-06-05, new format).
- launch-report.py: kickoff text reflects the new priority-ordered structure.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.claude/skills/recipe-report/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: recipe-report
-description: Generate the weekly public "Recipe Report" after the cc-ci /upgrade-all run. Reviews how the upgrade went and the state of every recipe + open PR, classifies what needs attention vs routine, and publishes a self-contained HTML page to report.ci.commoninternet.net (one page per week + a home index). Read-only — reports, never merges or edits PRs. Runs as its own agent (model configured separately from the upgrader; default opus). Invoke as /recipe-report [YYYY-MM-DD].
+description: Generate the weekly public "Recipe Report" after the cc-ci /upgrade-all run. Reviews how the upgrade went and the state of every recipe + open PR, and publishes a self-contained HTML page to report.ci.commoninternet.net (one page per week + a home index). Page order: short lead → the full wire table (priority-sorted, CVE-count column, CVE recipes first) → Addendum of special issues → Security Bulletin → per-recipe "what changed". Read-only — reports, never merges or edits PRs. Runs as its own agent (model configured separately from the upgrader; default opus). Invoke as /recipe-report [YYYY-MM-DD].
 ---
 
 # recipe-report
@@ -24,34 +24,45 @@ Helper: `python3 /srv/cc-ci/cc-ci-plan/recipe-report.py {survey|render|publish}`
    verdict; and each recipe's **per-recipe upgrade notes** (`upgrade_notes_md` — the breaking-change /
    **CVE / security** analysis the upgrade did). Read it all.
 
-3. **Review & classify — this is a front page, write it like an editor.**
-   - **Security first.** Scan the per-recipe `upgrade_notes_md` + the summary (and use your own knowledge
-     of the version bumps) for upgrades that fix **CVEs / security issues**. Anything **critical/high**
-     leads the page → the `security` bulletin (recipe · CVE id(s) + severity · what it fixes · PR link).
-     This is the most important section; be specific about severity and what's exposed if not merged.
-   - **Lead / editorial.** Write the `lead` in opus's voice — useful, concrete, opinionated. **~3 short
-     paragraphs, ~150–180 words:**
-     1. **Fleet state** in a line or two — how healthy, what moved, any trend.
-     2. **What to focus on** — security/critical merges first, then the key failures.
-     3. **Anything strange worth looking into** — odd or unexpected failures, parser snags, PR-state
-        oddities (e.g. a recipe carrying two open PRs to reconcile), drift from the summary, leftover
-        artifacts. This is the "editor's eye" paragraph; flag what a careful maintainer would want to notice.
-     Lead with the single most important thing; the rest of the page carries the detail.
-   - **Needs attention** — GREEN PRs ready to merge + errors/failures to investigate (RED `!testme`,
-     recipe bugs). Short, specific prose + links. Flag cross-cutting issues (e.g. two open PRs to reconcile).
-   - **Routine** — minor/clean bumps, stale-test PRs (need operator `--with-tests`), up-to-date / skipped.
+3. **Review & classify.** The page order is: **short lead → the full wire table (priority-sorted) →
+   Addendum → Security Bulletin → per-recipe "What changed".** Same newspaper style; this order.
+   - **Security analysis.** Scan the per-recipe `upgrade_notes_md` + the summary (and use your own
+     knowledge of the version bumps) for upgrades that fix **CVEs / security issues**. For each recipe,
+     **count the CVEs** the PR fixes — this drives both the table's `cve` column and the priority sort.
+     Anything **critical/high** also gets a `security` bulletin entry (recipe · CVE id(s) + severity ·
+     what it fixes · PR link); be specific about severity and what's exposed if not merged.
+   - **Lead — ONE short paragraph.** A tight, concrete opener in opus's voice: fleet state in a sentence
+     (how healthy, what moved) and what to address first. Lead with the single most important thing; the
+     table and sections carry all the detail. Do NOT write multiple paragraphs.
+   - **Priority sort for the table.** Order rows by **recommended priority to address**:
+     1. recipes **with CVEs** first (more/higher-severity CVEs higher),
+     2. then **FAILED** (RED) recipes,
+     3. then **STALE**-test recipes,
+     4. then routine **GREEN** bumps,
+     5. then **UPTODATE / SKIPPED** last.
+   - **Addendum — special issues to look into.** A bullet list of real anomalies worth an operator's
+     eye: a recipe carrying **two open PRs** to reconcile, a **CI-run oddity** (flaky tier, needed
+     re-runs), drift between the summary and reality, a **misleading branch name**, a tooling snag that
+     silently drops a recipe, leftover artifact PRs, or **something in the test run that could be
+     improved**. **Only real issues — if everything looks clean, leave it empty; do NOT invent items.**
+   - **What changed — per recipe with a PR.** One short section per recipe that has a PR this week
+     describing what the upgrade actually changes (versions, notable deps, migrations/gotchas, reconcile
+     notes). Skip recipes with no PR.
 
-4. **Write the spec** `/tmp/report-spec.json` (shape in the helper header): `date`, `subtitle`
-   ("Week of <human date>"), `lead` (the editorial, blank-line-separated paragraphs), `security[]`
-   (critical-CVE upgrades — may be empty), `needs_attention[]`, `routine[]`, and a **comprehensive
-   `table[]`** with EVERY recipe (`recipe`, `change` "a → b", `status`
-   GREEN/STALE/FAILED/SKIPPED/UPTODATE, `ci` as a level/result number+info string e.g. `build 154 ✓`
-   or `RED · restore` with `ci_url`, `pr`/`pr_url`, `notes`). **CI = link + number/info only; no images.**
+4. **Write the spec** `/tmp/report-spec.json` (shape in the helper header):
+   - `date`, `subtitle` ("Week of <human date>"),
+   - `lead` — **one short paragraph**,
+   - `table[]` — EVERY recipe, **sorted by the priority above**. Fields: `recipe`, `change` "a → b",
+     `status` GREEN/FAILED/STALE/SKIPPED/UPTODATE, **`cve`** (integer count of CVEs this PR fixes; `0`
+     or omit for none), `ci` as a level/result number+info string e.g. `build 154 ✓` or `RED 200 ·
+     install` with `ci_url`, `pr`/`pr_url`, `notes`. **CI = link + number/info only; no images.**
+   - `addendum[]` — list of bullet strings (may be empty),
+   - `security[]` — critical-CVE bulletin entries (may be empty),
+   - `changes[]` — `{recipe, body, links[]}`, one per recipe that has a PR.
 
    **Template — match this.** `.claude/skills/recipe-report/example-spec.json` is the gold-standard
-   example (the 2026-06-02 report; the operator approved its style/format). **Match its editorial voice,
-   structure, field shapes, and level of specificity** — the only deliberate change is the **shorter
-   `lead`** described above. Read it before writing your spec.
+   example (operator-approved style/format/voice). **Match its editorial voice, field shapes, and level
+   of specificity**, following the section order above. Read it before writing your spec.
 
 5. **Render & publish.**
    `python3 .../recipe-report.py render /tmp/report-spec.json /tmp/week-<DATE>.html`