executepairflowplan

name	ExecutePairflowPlan
description	Orchestrate approved Pairflow plans through the next correct local workflow route, including post-close aftermath handoff, until a settled checkpoint or real blocker is reached. USE WHEN execute a plan, continue plan-driven task progression, or determine the next delegated plan/task/bubble workflow.

ExecutePairflowPlan

Execute a Pairflow plan as a state-aware orchestrator over existing specialized workflows.

Canonical metadata authority for the inputs named below lives in:

1. references/Plan-Task-Metadata-Contract.md

Mandatory delegation and mutation gates live in:

1. references/Delegation-Gates.md

Read references/Delegation-Gates.md before the first route-caused mutation in each invocation.

Artifact Responsibilities

This skill owns only the top-level orchestration contract:

1. determine the next correct workflow route from plan metadata, task metadata, persisted bubble linkage, and normalized bubble-routing outputs
2. delegate the selected work to the correct specialized workflow surface
3. continue automatically only when the route contract allows it
4. stop cleanly at a settled checkpoint, real human checkpoint, or real blocker

This skill does not own:

1. plan/task workflow body text that belongs to CreatePairflowSpec
2. bubble lifecycle workflow body text that belongs to UsePairflow
3. raw bubble-detail interpretation or lifecycle-to-route classification
4. task supersede/archive execution
5. direct progress/archive aftermath verification details, which are delegated to repo-local Workflows/UpdateProgress.md after close-side admin has landed in the bubble commit
6. remote execution support in V1

Workflow Routing

ExecutePairflowPlan keeps the route-surface inventory stable, while some repo-local workflows exist only as backing handlers behind those route surfaces.

Route Surface Returned By ResolvePlanState	Role in This Skill	Owner / Backing Workflow
FixPlanMetadata	bootstrap or repair missing plan metadata before normal execution	repo-local Workflows/FixPlanMetadata.md
ResolvePlanState	assess current state and choose the next normalized route	repo-local Workflows/ResolvePlanState.md
ReviewPlan	review or refine plan-level readiness before task progression	CreatePairflowSpec ReviewSpec in plan-mode
CreateTask	create, review, and settle the next executable task inside a pre-kickoff ideation admin carrier	HandleTaskAdminBubble -> UsePairflow CreateBubble + CreatePairflowSpec CreateTask / ReviewSpec + PublishPreKickoffAdmin + UsePairflow InterveneBubble
ReviewTask	review/refine an existing active task inside a pre-kickoff ideation admin carrier before document refinement	HandleTaskAdminBubble -> UsePairflow CreateBubble + CreatePairflowSpec ReviewSpec + PublishPreKickoffAdmin + UsePairflow InterveneBubble
CreateDocumentBubble	stable route surface for document-bubble create/start, pre-kickoff admin publish, and same-bubble kickoff	HandleDocumentBubble -> UsePairflow CreateBubble + PublishPreKickoffAdmin + UsePairflow InterveneBubble
ReviewDocumentBubble	stable route surface for document-bubble deep review at the approval gate	HandleDocumentBubble -> UsePairflow ReviewBubble
CloseDocumentBubble	stable route surface for document-bubble approve/merge/cleanup after approval is already satisfied	HandleDocumentBubble -> UsePairflow CloseBubble
CreateImplementationBubble	stable route surface for implementation-bubble create/start, pre-kickoff admin publish, and same-bubble kickoff	HandleImplementationBubble -> UsePairflow CreateBubble + PublishPreKickoffAdmin + UsePairflow InterveneBubble
ReviewImplementationBubble	stable route surface for implementation-bubble deep review at the approval gate	HandleImplementationBubble -> UsePairflow ReviewBubble
CloseImplementationBubble	stable route surface for implementation-bubble approve/merge/cleanup after approval is already satisfied	HandleImplementationBubble -> UsePairflow CloseBubble
HandleNormalizedReplan	consume a normalized replanning signal without reclassifying raw bubble detail	repo-local Workflows/HandleNormalizedReplan.md
TroubleshootBubble	stable route surface for explicit bubble-runtime or lifecycle troubleshooting	active bubble handler -> UsePairflow troubleshooting surface
HumanCheckpoint	stop for ambiguity, contract refinement, or real operator judgment	explicit stop boundary, not an auto-run workflow
PlanComplete	stop after the plan reaches a complete settled boundary	explicit stop boundary, not a downstream workflow

