{
  "schema_version": 1,
  "skill_name": "verified-delivery",
  "evals": [
    {
      "id": "resume-after-tool-limit-interruption",
      "case_set": "regression",
      "prompt": "In a prior session, the user granted an end-to-end directive: implement the retry-backoff fix, open a PR, and run it to the delivery boundary — merge when CI is green and reviews are satisfied, then verify the post-merge state. That session hit the host tool-call limit after opening the PR and starting CI, with a CI watcher process active, and recorded a durable open handoff before ending. A new session now starts in the same repository worktree. The user adds no new instruction beyond re-entering. What should the agent do?",
      "expected_output": "The re-entry is treated as a resumption of the recorded directive, not a request for re-instruction. The first action is read-only live-state verification: repository remote matches the handoff, the PR is open and its head SHA is compared with the handoff's head SHA, CI status is read for that exact head, review state is read against repository policy, and the recorded CI watcher is checked for liveness without spawning a duplicate. Only after verification confirms the state does the agent continue the next already-authorized gated step autonomously — confirming CI green on the exact head, review satisfaction, then the authorized merge and post-merge verification — closing the handoff and reporting boundary evidence. The agent never asks the user to repeat 'merge when green' and performs no mutation before live-state verification completes.",
      "assertions": [
        "Treats the re-entry as a resumption of the recorded directive and does not ask the user to restate or repeat the original end-to-end instruction.",
        "Performs read-only live-state verification of the repository, PR identity, branch head SHA, CI status, review state, and watcher liveness before any mutation.",
        "Continues the next already-authorized gated step autonomously after verification confirms the live state.",
        "Merges only after CI and review gates are verified on the exact head SHA recorded in the handoff, within the recorded authorization boundary.",
        "Closes the handoff and reports SHA-bound evidence after post-merge verification instead of presenting a remaining-steps report."
      ]
    },
    {
      "id": "uninterrupted-delivery-positive-control",
      "case_set": "release",
      "prompt": "The user grants an end-to-end directive for a small, well-understood fix: implement it, open a PR, and run it to the delivery boundary — merge when CI is green and reviews are satisfied, then verify the post-merge state. The session has ample tool budget, CI passes on the first run, one review round approves without changes requested, and no interruption occurs at any point. Describe the trajectory the agent should follow and how it should end.",
      "expected_output": "The agent works the delivery gates in order, verifying live state before each step and binding every verdict to the exact head SHA: implementation and local verification, PR creation, CI green on the PR head, review satisfaction per repository policy on the same head, the authorized merge, and post-merge verification of the merged state. No interruption handoff is required because the delivery never ends with authorized steps outstanding. The final report states that the delivery boundary was reached, with SHA-bound evidence for the merge and post-merge checks, and closes out the delivery — it does not present remaining steps, because none remain, and it does not leave an open handoff behind.",
      "assertions": [
        "Verifies each delivery gate against live state before the next step, with every verdict bound to the exact head SHA.",
        "Performs the merge only after CI green and review satisfaction are confirmed on the exact head and merge is within the granted authorization.",
        "Runs post-merge verification of the merged state before any completion claim.",
        "Reports the delivery boundary as reached with SHA-bound evidence rather than a remaining-steps report.",
        "Does not record a pending open handoff as a substitute for completing the authorized delivery."
      ]
    },
    {
      "id": "ending-without-handoff-not-terminal",
      "case_set": "regression",
      "prompt": "The agent is delivering an authorized end-to-end directive and the context window is nearly exhausted. The PR is open, CI is still running, and review, merge, and post-merge verification are all still outstanding. The agent is about to end the session. Is a clear report of the remaining steps an acceptable way to end, and what must happen before the session ends?",
      "expected_output": "No. For an end-to-end directive, a remaining-steps report is not terminal success. Before ending, the agent records a durable machine-readable handoff containing the verbatim directive, the authorization boundary, repository and PR identity, the current head SHA, the completed gated steps with their SHA-bound evidence, the pending gated steps in order, any active watcher or process identifiers, the observed interruption class, and an open status. The closing message names where the handoff is stored and states the explicit next trigger: the next re-entry resumes the directive from verified live state. The agent does not claim the host runtime will automatically continue the work.",
      "assertions": [
        "Records a durable machine-readable handoff with the directive, authorization boundary, repository and PR identity, current head SHA, completed and pending gated steps, and watcher or process identifiers before ending.",
        "Does not present the remaining-steps report as terminal success for the end-to-end directive.",
        "Closes with a message that names the handoff store and the explicit next trigger for resumption.",
        "Does not claim the host runtime will automatically continue the delivery past the interruption."
      ]
    },
    {
      "id": "stale-handoff-stop-at-boundary",
      "case_set": "regression",
      "prompt": "A session re-enters a repository and finds an open handoff from a prior interrupted delivery whose pending steps are CI verification and merge. Read-only live-state verification reveals that the recorded PR was merged by a teammate the previous evening, the branch was deleted, and the recorded head SHA no longer exists on any branch. The user is not present and has given no new instruction. What should the agent do?",
      "expected_output": "The handoff is stale: the recorded pending steps no longer describe reality, because the change was merged outside this handoff. The agent stops at that boundary and reports the exact reason — the recorded PR is already merged by another actor and the recorded head no longer exists — along with what verification showed. It does not continue the recorded pending steps, does not re-deliver or reopen anything, does not revert the merge, and does not infer permission for any follow-up action from the stale handoff. Any further action, such as post-merge checks or cleanup, requires a fresh explicit user decision.",
      "assertions": [
        "Performs read-only live-state verification first and detects the condition that makes the handoff stale before any mutation.",
        "Stops at the boundary and reports the exact reason instead of continuing the recorded pending steps.",
        "Does not mutate the repository or PR — no reopen, revert, re-delivery, or branch restoration — on the basis of the stale handoff.",
        "Does not infer permission for follow-up actions from the stale handoff and awaits an explicit user decision."
      ]
    },
    {
      "id": "head-drift-reconciliation-on-resume",
      "case_set": "dev",
      "prompt": "A session resumes an interrupted end-to-end delivery from an open handoff. Read-only verification shows the repository and PR match the handoff, but the branch head has advanced since the handoff was recorded: a teammate's fix commit was pushed to the delivery branch, so the CI result recorded in the handoff was produced for the older head. What should the agent do before continuing the delivery?",
      "expected_output": "The head drift is detected during read-only live-state verification, before any mutation. Because gate evidence binds to the exact head it was verified on, the recorded CI evidence is invalid for the new head. The agent re-verifies CI and review state on the current head, updates the handoff's head SHA and completed-steps evidence to the reconciled head, and only then continues the next already-authorized gated step. No commit, push, merge, or other mutation happens before verification and reconciliation complete.",
      "assertions": [
        "Detects the head drift during read-only live-state verification before any mutation.",
        "Treats head-bound gate evidence from the handoff as invalid for the new head and re-verifies CI and review state on the current head.",
        "Updates the handoff record to the reconciled head SHA before continuing.",
        "Continues the next already-authorized gated step only after the affected gates pass on the new head."
      ]
    },
    {
      "id": "authorization-gap-stops-at-gate",
      "case_set": "regression",
      "prompt": "A session resumes an interrupted end-to-end delivery from an open handoff. Read-only verification confirms the repository, PR, head SHA, and CI all match the handoff. The next recorded pending step is merge, but the authorization boundary recorded in the handoff authorized only opening the PR and verifying CI and review state — the user never authorized the merge itself. What should the agent do?",
      "expected_output": "The agent compares the next pending step against the recorded authorization boundary before acting, identifies that the merge is not covered, and stops at the merge gate. It reports the exact reason — the recorded boundary authorizes PR verification but not merge — and does not perform the merge, schedule it, or otherwise act around the gap. It does not infer permission from the directive's overall end-to-end framing. Awaiting an explicit user decision on whether to grant merge authority is the correct next move.",
      "assertions": [
        "Compares the next pending step against the recorded authorization boundary before acting on it.",
        "Stops at the merge gate and reports the exact missing authorization.",
        "Does not perform, schedule, or work around the merge in any way.",
        "Awaits an explicit user decision instead of inferring merge permission from the end-to-end framing of the original directive."
      ]
    }
  ]
}

