Define layered verification loops and human validation package expectations

[BASIC-BIT]

Parent epic: #43

Problem:

VRDex wants code to move quickly without losing trust. The repo needs a clear model for how automated and human verification stack together across app code, scripts, UI work, and infrastructure.

Scope:

• define baseline verification layers across lint, types, tests, e2e, visual, and policy checks
• include scripts/ancillary code and infrastructure verification expectations
• define when VLM review and screenshot/video evidence are expected
• define the desired human validation handoff for a nearly mergeable feature

Non-goals:

• implementing every verification layer immediately
• forcing every feature to have the same heavyweight validation cost
• collapsing the policy/design work and the first concrete implementation slices into one issue

Acceptance criteria:

• the verification stack is documented clearly
• UI evidence expectations are documented clearly
• human validation is framed as a final confidence layer, not a substitute for engineering checks

Execution follow-ons

• [Draft] Bootstrap repository verification tooling and developer guardrails #59 Bootstrap repository verification tooling and developer guardrails
• [Draft] Bootstrap Playwright e2e and visual verification for critical paths #60 Bootstrap Playwright e2e and visual verification for critical paths
• [Draft] Bootstrap policy and infrastructure verification checks #61 Bootstrap policy and infrastructure verification checks

Soft dependencies

• Define repo-level definition of ready for feature work #44 Define repo-level definition of ready for feature work
• Choose and document product analytics plus feature-flagging direction #46 Choose and document product analytics plus feature-flagging direction

Soft dependents

• Define agentic review-recycle loop and trigger model #47 Define agentic review-recycle loop and trigger model
• Define contributor-friendly, agent-compatible contribution workflow #49 Define contributor-friendly, agent-compatible contribution workflow
• [Draft] Bootstrap repository verification tooling and developer guardrails #59 Bootstrap repository verification tooling and developer guardrails
• [Draft] Bootstrap Playwright e2e and visual verification for critical paths #60 Bootstrap Playwright e2e and visual verification for critical paths
• [Draft] Bootstrap policy and infrastructure verification checks #61 Bootstrap policy and infrastructure verification checks

[BASIC-BIT]

Concrete verification lesson from current supervisor-loop debugging:

We found a case where the first-pass diagnosis looked strong enough to guide a fix, but still should not be treated as fully proven without a second pass. In this case, cross-session session.prompt(...) delivery appears to acknowledge successfully while not materializing as a real message in the target supervisor session history.

Whether that exact root cause survives final retest or not, this is exactly the class of failure #51 should guard against:

• tool acks can be misleading
• first-pass transport conclusions can be directionally useful without being fully verified
• important orchestration/runtime findings need explicit second-pass verification and human verification

I think #51 should explicitly include guidance like:

• when a runtime/platform diagnosis changes implementation direction, require an independent re-check before locking it in
• distinguish working diagnosis from confirmed cause
• require human verification for important platform-behavior claims, not just agent/tool output
• ensure closeout packages include enough evidence that another reviewer can verify the conclusion without replaying the entire debugging session