DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path standing-notes/dunin7-build-list-v0_22.md

DUNIN7 — the build list — v0.22

Version. 0.22 Date. 2026-08-04 Status of this document. The single guide we work to. 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 lives in current-status/dunin7-status-brief. Author. Claude.ai; v0.3–v0.4 and v0.10 by Claude Code; the rest by Claude.ai.

Changes from v0.21. The clean-report cluster is closed and one item opened. Both repositories now pass their own checks. B-42's fix produced something worth more than the fix — an inventory separating exceptions that are genuinely inapplicable from exceptions covering real defects, so a zero can be read rather than merely counted. Two were in the second category; one is now B-51. And the recommendation is reordered: gate what is clean before it stops being clean.

Changes from v0.20, carried. A recommendation corrected and three items added that nobody knew were there. v0.20 recommended the clean-report cluster on the ground that it would make every future gate stronger. An inspection established that it makes three of six gates readable, and that three further gates exist which no document in this project had named — now B-48, B-49 and B-50. B-49 is the one to read twice: the engine's only automated check verifies documentation freshness and does not run the tests.

Changes from v0.19, carried. B-10 is closed — outside contributors can now be credentialed into an engagement without ever becoming members of it. **And this version answers what next explicitly**, at the top, because the list has grown to the point where the answer is no longer obvious from reading it.


What to do next

Three things, and the first has a window on it.

First: gate what is clean, while it is clean — B-49. Both repositories now pass their own checks, and the engine's suite is green for the first time in weeks. Nothing enforces that. The engine's only automated check verifies documentation freshness and does not run the tests at all; what the surface's automation runs is unread.

The order matters more than the size. A gate installed over a clean state simply holds. A gate installed later becomes a negotiation about what to grandfather — and this project has just spent a week finding out what accumulates when nothing holds. Small work, with a window.

Then: B-48 — decide what else a gate should check. The engine has two standard checkers configured, shipped, and never run, both reporting large backlogs. That is a decision, not a cleanup, and deciding it badly is expensive because of the volume. It does not block B-49 — running the tests needs no decision.

Then: B-11. The largest thing left on the main line, with B-12 and B-13 behind it.

Everything else can wait, and most of it is small enough to slot in whenever a session is short.


How this list works

It is written for you first. Technical cross-references sit at the end of each line for the sessions.

The highest-numbered version is always the truth — past nine, sort as numbers, not text.

Some numbers are deliberately absent. Where a count grows every time something is built, this list names the mechanism and says to count it at scoping time. A figure written here is wrong before it is read.

The statuses: READY · IN PROGRESS · NEEDS YOU: decision · NEEDS YOU: act · WAITING · DONE · PARKED.

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.


What just closed

B-10 — an outsider can contribute without becoming an insider.

A person who is never a member of an engagement can be given a credential by its Operator, claim it through the ordinary sign-up, and contribute into that engagement. Their contributions land unadmitted, fully attributed to them as a person, and admissible only by members with commit authority. They can see their own submissions and nothing else.

The fence is structural rather than a rule. Membership is what every existing read checks, and a credentialed non-member has no membership — so they are excluded from all of it without a single existing read being changed.

Three real defects were caught by its own acceptance tests, not by review: a revoke that reached across engagements, a query filter that was literally correct and broke the moment something was committed, and a value the system emitted that its own schema did not allow. All three were found by tests written to prove the acceptance criteria — the same pattern that caught a README nobody could follow two days ago.

(CR-2026-157 with its amendment note; engine 3b10ff1, tag cr-2026-157-non-member-contribution-v0_1.)

> One thing worth knowing about how it nearly went. That change request was written before the charter existed and sat unexecuted for a week. A check confirmed every function and line it named still resolved — and it would still have run a migration down-and-up cycle against the live production database, because that fence was written after it was. The code had drifted; the rules had drifted further.


Part 1 — The main line

B-1 to B-7. DONE. The four rooms exist: Memory, Manifestation, Shaping, Rendering.

B-8. Teach the Companion the last three rooms. READY — unblocked. (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. DONE.

B-10. Outside contributors, safely. DONE. See above.

B-11. Make answers truthful. READY — and the recommended next build after the cluster below. 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. Needs a Step 0 before anything is drafted.

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).


Part 2 — Side work

The clean-report cluster — closed

B-33. The engine's one broken test. DONE. A regression, not an always-broken test: a dependency added a stricter authentication step seventeen days after the test was last written, and the test's fixture had no way to know. The production path was never affected — it is a separate implementation that does not use the code the test exercises. Fixed inside the test's own fixture; nothing else changed.

B-34. The surface's test run ends in an error state. DONE — and it was hiding a real one. The failures under test were artefacts of incomplete test doubles. The gap underneath them was not: a background request failing at the network level — offline, DNS, a blocked request — threw an error nothing caught, in a browser exactly as under test. **Fixed so the failure is caught and reported, and so it still reads as we could not tell rather than *we checked and there is none*** — the rule three of the four rooms hold, and the obvious fix would have broken it.

B-42. A rule the codebase breaks systemically. DONE. The rule was right, and aimed at something this codebase does not do at those places — verified at every site individually, not sampled. Each exception states which of two things is true: the hazard does not apply here, or it does and the fix is its own item. Two fall in the second category, named rather than waived. (CR-2026-166.)

