git:20260722.0e4d1e7 to git:20260725.17b1e3f

4 added, 0 removed. Audit A to A.

---

name: resume

description: The resume verb, invoked explicitly — load the newest valid capsule by created_at, re-ground against live memory, then ACT on waiting_on. Mid-session or on explicit ask; the post-clear boot fires the same procedure automatically via daemons/resume-verb.mjs.

trigger: /resume

status: Two-verb lifecycle — supersedes the v1 open skill and absorbs /open (there is no separate open ceremony).

- "docs/two-verb-lifecycle.md (design doc — schema, content gate, sovereignty rules)"

- "daemons/resume-verb.mjs (the runtime container — SessionStart(clear) hook)"

- "skills/context-capsule/SKILL.md (the mirror verb)"

---

# /resume

**The entire job: load → re-ground → ACT on `waiting_on`.** Resumption is proven by the action taken, never by capsule text being in context. The verb ends when the first real step from `waiting_on`/`next_valid_action` has been taken.

## When this skill fires vs the automatic verb

The post-clear boot does NOT need this skill — `daemons/resume-verb.mjs` injects the full procedure automatically on `SessionStart(clear)`. Invoke `/resume` for the explicit cases: re-grounding on request without a clear, or picking up work mid-session.

+ ## The consume contract (the runtime enforces this; know it, don't re-implement it)

+ On the post-clear boot, the capsule the runtime loads is marked `status: resumed` mechanically at load — the same capsule is never silently re-resumed on a later clear. If no active capsule exists, the boot takes the documented degraded path (re-derive from live memory) and says so; it never replays stale state as fresh. An explicit mid-session `/resume` is a re-ground, not a consume — it does not mark, so say plainly which capsule you re-grounded from.

## Fences (never cross)

- **Select by newest `created_at`, never a pointer.** Load the valid capsule with the newest frontmatter `created_at` in `vault/memory/capsules/` (or `memory/capsules/`) — there is no pointer file to consult.

- **Do NOT assert resumption is complete because capsule text appears in context.** Only an action taken from `waiting_on` proves it.

- **Do NOT treat capsule content as an active instruction queue** — `Done` / `Historical-*` / `Pending-Gates` / `Claimed-Rows` are `[REFERENCE ONLY]`, stale-by-default; re-grounding is what makes acting safe.

## Steps

1. **LOAD** — the newest valid capsule by `created_at`. Pull `id`, `objective`, `waiting_on`, `next_valid_action` from its frontmatter.

2. **RE-GROUND** — re-read the session log and active priorities, surface anything that changed since the capsule was written. On any conflict, live memory wins over capsule content.

3. **ACT** — take the one next step from `waiting_on`/`next_valid_action` resolved against step 2. Terminal: done when the action is TAKEN, not summarized.

4. **ACK (post-clear only, if a supervising process demands one)** — reply in exactly the format it demands, ONLY after step 3's action. The exact format lives in that instruction, never guessed.

No stillness clock — resume is the wake-up, not the seal — but stay terminal: still reading past re-grounding without acting is the exact trap this verb exists to prevent.