Implementation handoff orchestration

Implementation Handoff Orchestration

Overview

Create a versioned execution contract and implementation governance docs before code changes: roadmap, ledger, decisions, risks, phase docs, handoffs, and, when explicitly selected, a controlled-parallel topology. This skill is planning-only; it must not implement code, migrations, runtime behavior, or feature changes.

When To Use

• A user asks for a large feature, research workstream, refactor, migration, release, cleanup, or cross-cutting system change.
• The work needs multiple sessions, handoffs, phase gates, validation evidence, or explicit owner decisions.
• Context loss, stale docs, release blockers, or manual-review loops are likely.
• A user asks to plan implementation prompts, handoff docs, roadmap docs, or governance docs.
• A workstream may benefit from independent implementation lanes and needs an explicit serial-versus-controlled-parallel decision.

When Not To Use

• The user asks for a small direct code edit or bug fix that fits in one focused turn.
• The user asks to implement an already-approved handoff.
• The task is only code review, debugging, testing, or deployment execution.
• The user explicitly asks not to create planning/governance documentation.

Core Principle

Govern the implementation before implementing it. Produce a system that lets a future agent continue from the latest ledger and handoff summary, with explicit validation, review, decision, risk, auto-continue, and stop rules.

Required Inputs

Gather or infer:

• Goal, business outcome, and non-goals.
• Repository/workspace root.
• Workstream name for the isolated docs/loop/<workstream-slug>/ folder.
• Known architectural, data, runtime, security, privacy, tenant, and compatibility constraints.
• Existing docs, source maps, ledgers, issue specs, design docs, and release notes.
• Commit granularity expectations, including which handoffs can produce one logical commit and which need multiple commit checkpoints.
• Owner decisions needed before implementation versus before release.
• Requested execution authorization scope. Propose continuous_autonomous for the entire workstream by default, but record it as approved only after explicit user execution approval.
• Any existing topology decision in the same workstream's Version 1 contract.

Ask only blocking questions before the first plan. If a question can be answered by reading code/docs, inspect first. If a decision can be deferred without implementation risk, record it as a future gate rather than stopping.

Output Workspace Rules

• Create a separate documentation workspace for every requested feature, research topic, refactor, migration, or system change.
• The default and expected base path is docs/loop/<workstream-slug>/.
• Do not create or continue a shared docs/implementation-handoffs/ workspace.
• Derive <workstream-slug> from the user's requested workstream using lowercase kebab-case, ASCII letters/digits/hyphens, and no spaces. Keep it short but specific.
• If a safe slug cannot be inferred, ask one blocking question for the folder name before producing the first plan.
• If docs/loop/<workstream-slug>/ already exists, inspect its ledger and summaries before deciding whether it is the same workstream. Continue there only when it clearly matches the current request; otherwise create a distinct slug.
• All generated paths in the plan and docs must be project-relative, use forward slashes, and stay under the selected base path.
• The initial plan must state the selected base path explicitly.
• The approved file set should use this structure:

docs/loop/<workstream-slug>/
  handoff-contract.md
  00-master-implementation-roadmap.md
  01-progress-ledger.md
  02-decision-log.md
  03-architecture-target-state.md
  04-risk-and-open-questions.md
  05-review-checklist.md
  06-controlled-parallel-topology.md  # only for controlled_parallel
  phases/
    phase-01-<slug>.md
  handoffs/
    phase-01/
      handoff-01-<slug>.md

Version 1 Execution Contract

handoff-contract.md is the durable producer-consumer boundary between this skill and the implementation-handoff-execution skill. Create it with Contract Status: Draft during governance doc creation and change it to Approved for Execution only after explicit execution approval.

Required fields:

