Version. 0.8
Date. 2026-07-31
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.8 by Claude.ai.
Changes from v0.7 (committed at 6288735). B-4 DONE — the completion plan is written and filed. B-21 corrected to DONE — the Aldous reply was sent; the list was wrong. B-5 through B-9 gain their change-request mapping, and B-9's dependency on B-25 is now explicit in its line. B-25 resized from three sites to eleven by the sizing sweeps, with one of its original three moved out of it entirely. Three new items: B-27 and B-28 (two broken paths that sit ahead of everything the completion arc builds and appeared nowhere on this list), and B-29 (one field, fabricated at eighty-three sites, one seam to fix it). W-10's disposition changed from struck to conditional. Findings filed alongside. 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. Confirmed working in the wild: engagement E0007, previously unable to produce a summary view at all, produced one on 2026-07-30. (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, and three findings made worse. 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.)
B-4. The completion plan for the missing screens. DONE (2026-07-31). Written and filed. It carries one governing rule in four faces — a surface states only what it has read back — enforced structurally rather than by review, so the ninth face cannot appear the way the first eight did. It maps B-5 through B-9 onto six change requests, sets the order and the dependencies, and defines the finish line: the walk runs clean with zero raw-mechanism departures, and the Companion never commits to an action before the authority for it has been checked. (Completion scoping note v0.1, record 7f49eba. Note goes to v0.2 with this bump.)
B-5. The Manifestation screen. READY — front of the queue. 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 and lands the rule: the room can no longer say "nothing here" without having actually looked. It also shows what the view was built from and whether the record has moved since. (Change request A. First Step 0 item: settle B-27, which sits underneath the finish line.)
B-6. The Shaping screen. WAITING on B-5. 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. Second consumer of B-5's rule, which is how we find out whether the rule generalises. (Change request C, with B-7.)
B-7. The Rendering flow, end to end. WAITING on B-5. Better than we thought: the documents are there, clearly named, and open cleanly. Two things missing, not three — no way to download, and no sign of which one is current when an older and a newer sit side by side. The stray formatting marks are an engine fault and moved to the engine work. (Change request C, with B-6.)
B-8. Teach the Companion the last three rooms. WAITING on B-5, B-6, B-7 and the engine work. Also better than we thought — asked to draft a Board brief it worked 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. And it disowns the product's own words — which is not a matter of tone: the exact word you use decides which permission gets checked, and vagueness appears to decide whether any permission gets checked at all. (Change request D. First Step 0 item: does a vaguely-worded request skip the authority check entirely?)
B-9. The "show me where this came from" walk. WAITING — depends on B-25. Click any statement in a finished report and walk backward to the person who said it. The machinery underneath already does this well — it returns the text as it was written at the time, which is exactly the point. What's missing is a screen. This cannot ship before B-25, because a walk over false authorship demonstrates a lie convincingly. (Change request E. B-29 is a design question here, not a blocker.)
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. The answer isn't wrong. It's unstable. Asked the same question three times in one conversation: correct, then "I fabricated that answer in my previous response" — a false confession about a true statement — then correct again with its source cited. A consistently wrong answer can be found and fixed; 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. (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; 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 — sized, and still the most serious correctness item on this list. It is eleven places, not three. The sweeps found the fabricated-author bug three times in one file rather than once; found five more routes that record how you signed in wrongly, destroying the one thing that distinction exists to carry; and confirmed both the wrong-engagement write and the two-doors-two-names problem. One of the original three moved out — the Companion-triggered composition is relabelled on the way to the screen, not in the record; the record is honest and the surface misreports it, so it moved to the engine work behind B-7. Every one of the first nine is invisible from any screen. (Findings at inspection-briefs/loomworks-b25-sizing-sweeps-findings-v0_1. Two open questions carried to its Step 0.)
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 — and the kind of check it describes could not have found the authorship bug in B-25. The claim needs a correction marker alongside it, preserved rather than deleted. (Findings v0.1 §3.1 W-19; manifest Entry 118.)
B-27. Fix the door that can't be closed. READY — new, and it sits underneath the finish line. The audit found that engagements started by conversation (doors 1 and 2) cannot be committed at all: the final step refuses every request, including well-formed ones, demanding something its own definition doesn't declare. Your browser pass appears to have got past it, so its current state is genuinely unknown — and the full demonstration cannot run while this stands. One read settles it. (W-2. First Step 0 item of change request A.)
B-28. Stop losing contributed documents. READY — new. The system advertises that it accepts Markdown documents, then refuses them on the way back out — and the contribution is lost, not merely unreported. The assertion count was identical before and after. Sits ahead of everything the completion arc builds. (W-3. Step 0 of change request C.)
B-29. The provenance field that is fabricated everywhere. READY — new, large-sounding and small to fix. Every record we write carries a field meaning "the event that produced this version." It is filled with a freshly invented value at eighty-three places across thirty-six files, and with the true value at exactly three. Every record this engine has ever written outside those three carries a well-formed identifier that points at nothing. The fix is one change in one place — the machinery that creates the event either accepts the true value or stamps it itself — and all eighty-three heal at once. Not a blocker for B-9; a design question for it. (Findings §5. Ruling 2 of 2026-07-31.)
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. DONE (2026-07-30). Sent. v0.7 recorded this wrongly as awaiting your action; corrected here.
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 · how many live records already carry a fabricated author (needs a production database query; a decision of a different kind, surfaced not folded in).
None open. Decisions 1–9 are all answered. The history is kept below.
The queue is still clear of questions. What is left of your involvement is one act — reading the seed draft before it commits (B-16).
DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — the build list — v0.8 — 2026-07-31