[Feature]: Reviewer agents lack an explicit verification discipline (verify-before-pass, pre-verdict checklist)

[vnlebaoduy]

Description

The two review-only agents (aidlc-architecture-reviewer-agent, aidlc-product-lead-agent) carry a strong ## Adversarial Posture (refute, ground every finding in checkable evidence) and a ## Turn Budget, but no explicit verification discipline: how the reviewer must behave between "assume it is broken" and "write the verdict". A grep of core/agents/ finds no pre-verdict checklist in any of the 14 agent personas.

Concretely, the current prose leaves these behaviors implicit:

• Assume-AI-authored posture. Stage artifacts are increasingly produced by the lead sub-agent itself. Polished tables and confident prose are not evidence that an ID resolves or that a criterion is testable, but nothing tells the reviewer to discount presentation.
• Verify-before-pass, not only verify-before-flag. The posture text grounds findings in evidence; it does not say that an unread section cannot count toward READY. Under the turn budget this is the failure mode that silently degrades a review: "ran out of turns" becomes "no findings" becomes READY.
• Competing readings before declaring a gap. "Missing" vs "lives under another ID" vs "already pinned by a passed contract" - the reviewer should rule the alternatives out with a lookup before charging the author with an omission (each false omission costs a revision round).
• Severity ranking. Findings are not required to be ordered by what blocks a developer / fails in production vs what is merely unclear.
• A pre-verdict checklist the reviewer confirms line by line (every NOT-READY finding has an anchor, every cross-reference resolved or flagged, validation-tool output cited, no sibling-unit read, unverified concerns recorded as questions).

Use Case

Reviewer sub-agents run unattended inside the adversarial loop (Construction) and as advisory decision support at human gates (ideation/inception). In both classes the human reads only the findings. A reviewer that passes unread material, or reports a "gap" that was a lookup it owed the author, wastes a review iteration or a revision round, and the audit trail records a READY that was never earned.

Proposal

Add a ## Verification Discipline section to both reviewer personas, placed between ## Advisory Dispatch and ## Key Principles, voiced in each agent's domain (systems/blast-radius for the architecture reviewer; customer/testability for the product lead). Prose only: no frontmatter change, no protocol change, the pinned ## Adversarial Posture / ## Output Contract / ## Turn Budget text (t234, t279) untouched, harness-neutral (t146).

If this shape is acceptable, I have a PR ready and would follow with the same treatment for the producing personas (developer, quality, devsecops, then product/design/delivery/operations) in small separate PRs.

Version

2.8.2 (main @ c0eb292)

Area

Agents (core/agents/)

Additional Context

Related but orthogonal: #1059 (weighted rubric / measured gate) adds a scoring layer on top of the verdict; this issue only sharpens how the reviewer arrives at the findings that feed any such layer.

[vnlebaoduy]

Status of the series proposed here, for whoever triages next:

Scope	Issue	PR	Adds
Reviewer personas (architecture-reviewer, product-lead)	#1134	#1135	## Verification Discipline + pin t338
Producing personas (developer, quality, devsecops, design)	#1136	#1138	same section, hand-off checklist + pin t339
Design persona visual direction	#1137	#1141	visual-design-foundations.md, persona group, one refined-mockups question + pin t340

All three are prose and tests only (no engine change, frontmatter untouched, harness-neutral), independent of each other, and currently mergeable against main @ 572c8265. Each PR body carries the full local run: package.ts --check, lint, typecheck, and the default suite (393-394 / 395 files; the single failure is the live-SDK preflight t19, which is my environment).

Because they come from a fork, the ci.yml test workflow and the AI PR review have not run on them - only the lint and label jobs have. Could a maintainer approve the workflow run on these three so the suite results are on the record? Happy to reshape any of them (for example, move the token table in #1141 to aidlc-shared/, or drop the devsecops section from #1138 if a support-only persona should stay lean) once there is direction.

[vnlebaoduy]

Closing: measured with a 12-run A/B (details on #1135) - the shipped reviewer personas already perform at parity with the proposed section on both an advisory and an adversarial artifact, including under turn pressure. The hypothesised READY-over-unread failure did not occur. Withdrawn.