Version. 0.9
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. Day-to-day status now also lives in current-status/dunin7-status-brief, which carries the decision queue.
Author. Claude.ai; v0.3–v0.4 updates by Claude Code; v0.5–v0.9 by Claude.ai.
Changes from v0.8 (committed at e037a37's parent line). B-27 DONE — the broken door turns out to have been fixed already, by a rider inside the memory-plumbing work, and the finish line is no longer blocked by it. B-29 shaped and its repair chosen — the fix is one small change in one file, not eighty-three, plus two one-line repairs the original sizing missed. B-5 sized — the screen needs almost nothing new from the engine; the piece we thought we'd have to build already exists. One of the audit's findings struck outright — the missing version-lookup for the summary view was never missing. One new item, B-30 — a trap in the plumbing that caused B-27 and was never repaired. Findings and corrections filed. 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 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.
The statuses, in plain terms: READY — a session can start it today · IN PROGRESS — a session is on it now · NEEDS YOU: decision — waiting on an answer (it will be in the status brief's queue) · NEEDS YOU: act — waiting on something only you can physically do · WAITING — queued behind an earlier item · DONE — finished, filed, verified · PARKED — deliberately set aside.
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. Built, tested, merged with a guard, pushed, and confirmed working in the wild. (CR-2026-158 v0.2; engine main a317051. Note the tag registry-completeness-v0_1 sits on the merge commit c4014d6, one before.)
B-2. Put the fix live. DONE (2026-07-30).
B-3. Your browser walk-through. DONE (2026-07-30).
B-4. The completion plan for the missing screens. DONE (2026-07-31).
B-5. The Manifestation screen. READY — front of the queue, and smaller than we thought. Today the "organize what we know" room is an empty placeholder. This builds the real screen and lands the rule that a room cannot say "nothing here" without having looked. The read found the engine already returns what the screen needs. The staleness marker — whether the record has moved since the view was built — is a wire, not a build: one existing call returns both the version the view was derived at and the engagement's version now. The remaining gaps are small and none needs a database change. (Change request A. Its first Step 0 item, B-27, is now settled — see below.)
One thing for the screen's design, found on the way. The engine has two different measures of "has the record moved": a raw version difference, and a content-change flag that deliberately ignores version movements that aren't real content. They can disagree — a view can be twenty-five versions behind and still correctly flagged current. The screen must pick one or show both with the difference made plain, or it will look like it is contradicting itself.
B-6. The Shaping screen. WAITING on B-5. (Change request C, with B-7.)
B-7. The Rendering flow, end to end. WAITING on B-5. Two things missing — no way to download, and no sign of which document is current when an older and a newer sit side by side. (Change request C.)
B-8. Teach the Companion the last three rooms. WAITING on B-5, B-6, B-7 and the engine work. (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. One of its two blockers is gone: the version-pinned lookup for the summary view, which the audit recorded as missing, exists and always did. What remains is 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). (CR-2026-157, filed, confirmed not executed.)
B-11. Make answers truthful. READY — rescoped by the walk. The answer isn't wrong, it's unstable — the same question three times gave correct, then a false confession of fabrication, then correct with its source cited.
B-12. Make the record searchable. WAITING on B-11. The biggest single piece of engineering on this list. May merge with B-11.
B-13. Ask your engagement. WAITING on B-12.
B-14. Read spreadsheets and slide decks. READY (independent). When this lands, the accepted-types list has to widen with it.
B-15. Catch the record up on June–July. DONE (2026-07-30).
B-16. Update the foundation document. READY to draft · NEEDS YOU: act (read it first). Three corrections queued for the seed, including replacing the outdated authorization wording. Drafting is authorized; committing a seed version is yours and cannot be delegated. This is the only thing on the whole list waiting on you. (Seed v0.13, three riders. Status brief queue entry Q-1.)
B-17. The portfolio filter. READY. One parameter.
B-18. File the four protocol requirements. READY.
B-19. Keep this list alive. IN PROGRESS (this document).
B-25. The record writes that aren't true. READY — drafted next, built after B-29. Eleven places where the system writes something into the permanent record that is plausible and wrong. Nine of the eleven are invisible from any screen. It cannot be built at the same time as B-29 — at three of the sites, B-25's fix and B-29's fix are the two halves of a single line of code. Its change request can be written while B-29 builds. (Two open questions and one unresolvable line reference carried to its Step 0 — see the corrections note.)
B-26. Correct the record about door 3. READY (small).
B-27. Fix the door that can't be closed. DONE — it was already fixed. The audit found that engagements started by conversation could not be committed at all. It was true of the engine the audit ran against. A rider inside B-1's work removed the broken route entirely on 2026-07-30, and the live path now calls the same code directly, so the fault cannot fire. The full demonstration is no longer blocked by this. Settled by reading the source, not by inferring from your browser pass. (W-2. Resolved at a425ecd. What is not proven this way is that creation completes end to end — that rests on B-1's own live checkpoint.)
B-28. Stop losing contributed documents. READY. The system advertises that it accepts Markdown documents, then refuses them on the way back out, and the contribution is lost rather than merely unreported. (W-3. Step 0 of change request C.)
B-29. The provenance field that is fabricated everywhere. READY — next in the engine, and the fix is chosen. Every record we write carries a field meaning "the event that produced this version." It is filled with an invented value at eighty-three places across thirty-seven files, and correctly at exactly three.
What the read changed. The fix is one small change in one file — the machinery that creates the event stamps the field itself, just before writing. The eighty-three sites are not touched. But "one seam" was not quite right: three places bypass that machinery entirely, and two of them need a one-line repair each. In both, the correct value is already sitting in a variable a line or two above the wrong one.
Why it is safe. Nothing in the system reads this field. Nothing hashes it. So changing what gets written cannot break anything downstream.
Why it should not wait. When the tamper-evidence layer is switched on, whatever is in these records at that moment becomes the permanently anchored version. Fabricated provenance inside an anchored history is materially worse than fabricated provenance outside one. B-29 lands before that switch.
(Findings §5 and the inspection findings §2. Seam option B taken — recorded with reasoning in the status brief §3, overturnable at cadence.)
B-30. The trap that caused B-27. READY — new, small. The thing that broke the door in B-27 was never repaired — only the broken door was removed. A shared piece of plumbing demands a value that only some addresses can supply, and any new address built without it will break the same way, silently. The test suite cannot see this, because the tests replace that piece of plumbing with a stand-in. It bit once, from birth, and nobody noticed for weeks. (api/deps.py:271. Named in the inspection findings §3.4 as a standing hazard.)
B-20. The marketing website. READY. All five answers confirmed.
B-21. Reply to Aldous. DONE (2026-07-30).
B-22. Package Stele for the outside world. WAITING (steady background track). (Repository at 689de41, tag v0.4.0, clean.)
B-23. The security story, told right. READY. All four answers confirmed.
B-24. Investor-visible FORAY. WAITING on B-10.
Restricted-visibility slices 2–3 · target-hosted visibility · the protocol wire-format changes · OVA's remaining standalone role · cross-fund questions · the stray zip file in the record · how many live records already carry a fabricated author (needs a production database query; surfaced, not folded in) · whether to sweep the eighty-three now-dead lines after B-29's fix lands (they will be harmless but misleading; the sweep is mechanical and collides with nothing once B-25 is done).
One, and it is the same one as yesterday.
B-16 — read seed v0.13 before it commits. Drafting was authorized on 2026-07-30; committing a seed version is yours by the charter and cannot be delegated to a session.
Everything else on this list proceeds without you. Decisions inside the authorized build items are taken by the sessions and recorded with their reasoning in the status brief, where you can overturn any of them at cadence in one word.
DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — the build list — v0.9 — 2026-07-31