Obligations, not tasks
A to-do list is a pile of sentences with no one responsible and no reason to look again. Items rot quietly in it, and an assistant reading it can only guess which ones still matter. The system replaces the list with obligations: every open item has an owner, either the founder or the system, and a date on which someone must check it again. Nothing is allowed to exist without both; if no date is given, a default one is set a week out.
That one constraint makes two questions answerable by a database instead of by memory. The first is completeness: what is due for a check? A view called v_due_for_check returns every row whose date has arrived, grouped by owner, so nothing can be silently skipped. The second is importance: what matters most right now? A view called v_next_up scores each open item by its horizon, its deadline and how much other work it unblocks, and explains the score in plain words.
The assistant does not recall what is open. It looks it up, and its claims become checkable. Facts about the state of things live in the database; documents only describe how things work.
In the kit: schema/obligations.sql, with the two views v_due_for_check and v_next_up.
The approval lattice
The assistant may do a great deal. What it may do without asking is a much shorter list, and it is written down. Every action falls through one of three gates. Read and draft is automatic: nothing changes, so nothing needs a yes. Create needs approval: it is usually undoable, but it adds weight someone has to carry. Delete, spend, send, or widen anyone's reach is always asked about, however small.
The gates are sorted by consequence, not by type. A class of action graduates to automatic only when it passes a four-part test: is it reversible, can it be undone completely? Is it internal, does nothing leave the system? Is it objective, is "right" checkable rather than a matter of taste? Is it bounded, is the worst case small and known? Taste never graduates.
The rules that matter most become locks rather than promises. A rule the assistant reads is a promise; a capability that is simply not connected is a lock. The assistant drafts a message; sending it is a step it cannot reach. That is what makes it safe to hand over real power: no one has to wonder what it might have done.
In the kit: SESSION_CONTEXT.md §Approval lattice.
The session ritual
A language model remembers nothing between conversations. The system does not try to fix that with a smarter model; it fixes it with a ritual that every session follows, in the same order, every time.
Open is reading, before any acting. First, what is due for a check. Then what matters most. Then a few health counters that show whether anything broke overnight. Then the last handoff, its typed fields only: what is in flight, what must not be done, what was measured. Finally, only the doctrine written since the previous session, so standing law is never re-read in full.
Close is a transaction, not an essay. Every thread the session touched is either closed or given an owner and a new check date. Anything launched gets its own open row, so a ruling that starts something is never closed in the same breath. Rulings, shipped work and learnings each become one row. Then a typed handoff is written for the next instance, which the database refuses if the required fields are empty.
Two minutes of ceremony, and the next session picks up exactly where this one ended.
In the kit: ritual/OPEN.md, ritual/CLOSE.md.
Rulings over approvals
An assistant that asks permission for everything is safe and exhausting. The founder becomes a reviewer, approving one output after another, and the system never gets faster than that queue. The way out is not to approve less carefully. It is to answer differently.
When a decision comes up that only the founder can make, the assistant briefs it with a recommended option first. The founder's answer is then filed as a ruling: a standing rule, written in plain language, that the assistant reads at every session open. The same question does not come back. Each ruling absorbs a whole class of future decisions, so the founder's time goes into a small number of durable rules instead of a long tail of yeses.
Rulings that come from incidents harden into doctrine, a short body of operational law. New entries can be added freely and logged; changing or removing an existing one needs the founder.
The watch condition: if review time climbs, fix the rule, not the reviewer.
In the kit: ritual/DOCTRINE_TEMPLATE.md.