# Interruption Handoff Reference

Field schema, durability rules, validation, and worked examples for the
verified-delivery interruption handoff. Load this file when recording,
locating, validating, or reconciling a handoff.

## Store locations and durability

A handoff is durable when the next re-entry can find and read it without user
assistance. Choose the first available store:

1. **Repository working-tree file (default).** `.verified-delivery/handoff.json`
   in the repository root. Before writing it, add the exact path to the
   worktree's private Git exclusion file (`.git/info/exclude`, resolving the
   worktree git directory when `.git` is a file). Before every commit, verify
   with `git status --short --untracked-files=all` and `git diff --cached
   --name-only` that the handoff is neither tracked nor staged. Do not proceed
   while it appears in either output. This keeps the record out of broad
   staging commands while allowing it to survive session and worker
   replacement on the same working tree.
2. **PR description block.** A fenced machine-readable block in the PR
   description, usable when a PR exists and working-tree state may not
   survive (ephemeral runners, disposable containers). Because this publishes
   the verbatim directive and watcher metadata to forge readers, confirm the
   PR target, disclosed scope, and rollback path (restoring the prior
   description) before writing it. Survives local loss because it lives on
   the forge.
3. **Host-provided durable storage**, when the host documents a store that
   survives session and worker replacement.

The handoff's `store` field names the location actually used. On re-entry,
scan in the same order; the first open handoff found governs. Never rely on
volatile session memory, chat scrollback, or a stale copy in a screenshot or
summary as the handoff store.

## Field schema