Repo-local Backing Workflow	Role in This Skill	Returned As target_workflow_surface?
HandleTaskAdminBubble	repo-local owner for task creation/review admin inside a document ideation carrier, including same-carrier document kickoff after publish	no; it backs CreateTask and ReviewTask route surfaces
HandleDocumentBubble	repo-local owner for document-bubble lifecycle interpretation, UsePairflow delegation, and normalized bubble outputs	no; it backs document-bubble route surfaces
HandleImplementationBubble	repo-local owner for implementation-bubble lifecycle interpretation, UsePairflow delegation, and normalized bubble outputs	no; it backs implementation-bubble route surfaces
PublishPreKickoffAdmin	repo-local manual operator workflow for publishing bounded ideation bubble admin changes to clean main and returning structured no-kickoff publish proof	no; the document-bubble and implementation-bubble create routes consume it before kickoff
UpdateProgress	repo-local owner for normal post-implementation progress/archive verification and local pilot proof after successful CloseImplementationBubble return; required implementation task/progress/archive mutations are owned by CloseBubble before lifecycle commit	no; it is entered only after the existing close route returns settled success

Route-surface rule:

1. the names above are stable routing labels and workflow targets only
2. they do not authorize this top-level skill to inline downstream workflow bodies
3. successor tasks may implement their internals, but they must not silently rename or reinterpret the route surfaces
4. HandleDocumentBubble, HandleImplementationBubble, and PublishPreKickoffAdmin are backing workflows, not target_workflow_surface values returned by ResolvePlanState
5. raw Pairflow lifecycle truth is never classified directly by this top-level skill; repo-local bubble handlers own that read-path and then delegate into UsePairflow
6. naming convention is deliberate:
   • target_workflow_surface names stay in PascalCase
   • route_class values returned by ResolvePlanState stay in snake_case
   • example: route_class=troubleshoot_bubble targets TroubleshootBubble

Pre-Kickoff Admin Route Contract

ExecutePairflowPlan owns route selection for workflow slices that use an ideation-created bubble as a bounded pre-kickoff admin container. This is a route contract only. In the current slice, both CreateDocumentBubble and CreateImplementationBubble have adopted the pattern.

Baseline dependency:

1. UsePairflow remains the owner of the existing create --ideation, start/round-0 hold, ideation.task_pending=true, and kickoff primitives.
2. This skill may rely on those primitives, but it must not redefine ideation, rename mode flags, or move lifecycle ownership into ExecutePairflowPlan.
3. The adopted create-route sequence for both document and implementation bubbles, and task-admin document carriers is: create --ideation -> start/round-0 hold -> bounded admin in bubble worktree -> commit -> publish to main -> verify -> kickoff.

Task-admin adoption:

