Vv Execute

Supported modes:

• inline: walk tasks in dependency order and implement directly in the current session without subagent dispatch, while preserving TodoWrite tracking, acceptance verification, and per-task or per-wave commit discipline.
• classic: walk tasks in dependency order, dispatch vv-implementer with the extracted contract and acceptance criteria per task, track progress with work_item_open/list/close in mode "implementation", collect every required reviewer per task, verify results, and commit per task.
• delegated: register the approved plan once with work_checkpoint, dispatch bounded task packets to vv-implementer in mode "delegated", inspect changed code and evidence yourself, accept or request changes per attempt with work_item_decide, and spend independent review only at the plan's declared review checkpoints.

Execution mode resolution — make the user explicitly choose an execution mode unless they already specified one:

• An execution mode that the user already stated explicitly is reused; do not ask for it again.
• If the approved plan declares an <execution><mode> and that intent is compatible with the user's explicit choice and the active session policy, reuse the declared mode without asking again.
• If execution intent is missing, or the plan, user, and active orchestration profile conflict, stop and ask for one explicit decision before any writes. Do not guess and do not silently switch policy mid-run.

Do not mutate files until the execution mode is explicit. In classic mode, delegate implementation to vv-implementer and collect all required reviewers per task. In inline mode, write code yourself in the current session. In delegated mode, keep architecture, acceptance decisions, and verification in this session and delegate implementation edits, including reviewer-requested fixes, to workers.

Read plan.xml from .vvoc/specs/<id>/plan.xml. Use list-tasks and count-tasks to understand scope. Use dependency-graph to determine execution order. Also check whether a sibling design-context.xml exists (.vvoc/specs/<id>/design-context.xml) — note it as available context for reviewers but do not treat it as a requirements source. Plan file exists and is readable Plan path is an active plan under .vvoc/specs/<id>/ with the plan as a sibling of spec.xml. Reject plans under any archive/ directory. Plan contains <plan> root tag Plan contains a non-empty top-level <status> whose value is approved If the top-level plan status is draft, stop and ask the user to approve the plan first. Do not execute draft plans. If the top-level plan status is applied, stop and report that the plan has already been applied. Do not re-execute applied plans. If the top-level plan status is missing or any value other than draft, approved, or applied, stop and report the invalid lifecycle status. Plan contains a non-empty <spec> path pointing to a readable active spec file at .vvoc/specs/<id>/spec.xml. Stop and report if the spec path is under archive/. The linked spec's top-level <status> is approved If the linked spec status is draft, applied, missing, or invalid, stop and report that vv-execute requires an approved active spec. Plan contains <tasks> section with at least one <TASK-T-NNN> element grouped under <WAVE-N> elements Each task element name matches the TASK-T-NNN pattern and the task has non-empty <title> and <file>. There is no child id element — identity lives in the element name. Each task has <snippet> (may be empty but must exist) Each task has <acceptance> with at least one <criterion> Plan architecture components use COMPONENT-UPPER-SLUG element names and every component exists in the linked spec's components section — plan components are a subset of spec components If any check fails, stop and report the issue with line numbers. Do not proceed with broken plan. Assess the plan after validation and before implementation. Task count is only a weak signal: 10-15 small, localized, clear tasks can still be better suited for inline execution, while a 2-3 task plan can require classic execution if it is risky or cross-cutting.

Consider:

• total task count and whether tasks are small/mechanical or broad/ambiguous
• number of target files and whether changes stay localized
• dependency graph shape and coupling between tasks
• whether public APIs, package exports, CLI behavior, setup flow, config locations, persistence, security, migrations, or user data handling change
• clarity and verifiability of acceptance criteria
• whether the plan requires architectural decisions, broad refactors, or integration-heavy coordination

Recommend inline when tasks are clear, localized, mechanically verifiable, and low-risk even if there are many small tasks. Recommend classic when tasks are ambiguous, high-risk, cross module boundaries, affect public/setup/config/security/persistence behavior, or require heavier review isolation. Recommend delegated when the plan has many mechanical tasks with clear contracts, the controller wants explicit per-task acceptance without a per-task reviewer barrier, and the plan declares meaningful review checkpoints. Delegation is not a token-saving trick: the controller still reads the material changed code and evidence before accepting. If the user already specified a mode, or the approved plan declares a compatible <execution><mode> and the user did not conflict with it, reuse that mode and proceed.

If the user did not specify a mode, stop and ask them to choose. Do not auto-pick. Present a compact assessment and recommendation in the user's language, then offer exactly three choices:

Recommended mode: inline|classic|delegated

Choose execution mode:

1. inline — execute in this session
2. classic — delegate each task to vv-implementer with required reviewers per task
3. delegated — delegate implementation, accept each attempt yourself, review at declared checkpoints

Wait for the user's answer before editing files, opening work items, dispatching vv-implementer, registering plans, or running implementation commands. Create a TodoWrite with all task IDs in dependency order for progress tracking.

If all criteria pass → proceed to review. If criteria fail → re-dispatch implementer with specific failure details.

Derive a business task identifier from (in priority order):

1. Branch name — extract ticket/issue reference (e.g. feat/JIRA-123-description → JIRA-123)
2. Plan spec reference — use the spec package directory name or the plan's <summary> title.
3. Plan title from plan.xml — use the plan's summary or overarching feature name
4. Ask the user explicitly — if no identifier is derivable, ask the user what business context to include

Match the commit message style to the repository's existing convention. Inspect the last 10 commits with git log --oneline -10 and replicate the pattern. Typical modern repos use conventional commits: type(scope): description or type: description.

Format: <business-ref> <type>(<scope>): <task title> e.g. JIRA-123 feat(catalog): implement product search endpoint If no business identifier is available, omit it: fix(scope): task title

Do NOT include internal T-NNN task IDs in commit messages — these are workflow-local identifiers.

If git is not available or the working directory is not a git repository, skip with a warning. If the commit fails (e.g. nothing to commit, hook rejection), report the failure and stop. Do not silently proceed.

If criteria fail with a clear local cause, fix and rerun verification. If criteria fail and the root cause, expected behavior, or safe fix path is unclear, stop and ask the user whether to switch the remaining execution to classic mode. Do not silently dispatch vv-implementer from inline mode.

Use the repository's existing commit style. Inspect recent commits before committing. Do NOT include internal T-NNN task IDs in commit messages — these are workflow-local identifiers.

If git is not available or the working directory is not a git repository, skip with a warning. If the commit fails (e.g. nothing to commit, hook rejection), report the failure and stop. Do not silently proceed.