• Contract Version: 1.
• Workstream and project-relative base path.
• Contract Status: Draft, Approved for Execution, Superseded, or Revoked.
• Execution Mode: propose continuous_autonomous.
• Authorized Scope: normally entire_workstream after approval.
• Approval Evidence: instruction summary, approver, and date.
• Decision Authority: evidence-based agent decisions are allowed and logged.
• Phase Gate Policy: auto-pass when exit evidence is satisfied.
• Human Review Policy: self-review unless a genuine material decision remains.
• Release Policy: finish implementation, but stop before unauthorized deploy, cutover, destructive production operation, irreversible cleanup, or external provider action.
• Commit Policy: logical checkpoint commits with narrow staging and evidence.
• Scope Repair Policy: bounded emergent checkpoints/handoffs may be added when they preserve the approved goal and non-goals.
• Execution Topology: serial or controlled_parallel.
• Topology Approval Evidence: user decision summary, approver, and date; or exact safety evidence when fewer than two safe lanes make serial mandatory.
• Maximum Parallel Workers: 5.
• Effective Worker Policy: min(contract cap, available slots - 1, ready safe lanes).
• Maximum Agent Depth: 1.
• Agent Creation Authority: root_orchestrator_only.
• Nested Delegation: prohibited.
• Governance Write Authority: root_orchestrator_only.
• Integration Authority: root_orchestrator_only.
• Worktree Isolation: required for every writing lane.
• Parallel Fallback Policy: continue_serial_and_record.
• Heavy Validation Policy: serialize per repository or shared resource.
• Local Integration Policy: root may integrate independently verified lane commits into the task integration branch.
• Release Boundary: target-branch merge, push, PR, deploy, and other release actions need separate authorization.

Do not treat conversation memory as durable execution authorization. Put the approved scope and policy in this contract and mirror its current status in the ledger.

These topology fields are a backward-compatible Version 1 extension. If they are absent from an existing Version 1 contract, execution must default to serial; absence never grants parallel authority.

Discovery Workflow

1. Inspect current docs and source reality before drafting phases.
2. Identify source of truth order: current code and schema, latest architecture docs, latest ledger, latest handoff summaries, then historical handoffs.
3. Extract failure modes: vague scope, oversized phases, stale docs, missing validation, migration drift, product decision blockers, security/KVKK/PII risk, tenant isolation risk, release-blocker confusion, and manual-review loops.
4. Assess controlled-parallel feasibility using references/controlled-parallel-planning.md. Build an acyclic dependency graph, write-scope conflict model, shared-resource lock model, backend-first edges, serial gates, and possible integration joins.
5. Resolve topology history before asking:
   • if the same workstream already records Execution Topology, preserve it and do not ask again;
   • if an existing Version 1 contract lacks topology fields, treat it as durable serial and do not ask merely because safe lanes are discovered; change it only when the current user instruction explicitly selects an upgrade;
   • for a new workstream with at least two ready-or-downstream, dependency-safe, write-disjoint lanes, ask exactly once for controlled_parallel_with_serial_fallback or serial;
   • when fewer than two safe lanes exist, select serial and record the safety reason;
   • do not create governance files until a required topology choice is answered.
6. Produce this first response, not files:

# Implementation Handoff System Plan

1. Output workspace path
2. Proposed phase list
3. Proposed handoff list per phase
4. Master roadmap structure
5. Ledger structure
6. Decision log structure
7. Risk/open questions structure
8. Review checklist structure
9. Version 1 execution contract structure
10. Architecture target state structure
11. Handoff template
12. Phase template
13. Decision authority and bounded scope repair rules
14. Auto-continue rules
15. Genuine decision-dead-end conditions
16. Validation strategy
17. Commit checkpoint strategy
18. Context-loss prevention strategy
19. Open questions for user
20. Implementation readiness decision
21. Parallel feasibility, proposed lanes, serial gates, resource conflicts, and topology decision status

7. Wait for user approval before creating docs unless the user already explicitly approved doc creation. Topology selection and governance-doc approval are separate decisions, though both may be answered in one user message.
8. When approved and any required topology choice is recorded, create docs only. Do not edit implementation files, add migrations, run destructive commands, or implement feature behavior.
9. Use the templates in references/templates.md when creating the file set.

Controlled Parallel Planning

Read references/controlled-parallel-planning.md whenever two or more handoffs might execute independently.

