dotHuman
Protocol Handbook v0.3

Resume Notes

Depth

RESUME.md — a per-goal handoff for active work. It's the live cursor on a goal: drop it, and the next session picks the goal up exactly where it stopped — whether that's you two weeks later or someone else taking it over.

What it's for

Real work is rarely one goal at a time. You're moving between several projects across weeks or months, and a goal you paused on Tuesday is cold by the time you come back to it. Git tells you what changed; it doesn't tell you what you were in the middle of — the decision you were weighing, the thing you'd just verified, the trap you'd discovered, the exact next step. That context normally evaporates when the session ends.

RESUME.md is where it gets parked instead. It turns "spend an hour rebuilding context" into "read one page and keep going." Three jobs it does:

  • Cold-start recovery. Return to a goal after two weeks and reload it in a minute — what's done, what's next, what not to touch.
  • Parallel projects. Each goal carries its own landing pad, so switching between projects costs a read, not a re-investigation.
  • Mid-stream handoff. Hand the goal to another person — or a fresh agent — and they can pick it up: the notes carry the owner, the open decisions, and how to confirm the work is where the notes say it is.

This is part of what makes a goal different from a one-off command: a command ends when the session does; a goal survives the session, because its cursor is written down.

What goes in one

It's a snapshot of live state, not a spec — it changes every session. The fields that recur in real ones:

  • Status line — paused-date, owner, and a one-line "where it stands" (e.g. built & verified, or blocked on 4 decisions).
  • The goal — a line or two, so a cold reader knows the point without opening the spec.
  • Done this session — what's settled, so nobody re-investigates it.
  • Next up — the exact next step(s), specific enough to act on without re-thinking.
  • Blocked on / open decisions — anything waiting on a human call, listed so it isn't lost.
  • Verify on resume — a couple of read-only checks that confirm reality still matches the notes (state drifts while you're away).
  • Watch-outs — the traps and "don't break this" guardrails the session surfaced.

Keep it current and keep it short — it's a cursor, not a chronicle. The running history of how the work went lives in the Captain's Log; RESUME.md only holds where you are right now.

Example

A generalized handoff for an in-flight goal:

# RESUME — add a contact form to the site (pick up here)

> Paused: 2026-06-16 · Owner: you · Goal folder: Goals/2026-06-16_contact-form/

## The goal
Add a working contact form so visitors can send a message from the site.

## Done this session
- Form built and styled; it submits without errors in the browser.
- Wired up sending through the mail service.

## Next up
1. Messages aren't arriving yet — verify the sender address, then re-test a real submit.
2. Add spam protection (parked as a sidequest).

## Verify on resume
- Open /contact and submit a test message — the form should accept it.
- Check the inbox: nothing arrives yet (that's the open thread).

## Watch-out
- A submit can succeed in the browser and still never be delivered — test end to end.

That's enough for a cold start: the goal, what's settled, the precise next move, how to check the world still matches the notes, and the trap to avoid.

Where it sits

RESUME.md is part of the floor of every Goal, and one of the two artifacts the protocol uses to survive a context reset. Where _contextreset.md re-grounds the whole context, RESUME.md resumes one goal — the project-wide briefing versus the per-goal cursor.

Related

Last updated