1. CreateTask and ReviewTask are adopted pre-kickoff admin routes. They must create or safely reuse the canonical document ideation carrier <task_id>-doc before modifying task, plan, progress, or directly related docs/admin artifacts.
2. Task creation, task refinement, task splitting, task metadata updates, plan tracker updates, and ReviewSpec task-mode approval all occur in the carrier worktree, not directly on main.
3. The carrier must remain a round-0 ideation hold while task admin is being prepared and reviewed.
4. Before task-admin files are created or edited, the handler must prove the exact carrier worktree path from refreshed Pairflow status, prove clean main, and write a PublishPreKickoffAdmin pre-side-effect authorization record naming selected admin paths, expected postconditions, ideation hold proof, and changed-path coverage.
5. CreateTask drafting may be performed directly by the handler after the carrier guard succeeds, or by CreatePairflowSpec CreateTask as a distinct helper step. A helper step is not required merely to draft the initial task. Any delegated task-admin step that can write files must execute in the proven carrier worktree. If that execution root cannot be guaranteed, it may return only proposed content or a review decision for the handler to apply inside the carrier.
6. After every task-admin edit, the handler must prove main is still clean and all changed/untracked carrier paths are selected-scope admin paths. A dirty main is a hard stop, not a cleanup opportunity.
7. After the latest task artifact is approved, the bounded admin commit must be fast-forward-published to clean main through PublishPreKickoffAdmin.
8. Only after refreshed main proves the selected plan/task/admin postconditions and refreshed Pairflow status proves the same round-0 hold may the workflow kickoff the same <task_id>-doc carrier for document refinement.
9. A task-admin route that produces route-back-to-plan, split-task, or block-not-ready output publishes only the bounded settled admin state that is explicitly authorized, then stops at the appropriate checkpoint instead of kicking off document refinement.

Admin scope:

1. allowed admin edits are bounded to plan/task/progress metadata and directly related docs or admin notes needed for the selected route
2. repo-local ExecutePairflowPlan skill/workflow documentation is allowed only when the selected admin task itself changes that orchestration contract
3. product/source implementation, runtime behavior changes, new Pairflow commands, and UsePairflow edits are forbidden during pre-kickoff admin
4. every successor task that adopts or extends this route must leave the skill operational after it lands; it must not make current routes depend on unimplemented future workflows

Publish proof:

1. the repo-local Workflows/PublishPreKickoffAdmin.md workflow is the manual operator path for proving a bounded admin commit was published to clean main, refreshed metadata or selected artifact-content postconditions were re-read, and refreshed ideation hold evidence still allows later kickoff
2. the integrated CreateTask and ReviewTask routes must consume that structured proof before document kickoff
3. the integrated CreateDocumentBubble route must consume that structured proof before kickoff
4. the integrated CreateImplementationBubble route must consume that structured proof before kickoff
5. an unmerged bubble-worktree commit, transcript prose, operator memory, or stale pre-publish metadata is never proof that lifecycle-relevant admin state reached main
6. if proof of admin scope, commit identity, publish result, or refreshed postcondition is absent or ambiguous, the workflow must stop before kickoff
7. failed admin publish, partial publish, or unknown publish state must not be converted into kickoff by fallback reasoning

Delegation Enforcement Contract

ExecutePairflowPlan is an orchestrator, not a substitute implementation of the workflow surfaces it routes to.

Hard rules:

1. every route whose target_workflow_surface is owned by another workflow must be executed as a distinct delegated workflow step before the orchestrator may advance
2. reading a downstream workflow file and applying its rules locally does not count as executing that workflow
3. the orchestrator must not approve, refine, create, close, or troubleshoot artifacts by approximating the downstream workflow in its own context
4. each delegated workflow step must return a concrete result that can be recorded in the route ledger before ResolvePlanState is run again
5. if a delegated workflow cannot be executed in the required surface, stop at HumanCheckpoint or a real blocker instead of silently downgrading to inline reasoning
6. before any route-caused mutation or lifecycle command, apply references/Delegation-Gates.md

Mandatory route-to-delegation mapping:

