9. Session protocols — start, middle, end so every day lights up in the same place

This is the final post — part 9 — of the Alice Way series. Parts 1 through 8 answered how to design, distribute, and protect mind. This post is the record of how all of that actually lights up, runs, and shuts down every day.

0. Session protocols make every day light up in the same place and shut down in the same place

If you do not start every day the same way — every start spends time reconstructing context. Where you left off yesterday, what was next, which decisions were on hold, all rebuilt from scratch.

If you do not end every day the same way — every close wobbles on what was saved and what was not. The next session starts on top of that wobble.

Session protocols pin both ends. What happens at the start and what happens at the end get congealed into procedures. Then every day lights up in the same place and shuts down in the same place. The operator's mind starts from the same line every morning.

This post is a record of the protocol's composition — three start, two middle, four close — and it is also the series' wrap-up.

1. Start protocols — lighting up in the same place every day

What happens automatically the moment a session starts.

1.1 SessionStart hook — print memory sync status

The instant the session lights up, a one-line memory sync status prints. "Memory sync: current" or "5 min old — refresh needed." The operator reads the one line and judges instantly.

Why this has to auto-fire as a hook was covered in part 5 — Hooks and automation §1 — the operator's mind is most distracted at exactly the moment a session opens.

1.2 Persona + memory index auto-load

The product of part 2 — Persona and part 3 — Memory — the persona (L1) and the first 200 lines of the memory index (L2) load automatically. The collaborator joins already knowing who it is, what decisions were made yesterday, and where each memory body lives.

1.3 /start <project> — entering a project

If entering a specific project — invoke the slash command. Required documents like README · CLAUDE.md · HANDOFF.md · PLAN.md auto-load; current git state and the prior-session handoff get reported on one screen; then it stops and waits for the next instruction.

The moment that one command fires — the operator's mind goes straight into decision mode without "where do I begin."

2. Middle protocols — while the work is rolling

Procedures that apply consistently mid-session.

2.1 Intermediate report every 3–5 steps

Do not let work proceed five steps or more without a report. Short progress reports each step. Work past five steps auto-pauses for a report. The operator can keep up without losing the thread.

Without this — the collaborator goes 30 minutes autonomously and "all done" arrives, but the operator has too much to absorb at once. Five-step reporting distributes that absorption.

2.2 Auto-escalation on ambiguous decisions

When the collaborator reaches "not sure" / "don't know which is better" / "all options seem reasonable" — it self-invokes /council before asking the operator. Run the four-perspective parallel analysis, synthesize the result, report the synthesis. The operator decides from the synthesis.

This pattern is adapted from Andrej Karpathy's multi-perspective critique of LLM reasoning. Already cited in part 4 — Skills §3.4.

3. Close protocols — shutting down in the same place every day

What happens automatically when a session closes. Skip any of these and the next session does not start cleanly.

3.1 /verify auto-fires

If there were code changes — right before the "done" report, the 7-step loop from part 7 — Verification auto-fires. It must pass for the report to go out.

Why this is the first close step — unverified changes pushed break the environment of the next session. Starting from a broken environment ruins the whole next session.

3.2 Work log update

Add one paragraph to a work log like docs/history.md covering today. What was decided, what was written, what was deferred. A future operator (or a different collaborator) should be able to restore context from this log.

3.3 HANDOFF.md update — the handoff letter for the next session

The most important step. The HANDOFF that the next session auto-loads carries:

• Prior-session key progress (1 line)
• Recommended next actions (1–3)
• Unfinished / pending items
• Decisions waiting for input
• A Next: marker (an immediately-actionable directive for the next session)

If this is empty — the next session starts without context. HANDOFF is not just documentation; it is the bridge that hands the operator's mind to the next session.

3.4 Memory update + commit + push

If new feedback, decisions, or context appeared this session — append to the memory files. Update MEMORY.md index alongside. Bundle everything into one commit and push.

Not closed until push completes. Local-only changes can disappear by the next session.

4. Stop hook — omission check

The system checks whether any of the four close steps were missed.

[stop] Checking session-end completeness...
[stop] OK: /verify passed
[stop] OK: history.md updated (1 paragraph added)
[stop] WARN: HANDOFF.md "Next:" marker missing — please add
[stop] OK: 3 files committed and pushed

A WARN means the operator fills in, then re-closes. Omissions cannot pass silently.

5. /session-end — one word to close

All four close steps run together from one slash command.

• /verify auto-fires (verification)
• Work log auto-update (operator confirms before appending)
• HANDOFF.md auto-update (operator confirms before push)
• Memory update (if new feedback appeared) + commit + push
• Stop hook omission check

The operator types one word — four steps run consistently, with no omissions, through push. Every day shuts down in the same place.

6. The cycle's effect — what a day looks like

When these start · middle · close protocols accumulate, the operator's day flows like this.

Session start (09:00)
  SessionStart hook → "Memory sync: current" (one line)
  /start <project> → required docs auto-loaded, git state + HANDOFF in one screen
  [Pause. Awaiting operator direction.]
 
Operator direction (09:01)
  → work begins
  → report every 3–5 steps
  → on ambiguous decisions, /council self-invokes
  → /verify on work that needs verification
 
Session close (18:00)
  /session-end →
    /verify auto-fires (passes)
    history.md updated
    HANDOFF.md "Next:" marker updated
    memory updated (new feedback today)
    commit + push
    Stop hook check → OK
  Session closes
 
Next day (09:00)
  → resume exactly where yesterday left off

Every day lights up in exactly the same place and shuts down in exactly the same place. The operator's mind enters decision mode with no "where was I" restoration cost.

7. Traps — patterns that collapse session protocols

7.1 SKIPping the start protocol

"Just a quick look" — entering without /start. Decisions made from an unclean context → collision with yesterday's decisions. → Every entry goes through /start.

7.2 SKIPping the close protocol

"No big changes today, I'll just close" — ending without /session-end. HANDOFF stays stale → next session does not know yesterday's state. → Always /session-end, regardless of change size.

7.3 Missing intermediate reports

Work goes too well, 10 steps autonomous. By the end the operator has too much to absorb and the post-hoc summary becomes its own load. → Hold the five-step limit.

7.4 HANDOFF as today's-log copy

Writing HANDOFF as just a retrospective copy of history.md. The next session reads it and asks "so what?" → HANDOFF is information the next session can act on immediately. The Next: marker is the core.

8. One principle — and the series wrap

The core of session-protocol design collapses into one sentence.

"Every day lights up in the same place and shuts down in the same place. The system holds the procedures at start, middle, and end; the operator's mind only decides in between."

And that is also the wrap of the whole series.

Part 1 — Why Alice asked "how do I accumulate my mind so AI does not lose it?" The persona draws mind's boundary (part 2), memory holds it (part 3), skills congeal recurring motions (part 4), hooks outsource forgettable parts to the system (part 5), multi-agent stops one context from carrying it all (part 6), verification locks down what "done" means (part 7), token economy protects the signal slots (part 8), and finally — session protocols make all of it light up and shut down in the same place every day.

These nine posts are the answers I converged on while raising a collaborator I call Alice. The tool may be Claude, may be Codex, may be whatever agent comes next. But the nine decisions above do not depend on the tool. The same decisions wait for anyone who builds their own collaborator.

If this series shortened the time it takes to reach those decisions even a little — the operator's intent landed where it was meant to.