@@ -102,7 +102,7 @@ read back its state and unchanged head, and refresh the review packet. Drafts
102102are excluded from the review queue, so waiting for a review before marking one
103103ready creates a deadlock. A reviewer must still obey the packet's action
104104authority and may not mark another author's Draft ready without authorization.
105- Keep exact-head review, required validation, first-screen approval and explicit
105+ Keep exact-head review, required validation, first-screen evidence and explicit
106106merge authorization as their separate gates.
107107
108108### DCO Sign-Off
@@ -278,20 +278,34 @@ the validator's explicit bilingual no-change declarations. Never treat the
278278existence of a checklist, a release PR draft, or architecture-only capability
279279copy as proof that the final release body is usable.
280280
281- ## First-Screen Review Gate
282-
283- Treat the first visible screen of public product surfaces as owner-reviewed
284- presentation, not as ordinary copy. Before committing, pushing, or self-merging
285- changes that alter the first viewport, hero block, primary CTA, or opening
286- navigation of README, hosted frontstage, showcase index pages, product home
287- pages, or similarly prominent public entry points, show the user a preview
288- first and wait for approval.
289-
290- The preview should be concrete enough to judge the presentation: provide the
291- local URL and, when the surface is visual HTML, a screenshot or browser view of
292- the first viewport. Do not move the review gate into a PR comment, todo note, or
293- final summary after the fact. It must happen before the public first-screen
294- change is finalized.
281+ ## First-Screen Review Evidence
282+
283+ Treat the first visible screen of public product surfaces as reviewable product
284+ presentation. For authorized work within the requested outcome and existing
285+ product/design contract, do not add a separate user-confirmation round before commit,
286+ push or PR submission merely because the first viewport, hero, primary CTA or
287+ opening navigation changes. Reuse prior scoped approval; a new commit or a
288+ routine refinement does not invalidate it.
289+
290+ Before submitting or updating the PR, inspect the actual first viewport and put
291+ its screenshot or browser capture directly in the PR description's visual
292+ evidence section. Include a useful before/after comparison for an existing
293+ surface, affected desktop/narrow views, and a working preview link when one is
294+ available. Identify the tested revision and whether the data and surface are
295+ synthetic, a prototype, packaged or installed. Use public-safe evidence; keep
296+ private messages, paths and live operating context out. A screenshot only in
297+ chat, a PR comment, a Todo note or the final report does not satisfy this rule.
298+ Refresh the evidence when the visible result materially changes, without
299+ requesting another approval for the same authorized direction.
300+
301+ Ask only for a genuinely missing consequential decision, work outside the
302+ accepted scope, or an explicit user instruction reserving presentation approval.
303+ Do not infer such a reservation from a first-screen change alone. Name the
304+ specific unresolved choice and continue independent authorized work. This
305+ presentation evidence rule does not grant merge, installation, release, paid
306+ execution or sensitive-data publication authority. Existing approval records
307+ remain historical evidence; older prose that merely repeats the blanket
308+ first-screen confirmation requirement follows this current rule.
295309
296310## Product Delivery Completeness
297311
0 commit comments