Route Surface	Required Delegated Execution	Minimum Result Needed Before Continuing
FixPlanMetadata	repo-local Workflows/FixPlanMetadata.md	repaired metadata or fail-closed checkpoint
ReviewPlan	CreatePairflowSpec ReviewSpec in plan-mode	approve_plan, refine_plan, split_plan, or block_not_ready; if refine_plan changes the plan, rerun ReviewSpec in fresh plan-mode context before any downstream route may advance
CreateTask	repo-local HandleTaskAdminBubble delegating create/start to UsePairflow CreateBubble; drafting the initial task directly in the handler or through CreatePairflowSpec CreateTask; delegating approval/review to CreatePairflowSpec ReviewSpec; admin publish to PublishPreKickoffAdmin; and same-carrier document kickoff to UsePairflow InterveneBubble only after approval and refreshed proof	created or safely reused <task_id>-doc ideation carrier, created/refined task artifact, ReviewSpec task-mode decision=approve_task for the latest artifact when kickoff runs, persisted doc_bubble_id=<task_id>-doc and approved task/plan tracker metadata on refreshed main, structured publish success, audited same-bubble kickoff result, or a truthful checkpoint for split/route-back/block output
ReviewTask	repo-local HandleTaskAdminBubble delegating task review/refinement to CreatePairflowSpec, admin publish to PublishPreKickoffAdmin, and same-carrier document kickoff to UsePairflow InterveneBubble only after approval and refreshed proof	approve_task, refine_task, route_back_to_plan, split_task, or block_not_ready result handled inside the carrier worktree; if approved, refreshed main proves approved task metadata, plan tracker state, doc_bubble_id=<task_id>-doc, structured publish success, and audited same-bubble kickoff
CreateDocumentBubble	repo-local HandleDocumentBubble delegating create/start to UsePairflow CreateBubble, consuming PublishPreKickoffAdmin proof, and delegating same-bubble ideation kickoff to UsePairflow InterveneBubble after refreshed postconditions	created/started ideation document bubble id, persisted doc_bubble_id linkage on main, structured publish success with refreshed postconditions, audited same-bubble kickoff result, and boundary status
ReviewDocumentBubble	repo-local HandleDocumentBubble delegating to UsePairflow ReviewBubble	review result and human approval/rework checkpoint; skipped when the handler emits a close route from trusted multi-clean-meta-review auto-approval proof
CloseDocumentBubble	repo-local HandleDocumentBubble delegating to UsePairflow CloseBubble	close/merge result, including merge_conflict_recovered when CloseBubble safely resolved and retried a bounded merge conflict; task_source_resolution proving artifact file source, verified route-context inline document payload, or explicit human override; status=implementable metadata applied in the bubble worktree before explicit conventional lifecycle commit and verified on refreshed main; and bubble artifact deletion or explicit retained-bubble reason
CreateImplementationBubble	repo-local HandleImplementationBubble for fresh create/start, safe same-id carrier reuse, pre-kickoff resume/kickoff, or linked active-hold classification; it delegates create/start to UsePairflow CreateBubble only when a new carrier is needed, consumes PublishPreKickoffAdmin proof before kickoff, and delegates same-bubble ideation kickoff to UsePairflow InterveneBubble only after refreshed postconditions	created or safely reused ideation implementation bubble id when kickoff runs, persisted impl_bubble_id linkage on main, status=in_progress on main, structured publish success with refreshed postconditions, audited same-bubble kickoff result when applicable, or a truthful active-bubble/human-checkpoint boundary when no create/kickoff delegation applies
ReviewImplementationBubble	repo-local HandleImplementationBubble delegating to UsePairflow ReviewBubble	review result and human approval/rework checkpoint; skipped when the handler emits a close route from trusted multi-clean-meta-review auto-approval proof
CloseImplementationBubble	repo-local HandleImplementationBubble delegating to UsePairflow CloseBubble	close/merge result, including merge_conflict_recovered when CloseBubble safely resolved and retried a bounded merge conflict; implementation task/progress/archive admin applied in the bubble worktree before explicit conventional lifecycle commit and verified on refreshed main; plus bubble artifact deletion or explicit retained-bubble reason before UpdateProgress verification
HandleNormalizedReplan	repo-local Workflows/HandleNormalizedReplan.md	normalized replanning follow-through result
TroubleshootBubble	active bubble handler delegating to UsePairflow troubleshooting surface	troubleshooting result and explicit stop boundary

Plan/task review gates:

