The Review Surface: Intentions, Not Conclusions

Why a Tool at All

Reading a brief is easy; acting on it used to mean typing task commands. So the system grew a small local web app, specified conversationally and built by the chief of staff itself over a few sessions, page by page. It binds to localhost only, has no login, reads the same vault and task database, and renders:

• The latest brief, with every task reference clickable. Click one and a modal shows the full task with one-click dispositions: confirm and raise, defer with a follow-up date, re-label to another venture, close with a reason, or attach a note.
• A task workbench — perspectives (inbox, today, flagged, forecast, waiting, review, stale, all), grouped lists, an inspector pane, keyboard-first navigation, multi-select with a batch bar, quick entry with a tiny syntax (title #venture @mode !priority ~defer ^due), and undo.
• A weekly-review walker that goes one task at a time through the stale buckets — unconfirmed, aging waiting, old low-priority, stalled in-progress — so Sunday is a guided pass, not a spreadsheet stare.
• A dependency canvas drawing the open task graph as nodes and edges, swim-laned by venture.
• Browsers for the inbox, people notes, team charters, and slash commands — each with a feedback box.
• Reports, rendered from Efforts/reports/, with the same clickable task references and a per-report comment box.

You do not need to copy this tool. You need its idea: once typing dispositions starts to chafe, ask your own chief of staff to build you a review surface, and let it grow one page at a time.

The Design Rule: Intentions, Not Conclusions

The trick that makes it safe to let a web app write into a system built on provenance: the tool writes intentions, not conclusions. Every free-text note and every non-trivial decision drops a small file into Efforts/inbox/ with a structured header — which task, which action, which page it came from — where the chief of staff picks it up on the next triage, executes it with full context, and commits it with provenance. You click; the assistant still does the bookkeeping. A note left on a report becomes a capture, not a mutation.

This matters because the tool has no judgment. It does not know that the task you just closed was a duplicate of another, or that the venture you re-labelled to was archived last week. The chief of staff does.

When Direct Mutation Is Allowed

For a long time every action went through the intention file. Then the backlog reached several hundred tasks and the round-trip — click, wait for the next triage, see the result tomorrow — was the thing making the review chafe. So a decision record carved out the task workbench as the one page that mutates the task database directly, with audit rails that mirror the vault’s:

• One git commit per action, with a tasks: prefix so they are distinguishable from the chief of staff’s own commits.
• The inverse of every action journaled, so undo is real.
• The intention file still written for anything with free text attached.

The rule that came out of it: direct mutation for actions whose meaning is unambiguous and whose author is the human; intention files for everything that needs context. “Close” from the human is unambiguous. “Here’s why this is wrong” is not.

Reports as Actionable Surfaces

Every report the chief of staff produces — research, meeting prep, a plan, a travel itinerary — is a standalone file in Efforts/reports/, and the review surface renders it. The convention that turns reports from documents into surfaces: every task reference in a report is a live handle. In Markdown reports the renderer links known task IDs automatically; in HTML reports the author marks them explicitly. Click the handle, get the modal, act. See Reports as deliverables.

The Phone / Laptop Split

Two loops, neither blocking the other. The phone is for fast reactions — a one-word reply to a brief line, a voice note. The laptop is for the heavy days: Sunday’s review, a long report, a backlog clean-up. The channel carries the first; the review surface carries the second. Both write into the same vault and the same graph.

Keep It Boring

Localhost only. No auth, because nothing leaves the machine. No build step you would dread maintaining. Read the vault directly; never keep a second copy of anything. When a page is not used for a month, delete it — the tool audit in the quarterly cadence applies here too.

#review · #tooling · #reports · #brief-review