Version. 0.7
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–v0.4 updates by Claude Code; v0.5–v0.7 by Claude.ai.
Changes from v0.6 (committed at e5689e1). B-3 DONE — the Operator ran the browser walk-through. It found two engine bugs that write the record wrongly, overturned two of the audit's findings, and changed what B-11 is looking for. B-4 is unblocked and now the front of the queue. B-11 rescoped — the lead written into it this morning was wrong; the real one is in its line below. B-25 has grown from a one-line fix into a change request covering three sites, and it is now the most serious correctness item on this list. New B-26 (correct the record about a verification claim that isn't supported). Findings filed at d0efb07. 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. DONE (2026-07-30). Eight kinds of recorded events were never registered with the replay machinery, so six real engagements couldn't produce their summary view. Built, tested, accepted, merged with a guard, pushed. (CR-2026-158 v0.2; engine main a317051, tag registry-completeness-v0_1. Manifest v0.76 Entry 126.)
B-2. Put the fix live. DONE (2026-07-30). Restart done, live engine verified running the fixed code, six engagements healing on next derivation.
B-3. Your browser walk-through. DONE (2026-07-30). You clicked through ten tasks. It cost about two hours rather than fifteen minutes, and it was worth every one: two engine bugs that write the record wrongly (now B-25), two of the audit's findings overturned — the Companion drafts fine and the finished documents are clearly distinguishable — and three findings made worse, including the one B-11 rests on. Not covered: the passkey commit was never re-run, so the attestation step still hasn't been proven end to end from a browser; and two smaller checks were skipped. (Findings at inspection-briefs/loomworks-walk-audit-operator-pass-findings-v0_1, filed d0efb07. Amendments W-17 onward.)
B-4. The completion plan for the missing screens. READY — unblocked, and now the front of the queue. A session takes the audit's break list, your walk-through findings, and writes the precise ordered plan for B-5 through B-9. The walk changed what this plan needs to say. It shouldn't be a list of broken screens to fix. It should carry one rule: a screen states only what it has actually checked. Eight times during your walk a screen told you something it hadn't verified — that a conversation didn't exist when it did, that your foundation was saved when its author was fabricated, that a room was empty when it wasn't. That is one problem with eight faces, and fixing it face by face will miss the ninth. (Completion scoping note, from the walk-audit break list + findings v0.1 §4 + manifest v0.76 §5.)
B-5. The Manifestation screen. WAITING. Today the "organize what we know" room is an empty placeholder — you saw it say "Nothing organized into a picture yet" on an engagement that had produced one that same morning. This builds the real screen, with a marker that tells you when the view has gone stale.
B-6. The Shaping screen. WAITING. The room where knowledge is arranged for a particular reader — also a placeholder. You saw it claim no shapes existed on an engagement holding two finished ones.
B-7. The Rendering flow, end to end. WAITING. Better than we thought: the documents are there, clearly named, and open cleanly. Three things missing — no way to download, no sign of which one is current when an older and a newer sit side by side, and the finished document carries stray formatting marks that shouldn't reach a client.
B-8. Teach the Companion the last three rooms. WAITING. Also better than we thought — asked to draft a Board brief it simply did it, working correctly from the record. What it can't do is find a finished document by the name printed on the screen, or act on a note by its number.
B-9. The "show me where this came from" walk. WAITING — and now depends on B-25. Click any statement in a finished report and walk backward to the person who said it. This cannot ship before B-25. Two of the walk's findings are records with false authorship in them; a provenance walk over false provenance demonstrates a lie convincingly.
B-10. Outside contributors, safely. READY (can run now). Lets a founder or a customer reference contribute to a deal file through a one-time link — labelled as theirs, held for approval, seeing nothing else. Fully specified and approved. (CR-2026-157, filed, confirmed not executed. At Step 0: its OVA naming is historical — GRANTHA holds the authorization seat.)
B-11. Make answers truthful. READY — rescoped by the walk. What we thought: the system answers with an old, already-corrected value. What your walk actually found, asking the same question three times in one conversation: correct answer, then "I fabricated that answer in my previous response" — a false confession about a true statement drawn from a note sitting on the screen — then correct again with its source cited. The answer isn't wrong. It's unstable. That's worse: a consistently wrong answer can be found and fixed, but one that occasionally disowns itself can't be trusted even when it's right. Second thing found: the system can read a note by its number perfectly but can't act on one — "retract 3" and "withdraw finding 3" both came back saying no such record exists, about a note it quoted correctly two turns later. The lead I wrote into this item this morning was wrong and is withdrawn: the recall path I pointed at answered correctly, twice. (Findings v0.1 §3.2 and §3.3. One read still owed: what correction-matching was actually built in July — no document records it.)
B-12. Make the record searchable. WAITING on B-11. Today a question looks at the fifty most recent notes, whatever they are — no real search exists. The biggest single piece of engineering on this list. May merge with B-11.
B-13. Ask your engagement. WAITING on B-12. A partner asks a plain question and gets a truthful answer with every source shown. When this lands, our rule against demonstrating question-answering lifts.
B-14. Read spreadsheets and slide decks. READY (independent). Today the system can't take in the cap table, the financial model, or the pitch deck. One thing the walk added: the file-chooser greys out the types it won't accept, with no explanation — so when this lands, the accepted-types list has to widen with it, or the new capability will be invisible at the only place a user meets it.
B-15. Catch the record up on June–July. DONE (2026-07-30). Six weeks and roughly forty change requests absorbed into the current-status record; seven new entries, two owed corrections applied, six open items recorded. (Manifest v0.76, record 7539f05.)
B-16. Update the foundation document. READY to draft · commit NEEDS YOU: act (read it first). Three corrections queued for the seed, including replacing the outdated authorization wording. Drafting approved; you read and approve before it commits. (Seed v0.13, three riders.)
B-17. The portfolio filter. READY. The dashboard can 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. READY. Four precise requirements for the identity and authorization specs, approved — a session files them with the right owners so they're waiting when those specs next move.
B-19. Keep this list alive. IN PROGRESS (this document).
B-25. The record writes that aren't true. READY — and the most serious correctness item on this list. What your walk found. When you edited the foundation of the new engagement, the system recorded that edit as the work of a contributor who does not exist — it checked you were allowed to make the change, then threw away who you are and stamped a randomly generated identity in the record. Separately, the greeting from the create-engagement conversation was written into a different engagement's permanent history — the one you happened to have open last — because the code can't tell "deliberately blank" from "not supplied" and quietly filled in the gap. A third instance was already known: work the Companion triggers is recorded as a contributor's. Three places where the system can't work out the true answer and writes a believable one instead of stopping. On a product whose promise is a record that tells you truthfully who did what, this is the worst failure available, and none of it is visible from any screen. One change request, not three fixes. Two searches are needed first to find out whether it's three sites or twenty. (Findings v0.1 §3.1: engagements.py:347, converse.py:690, compositions.py:73.)
B-26. Correct the record about door 3. READY (small). Our own current-status record says the document-upload path was verified live in June with an edit surviving to commit. No evidence of that verification exists anywhere in the record — and the kind of check it describes could not have found the authorship bug in B-25, because it would have compared the words and never looked at who wrote them. The claim needs a correction marker alongside it, preserved rather than deleted. Small, but it's our record making a claim it can't support. (Findings v0.1 §3.1 W-19; manifest Entry 118 carried the claim forward unexamined into v0.76.)
B-20. The marketing website. READY. All five answers confirmed. The answers are in the marketing alignment note; the session writing the copy reads them there.
B-21. Reply to Aldous. NEEDS YOU: act. Draft chosen — the shorter, warmer one. Edit if you like, then 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 its papers in the shape a security evaluation would want.
B-23. The security story, told right. READY. All four answers confirmed. Incidents in the news as backdrop, a proper assurance page, certification before category, "a rogue agent is an unsigned agent" as the flagship of our standards work.
B-24. Investor-visible FORAY. WAITING on B-10. Investor-hosted first, not target-hosted. A session scopes the adapter once B-10 lands; the pilot conversation leads the build.
Restricted-visibility slices 2–3 (to be reworked in grant language when their day comes) · 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.
None open. Decisions 1–8 are all answered. The history is kept below.
The queue is still clear of questions. What is left of your involvement is two acts — sending the Aldous reply (B-21) and reading the seed draft before it commits (B-16).
DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — the build list — v0.7 — 2026-07-30