1. plan_review is not satisfied by the orchestrator reading the plan and deciding it looks ready
2. task_review is not satisfied by the orchestrator creating a task with status=approved
3. CreateTask and ReviewTask may not mutate task or plan artifacts directly on main; their route-caused admin edits are made in the <task_id>-doc ideation carrier worktree and then published through PublishPreKickoffAdmin
4. CreateTask output may leave a task in draft, under_review, or another workflow-defined state; any transition to bubble-ready status must come from the delegated task review result or an explicitly delegated task-creation contract that says the task is already approved
5. no bubble route may be executed unless every upstream plan/task route in the current execution chain has a route-ledger entry with a delegated result
6. if a delegated ReviewSpec returns refine_plan or refine_task and the artifact is modified, the same review mode must be delegated again from a fresh context using the refreshed artifact before the route can be considered approved
7. a refinement loop is settled only by approve_plan, approve_task, split_plan, route_back_to_plan, block_not_ready, or a real blocker; the orchestrator must not treat its own post-edit inspection as a replacement for the repeated ReviewSpec result
8. invoking ExecutePairflowPlan explicitly authorizes mandatory downstream delegation required by this skill; this includes fresh sub-agent CreatePairflowSpec ReviewSpec passes for ReviewPlan, CreateTask approval, and ReviewTask whenever the runtime supports sub-agents
9. for ReviewPlan, CreateTask approval, and ReviewTask, sub-agent delegation is mandatory whenever the runtime supports it; if unavailable, the substitute must be an explicitly separate compact workflow step, not blended local reasoning. Initial CreateTask drafting itself may be handler-local after the carrier guard succeeds.
10. CreateTask may draft or propose the initial task artifact, but any transition to status=approved requires a fresh sub-agent ReviewSpec task-mode result for the exact refreshed task artifact and parent plan
11. if a ReviewSpec pass returns refine_plan or refine_task and any artifact changes, rerun the same mode in a new fresh sub-agent over the refreshed artifact; repeat until the result is approve_plan, approve_task, route_back_to_plan, split_plan, split_task, block_not_ready, or a real blocker
12. if sub-agents are available and no sub-agent id/result is recorded for a required ReviewSpec pass, stop with REVIEW_SPEC_DELEGATION_MISSING
13. status=approved may be written or committed only after the route ledger contains ReviewSpec task-mode decision=approve_task for the latest task artifact

Review delegation budget:

1. For the first ReviewSpec pass in a ReviewPlan, CreateTask approval, or ReviewTask route, default to full_lane_review when sub-agents are available. The first pass is the discovery pass; do not prematurely optimize it away with narrow trigger heuristics.
2. full_lane_review means the orchestrator spawns independent ReviewSpec lanes, then obtains one final ReviewSpec decision over the refreshed artifact and lane outputs:
   • metadata_lane
   • scope_lane
   • contract_lane
   • capability_lane
3. ReviewSpec lane agents are siblings owned by the ExecutePairflowPlan orchestrator. Do not ask a ReviewSpec lane sub-agent to spawn its own sub-agents.
4. After a refinement changes an artifact, default to targeted_lane_review, not another full fan-out. Rerun only:
   • lanes that previously returned refine, fail, route_back, split, or uncertain coverage,
   • lanes whose covered surfaces changed in the artifact diff,
   • and a final top-level ReviewSpec reconciliation step.
5. Before spawning targeted rerun lanes, close completed first-pass lane agents whose outputs have already been recorded in the route ledger. This is lifecycle hygiene for the orchestrator, not a review decision; it prevents stale completed agents from consuming the runtime's sub-agent/thread budget.
6. Escalate a refinement rerun back to full_lane_review only when:
   • the task or plan identity changed,
   • the bounded scope materially changed,
   • the split/no-split decision changed or became uncertain,
   • parent-plan sequencing changed,
   • a previously untouched gate family became relevant,
   • or the final reviewer cannot prove that skipped lanes remain unaffected.
7. single_thread_review is allowed only when sub-agents are unavailable, or when a later explicit policy introduces a low-risk fast path. Until then, the first pass should spend the discovery budget and refinement passes should save budget through targeted invalidation.
8. Every ReviewSpec delegation result must record the selected review mode, why that mode was selected, lane ids or explicit skipped-lane reasons, and the final ReviewSpec decision.