• Parallelism is opt-in. Only an explicit controlled_parallel_with_serial_fallback user choice becomes Execution Topology: controlled_parallel.
• Model handoffs as a dependency DAG; reject cycles and preserve backend/schema/contract producer-before-consumer order.
• Compare exclusive write scopes, repository boundaries, migrations, runtime ports/services, build ownership, authenticated browser/test accounts, and external providers.
• Treat governance files and lane integration as root-only. No leaf worker may own docs/loop/<workstream-slug>/**.
• Plan at most five leaf workers. Runtime capacity is dynamic and reserves one slot for root.
• Agent depth is one: root may create leaf workers; leaf workers may not create or delegate to agents.
• Require an isolated branch/worktree for every writing lane. A missing safe isolation path causes serial fallback, not invented parallel execution.
• Put full builds, migration verification, authenticated browser smoke, and other shared-resource-heavy validation at serial join gates.
• When serial is selected, omit 06-controlled-parallel-topology.md and retain the ordinary roadmap/ledger shape.
• When controlled_parallel is selected, create 06-controlled-parallel-topology.md, add DAG/join data to the roadmap, parallel runtime tables to the ledger, lane metadata to handoffs, protocol checks to review, and parallel failure modes to risks.
• Topology approval authorizes scheduling shape only. It never changes a Draft contract to Approved for Execution and never authorizes target-branch merge, push, PR, deploy, migration execution, or external effects.

Phase Design Rules

• Keep phases outcome-oriented and dependency-ordered. Each phase must have a goal, scope, non-goals, handoffs, risks, validation requirements, and exit criteria.
• Split large phases until each handoff can be implemented and validated independently.
• Split or checkpoint handoffs so every meaningful code development slice can be validated and committed separately.
• Put discovery, architecture, migration planning, security, runtime integration, regression validation, docs closeout, and release readiness into separate handoffs when risk warrants it.
• End each phase with a phase gate handoff if the next phase depends on accepted decisions or validated evidence.
• Under an approved continuous_autonomous contract, treat phase gates as evidence gates rather than conversation pauses. Auto-pass them when their recorded exit criteria are satisfied.
• Separate implementation completion from production release approval. A final phase may close with release blockers if implementation is validated but deploy/cutover decisions remain.
• A controlled-parallel DAG may expose cross-phase readiness, but phase completion order remains dependency-ordered and each phase still satisfies its own exit criteria.

Handoff Design Rules

Every handoff must let a future agent work from the file alone plus must-read references. Include:

• Stable Handoff ID such as P01-H01
• Depends On
• Lane ID
• Parallel Eligibility
• Exclusive Write Scope
• Shared Resource Locks
• Integration Gate
• Objective
• Scope
• Out of Scope
• Must Read Before Starting
• Expected Code Areas
• Expected Tests
• Database/Migration Impact
• Runtime Impact
• Security/KVKK/PII Impact
• Backward Compatibility
• Genuine Decision Dead End
• Validation Checklist
• Commit Checkpoints
• Self-review Checklist
• Exit Criteria
• Next Handoff

Add handoff summary fields for completion: Implemented Summary, Review Summary, Validation Summary, Commit Summary, Remaining Work, Known Issues, Modified Files, Created Files, Tests Added/Updated, Validation Evidence, and Git Commit Evidence.

Every Must Read Before Starting list must include the contract, roadmap, ledger, decisions, architecture target state, risks/open questions, global review checklist, current phase doc, and handoff-specific sources.

Commit Checkpoint Rules

• Every implementation handoff must include a Commit Checkpoints section.
• Use one checkpoint when the handoff is one coherent development slice; use multiple checkpoints when the handoff contains separable behavior, data, UI, integration, or cleanup slices.
• Each checkpoint must state the intended logical change, expected file areas, required validation evidence, and expected commit message intent.
• A checkpoint is complete only after implementation, validation, governance doc updates, git add of relevant files only, git commit, and recording the commit hash/message.
• Because a commit cannot contain its own hash in committed docs, plan a small governance evidence commit after the implementation checkpoint commit when the ledger/handoff must record that hash. Do not require governance docs to record the governance evidence commit's own hash.
• Planning-only, discovery-only, or no-code handoffs must mark commit checkpoint status as Not applicable with a reason.
• Do not plan one final catch-all commit for unrelated handoffs. Prefer small commits that explain why the specific development slice exists.

Ledger Rules

The ledger is the recovery source after context loss. It must show:

• Contract Version
• Contract Status
• Execution Mode
• Authorized Scope
• Approval Evidence
• Execution Topology
• Topology Approval Evidence
• Maximum Parallel Workers
• Effective Worker Policy
• Active Lanes
• Ready Queue
• Integration Queue
• Resource Locks
• Current Phase
• Current Handoff
• Last Validated Handoff
• Next Handoff
• Overall Status
• Implementation %, Review %, Validation %
• Human Approval Status
• Phase Gate Status
• Known Blockers
• Release Blockers
• Last Commit
• Uncommitted Handoff Changes

Each handoff row must include lane, parallel eligibility, dependencies, exclusive write scope, shared resource locks, integration gate, status, review level, approval mode, phase gate status, commit status, worker source hash, integrated hash, modified/created files, tests, validation debt, known issues, next pointer, and last session note. In serial workstreams, parallel-only columns may be omitted. Never mark Validated without root-confirmed review, sufficient validation evidence, required commit evidence, and any integration gate.

Decision Log Rules

• Add a decision before any boundary-changing implementation handoff.
• Use decisions for chosen direction, context, options, consequences, reversibility, and affected phases/handoffs.
• Use open questions for unresolved facts. Do not bury decisions in handoff prose only.
• If evidence selects a safe product/security/runtime direction, plan an Agent-Derived Decision and continuation. Stop only when all Genuine Decision Dead End conditions pass. If a decision is required only for release, record it as a release blocker and continue implementation planning.

Risk / Open Questions Rules

• Classify every item as one of: decision blocker, release blocker, validation debt, non-blocking known issue, or future follow-up.
• Record severity, owner, affected phase/handoff, mitigation, blocking status, and current state.
• A security/KVKK/PII finding, tenant-isolation defect, schema inconsistency, runtime mismatch, or build/test failure is recovery work when accepted evidence defines a safe correction. Classify it as a decision blocker only when it passes every Genuine Decision Dead End condition.
• Release blockers do not block remaining implementation docs unless they change what must be built.

Decision Authority

Plan for execution to select a direction using this precedence:

1. Latest user instruction and approved workstream goal/non-goals.
2. Current code, schema, configuration, contracts, and tests.
3. Approved contract, current ledger, active handoff, and recorded decisions.
4. Security, privacy, tenant isolation, and least privilege.
5. Backward compatibility.
6. Additive, reversible, and minimal implementation.
7. Repository conventions and validated architecture boundaries.

When this order identifies a safe option, require execution to record an Agent-Derived Decision for boundary-relevant choices and continue without asking the user.

Genuine Decision Dead End

Plan a user-facing implementation stop only when every condition is true:

1. A material product, contract, security/privacy, tenant-isolation, schema, compatibility, scope, runtime, or external-authorization decision is required.
2. The answer cannot be derived from user instructions, the approved contract, decisions, current code/schema/configuration, tests, or repository conventions.
3. No safe option can be preferred using least privilege, backward compatibility, reversibility, minimal scope, and existing behavior.
4. Continuing would require unsafe guessing or could cause data loss, a security/privacy breach, a material contract violation, or an irreversible external effect.
5. Further read-only investigation, normal diagnosis, safe experimentation, or alternative validation cannot resolve the uncertainty.

Only this predicate may create an IMPLEMENTATION_DECISION_BLOCKED stop. Initial build/test failure, a known defect, missing evidence, documentation drift, or a safely repairable security/schema issue does not satisfy it.

Bounded Scope Repair

Plan execution to add an emergent checkpoint or corrective handoff without pausing when the discovered work:

• is necessary for the approved workstream outcome;
• preserves non-goals and public/product behavior;
• does not authorize destructive, production, deploy, or external actions;
• is reversible or backward compatible;
• has explicit validation and commit boundaries; and
• is recorded in the ledger, handoff summary, risks, and decision log when boundary-relevant.

Self-review Rules

Every handoff must require self-review for:

• Scope drift
• Runtime behavior mismatch
• Build/test failure
• Migration/schema drift
• Security/KVKK/PII risk
• Tenant isolation risk
• Backward compatibility risk
• Documentation drift
• Decision log omissions
• Risk/open question omissions
• Missing validation evidence
• Agent depth or nested-delegation violation
• Missing worktree isolation or write-scope overlap
• Governance ownership violation
• Unverified worker or integration evidence

Use role lenses where useful: Planner, Architect, Developer, Tester, Reviewer, Security/KVKK Reviewer, Release Owner, and Operator. These are checklist perspectives, not implicit parallel authorization.

Auto-continue Rules

The handoff system should avoid asking "should I continue?" after every handoff.

Continue automatically when all are true:

• The Version 1 contract is Approved for Execution with Execution Mode: continuous_autonomous, or the current user instruction explicitly supplies equivalent authorization for a legacy workstream.
• Validation passed or a non-applicable validation item has exact evidence.
• Ledger, handoff summary, decision log, and risk log are updated.
• Required commit checkpoints are committed or explicitly marked not applicable with evidence.
• No decision blocker remains.
• Remaining issues are classified as non-blocking, future gate, or release blocker only.

Do not stop for:

• Generic manual review markers with no specific approval need.
• Evidence-satisfied phase gates under continuous_autonomous mode.
• Recoverable build, test, lint, migration, schema, runtime, security, or validation failures.
• Bounded scope repairs that preserve the approved outcome and non-goals.
• Documentation pending that is part of the next planned closeout handoff.
• Non-blocking known issues.
• Release blockers that do not block implementation.
• Owner decisions explicitly moved to a later phase or release gate.

Stop Conditions

Stop implementation only when:

• Every Genuine Decision Dead End condition is satisfied and the exact decision request is recorded with evidence and alternatives.
• User-owned dirty work cannot be preserved without overwrite or history rewriting.

Do not stop remaining implementation for a release-only constraint. Finish all safe implementation work and stop immediately before an unauthorized deploy, cutover, destructive production operation, irreversible cleanup, backward-compatibility break, or external provider action.

Validation Rules

• Planning validation checks document completeness, internal consistency, source-of-truth alignment, and no-code boundary compliance.
• Implementation validation strategy must name exact expected commands, manual checks, greps, fixtures, environments, and evidence fields.
• If validation cannot run, record why, what would be run, what evidence exists instead, and whether that blocks implementation or release.
• Continue independent work and create explicit validation debt when an environment prevents required evidence. Retry that debt before final closeout and never mark Validated without sufficient evidence.
• Validation evidence must be copied into the handoff summary and ledger. "Looks good" is not evidence.
• Commit evidence must include commit hash, commit subject, committed file summary, and the validation evidence that justified the commit.

Context-loss Prevention Rules

Require these recovery anchors:

• Progress ledger with current/last/next pointers.
• Handoff summaries with implemented, remaining, known issues, and validation evidence.
• Commit checkpoint status and commit hashes in the ledger and handoff summaries.
• Decision log and risk/open questions log.
• Must-read file list per handoff.
• Latest source-of-truth note distinguishing current code from historical docs.
• Final output format for future agents.
• Final completion summary after all handoffs.

Templates

For copyable templates, read references/templates.md when creating the doc set. It includes the Version 1 execution contract, implementation plan, master roadmap, progress ledger, optional controlled-parallel topology, architecture target state, phase, handoff, decision log, risk/open question, review checklist, and final completion summary templates.

Orchestration Completion

After approved governance docs are created and planning validation passes:

1. Keep the contract Draft until the user gives explicit execution approval.
2. On approval, set it to Approved for Execution, record approval evidence, and update the ledger mirror.
3. Return READY_FOR_EXECUTION with this copyable invocation:

Use the `implementation-handoff-execution` skill to execute docs/loop/<workstream-slug>/ from its Version 1 contract and ledger in continuous-autonomous mode until all implementation is complete or a genuine decision dead end is proven.

Do not invoke execution or implement code from this planning-only skill.

Plan the execution docs to use only these terminal outcomes: ALL_HANDOFFS_COMPLETE, IMPLEMENTATION_COMPLETE_RELEASE_BLOCKED, IMPLEMENTATION_DECISION_BLOCKED, and VALIDATION_BLOCKED_AFTER_INDEPENDENT_WORK_EXHAUSTED.

Pressure Scenarios / Skill Tests

Use these scenarios before trusting the generated system:

Scenario	Expected Behavior
Huge feature with vague scope	Produces phases/handoffs first, asks only blocking product questions, does not implement.
LLM tries to implement code	Stops itself and returns to planning/governance docs only.
Manual review loop problem	Encodes auto-continue for validated non-blocked handoffs; stops only for real gates/blockers.
Context loss after long run	Recovers from ledger, last validated handoff, next pointer, decisions, risks, and summaries.
Stale docs vs current code	Treats current source and latest ledger/summaries as authoritative; labels historical notes.
Different unrelated workstreams	Creates or selects a separate docs/loop/<workstream-slug>/ folder for each workstream.
Long implementation with several logical chunks	Adds separate commit checkpoints instead of one final catch-all commit.
Product decision needed	Uses decision authority and records an Agent-Derived Decision when evidence identifies a safe option; stops only at a Genuine Decision Dead End.
Release blocker vs decision blocker	Allows validated implementation closeout with release blockers preserved.
Security/KVKK/PII risk	Plans least-privilege remediation and continuation when evidence is clear; stops only before unsafe guessing or unauthorized action.
Recoverable build/test failure	Plans diagnosis, repair, revalidation, and continuation rather than a user-facing stop.
Safely inferable material choice	Requires an Agent-Derived Decision and continuation.
Bounded scope discovery	Adds an emergent checkpoint/handoff and continues without broadening the approved outcome.
Evidence-satisfied phase gate	Auto-passes under the approved continuous-autonomous contract.
Two or more safe lanes, no recorded topology	Asks once for controlled parallel with serial fallback or serial before creating governance files.
Existing topology decision	Preserves contract evidence and does not ask again.
Shared file, migration, port, build, browser account, or provider	Adds a dependency or shared lock so conflicting handoffs cannot share a wave.
Controlled parallel selected	Creates topology, DAG/join, lane, lock, isolation, root-only governance, and dynamic-capacity rules.
Serial selected or legacy Version 1 contract	Omits topology file; execution remains serial.
Topology selected while contract is Draft	Keeps implementation unauthorized.

Common Mistakes

Mistake	Correction
Writing code while using this skill	Stop. This skill creates governance docs only.
Making phases too large	Split until each handoff has clear scope, validation, and exit criteria.
Asking every open question upfront	Ask only blocking questions; log deferrable ones with owner/gate.
Treating release blocker as decision blocker	Classify separately and continue if implementation can proceed safely.
Advancing without evidence	Keep status below Validated until evidence is recorded.
Trusting historical handoffs over current code	Re-check source reality and mark historical docs as superseded when needed.
Stopping after every handoff for generic review	Use auto-continue unless a real stop condition exists.
Reusing one global docs folder for unrelated work	Create or select the workstream-specific docs/loop/<workstream-slug>/ folder first.
Leaving commit handling implicit	Add commit checkpoint todos and commit evidence fields to every implementation handoff.
Using conversation memory as authorization	Persist execution mode, scope, approval evidence, and release limits in handoff-contract.md.
Treating any failure as a stop	Apply the five-part Genuine Decision Dead End predicate; otherwise recover and continue.
Treating autonomous execution as parallel authorization	Persist a separate explicit Execution Topology choice.
Letting lanes share files or scarce resources	Add dependency edges or exclusive resource locks and serialize the join.
Allowing workers to own governance or integration	Keep agent creation, governance writes, verification, and integration root-only.

Final Checklist

• Planning-only boundary preserved.
• Initial Implementation Handoff System Plan produced before files.
• Output workspace path is explicitly under docs/loop/<workstream-slug>/.
• Version 1 handoff-contract.md is included and its approval state is honest.
• User approval obtained before creating docs.
• Parallel feasibility checks cover DAG cycles, write overlap, shared resources, backend-first order, worktree isolation, and approval gates.
• A feasible topology choice is asked once and durably recorded; an existing choice is not re-asked.
• Legacy contracts without topology fields remain serial.
• Roadmap, ledger, decision log, risk/open question log, review checklist, architecture target state, phase docs, and handoff docs are covered.
• 06-controlled-parallel-topology.md exists only for controlled_parallel.
• Controlled-parallel handoffs define lanes, exclusive write scopes, locks, and integration gates.
• Worker cap, dynamic capacity, depth one, root-only authority, worktree isolation, and serial fallback are explicit.
• Handoffs include validation, self-review, Genuine Decision Dead End rules, exit criteria, and next pointer.
• Handoffs include commit checkpoint todos and commit evidence fields.
• Auto-continue and stop rules are explicit.
• continuous_autonomous, Agent-Derived Decision, Genuine Decision Dead End, and Bounded Scope Repair rules are explicit.
• Release blockers and decision blockers are separate.
• Context-loss recovery anchors are present.
• Security/KVKK/PII and tenant isolation are mandatory review areas.
• Pressure scenarios pass or gaps are fixed before declaring the system ready.
• Final output provides READY_FOR_EXECUTION and the copyable execution invocation.