dv-verify

name	dv-verify
description	Da Vinci verify direct route skill for Codex.

Da Vinci Verify

Use this direct $dv-verify skill for the request.

Action: verify

Shared hook and lifecycle boundary:

• treat da-vinci workflow-status --project <path> [--change <id>] --json and da-vinci next-step --project <path> [--change <id>] as the single routing brain; do not invent a separate routing or readiness engine
• treat .da-vinci/state/change-state.json, .da-vinci/state/change-seq.json, and .da-vinci/state/change-lifecycle.lock as command-owned lifecycle surfaces, not prompt-owned heuristics
• after those route checks confirm $dv-verify, run da-vinci hook-bridge --project <path> [--change <id>] --trigger-kind stage:start --stage verify --json
• hook-bridge is bounded to stage:start preflight only; it must not replace manual promotion, route selection, or lifecycle commands
• treat hook requires as same-trigger dependencies only; required consumers block when a dependency is missing, disabled, stale, failed, returns WARN, or is ordered after the consumer, and optional consumers warn and skip execution
• preserve policy order as execution order; do not topologically sort or auto-reorder hook bindings
• treat da-vinci hook-status and workflow-status as read-only hook diagnostics for local binding identity, project declaration/default provenance, snapshot status, role metadata, latest-versus-effective run interpretation, and hookRecovery; they must never become route authority or a second workflow engine
• if .da-vinci/changes/<change-id>/hook-policy.system.json is missing, keep the story hook-local: surface hookRecovery.status = recovery_required with hookRecovery.reason = system_snapshot_missing instead of inventing an empty-policy fallback or lifecycle repair
• treat .da-vinci/changes/<change-id>/project-profile.system.json as a separate frozen change-local platform/locale/app-technology contract; hook or route diagnostics may reference it, but active changes must not live-read .da-vinci/project-profile.json
• treat system.project-profile.ensure as a check-only stage:start:breakdown validation seam: it may refresh .da-vinci/changes/<change-id>/project-profile.system.json only after canonical .da-vinci/project-profile.json is confirmed; profile collection remains owned by da-vinci dv-change-new [change title] / $dv-change-new before lifecycle creation
• treat .da-vinci/design-source-profile.json as the canonical project-level design-source selector; repo-owned .da-vinci/design-sources/awesome-design-md/*/DESIGN.md snapshots stay bounded advisory reference input and sibling tokens.system.json stays derived import evidence rather than route truth
• treat .da-vinci/changes/<change-id>/candidates/product-prototype.md and .da-vinci/changes/<change-id>/candidates/copy-catalog.json as generated promotion inputs; the requirement export hook may refresh them, but candidates alone never satisfy design entry
• treat .da-vinci/changes/<change-id>/requirement-truth-promotion.system.json as read-only paired-promotion evidence for accepted breakdown_to_design
• treat .da-vinci/changes/<change-id>/product-prototype.md and .da-vinci/changes/<change-id>/copy-catalog.json as promoted canonical change-local requirement-side design-entry companions; hook or route diagnostics may reference them, but only paired promotion may update them
• treat .da-vinci/changes/<change-id>/page-design-contracts.json and .da-vinci/changes/<change-id>/icon-map.json as canonical change-local design-entry contracts; hook or route diagnostics may reference them, but they are not hook-owned artifacts
• keep one canonical consumer chain for design-entry consumers: promoted product/copy truth -> page design contracts -> icon map
• when .da-vinci/design-source-profile.json is missing, treat confirmed .da-vinci/DESIGN.md as the project-local design-source baseline only when it stays rich and complete
• during breakdown, .da-vinci/DESIGN.md is read-only advisory if it already exists; do not create .da-vinci/DESIGN.md during breakdown, and leave .da-vinci/DESIGN.md missing until the design route materializes it through design-confirm --confirm
• treat .da-vinci/changes/<change-id>/source-digests.system.json as design-entry source freshness evidence; stale canonical artifacts block design entry instead of being auto-regenerated as recovery
• treat .da-vinci/changes/<change-id>/icon-supply.system.json as derived change-local icon-catalog readiness evidence; hook or route diagnostics may reference it, but it is not editable route truth
• when the shared design_to_tasks gate is rendered, keep design-entry readiness plus parallel Design Review, Icon Verification, and Copy Verification on the same fail-closed seam; WARN remains pending until explicit dv-handoff acceptance
• keep structured UI quality checks on that same seam: uiQualityScore, first-screen structured .dvp metadata, the density linter, anti-AI-look issue ids, visible text copyKey / locale, and icon iconId / qualifiedName bindings must not create a new route or workflow stage
• keep the task/build/conformance spine on existing seams: build-packet.system.json artifactSpine, derived tasks.index.json contractRefs, and implementation-conformance.system.json are replay evidence for task, build, and verify promotion, not new workflow stages or canonical source truth
• when build_to_verify replay sees missing, stale, or BLOCK implementation conformance, keep verification promotion blocked instead of treating the gap as advisory guidance
• treat .da-vinci/changes/<change-id>/quality-profile.system.json as a separate frozen change-local quality contract; hook or route diagnostics may reference it, but active changes must not live-read .da-vinci/quality-profile.json or .da-vinci/quality-profiles/*.json
• treat .da-vinci/changes/<change-id>/prd.md as a read-only derived summary owned by system stage:start:design; do not promote it to requirement truth or regenerate it from requirement handoff
• if hook-status --json is missing or invalid, keep recovery bounded to hook_status_payload_invalid or hook_status_payload_missing; hook policy mutation must wait until payload trust returns
• keep lifecycle commands explicit: da-vinci dv-change-new [change title], da-vinci dv-change-close, and da-vinci dv-change-recover <change-id> [--confirm]
• if lifecycle repair is required, do not invent a switch-change route; point the operator to $dv-repair as the maintained repair surface for abnormal lifecycle recovery

Reply contract:

• after route work, rerun da-vinci workflow-status --project <path> [--change <id>] --json and da-vinci next-step --project <path> [--change <id>] --json so the final report reflects current truth
• keep the reply in the standard Da Vinci operator format instead of a plain work log
• summarize current truth first: active change id, title, lifecycle status, derived stage, pending handoff, and blocker or repair status
• when blocked, surface Root cause: ... before any maintained next command
• include Execution detail: ... only when the underlying CLI result or gate clarifies the blocker without replacing the maintained route
• keep Evidence refs: ... high-signal on terminal-style output; richer JSON payloads may keep fuller ref lists
• preserve Failures:, Warnings:, and Notes: when present
• if exactly one legal next action exists, emit Next command: ...
• if pendingHandoff.command or the top recommended legal next command is $dv-handoff because review is still missing or WARN needs explicit acceptance, emit Next command: $dv-handoff instead of skipping directly to the downstream stage route
• if multiple legal next actions exist, group them as Recommended, Also valid, Mandatory rollback, and Rollback
• when the legal next action is another maintained Da Vinci surface, restate it using this platform's wrapper names: $dv-continue, $dv-code-context, $dv-change-new, $dv-change-close, $dv-change-recover, $dv-breakdown, $dv-handoff, $dv-design, $dv-tasks, $dv-build, $dv-verify, $dv-repair, $dv-illustration-list, $dv-illustration-prompt, $dv-illustration-add
• do not recommend raw CLI or /prompts:* actions as the next command; mention raw CLI only as execution detail inside the current maintained surface
• do not auto-invoke the next command from inside $dv-verify

Check:

• requirement coverage
• .dvp coverage
• drift between artifacts and code

Update .da-vinci/changes/<change-id>/verification.md when needed. When shell access is available:

• run da-vinci verify-bindings --project <path> [--change <id>]
• run da-vinci verify-implementation --project <path> [--change <id>]
• run da-vinci verify-structure --project <path> [--change <id>]
• run da-vinci verify-coverage --project <path> [--change <id>]
• keep .da-vinci/changes/<change-id>/code-evidence/verify.json latest-only; it should carry generatedAt, top-level projectPlatforms, and flat per-file requirementSurfaceRefs, specRefs, designSurfaceRefs, and platformRefs
• derive verify impact from the accepted build_to_verify deliveryPackage, not from a second ad hoc changed-file inventory
• do not rewrite .da-vinci/code-context/index.json; project-level current code context stays advisory outside verify output
• supporting da-vinci verify-* CLI surfaces may accept --input <path> to refresh .da-vinci/changes/<change-id>/runtime-evidence.system.json
• treat runtime-evidence.system.json as structured verify input and replay evidence on the existing seam; it does not create a new workflow stage and it does not replace .da-vinci/changes/<change-id>/verification.md or the accepted verificationPackage
• da-vinci verify-coverage refreshes .da-vinci/changes/<change-id>/visual-contract-regression.system.json and reports visualContractRegression; treat it as derived verify-time replay evidence that checks page design contracts, copy catalogs, icon maps, responsive expectations, and P0/P1/P2 hierarchy, complements runtime-evidence.system.json, launch-readiness.system.json, implementation-conformance.system.json, .da-vinci/changes/<change-id>/verification.md, and the accepted verificationPackage, and does not create a new workflow stage
• read the shared verificationLoop contract from verify-coverage or workflow-status --json; treat attemptCount, maxAttempts = 2, stopReason, reentryTarget, and nextAction as authoritative
• only these verification-loop stop reasons are valid: verification_block, repair_limit_reached, human_intervention_required, reentry_required, completion_audit_block, readiness_block
• if stopReason is repair_limit_reached, stop automatic repair after maxAttempts = 2 and require human intervention before continuing
• if stopReason is reentry_required, resume from the minimal unfinished upstream route instead of continuing verification locally
• if stopReason is completion_audit_block or readiness_block, clear that blocker before claiming completion
• treat command output as the gate; do not downgrade BLOCK or FAIL into soft guidance
• if any verification surface is still BLOCK or FAIL, keep the workflow in verification and record the drift instead of claiming success
• require fresh verification evidence in verify-coverage and workflow-status before any terminal completion wording
• if task-review evidence is recorded, keep unresolved WARN/BLOCK task-review stages open instead of closing the task group If da-vinci-pencli MCP is active and terminal completion is being considered, re-check the MCP runtime gate evidence before treating verification as complete. When verification is ready for final acceptance, stop this route and tell the user to run $dv-handoff manually; do not invoke $dv-handoff automatically from inside $dv-verify. Before any terminal completion claim, require da-vinci audit --mode completion --change <change-id> <project-path> to pass.