Fresh-context requirement:

1. downstream specialized workflows must run in fresh context whenever feasible
2. if the execution environment cannot spawn a fresh context, the orchestrator must still create a distinct workflow step with a compact input packet and a compact returned result
3. the returned result, not the orchestrator's private reasoning, is the authority for the next routing decision
4. every repeated ReviewSpec pass after a refinement must use a fresh sub-agent context whenever the runtime supports it; if a fresh sub-agent is unavailable, create a distinct compact workflow step that rereads the refreshed artifact and returns a new explicit ReviewSpec decision
5. route-ledger evidence for sub-agent ReviewSpec passes must record the sub-agent id or explicit unavailability reason, the reviewed artifact path or refreshed content version, the decision, and any required refinement loop continuation

Route Ledger

Maintain a route ledger during every invocation.

Before delegating a route, append:

route_step: <number>
resolved_route:
  route_class: <route_class>
  target_workflow_surface: <target_workflow_surface>
  continuation_mode: <continuation_mode>
  reason_code: <reason_code>
delegation:
  required_workflow: <workflow name>
  input_artifacts:
    - <path or id>
  delegated_execution_method: <subagent|separate_local_step|not_applicable>
  review_delegation:
    mode: <full_lane_review|targeted_lane_review|single_thread_review|not_applicable>
    reason: <short trigger or unavailable reason>
    lanes:
      metadata_lane: <agent_id|skipped:not_affected|skipped:unavailable|not_applicable>
      scope_lane: <agent_id|skipped:not_affected|skipped:unavailable|not_applicable>
      contract_lane: <agent_id|skipped:not_affected|skipped:unavailable|not_applicable>
      capability_lane: <agent_id|skipped:not_affected|skipped:unavailable|not_applicable>
    final_review: <agent_id|separate_local_step|not_applicable>
  delegated_result: null
mutation_allowed: false

After the delegated workflow returns, update the same entry:

delegation_result:
  status: <completed|checkpoint|blocked>
  decision: <workflow-specific decision>
  changed_artifacts:
    - <path or id>
  evidence_summary: <short factual summary>
next_resolution_allowed: <true|false>
mutation_allowed: <true|false>

Ledger rules:

1. a route with continuation_mode=auto_continue may continue only when next_resolution_allowed=true
2. if the same route repeats with no material new state recorded in the ledger, stop at HumanCheckpoint or troubleshooting
3. final reports must include the route ledger summary when any route was delegated
4. if a bubble lifecycle action is attempted without ledger proof of prior plan/task review gates, treat that as a workflow violation and stop
5. for ReviewPlan, next_resolution_allowed=true after refine_plan only authorizes rerunning the same ReviewSpec route from refreshed artifacts; it does not authorize task creation, bubble creation, or lifecycle actions
6. for ReviewTask, repeated refine_task review loops must remain inside the active HandleTaskAdminBubble carrier workflow; they do not authorize direct main edits or top-level lifecycle shortcuts outside that carrier
7. after a repeated ReviewSpec pass returns approve_plan or approve_task, the ledger entry must mention the latest reviewed artifact version or commit/evidence summary so downstream routing is tied to the approved content, not an older pre-refinement version
8. route-caused plan/task/progress metadata edits may not be committed while mutation_allowed=false
9. before committing route-caused metadata changes, cite the delegated workflow decision that authorized each staged mutation; if no decision exists, unstage or stop at HumanCheckpoint

Orchestrator Execution Style

1. Resolve before acting

Before every meaningful action:

1. read sequencing truth from plan metadata
2. read detailed local execution truth from task metadata
3. use persisted bubble linkage only to identify which repo-local bubble handler owns the next bubble-side read/decision
4. consume only normalized bubble outputs at the top level; raw Pairflow lifecycle truth is read inside HandleDocumentBubble or HandleImplementationBubble, not here
5. apply deterministic precedence only inside the declared metadata authority split
6. route to FixPlanMetadata or HumanCheckpoint instead of guessing when the contract does not close the ambiguity

