| name | planner-closure-backfill |
| description | Produce one revision-fenced Planner backfill proposal for either a Detailer replan or task-set closure, with compact Frontdesk status evidence. |
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):
{"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:
{"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>"]}
**planner-backfill.json**
```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.