planner-closure-backfill

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.