2. Drive until a real boundary

Default mode is drive-until-blocked.

One invocation should continue through obvious next steps until it reaches one of these boundaries:

1. a plan-settled boundary such as PlanComplete
2. a settled bubble boundary such as "bubble started with task linkage persisted" or "bubble handed to approval review"
3. HumanCheckpoint
4. a real blocker that requires explicit troubleshooting

Loop-bound rule:

1. auto_continue is allowed only while each delegated step returns materially new authoritative state for the next routing decision
2. if the same normalized route would repeat without a trustworthy state advance, the orchestrator must fail closed to a checkpoint or troubleshooting path instead of spinning
3. drive-until-blocked applies only after every upstream delegated gate in the current route chain has a concrete route-ledger result; delegated gates outrank continuation momentum

2a. Terminal vs settled completion

ExecutePairflowPlan distinguishes task-local terminal state from plan-level settled completion.

Definitions:

1. done means task execution is complete, but archive aftermath may still be pending.
2. archived means task execution is complete and the task artifact has moved to its canonical archive path.
3. superseded means executable identity was replaced; it is terminal for execution, but its archive/lineage aftermath must still be settled before plan completion.
4. PlanComplete is a settled plan boundary, not merely a task-execution boundary.
5. A completed plan is settled only after both its task artifacts and the plan artifact itself are at their canonical archive paths.

Plan-completion rule:

1. a normal completed task must be archived before PlanComplete
2. a task left as done at a live task path is not settled enough for PlanComplete
3. the plan artifact must be archived to plans/archive/plans/<created_on>-<live-plan-filename-stem>.md before PlanComplete
4. the date used for task archive groups and archived plan filenames is the plan creation date, not the archive execution date
5. an existing archive_group date prefix may verify a known created_on, but it must not be used as the source for a missing created_on
6. when created_on is missing, derive it from explicit creation metadata or unambiguous committed first-added history before any archive move; if the only candidate is today's date, the archive execution date, body prose, or archive_group, fail closed
7. if archive settlement is deterministic, the next owner is the normal aftermath path, not direct completion
8. if archive settlement is not deterministic, stop at HumanCheckpoint with an explicit archive blocker
9. the only acceptable reason to report done after completion is as fail-closed evidence that task work finished but archive settlement did not

3. Fresh-context downstream execution

Downstream specialized workflows must run in fresh context whenever feasible.

Reasons:

1. orchestration state should not overload plan/task/bubble review contexts
2. repeated review/refinement loops should stay as unbiased as practical
3. ExecutePairflowPlan should remain a router, not an all-in-one execution transcript

Practical rule:

1. keep only orchestration state in the top-level context
2. pass the minimum correct artifact context to the delegated workflow
3. treat invocation of ExecutePairflowPlan as authorization for mandatory downstream delegation required by this skill, including fresh sub-agent ReviewSpec passes
4. use a fresh sub-agent execution whenever the runtime supports it
5. when fresh sub-agent execution is unavailable, create a distinct local workflow step with a compact input packet and a compact returned result instead of blending the downstream workflow into orchestration reasoning
6. do not advance from ReviewPlan, CreateTask, ReviewTask, bubble handler, or aftermath routes without a route-ledger result from that distinct workflow step

4. Continuation-mode policy

Continuation-mode classification is intentional across the full V1 route taxonomy:

1. auto_continue: metadata_bootstrap, plan_review, document_bubble_close only with approval_gate_state=already_satisfied, implementation_bubble_close only with approval_gate_state=already_satisfied, normalized_replanning
2. stop_at_settled_checkpoint: task_create, task_review, document_bubble_create, implementation_bubble_create, plan_complete
3. stop_at_human_checkpoint: document_bubble_review, implementation_bubble_review, troubleshoot_bubble, human_checkpoint

