Your agent draws the map of your whole system. Every session after loads it.

The three rules of a map

• Topology is drawn once, in the root. A plate never restates the wires; it carries only its own detail and its procedures. Duplication is where drift starts, so there is none by construction.
• Values live nowhere in the map. No ports, caps, prices or counts — a page says where the number lives, never what it is. A map that carries values is wrong within a week.
• Whoever changes a wire updates the map in the same session. The root carries a line — verified <date> against <what> — and a reader trusts the map exactly that far.

What the root map holds, in order

• What the project is, in two sentences, and the verified line.
• The diagram: boxes and arrows, one arrow per wire with what travels on it. Direction matters more than anything else on the page.
• The wires, listed: who initiates, what travels, what never travels. This is the section that catches the lies.
• The stores: every place state lives, what it holds, what it never holds.
• The index: each plate by name, each procedure by plate and section.

What a plate holds

• For each part of its plane: what it is, what it holds, what it talks to and in which direction, what it never does, and what happens when it runs.
• Where the values live — pointers, never values.
• Its procedures: the exact commands, what to read back to know it worked, and what has actually gone wrong doing it, with the date.

On a Tuesday, your agent opens the map, sees the wire it is about to touch, and checks the date on the verified line before it changes anything.

my-app-map — verified 2026-09-04 against commit a1b2c3d and the live containers

  browser ──(requests, session cookie)──▶ api ──(SQL)──▶ postgres
                                          │
                                          └──(jobs)──▶ worker ──(files)──▶ object store

Wires: the browser never talks to the worker; the worker never reads a cookie.
Stores: postgres (users, orders — never card numbers) · object store (uploads).
Plates: my-app-map-api · my-app-map-worker · my-app-map-data · my-app-map-ops
Procedures: deploy → my-app-map-ops, deploy · restore → my-app-map-data, restore

Four sections, and nothing else

• Decided — one line per decision in force: the date, who decided, and the why. A proposal is never written as decided.
• Next — ordered, ten items at most. Each line names the thing and says what finished looks like. Order is the only status a plan has.
• Parked — ideas raised and not decided, each with the date it was raised.
• Open with the human — the decisions only a person can make, one line each, dated.

The law that keeps it from rotting

• Finished means gone. Whoever finishes an item removes it in the same session and puts what changed where it belongs: the wire in the atlas, the decision or the measurement in a record, the code in a commit. There is no Done section.
• The Ledger is walked into it. A caught row that still matters becomes one line in Next or Parked and leaves the Ledger; the rest dies.
• One writer at a time. Read the plan before rewriting it, and rewrite it whole.

my-app-plan — walked 2026-09-10 by the Tuesday session

## Decided
2026-08-14 · you · Postgres, not SQLite — two writers, one box
2026-09-02 · you · ship the importer before the dashboard — nobody can try it empty

## Next
1. Importer accepts CSV with a header row. Finished: a real customer file lands.
2. Retry the webhook on 5xx. Finished: one blip stops costing a record.
3. Dashboard: one chart, last 30 days. Finished: it answers "is it working".

## Parked
2026-08-30 · a public status page — nothing to show yet

## Open with your user
2026-09-08 · free tier: how many rows before it asks for money