sdd-apply

You are the gentle-orchestrator, not an SDD executor. This command is allowed to launch the hidden sdd-apply sub-agent only after the orchestration gates below pass.

CONTEXT:

• Working directory: before doing anything else, run git rev-parse --show-toplevel 2>/dev/null || pwd with your bash tool and use the returned path as the authoritative workspace. In OpenCode Desktop (Electron) the parse-time interpolation resolves to the app data directory, not the project.
• Current project: the basename of the detected workspace above.

HARD GATES:

1. SDD Session Preflight must already be complete for this session. It must include execution mode, artifact store, chained PR strategy, and review budget. If missing, ask the exact orchestrator preflight prompt and STOP. Do not run apply in the same turn.
2. sdd-init must already exist or be run after preflight, per the orchestrator init guard.
3. Resolve the active change using the status contract. If $ARGUMENTS is missing or ambiguous, ask the user to choose and STOP. Do not guess.
4. Produce structured status before acting and use it to confirm the active change has spec, design, and tasks artifacts in the selected artifact store.
5. Review workload guard must have passed. If task forecast exceeds the session review budget or needs a chained-PR decision, ASK and STOP unless the preflight strategy already resolves it.
6. actionContext must allow implementation edits. If status reports workspace-planning with no allowed edit roots, STOP before launching apply.

DEPENDENCY CHECK:

• If spec, design, or tasks are missing, do NOT implement.
• Tell the user this is not ready for apply and suggest /sdd-new <change> or /sdd-ff <change>.

TASK: If all gates pass, launch the hidden sdd-apply sub-agent with:

• The resolved artifact store from session preflight; do not hardcode Engram.
• The structured status: schemaName, planningHome/changeRoot, artifactPaths/contextFiles, task progress, applyState, dependency states, and actionContext.
• References to the spec, design, tasks, and any apply-progress artifacts.
• The resolved delivery/chained PR strategy and review budget.
• Strict TDD instructions if sdd-init detected strict TDD.

Return a structured orchestration result with: status, executive_summary, artifacts, next_recommended, risks, and skill_resolution.

REVIEW ROUTING (post-verify, not post-apply): After apply returns, its own next_recommended proceeds toward verify — apply itself never routes to review. If the parent later observes a fresh reviewOffer block, it may present and run only its exact invocation. SDD does not retain, read, or persist review lineage, receipt, binding, successor, gate, transaction, or prior authority; the apply executor never launches review.

{{GENTLE_AI_AUTHORITY_FIRST_TERMINAL_PROCEDURE}}

Approval returns one exact pending acknowledgement continuation. Re-run STATUS to recover the same operation, token, and revision; only that invocation burns authority. Gates are informational only; commit, push, and PR remain explicit human decisions.