The review loop
This is the motion you repeat. Four steps, and every change the company ever makes goes through them.
1. Edit a document
Change company/mission.md in whatever editor you like. Or have an agent draft it: in the room,
edit company/mission.md "<instruction>" asks for the change, and the draft still comes to you to
approve (this one wants a runner).
2. Propose it
structure propose company/mission.md -m "what changed and why"
Your edit becomes a proposal — a described change waiting to be read — and your working copy stays exactly as you left it. The change now also lives somewhere reviewable.
If you propose a file you haven't actually changed, Structure tells you so with a hint rather than a mystery.
Keep editing and propose again, and Structure notices the proposal that already covers those files and
offers to add your new edit to it as a revision — one change to review, with its history —
instead of opening a second one.
structure propose <path> --update <id> -m "what this revision changes" says it explicitly.
Amendments to one document in one arc ride one card. When your own proposal is already open on a
document you are proposing again, Structure asks rather than quietly opening a second card — and where
there is no terminal to answer at, it declines and names the two doors: fold this in with
--update <id>, or replace that card with a fresh cut using --supersedes <id>. (A third door,
--sibling, opened a second card on purpose; it was retired on 2026-09-10 — two open cards on one
document is the tangle these doors exist to prevent.) The reason is what happens next: whichever of
two cards on one document is approved first stales the other, and its author then owes a re-cut
nobody asked for.
A card that has gone stale that way says so, and says whose it is — "waiting on a re-cut from
Sofia". The re-cut is the author's chore, not the reviewer's, and its author is told through their
flags the moment it happens. The way to do one is a fresh cut:
structure propose <path> --supersedes <id> -m "…" writes the same intent against the company as it
stands and retires the stale card in its place. Adding a revision cannot fix it — a revision keeps
the base its proposal was cut from, and that base is what the conflict is about.
When a change folds several documents into one — a new page that a handful of older ones become — say so as you propose it:
structure propose notes/edition-04.md notes/frag-1.md notes/frag-2.md \
-m "consolidate two fragments into one edition" --replaces notes/edition-04.md
Structure never guesses this. Documents that merely look related are not a consolidation, so without
--replaces the final approval screen says only what the change mechanically does. With it, that
screen reads consolidates 2 existing documents into 1 replacement document above the list of what
leaves — the removals are still shown one by one, and you still sign for them. --description "…"
adds anything that wouldn't fit in the title; it is repeated on that same screen.
3. Review and approve
structure queue # what is waiting, and on whose signature
structure approve <id> # the card in full, then one honest yes
In the room, a proposal waiting on you stands above the command line as one chip, and r opens
it. Either way you read the same card, in this order:
- the author's own words about what changed and why;
- the diff of every document it touches, and the net effect counted;
- what approving does, and what it does not do;
- and only then the question.
yapproves,nleaves it open,ddiscards it after asking again.
Before anything lands, the check runs against what would actually land, not against your draft.
Approving your own proposal is fine and expected when you're working alone. That approval is the ratification, and it's recorded in the company's history with your name on it.
4. Send an agent at it
In the room, edit <path> "<instruction>" sends a role at a document. The agent works
read-only: it narrates what it's reading as it reads, and its output arrives as — a proposal.
Same review, same approval, same record.
That symmetry is the point: everything becomes a proposal, and review is where the company decides. There is no path where an agent's change lands without the read that yours needs.
When something's off
structure doctor— what's connected, what isn't, and the next command for each.structure check— the company typechecks. Run it in CI and it keeps everyone honest.- A model you asked for that isn't available says so and falls back to built-in heuristics. It never quietly substitutes a different one.
A proposal is a branch and an approval is a merge with your name in the trailer — Structure never makes you say it that way.