Panel launch prompts are hand-authored per lens per round — nothing assembles the contract, so an omitted item is invisible

[topij]

Observed across ten panel rounds on PRs #202 and #207, 2026-08-01. Severity MED.

The gap

fallback-review-panel.md specifies what every lens must be told — ten contract items plus the lens's focus from review.fallback_panel.lenses, plus the repo/branch/sha, plus the base and how its currency was established, plus the scratch-isolation rules.

Nothing assembles that. Each launch prompt is hand-authored by the cockpit, from a 598-line source (#213), once per lens per round. Twenty prompts this session.

What that costs

• An omitted contract item is invisible. Nothing compares the prompt against the contract, so a lens that was never told to mutation-test simply does not mutation-test, and its report reads as a clean pass with no mutation section. Contract item 8 asks the lens to state what it verified — but a lens cannot report the absence of an instruction it never received.
• Rounds are not comparable. I varied the framing deliberately between rounds — pointing later lenses at specific suspicions — which is useful, but it means "round 5 found less than round 4" cannot be read as "the code got better". Some of the variance is mine.
• Config that exists is not reliably applied. review.fallback_panel.lens_compute sets model and effort per runtime. On the Claude path pr_followup_hook.py renders it into a reminder, but the cockpit still transcribes it by hand into each launch. A key can be set correctly in config and silently not reach a lens.
• The base-currency statement is re-derived by hand every time, and it is the field that most needs to be mechanical: a stale base yields a large, wrong, entirely plausible diff that satisfies every other check (the doctrine says so itself).

Why the existing pieces do not close it

• pr_followup_hook.py renders a reminder to run the panel, not the prompt.
• .agents/skills/pr-watch/SKILL.md names lens_compute.codex for the Codex adapter — again a pointer, not an assembler.
• The doctrine's step 2 says to state repo/branch/sha and gives the git worktree add --detach recipe, so the inputs are specified. Nothing renders them.

Suggested

A small engine — <engine-dir>/panel_prompt.py or equivalent — that takes PR number, head sha, base sha and lens name, and emits the launch prompt: contract items verbatim from the doctrine, focus and compute from config/dev-model.yaml, and the provenance fields resolved mechanically (git rev-parse, git fetch origin <base> then compare, diffstat).

Two properties worth having, both cheap:

1. It fails closed on a stale base rather than emitting a prompt that names one.
2. It emits the same prompt for the same inputs, so a round's framing differences are deliberate additions the cockpit appends, not variance in what the contract delivered.

This also makes the contract mechanically consumable, which is the precondition for #212's "quote sources verbatim with file and line" and for any future check that a lens's report covers every item it was given.

Scope note

This is worth doing after #213 (splitting what executes from what explains), not before — an assembler that inlines 598 lines into every prompt is worse than the status quo. The executable contract is what it should render.

Related

#213 (the doctrine's length — this depends on it), #32 (the lens roster is self-reported; a rendered prompt does not fix that but is what a real check would build on), #212 (lens disagreement), #163 sink 1 (every lens rediscovering the same environment failure — a rendered prompt is where the environment answer would live once).

[topij]

Concrete argument I did not have when filing this — my own launch prompts were wrong twice in one round. PR #217, 2026-08-01.

Reviewing the wrap-up PR, the correctness lens reported two errors in the prompt I had written for it:

• it was told to read five commit messages on the branch; there were four
• it was told the sweep claim under review lived in the PR comments; it lived in a commit message, and the lens spent effort searching the comment thread before saying it could not find it

Both are the kind of provenance detail this issue proposes to render mechanically — commit count and the location of a claim are derivable, and I derived them by hand and got them wrong. The cost was not a wrong finding; the lens noticed and said so. The cost was misdirected effort and a report that had to spend space correcting its own brief.

That is a sharper case for assembly than the ones in the body, which are about omitted contract items. This is about asserted-but-wrong provenance, which an assembler cannot get wrong because it reads it from git.

[topij]

A second argument for this issue, from PR #218 (merged 30feeec) — and it is a stronger one than the original.

This issue was filed because nothing assembles the launch prompt, so an omitted contract item is invisible. PR #218 produced evidence that the assembler would also carry the highest-yield lever measured so far, which is a different and larger claim.

Across five panel rounds on that PR, the variable that moved finding-yield was not pass size or lens count — it was what the launch prompt aimed the lenses at.

• Rounds 1–3 pointed lenses at the change generally. Fourteen findings, every one in the author's claims rather than the changed content. Round 3 ran a full two-lens panel over a diff that already contained an instruction-force regression and neither lens saw it.
• Rounds 4–5 said in the prompt, in substance: prior rounds found everything in the claims and nothing in the content — invert that, attack the shipped content, and either find a gap or establish there isn't one and say how. Round 4's two lenses then independently converged on the same three gaps, including the one round 3 walked past. Round 5's two lenses independently ran a re-runnable method and both found nothing.

Those prompts were hand-authored per lens per round, which is exactly what this issue says is unmechanised. The carry-forward that worked — "here is what prior rounds have and have not covered" — has no home today except an author remembering to type it. An assembler is the natural place for it, and unlike a proportionality valve it weakens no bound and costs nothing.

Full measurement, including the caution that this is not evidence about lens count: #209 (comment)

Note the dependency this issue already records is now discharged: #213's split merged, so the contract is 13 named items in a file an assembler can extract from, rather than 598 lines of interleaved instruction and rationale. #213 stays open for its length goal, which the split did not meet.