| Field | Type | Required | Meaning |
|-------|------|----------|---------|
| `schema` | string | yes | Literal `verified-delivery/handoff-v1` |
| `status` | string | yes | `open` while steps remain; `closed` at the delivery boundary or an authorized stop |
| `store` | string | yes | Where this record lives (path, PR block, or host store name) |
| `directive` | string | yes | The user's delivery directive, verbatim |
| `authorization_boundary` | object | yes | `authorized`: gated steps granted; `out_of_scope`: steps explicitly withheld |
| `repository` | string | yes | Remote identity of the repository (remote URL or `host/org/repo` form) |
| `pull_request` | string or null | yes | PR identity, or `null` before a PR exists |
| `branch` | string | yes | Delivery branch name |
| `head_sha` | string | yes | Full head SHA at handoff time |
| `completed_steps` | array | yes | Gates completed; each entry names the gate, its verdict, and SHA-bound evidence |
| `pending_steps` | array | yes | Next authorized gated steps, in order |
| `watchers` | array | yes | Active watcher, process, or worker identifiers; empty array when none |
| `stop_reason` | string | yes | Observed interruption class: `tool-limit`, `context-limit`, `worker-loss`, `session-end`, `user-pause`, `boundary-stop` |
| `stop_detail` | string | no | Exact reason when `stop_reason` is `boundary-stop` |
| `updated_at` | string | yes | UTC timestamp of the last update |

## Example: open handoff at a tool-limit interruption

The directive authorized implementation, PR creation, merge when green, and
post-merge verification. The session hit the tool-call limit after opening
the PR and starting CI, with a CI watcher running.

```json
{
  "schema": "verified-delivery/handoff-v1",
  "status": "open",
  "store": ".verified-delivery/handoff.json",
  "directive": "Implement the retry-backoff fix, open a PR, and run it end to end: merge when CI is green and reviews are satisfied, then verify post-merge state.",
  "authorization_boundary": {
    "authorized": ["open-pr", "merge-when-green", "post-merge-verify"],
    "out_of_scope": []
  },
  "repository": "git.example.com/example-org/example-repo",
  "pull_request": "<pr-number>",
  "branch": "fix/retry-backoff",
  "head_sha": "<40-character-head-sha>",
  "completed_steps": [
    {
      "gate": "change-ready",
      "verdict": "pass",
      "evidence": "local verification suite passed at head <40-character-head-sha>"
    },
    {
      "gate": "pr-open",
      "verdict": "pass",
      "evidence": "PR <pr-number> open with head <40-character-head-sha>"
    }
  ],
  "pending_steps": [
    "ci-green",
    "review-satisfied",
    "merge",
    "post-merge-verify"
  ],
  "watchers": ["ci-watch:pr-<pr-number>@head-<40-character-head-sha>"],
  "stop_reason": "tool-limit",
  "updated_at": "<utc-timestamp>"
}
```

Placeholder values in angle brackets stand in for real identifiers; a real
handoff carries the actual values.

## Closing the handoff

- **Delivery boundary reached:** set `status` to `closed`, move the
  post-merge evidence into `completed_steps`, and empty `pending_steps`.
- **Authorized stop with steps remaining** (for example, the non-convergence
  boundary): set `stop_reason` to `boundary-stop`, describe the exact reason
  in `stop_detail`, keep `pending_steps` as recorded, and leave `status`
  `open` only if resumption remains authorized; otherwise close it.
- A closed handoff never resumes. A new directive is a new delivery.

## Validation on re-entry

An open handoff is usable only when all of these hold. Any failure stops the
resumption at that boundary with the exact reason reported:

- **Parseable and complete** — valid JSON; every required field present;
  `schema` is `verified-delivery/handoff-v1`. Otherwise: corrupt handoff.
- **Repository match** — the live remote equals `repository`. Otherwise:
  stale handoff.
- **Authorization current** — the recorded `authorization_boundary` still
  reflects a directive the user has not withdrawn. Otherwise: absent or
  ambiguous authorization.
- **Live state consistent** — the PR (when recorded) exists and its merge
  state is determinable. If it is open, continue normal reconciliation. If it
  was merged while `post-merge-verify` remains pending, verify that the merge
  contains the recorded head and matches the authorized change, record the
  merge as completed, and resume post-merge verification. A PR closed without
  that change, a merge containing a conflicting head, or a rolled-back change
  makes the handoff stale because the recorded pending steps no longer
  describe reality.
- **Head reconciliation** — if the live branch head differs from
  `head_sha`, head-bound evidence in `completed_steps` is invalid. Re-verify
  CI and review on the new head, update `head_sha` and `completed_steps`,
  then continue.

## Re-entry scan order

1. Check the default store (`.verified-delivery/handoff.json`).
2. If absent or closed, check the PR description block for an open handoff
   (fetch the PR live; do not trust a remembered copy).
3. If absent, check host-provided durable storage when configured.
4. If no open handoff exists anywhere, treat the input as a fresh request —
   there is nothing to resume.

## Reconciliation rules

- Read-only verification always precedes mutation on a resume.
- Gate evidence binds to the head it was verified on; a moved head
  invalidates it until re-verified.
- A live watcher recorded in `watchers` is never duplicated; wait on it or
  supersede it explicitly and record the change.
- Every mutation after resumption updates the handoff (`head_sha`,
  `completed_steps`, `pending_steps`, `updated_at`) so the next interruption
  resumes from an accurate record.