Project Verification Capability Grill Status

Phase State

• Topic: Project Verification Capability.
• Scope boundary: requirements only; no implementation, backlog, or provider mutation.
• Shared understanding: confirmed.
• Starting direction: add a maintained project-specific executable layer beneath verify-behavior; preserve review-phase as code review.

Branch Dashboard

Technical Grounding

Current Round

• Round: 2026-09-05 review-topology follow-up (umbrella R6)
• Prior round: R5 (closed)
• Current frontier: empty
• Shared-understanding confirmation: confirmed

Parked Branches

• None.

Glossary

Terms

• Verification: Exercising observable product behavior through a real user path and retaining evidence of the action, resulting state, and applicable side effects. Avoid: code review, static validation.
• Code review: Readonly inspection of a frozen change against Spec, standards, security, architecture, simplicity, and skill obligations. Avoid: verification.
• Project Verifier: The project-owned collection of surface-specific verification references consumed through the single verify-behavior entrypoint. Avoid: verification skill.
• Surface Verification Reference: The Project Verifier content for one independently runnable surface, stored below .agents/skills/verify-behavior/references/<surface>/. Avoid: separate verifier skill.
• Update Verification Skill: The shared update-verification-skill capability invoked by implement-spec to add or repair executable coverage for an Uncovered Behavior in its selected scenario. Avoid: periodic maintenance as the only update path.
• Uncovered Surface: An independently runnable app in scope with no Surface Verification Reference. Avoid: failed verification.
• Uncovered Behavior: In-scope behavior with no Feature Map entry or executable drive path in an existing app reference. Avoid: product regression.
• Reference Smoke Proof: A one-time end-to-end check that a newly created app reference can launch, pass Doctor, drive one mapped feature, retain evidence, and clean its run-owned state. Avoid: full Feature Map audit.
• Feature Map: A maintained index of executable user entry points, driver recipes, expected observable states, variants, and gotchas. Avoid: product specification, domain authority.

Relationships

• implement-spec uses Verification before acceptance classification when acceptance criteria are visibly exercisable.
• A Project Verifier supplies project-specific mechanics to the portable verify-behavior protocol.
• A Project Verifier contains one Surface Verification Reference per independently runnable surface.
• implement-spec invokes the Update Verification Skill when its selected scenario has Uncovered Behavior.
• A Cross-Surface Journey composes two or more Surface Verification References through the single verify-behavior entrypoint.
• review-phase performs Code review and may audit retained verification evidence without creating that evidence.

Axioms

• Verification and code review are separate gates.
• Product-specific launch and driver mechanics do not belong in the shared portable verify-behavior protocol.
• Evidence must survive cleanup, while cleanup removes only resources owned by the verification run.
• implement-spec owns both verification coverage-gap branches: creation for an Uncovered Surface and targeted update for Uncovered Behavior.
• review-phase does not own verification evidence freshness or reruns.
• The adapted creator and updater write project-owned content only below .agents/skills/verify-behavior/references/; they do not create app-specific skills.
• docs-ingest-phase never invokes the Update Verification Skill or writes Feature Maps.
• Post-scaffold and post-update follow-through leaves Project Verifier content unchanged.
• create-verification-skill and update-verification-skill are model-invoked because implement-spec must reach them for the two distinct coverage-gap branches.
• implement-spec invokes create-verification-skill only when its selected scenario has an Uncovered Surface.

Flagged Ambiguities

• "Verification skill" previously meant the shared generator, generated capability, or portable protocol. Resolution: use Project Verifier for the generated capability and keep verify-behavior, create-verification-skill, and update-verification-skill as exact skill IDs.
• "Missing reference" means an Uncovered Surface, not any failed product check.
• "Prove one real feature" means a one-time Reference Smoke Proof for a newly created app reference, not a full app verification or map regeneration.
• Q19 supersedes Q7's post-scaffold creation timing. Scaffold and update follow-through only preserve Project Verifier content.
• Q20 supersedes Q7's updater ownership, Q9's docs-ingest maintenance route, Q11's docs-ingest trigger, Q14's Uncovered Behavior route, Q16's later-update route, and Q19's statement that Q7 updater ownership remained accepted. Q19 remains authoritative for Uncovered Surface creation.

Accepted Follow-Up — 2026-09-05

• Selected verification scenarios must state an observable Scenario Falsifier alongside the positive proof result.
• Important behavior includes a relevant failure or negative condition and the actual downstream result when applicable. This is relevance-bounded and does not require exhaustive negative testing for every scenario.
• Creator or updater proof may be reused when authority, code, runtime, and scenario conditions match the requesting scenario. A mismatch requires the missing proof; implement-spec remains the freshness owner.
• A targeted update-verification-skill run may retire an obsolete Feature Map entry only with current source evidence and reconciled references. It preserves unrelated entries and documented product-expected semantics and never broadly regenerates the map.
• These are specification clarifications and add no experiment or benchmark requirement; the current admission policy remains unchanged.

Final Handoff

• Shared understanding confirmed on 2026-09-04.
• Requirements are ready for create-spec.
• No branches are parked.
• Remaining non-design work: implement the adapted skills and lifecycle pointers, then prove Uncovered Surface creation, Uncovered Behavior repair, on-demand resume, docs-ingest immutability, preservation, isolation, cleanup, and failure routing with live fixtures.