Policy notes:

1. ReviewPlan remains an auto_continue route because its outputs can often be consumed mechanically inside the same artifact-refinement loop without crossing a human approval gate.
2. CreateTask and ReviewTask stop at a settled checkpoint because their adopted route now creates or reuses the document ideation carrier, performs task admin in that carrier, publishes bounded admin to main, and kicks off the same carrier for document refinement only after refreshed proof. If task review returns split, route-back, or block output, the route stops at that checkpoint instead of falling through to direct main edits.
3. CreateDocumentBubble stops at a settled checkpoint only after the document route has created or reused the ideation carrier, published required admin linkage to main, verified refreshed postconditions, and kicked off the same bubble. CreateImplementationBubble stops at a settled checkpoint only after the implementation route has created or reused the ideation carrier, published impl_bubble_id and status=in_progress admin to main, verified refreshed postconditions, and kicked off the same bubble. Later review/close routing depends on successor-owned normalized bubble outputs rather than immediate top-level continuation.
4. ReviewDocumentBubble and ReviewImplementationBubble stop at a human checkpoint when the bubble handler emits a review route; however, if the handler proves the bubble reached READY_FOR_HUMAN_APPROVAL with reviewPolicy.meta_review_consecutive_clean_runs_required > 1 and metaReview.consecutiveCleanRuns meeting that threshold, it should emit the corresponding close route instead of a review route
5. document_bubble_close and implementation_bubble_close may auto-continue only when ResolvePlanState returns them with approval_gate_state=already_satisfied; the top-level skill must never infer approval from raw Pairflow state, but it may consume a bubble handler's normalized auto-approval proof as part of the close route
6. a close route is not settled merely because merge succeeded; the delegated close result must also prove bubble artifact deletion/cleanup or provide an explicit retained-bubble reason that is safe to carry forward
7. after successful implementation_bubble_close, the next same-run owner is repo-local UpdateProgress; CloseBubble must already have carried required implementation task/progress/archive admin inside the bubble commit, and only the refreshed verification result may then rerun ResolvePlanState, stop at PlanComplete, or fail closed to HumanCheckpoint
8. normalized_replanning remains auto_continue because it hands control to repo-local HandleNormalizedReplan follow-through while preserving the normalized source scope rather than dropping back to heuristic routing

See Workflows/ResolvePlanState.md for the canonical per-route output fields, including route_scope, source_scope, approval_gate_state, and the full Auto-Continue vs Checkpoint Rules.

5. Fail closed across authority boundaries

Allowed same-authority resolution:

1. plan sequencing fields remain plan authority
2. task-local status remains task authority
3. bubble lifecycle remains Pairflow authority, but raw lifecycle interpretation is consumed only inside the repo-local bubble handlers

Fail-closed cases:

1. missing required plan metadata
2. cross-authority disagreement with no declared precedence rule
3. blocked-state semantics that would widen the approved V1 contract
4. raw bubble detail that has not yet been normalized into a route class
5. route ownership ambiguity between this shell and successor tasks

V1 Routing Boundaries

This skill preserves the following V1 boundaries:

1. local-only execution scope
2. incremental next-task creation rather than generating the full task tree upfront
3. mandatory plan/task review gates before execution
4. separate document-refinement and implementation bubbles
5. normalized replanning as an explicit route surface, not a generic failure bucket

Out-of-scope route ownership remains explicit:

1. Task 3 owns raw bubble lifecycle interpretation inside HandleDocumentBubble and HandleImplementationBubble, then maps it into the normalized route taxonomy
2. Task 4 ownership is encoded in repo-local HandleNormalizedReplan, which owns plan/task follow-through after review loops or normalized replanning signals
3. Task 5 ownership is encoded in repo-local UpdateProgress, which owns normal progress/archive verification and local pilot evidence after successful implementation close; mutation of implementation task/progress/archive closeout belongs to UsePairflow CloseBubble before lifecycle commit