> The inventory matters more than the zero. Lint now reports nothing. A zero standing over an unlabelled exception is the same defect as a green report standing over a known failure — so every exception is categorised in the implementation notes, and the ones covering real defects carry the item that will fix them.

These three were one problem wearing three hats, and they were three of six. Each was a case where nobody could read a clean report as clean, because a standing exception had to be held in mind — and a standing exception is how a second failure hides. The other three are below, and nothing yet enforces the three now fixed. (CR-2026-166; engine 7bdbf8b, tag stele-mount-test-fix-v0_1; surface 7a9adc9, tag clean-report-surface-v0_1.)

The three nobody had named

B-48. The engine has quality tooling it has never run. READY to scope — new, and the largest of these. Two standard checkers are configured in the engine's own settings and shipped as dependencies. Neither has ever been run as a gate, and both report large backlogs — one of them in the thousands, across dozens of distinct rules, though a majority of those are mechanically fixable.

This is not a cleanup item and should not be scoped as one. The question is what a gate ought to check, and the answer is unlikely to be everything currently reported. A rule that has never run has never been agreed to — the same finding as B-42, at forty times the size. Scope it before anyone fixes anything.

B-49. The engine checks documentation and nothing else. READY — new, small, and it follows B-48. The engine's single automated check verifies that its API documentation is current. It does not run the tests. Every guarantee this project makes about the engine rests on someone remembering to run them by hand. The fix is small; what it should run is B-48's decision.

B-50. Building the surface is not the same as checking it. READY — new, small. The surface's build passes cleanly, and a direct type-check of the whole project does not. The build only inspects files reachable from the running application, so anything in the test tree is invisible to it — and that is where the errors are. A green build has been read as a checked codebase and is not one.

Everything else

B-16. Update the foundation document. READY to draft · NEEDS YOU: act (read it first). (Seed v0.13.)

B-17. The portfolio filter. READY. B-18. File the four protocol requirements. READY. B-19. Keep this list alive. IN PROGRESS.

B-25, B-27, B-28, B-29, B-41. DONE.

B-26. Correct the record about door 3. READY (small).

B-30. The trap that caused B-27. READY — small. Never repaired; only the broken door was removed. The test suite cannot see it.

B-31. The post-admission lifecycle investigation. READY to open. An investigation, not a build.

B-32. The re-derive button on the Manifestation screen. READY — small.

B-35. A missing key looks like a crash. READY — small.

B-36. A way to retire a render. READY — small.

B-37. Show when a shape's production has failed. READY — small (engine).

B-38. Bring the Rendering screen onto the shared contract. READY — small.

B-39. Ephemeral agent identities. READY to scope. B-40. Where contributed Markdown should go. READY to scope.

B-43. Walk the other way. READY — costed.

B-44. An untitled draft that has a title. READY — cosmetic.

B-45. One command instead of five. READY — deliberately deferred. Now that the stand-up sequence is written down and proven, wrapping it is available whenever it is wanted.

B-46. Where documents live. READY to scope — small. Implementation notes land in the code repositories; the filing convention says documents live in the record. A session orienting from the record alone cannot find them.

B-51. Four components rebuilt on every change. READY to scope — new. On the main dashboard, four pieces of the screen are defined inside the screen itself. The consequence is that they are torn down and rebuilt whenever anything on that page changes, rather than updated in place.

What is unread, and it decides the priority: whether any of the four holds something a user would notice losing — a scroll position, a selection, where the cursor is. If so, this is a bug people have been living with. If not, it is a performance cost. Nobody has looked.

B-47. The issuance screen for contributor credentials. READY — new, small. B-10 built the whole pathway in the engine and deliberately built no screen for it — an Operator can issue a credential only through the interface. Named as a follow-on when it was scoped, and now the follow-on.


Part 3 — Your track

B-20. The marketing website. READY. B-22. Package Stele. WAITING (background). B-23. The security story. READY. B-24. Investor-visible FORAY. READY.


Part 4 — Deliberately parked

Restricted-visibility slices 2–3 · target-hosted visibility · protocol wire-format changes · OVA's remaining standalone role · cross-fund questions · the stray zip file in the record's working tree — every session reports it and leaves it alone; a one-line decision ends that · how many live records carry a fabricated author · whether playground_dev's schema matches what the chain now produces · whether a held shape whose job failed is ever cleaned up.


Waiting on you

The restart. Nine change requests, eleven merges — two span both repositories.

| Merged and not deployed | Where | |---|---| | CR-2026-159 — the provenance field | engine | | CR-2026-160 — the Manifestation screen | surface | | CR-2026-161 — the record writes that aren't true | engine | | CR-2026-162 — the lost contribution, and downloads | both | | CR-2026-163 — the Shaping screen | surface | | CR-2026-164 — the provenance walk | surface | | CR-2026-165 — the stand-up sequence | engine | | CR-2026-157 — outside contributors | engine | | CR-2026-166 — the clean-report cluster | both |

B-16. Read seed v0.13 before it commits.

Two decisions on the queue, blocking nothing. Per-statement provenance — clicking a sentence rather than a note, which cannot be built the obvious way because asking the model to cite makes the citations model output. And whether a walk should use the event identifier, which would show the act rather than the record.

Everything else proceeds without you.


DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — the build list — v0.22 — 2026-08-04