Fresh-Eyes Panel Procedure

Updated: 2026-07-21 10:33 ET

TL;DR: A repeatable scrutiny pass for a feature area: N independent review agents (default 3), each launched with zero shared conversation context and an orthogonal lens, each handed the area's prior-findings exclusion list, each required to return evidence-backed, severity-ranked findings — and none of them allowed to fix anything. The orchestrator then runs a convergence step: dedupe across panels, rank, and triage survivors into work items with the user. At most one panelist owns the live device; the rest work from code and captured design docs. The panel's value comes from the isolation and the lens diversity — three copies of the same reviewer is not a panel.

First run: the Flight Finder search area (2026-07-21, AB#2316 era) — used throughout as the worked example. The name comes from the project's existing "fresh-eyes pass" vocabulary (the AB#2301 UX fixes came out of the first single-agent version of this move).

Table of Contents

1. When to run a panel
2. The six properties that make it a panel
3. Phase 1 — Scope and exclusion list
4. Phase 2 — Lens roster and device arbitration
5. Phase 3 — Launch (isolation rules, prompt template)
6. Phase 4 — Convergence: dedupe, rank, triage
7. Standard lens catalog
8. Worked example — Flight Finder, 2026-07-21
9. Gotchas

1 · When to run a panel

• A feature area has just reached functional completeness (its audit findings are dispositioned, its tests are green) and the question shifts from "does it work?" to "does anything here not make sense?" — sensible defaults, edge cases, states the design never drew.
• Before graduating an area to testers or a device build, as a last sweep for experience-level surprises automation doesn't catch.
• NOT for finding functional bugs in fresh code — that's what the audit + UI-test loop is for. A panel on unstable code drowns in noise.

2 · The six properties that make it a panel

3 · Phase 1 — Scope and exclusion list

1. Name the area precisely ("Flight Finder search area only") — a panel over everything is a panel over nothing.
2. Collect the exclusion list — the sanctioned way is to run the Pre-Flight Readiness Check first: its pending-items table + settled-records list (audit rows and dispositions, closed design questions, keep-decisions) is the exclusion list. Link the actual files — panelists read them, not summaries.
3. Pick the working copy (a worktree at the current tip, or the branch under review) and note it as read-only in every prompt.

4 · Phase 2 — Lens roster and device arbitration

Default panel size is 3 — two lenses agreeing is confirmation; three is the cheapest configuration where a single-lens finding is itself information (it tells you which blind spot the other lenses share). Assign lenses from the catalog, adapted to the area. Decide which single panelist (if any) gets the live device, and verify what binary the simulator is actually running before granting it (see Gotchas).

5 · Phase 3 — Launch

Launch all panelists in parallel. Every prompt must contain, explicitly:

• "RESEARCH ONLY" up front — no file edits, no commits, no deploys.
• The lens, phrased as questions to interrogate plus "think beyond these" — the seed list bounds the floor, not the ceiling.
• The working-copy path and the primary files for the area.
• The exclusion-list docs with an instruction to not re-report dispositioned findings.
• The deliverable contract: ranked list, [severity] [issue] [evidence] [why / expected], findings only, no preamble.
• For the device-holder only: the interaction tools, where to save screenshots, and the hard prohibitions (no logout, no test runs, target the visible webview).

6 · Phase 4 — Convergence

1. Dedupe across panels — same underlying issue reported through different lenses collapses to one finding; note how many panels hit it (multi-panel hits are usually real).
2. Verify the surprising ones — anything High-severity from a single panel gets a quick orchestrator spot-check against the code or live app before it's presented.
3. Reconcile against the deviation registry — before anything becomes actionable, check each survivor against the area's known, recorded deviations from the design:
   • audit-doc rows and their dispositions (incl. explicit keep-decisions),
   • open design questions (design-questions.html),
   • decision records (D-numbers in naming-decisions-record.html),
   • token-vs-master discrepancies already captured (DQ-29 pattern).
   Each survivor lands in exactly one bucket:

   Bucket	Meaning	Action
   Already decided	Matches a recorded keep-decision or disposition and brings no new evidence.	No action; cite the record in the convergence report. (If the exclusion list was complete this bucket should be near-empty — a full bucket means Phase 1 was sloppy.)
   Reopens a decision	Matches a recorded deviation but brings new evidence the original decision never saw (real user impact, changed tokens, changed backend behavior).	Reopen deliberately: append the evidence to the existing DQ / audit row rather than filing a duplicate; flag to the user as a reopened decision, not a new finding.
   Feeds an open question	Bears on a DQ that is still open.	Attach as evidence to that DQ (timestamps per doc rules); no separate work item.
   Genuinely new	No record covers it.	Goes to triage (next step).

4. Rank the remaining actionable list by user impact, not by fix cost.
5. Triage with the user — findings graduate to work items (bug/task per repo convention, one WI + worktree + branch + PR per slice), get recorded as new design questions, or get an explicit keep-decision written into the audit doc so the next panel's exclusion list catches them. Nothing is fixed straight out of a panel.
6. Close the loop — the convergence report (merged list, buckets, dispositions) lands in the area's audit doc or as a dated section beside it, so it becomes part of the next panel's exclusion list.

7 · Standard lens catalog

8 · Worked example — Flight Finder, 2026-07-21

• Scope: Flight Finder search area only (search form, results, advanced options, search-adjacent lists).
• Exclusion list: flight-finder-audit.html (FF-1..FF-17, all dispositioned) + closed DQs.
• Roster: the three standard lenses above; panelist 3 held the device (authenticated session, read-only interaction).
• Launch: three parallel agents, fresh context each, prompts per Phase 3.
• Convergence: run per Phase 4; findings triaged with the user into work items / design questions. (This panel also produced the procedure you are reading.)

9 · Gotchas

• Verify the simulator's binary before granting the device. Shared simulators get clobbered by smoke deploys from other checkouts — maui-devflow list must show the agent registered from the worktree under review, or the device-holder's evidence is against the wrong build.
• Stacked webviews lie. After any MAUI navigate BlazorDevPage, check cdp webviews — with two instances registered, CDP defaults to the hidden one while screenshots show the visible one. Target the highest index.
• Panelists drift toward fixing. The firewall line ("RESEARCH ONLY, do not modify any files") goes first in the prompt, not last — agents weight openings.
• Auth state is shared mutable state. If the device-holder needs an authenticated session, no other process (test batches, their Order-25 logout) may run during the panel.
• Don't feed panelists your hypotheses. Seed questions should point at surfaces ("interrogate every default"), not at expected answers ("the date default is probably wrong") — a panel that confirms the orchestrator's guesses has been contaminated by them.

Related docs

• Figma Sync Procedure — upstream: how design revisions land in specs
• Component Library Reconciliation Procedure
• Feature Alignment Check — the architectural counterpart to this UX pass
• Working in This Repo — Start Here