Version. 0.3
Date. 2026-07-30
Status of this document. The single guide we work to: everything we are building, in order, with its current status. This is the one page the Operator reads at each sitting. Charter v0.1 ratified 2026-07-30; autonomous regime in effect.
Author. Claude.ai; v0.3 update by Claude Code. Operator: Marvin Percival.
Changes from v0.2 (committed at 4099715). B-1 executed and merged 2026-07-30 (CR-2026-158; Checkpoint A accepted by the Operator; engine main merge c4014d6, tag registry-completeness-v0_1) — status moved to MERGED, AWAITING DEPLOYMENT; the engine push is halted awaiting the Operator per standing protocol, after which B-2 is one restart. No other content changed.
It is written for you first. Every item has a plain-English line saying what it is and why it matters. Technical cross-references sit at the end of each line for the sessions; you can ignore them.
It updates as we go. Whenever an item's status changes, the responsible session saves the next version of this file (v0.2, v0.3 …) with the change made and the date on it — old versions stay as history, per our filing rules. The highest-numbered version is always the truth. Updating this list is part of every session's closing duty, like the rest of its reporting.
The statuses, in plain terms:
The standing documentation rule, recorded here: every substantial piece of system documentation gets an easy-to-read plain-English companion for your consumption, with examples where they help. You never have to ask for it; you only ask when you want more explanation.
The finish line, in one sentence: the full live demonstration works with no excuses — a firm's own document becomes a working engagement, information flows in, the summary view appears, a finished report comes out, a question gets a truthful answer with its sources shown, and an outsider can contribute without seeing anything else.
B-1. Fix the memory plumbing. MERGED, AWAITING DEPLOYMENT (2026-07-30). Eight kinds of recorded events were never registered with the replay machinery, so six real engagements — including your biggest — couldn't produce their summary view. The fix is built, tested (the walk-audit engagement now produces its summary view on the fixed code), accepted at its review gate, and merged with a guard that stops the mistake from ever being reintroduced. It reaches the live system through B-2. (CR-2026-158 v0.2 executed; engine merge c4014d6, tag registry-completeness-v0_1; push halted awaiting Operator; Checkpoint A report + implementation notes filed.)
B-2. Put the fix live. WAITING on B-1 · then NEEDS YOU: act. Once B-1 is finished and you've accepted it, one restart from you puts it on the live system. Example of what changes: engagement E0060, which today silently cannot produce a summary, will produce one the first time anything asks it to.
B-3. Your browser walk-through. NEEDS YOU: act (anytime). A short checklist (already written, with the exact commands to start things up) where you click through the system and say what feels right or wrong. Fifteen minutes. Your answers sharpen B-4.
B-4. The completion plan for the missing screens. WAITING on B-1–B-3. A session takes the audit's break list and your walk-through notes and writes the precise, ordered plan for items B-5 through B-9. (The completion scoping note, from walk-audit report W-list.)
B-5. The Manifestation screen. WAITING. Today the "organize what we know" room is an empty placeholder. This builds the real screen — including a marker that tells you when the view has gone stale, so what happened silently to E0005 (its newest summary is 25 versions out of date and nothing says so) can never happen invisibly again.
B-6. The Shaping screen. WAITING. The room where knowledge is arranged for a particular reader — also a placeholder today. This makes it real.
B-7. The Rendering flow, end to end. WAITING. Producing the finished document and downloading it, smoothly, from the screen — no workarounds.
B-8. Teach the Companion the last three rooms. WAITING. Today you can talk to the Companion while gathering information, but not to organize, shape, or render — for those you'd have to leave the conversation and use raw mechanics. The audit counted eight forced exits. This closes them: you ask, it does.
B-9. The "show me where this came from" walk. WAITING. Click any statement in a finished report and walk backward — to the shaped view, to the record, to the person who said it and when. The machinery underneath already does this perfectly; no screen shows it. This is the product's promise made visible.
B-10. Outside contributors, safely. READY (can run right after B-1). Lets a founder or a customer reference contribute to a deal file through a one-time link — everything they add is labelled as theirs and held for your team's approval, and they can see nothing else. Fully specified and approved. (CR-2026-157, filed.)
B-11. Make answers truthful. WAITING (needs B-16's history check first). In testing, a tiny six-note engagement answered a question with an old, already-corrected value presented as current. Before search gets better, answers must stop being wrong. Step one is finding out what happened.
B-12. Make the record searchable. WAITING on B-11. Today a question just looks at the fifty most recent notes, whatever they are — no real search exists. This builds it, over the notes and the text of uploaded documents. The biggest single piece of engineering on this list.
B-13. Ask your engagement. WAITING on B-12. The payoff: a partner asks a plain question — "what did the reference calls say about churn, and what does the contract actually promise?" — and gets a truthful answer with every source shown, which can then be kept in the record, marked as machine-assisted. When this lands, our rule against demonstrating question-answering lifts.
B-14. Read spreadsheets and slide decks. READY (independent — can run alongside anything). Today the system can't take in the cap table, the financial model, or the pitch deck — the heart of a data room. This adds those file types and fixes an inconsistency between the two upload paths.
B-15. Catch the record up on June–July. READY. Engine work landed in a window our record never absorbed. A session reads the history and writes it up properly. Also feeds B-11's investigation. (Manifest absorption pass, v0.75 residue.)
B-16. Update the foundation document. Drafting READY · commit NEEDS YOU: decision. Three corrections queued for the seed, including replacing the outdated authorization wording. A session drafts; only you approve the new version. (Seed v0.13, three riders.)
B-17. The portfolio filter. READY. A small fix: the dashboard can already group engagements into workspaces but won't filter by them. One parameter. Gives the fund-level "compare my deals" view its plumbing.
B-18. File the four protocol requirements. NEEDS YOU: decision (one word). Your agent-construction idea produced four precise requirements for the identity and authorization specs. Saying yes files them in writing with the right owners so they're waiting when those specs next move.
B-19. Keep this list alive. IN PROGRESS (this document). Sessions maintain it; you read it.
B-20. The marketing website. NEEDS YOU: decision (five questions, answers suggested). Site scope, the headline sentence, "book a working session" as the button, the honesty rule for every claim, and the go-ahead to write the full text.
B-21. Reply to Aldous. NEEDS YOU: act. Two drafts written — pick one, edit if you like, send.
B-22. Package Stele for the outside world. WAITING (steady background track). The identity component, cleaned up so a stranger can run it — plus assembling its papers in the shape a security evaluation would want, at little extra cost while we're in there.
B-23. The security story, told right. NEEDS YOU: decision (four questions, answers suggested). Not "we sell security" — rather: the incidents in the news become our backdrop, a proper assurance page speaks the security buyer's language, and certification comes before category. Includes making "a rogue agent is an unsigned agent" the flagship of our standards work.
Restricted-visibility slices 2–3 (to be reworked in grant language when their day comes) · the live-operations feed to investors (after B-10) · target-hosted visibility · the protocol wire-format changes (queued to the next version boundary by design) · OVA's remaining standalone role (one conversation, whenever) · cross-fund questions · the stray zip file in the record.
Decision 1 answered — the machine is running. The rest can wait for any sitting — nothing here decides itself.
DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — the build list — v0.2 — 2026-07-30