Disk memory
The workshop remembers on disk — ledger, resume, board, last-session card. The chat window is not memory.
What it is#
A small set of plain Markdown files that survive the end of a chat window.
| File | What it holds | Who writes it |
|---|---|---|
.workflow/RESUME.md |
Where the workshop stands; the first thing a new seat reads | You and the Chair |
.workflow/LEDGER.md |
The numbered requirements list, one - [ ] N. line per item |
You and the Chair |
.workflow/BOARD.md |
The live board: open sessions, claims, verdicts | orch and the Chair |
<project>/docs/TRACKER.md |
Per-project state table — status, SPEC, evidence | The project's agents |
.orch/LAST_SESSION.md |
Telegraphic card describing the seat that just ended | orch, at close |
.orch/MEMORY_BRIEF.md |
Short durable brief, when memory is enabled | orch |
.orch/ORCH_RUNTIME.md |
This seat's identity: session, agent, role, MCP hint | orch, at open |
orch init seeds the first three; the rest appear as you work.
Why it exists#
Because chat is ephemeral and everybody keeps pretending it is not. A model's context window ends, gets compacted, or gets replaced by a different model tomorrow. Anything that has to outlive the window has to be a file — and a file the next agent can find without being told where to look, which is why the paths are fixed rather than configurable per project.
The second reason is arbitration. When two sessions disagree about what was decided, a ## Clarified block in the ledger settles it and a chat transcript does not.
How it relates to the rest#
- A worker's
verify_reportand the guardrail verdict orch observes at session close both land on the board, so the board is the one place where reported and observed halves sit side by side. task_claim/orch task claim <ledger-file> <item>puts exactly one owner on a- [ ] N.line, visible on the board and released when the task finishes or the session is reaped. Two agents cannot quietly both take item 12.- The sealed
orch-recallskill exists to make a new seat read.orch/LAST_SESSION.mdinstead of asking you to re-explain the project.
Shrinking a file is a human decision#
.workflow/BOARD.md and .orch/LAST_SESSION.md grow. When one gets unwieldy:
orch memory condense
It runs through the workspace gateway and it is never automatic — no size threshold triggers it. It preserves ## Clarified and ## Ownership byte-for-byte, keeps every open checkbox item, and leaves the original beside the file. There is deliberately no MCP tool for it: an agent cannot decide to forget on your behalf.
The optional context.hooks.pre_compact hook runs the same condenser just before a harness compacts its own context. Like every hook, it is off until you turn it on — see Hooks and guards.
Nothing to run here#
Reading these files is the point; writing them is ordinary editing. The only command on this page is orch memory condense, and you run it when a file is too big, not on a schedule.