dv-continue

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

Da Vinci Continue

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

Action: continue

Focus on:

• inspect existing workflow artifacts first
• detect the current workflow phase
• route back to the single legal workflow command without inventing a separate routing brain

Output should include:

• detected workflow state
• active change id, title, lifecycle status, derived stage, pending handoff, and blocker or repair status
• when blocked, prefer Root cause, Execution detail, and Evidence refs from operatorSummary over raw CLI echo
• missing or weak artifacts
• grouped legal next commands as Recommended, Also valid, Mandatory rollback, and Rollback when more than one legal next action exists
• Next command: ... only when exactly one legal next action exists
• a conservative fallback only when the legal route is ambiguous

Route discipline: Shared hook and lifecycle boundary:

• treat da-vinci workflow-status --project <path> [--change <id>] --json and da-vinci next-step --project <path> [--change <id>] --json 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
• invoke da-vinci hook-bridge --project <path> [--change <id>] ... --json only after workflow-status and next-step confirm a deeper stage or handoff route
• hook-bridge remains bounded to stage:start or handoff-start preflight; it must not replace 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
• do not invent local readiness heuristics or phase-selection rules when workflow-status and next-step already returned route truth
• run da-vinci scope-check --project <path> [--change <id>] when page/state propagation looks ambiguous
• do not restart discovery if the current artifacts already contain enough truth
• determine route selection from artifact and checkpoint truth before reading contextual deltas
• if workflow-status or next-step output is missing, stale, or unavailable, fall back to artifact scanning and checkpoint evidence
• use contextual deltas as auxiliary recovery context only; they must not override route selection
• if contextual deltas conflict with current artifacts, ignore them for routing and call out the conflict
• read operatorSummary.rootCause, operatorSummary.executionDetail, operatorSummary.evidenceRefs, blockingGate, pendingHandoff, and readiness from next-step --json before giving deeper recovery advice
• if workflow-status exposes decisionMemory, treat .da-vinci/decision-memory.system.json as the project-scoped derived advisory memory source: bounded prior design/verify context with provenance-backed source refs may explain the current route, but it must never override workflow-status, next-step, stage, pending handoff, blocker truth, or accepted package truth
• for active changes, treat .da-vinci/changes/<change-id>/project-profile.system.json as the frozen platform/locale/app-technology contract and do not live-read .da-vinci/project-profile.json
• for active changes, keep the task/build/conformance spine explicit in route explanations: build-packet.system.json artifactSpine, derived tasks.index.json contractRefs, and implementation-conformance.system.json explain build/verify blockers but never replace route truth or create a new stage
• if build_to_verify replay reports missing, stale, or BLOCK implementation conformance, keep the next route on the maintained blocker surface instead of routing past it into verification
• if breakdown preflight reports system.project-profile.ensure as BLOCK, treat it as a check-only validation seam: collection owner stays $dv-change-new for new changes, while active changes should manually confirm .da-vinci/project-profile.json and rerun breakdown preflight
• treat .da-vinci/design-source-profile.json as the canonical project-level design-source selector; imported .da-vinci/design-sources/awesome-design-md/*/DESIGN.md snapshots remain bounded inspiration input and sibling tokens.system.json remains read-only derived import evidence, not canonical design truth
• for active changes, treat .da-vinci/changes/<change-id>/candidates/product-prototype.md and .da-vinci/changes/<change-id>/candidates/copy-catalog.json as generated promotion inputs only; prefer promoted canonical .da-vinci/changes/<change-id>/product-prototype.md and .da-vinci/changes/<change-id>/copy-catalog.json over candidates or .da-vinci/changes/<change-id>/prd.md when explaining design-entry truth
• for active changes, treat canonical .da-vinci/changes/<change-id>/page-design-contracts.json and .da-vinci/changes/<change-id>/icon-map.json as the design-side entry companions; if the route explanation references design-entry outputs, prefer these artifacts over ad-hoc review prose
• keep the canonical consumer chain explicit in route explanations: promoted product/copy truth -> page design contracts -> icon map
• if .da-vinci/design-source-profile.json is missing, describe it as a project-local DESIGN.md baseline only when .da-vinci/DESIGN.md remains rich and complete
• for active changes, treat .da-vinci/changes/<change-id>/icon-supply.system.json as derived icon-catalog readiness evidence for the same stage:start:design seam; do not promote it to editable design truth
• for active changes, treat .da-vinci/changes/<change-id>/quality-profile.system.json as the frozen quality contract and do 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; it may explain design context, but it must never become route truth or the canonical copy/page contract
• if workflow-status exposes coverageMatrix, treat .da-vinci/changes/<change-id>/coverage-matrix.json as a derived-only row-first ledger; when canonical design-entry targets exist, stable coverageRowId expands from the approval-unit surface + qualifier identity to surface + qualifier + platformTarget + localeTarget; when those targets are unavailable, use the current surface-level surface + qualifier row id for uncovered, stale, and drifted rows plus evidence refs in workflow-status and /dv-handoff; do not let it replace stage, pending handoff, or readiness truth
• if workflow-status exposes the shared design_to_tasks review, keep Design Engine v2 data bounded to the current gate: qualityProfileId, reviewDimensions, problematicDimensions, affected rows, and evidence refs should inform the route explanation, but they must not create a second design workflow
• if workflow-status exposes that shared design_to_tasks review, keep design-entry readiness plus Design Review, Icon Verification, and Copy Verification on the same fail-closed gate; do not describe WARN as passing until dv-handoff explicitly accepts it
• if readiness blocks the route, surface operatorSummary.rootCause first, include operatorSummary.executionDetail only when it clarifies the blocker, and keep operatorSummary.evidenceRefs high-signal on terminal-style output
• if the current main-path maintained surface can resolve the issue directly, keep that maintained surface as the next command
• if the blocker is workspace isolation or another shared readiness gate, recommend $dv-repair
• if the blocker is a repairable non-mainline readiness issue, recommend $dv-repair
• if pendingHandoff is present, recommend /dv-handoff as the next manual command instead of forcing the next stage route
• do not default the user into $dv-build unless the project is clearly implementation-ready
• if design artifacts exist but tasks.md does not, prefer a continuation prompt that moves into $dv-tasks
• only prefer $dv-build once task generation and implementation readiness are already clear
• do not route into $dv-build when any design gate is unresolved: missing shell-visible project-local .dvp, active/unclosed design session, runtime/design-source checkpoint still BLOCK, or required Design Review evidence still BLOCK/unaccepted
• if bounded-parallel execution is hinted, include $dv-repair before emitting a parallel implementation continuation prompt
• avoid terminal completion wording unless fresh verification evidence and completion audit requirements are explicit
• continuation should return the user to one primary command among breakdown, handoff, design, tasks, build, or verify