Planner Closure Backfill

Use this output contract only when the controller activation mode is exactly one of detailer_replan or task_set_closure. Initial intake remains owned by planner-task-packet. Return one proposal for one activation; never combine the two modes or substitute one mode for the other.

Activation Modes

detailer_replan

Use only the controller-provided task identity and task revision, expected PlanTree revision, closure evidence digest, accepted facts, and supplied Detailer/user macro-adjustment evidence. Copy those authority fields and evidence refs exactly; do not read or infer unsupplied state.

Preserve accepted facts. Then return a complete replacement macro proposal for the task: it invalidates and replaces the old orchestration semantics rather than continuing, replaying, or patching the prior orchestration bundle. Do not lower acceptance criteria. The proposal mode must be exactly detailer_replan; it must never masquerade as task_set_closure.

task_set_closure

Use only the script-owned child status, revision, round digest, cleanup, release, aggregate, and closure envelope. Preserve the task-set aggregate, closure, and Frontdesk-status rules below. The proposal mode must be exactly task_set_closure; do not treat a closure as a Detailer replacement proposal.

Inputs

• controller-provided expected PlanTree and task/task-set revisions
• original intake and Planner task refs
• for detailer_replan: validated Detailer macro-impact and user evidence
• for task_set_closure: validated child round, release, cleanup, aggregate,

and closure evidence

• controller-provided closure_evidence_digest and ordered evidence refs
• for task_set_closure: script-owned closure_ref with its canonical

project-relative closure path

• current Brief/Roadmap/TODO summary supplied by the host

Do not run shell commands, file reads/searches, tests, builds, CCB commands, or notification commands. Use only the compact authority envelope in the prompt.

Semantic Decisions

Planner decides:

• whether Detailer evidence changes scope, dependency, acceptance, risk,

Roadmap ordering, or only local implementation detail;

• which accepted facts and completed child outputs remain valid;
• how partial, blocked, or replan branches change Roadmap/TODO state;
• whether the next milestone is ready, needs clarification, blocked, or the

macro request is terminal;

• what concise status Frontdesk may report to the user.

Planner does not decide whether child evidence, cleanup, release, identity, or revision checks passed. Those are controller-owned input facts.

Output

Return exactly this one fenced section and no alternative authority shape. Set mode to the exact activation value, never a selector or placeholder.

For detailer_replan, emit this legal identity/result core (all remaining fields use the same schema fields shown below):

json
{"schema":"ccb.planner.backfill_proposal.v1","mode":"detailer_replan","expected_plan_revision":"<controller expected_plan_revision>","task_or_task_set_id":"<controller task_id>","task_or_task_set_revision":<controller task_revision>,"closure_evidence_digest":"<controller closure_evidence_digest>","aggregate_result":"replan_required","result":"task_set_replanned","evidence_refs":["<controller ordered evidence ref>"]}

For task_set_closure, emit this separate legal core:

json
{"schema":"ccb.planner.backfill_proposal.v1","mode":"task_set_closure","expected_plan_revision":"<controller expected_plan_revision>","task_or_task_set_id":"<controller task_set_id>","task_or_task_set_revision":<controller task_set_revision>,"closure_evidence_digest":"<controller closure digest>","aggregate_result":"<controller aggregate_result>","result":"<mapped controller result>","evidence_refs":["<controller ordered evidence ref>"]}

`markdown
**planner-backfill.json**

{ "schema": "ccb.planner.backfill_proposal.v1", "mode": "detailer_replan", "expected_plan_revision": "sha256:<64 lowercase hex>", "task_or_task_set_id": "stable-id", "task_or_task_set_revision": 1, "closure_evidence_digest": "sha256:<64 lowercase hex>", "aggregate_result": "replan_required", "result": "task_set_replanned", "brief_summary": "durable compact summary", "roadmap_transitions": ], "todo_transitions": ], "decision_refs": ], "open_question_refs": ], "evidence_refs": ], "accepted_scope": ], "unresolved_scope": ], "blockers": ], "replan_inputs": ], "next_milestone": { "kind": "selected|workflow_terminal|blocked_none", "ref": "stable-milestone-ref", "rationale": "semantic reason" }, "frontdesk_notification_required": true, "frontdesk_status": { "schema": "ccb.planner.frontdesk_status.v1", "notification_identity": "stable-id", "aggregate_result": "replan_required", "accepted_scope": ], "unresolved_scope": ], "blockers": ], "next_milestone": { "kind": "selected|workflow_terminal|blocked_none", "ref": "stable-milestone-ref", "rationale": "semantic reason" }, "evidence_refs": ], "user_report_body": "factual user-facing report" } }

This skill carries two complete JSON exemplars: its templates/planner-backfill-detailer-replan.json file is only for detailer_replan, and templates/planner-backfill.json is only for task_set_closure. Neither exemplar authorizes emitting the other mode.

Rules

• expected_plan_revision is a digest: copy the supplied

sha256:<64 lowercase hex> value exactly. Never convert it to a counter, infer a newer revision, or repair a stale value in provider prose.

• Copy task_or_task_set_id, task_or_task_set_revision,

closure_evidence_digest, and the ordered supplied evidence refs exactly. detailer_replan uses the supplied task identity and task revision, never a task-set identity or an inferred replacement revision.

• Preserve the controller-owned aggregate_result exactly. The complete

mapping is pass -> closure_complete, partial -> closure_partial, replan_required -> task_set_replanned, and blocked -> closure_blocked. Never output a complete semantic result for non-pass aggregate evidence.

• For task_set_closure: Treat closure_ref as script-owned input. Copy

closure_ref.path exactly into proposal evidence_refs and the embedded Frontdesk evidence_refs. Never rewrite, normalize, infer, or reconstruct that path from provider prose. Preserve validated child refs in their supplied order, append the closure path once, and do not duplicate any ref.

• Derive accepted_scope, unresolved_scope, blockers, replan_inputs, and

evidence_refs from validated controller authority. Never invent accepted scope or pass from missing/nonterminal evidence. pass requires empty unresolved/blocker/replan fields. Every non-pass requires non-empty unresolved_scope; blocked requires blockers and replan_required requires replan inputs.

• A detailer_replan retains accepted facts but replaces old orchestration

semantics. Do not replay, merge with, or claim continuity of the old bundle. A task_set_closure retains its aggregate and closure semantics. Never exchange those activation rules.

• Multiple replan children produce one coherent macro proposal, not multiple

independent Planner actions.

• Never overwrite a newer PlanTree revision. Return revision_conflict and the

supplied current revision as a blocker.

• Preserve aggregate result, accepted scope, unresolved scope, blockers, next

milestone, and evidence refs byte-for-byte in frontdesk_status.

• Embed exactly one complete ccb.planner.frontdesk_status.v1 object under the

sole frontdesk_status field, including when notification is not required.

• Do not fabricate child evidence, hashes, tests, release, cleanup, or user

decisions.

• No PlanTree write, Frontdesk notification, CCB command, file operation, test,

wait, watch, or downstream ask is allowed from this reply-only surface. The host validates and imports the proposal and owns every side effect.

• Do not modify PlanTree or send Frontdesk messages from the provider reply.