# Approved Plan Continuity Receipt Storage

This directory stores file-backed continuity receipts for approved-plan flows.

## Scope

This storage definition is intentionally minimal.
It defines only the receipt location, minimum receipt shape, and filename convention for continuity receipts.
It does **not** implement receipt writing, hook integration, dispatch orchestration, or gate evaluation logic.

## Receipt file format

- Format: JSON
- Encoding: UTF-8
- One receipt per file

## Minimum receipt shape

Each continuity receipt file must contain a JSON object with at least these fields:

- `planId`
- `currentTask`
- `nextDerivedAction`
- `dispatchedAt`
- `dispatchRunId`
- `childSessionKey`
- `replyClosureState`

### Minimal example

```json
{
  "planId": "plan_2026_04_24_example",
  "currentTask": "Task 15",
  "nextDerivedAction": "dispatch next approved-plan task",
  "dispatchedAt": "2026-04-24T12:00:00.000+08:00",
  "dispatchRunId": "dispatch_2026_04_24_example",
  "childSessionKey": "agent:engineering:subtask-example",
  "replyClosureState": "open"
}
```

## Filename convention

Continuity receipt filenames must follow this pattern:

```text
receipt-<planId>-<dispatchRunId>.json
```

## Naming rules

- `<planId>` should match the receipt `planId`
- `<dispatchRunId>` should match the receipt `dispatchRunId`
- Use lowercase kebab-case or other filesystem-safe identifiers
- Do not reuse one file for multiple dispatch runs

## State interpretation

- A receipt in this directory represents a persisted continuity dispatch record for one approved-plan dispatch run.
- `replyClosureState` is stored alongside the dispatch linkage so later tasks can distinguish an active dispatch record from an allowed non-dispatch closure state.
- Legal non-dispatch closure values are defined by the plan/runbook logic outside this storage README.