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):

```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**
```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