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

DUNIN7 — the build list — v0.19

Version. 0.19 Date. 2026-08-03 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.18. Two more figures removed, by the sweep v0.18 itself introduced. B-10 said the engine had moved through "five merges"it was already six, having gone stale on this same session's own merge. And B-34 named twelve unhandled requests with their per-screen split; the figure was accurate, and the executing session established the mechanism that makes it move — the requests come from shared layout components, so every new screen's test adds to the count, exactly as B-42's rule grows with every room. The drafting session had judged twelve stable one version earlier and was wrong. Both now name the mechanism and give no number.

Changes from v0.17, carried. One count removed rather than corrected. v0.17 said a code-quality rule was broken by "fourteen files"; a direct count returns eighteen. The figure has moved with every room built — thirteen, then fourteen, now eighteen — and the drafting session was carrying whichever version it last saw. A fast-moving number does not belong in a slow-moving document, so the item now says to count it at scoping time and gives no figure. (v0.17 was drafted and never filed.)

Changes from v0.16, carried. v0.16 was drafted, corrected, and never filed — the corrected copy never reached the machine, because the drafting session changed the content while keeping the filename, so the stale copy stood and the executing session correctly halted on it. This is v0.16's content under a filename that cannot collide with it. The record holds no v0.16.

Changes from v0.15, carried into v0.16 and re-checked here. B-41 is closed — a fresh Postgres instance can now be taken to a working database by following the engine's own README, proven by a session actually doing it. Two new items — B-45 and B-46 — the first deliberately declined for now. And one item renamed, because its number was right and its noun was wrong. And the cheapest available next move is flagged — a change request that was written weeks ago and never run.


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 — and past nine, sort the versions as numbers, not text.

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-41 — the system can now be built from its own sources.

Before this week, the only working database was the one that had been running since the beginning. The migration chain stopped partway through and nobody had noticed, because every real database got the rows it was missing from the application booting rather than from the chain. It was structurally invisible until something tried to build a database without ever starting the app — which is what a live check for the provenance walk did.

What it took: a script exposing a bootstrap that previously only ran inside a web server, and a README section that did not exist — the engine's README had said nothing about the database at all.

And the part worth knowing. The change request required its own documentation to be tested by following it, on the page alone, with anything supplied from memory counting as a defect. It failed. A command in the README looked right, had never been run in that form, and did not work. It was corrected and the whole run repeated from a fresh database. The instruction to distrust the writer's own knowledge is what caught it, and the writer and the tester were the same session.

(CR-2026-165; engine 5c24d65, tag stand-up-sequence-v0_1.)


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. READY — and this is the cheapest thing on the list. A change request for it already exists and has never been run. (CR-2026-157, filed, confirmed not executed.)

> One check before it runs. That change request was written before this week, and the engine has merged repeatedly since — and will have merged again by the time anyone reads this. Its line references and assumptions need confirming against the engine as it stands at the moment of execution, not against any figure written here. The same trap B-25 walked into, where every anchor in its evidence base had been taken before a merge. That check is small; it is not the same as drafting the item again.

B-11. Make answers truthful. READY — the largest thing left on the main line. 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).


Part 2 — Side work

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. 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-33. The engine's one broken test. READY — small. One long-standing failure, unrelated to anything built, means nobody can say the tests pass — only they pass except that one.

B-34. The surface's test run ends in an error state. READY — small. No test fails, and the run still exits non-zero, because a number of background requests are left unhandled. The count is of unhandled requests in the test run, not of lint warnings — and no figure is given here, for the same reason B-42 gives none.

The mechanism, which is what makes the number move: the unhandled requests come from shared layout components that every screen renders. Any new screen whose test renders them without mocking the platform-level call adds to the count — so it grows with the surface, exactly as B-42's grows with every room. Count it when you scope it. (v0.15 called this "the surface's twelve warnings", a lint-sounding name for a figure that is not a lint figure. Renamed at v0.16; the figure itself removed at v0.19.)

B-42. A rule the codebase breaks systemically. READY — small. One code-quality rule is broken across many files, including the room that is the model everything else follows. No count is given here on purpose — it has moved every time a room was built, so any figure written into this document is wrong by the next merge. Count it when you scope it. And lint is not otherwise clean either — it carries warnings alongside those errors, so "make lint pass" is a larger job than fixing one rule. Establish the real total before scoping it.

These three are the same item wearing three hats: in each case nobody can read a clean report as clean, because a standing exception has to be held in mind. Worth doing together, and worth counting each afresh when they are — every figure here has been carried between versions more often than it has been re-counted.

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-41. A fresh database cannot be built from our own migrations. DONE. See above.

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 — new, and deliberately not done yet. Standing a database up is five commands. Wrapping them in one script is obvious and tempting, and it was declined on purpose: a wrapper hides the steps, and one of these steps fails in a way that looks like nothing happened at all. Write it down first, follow it a few times, then wrap it if it earns wrapping. Now that the sequence is written down and proven, this is available whenever it is wanted.

B-46. Where documents live. READY to scope — new, small. Implementation notes have been landing in the code repositories beside the code they describe. The filing convention says documents live in the record. Both are defensible and nothing says which is intended — with the consequence that a session orienting from the record alone cannot find them.


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 at your cadence ends that · how many live records carry a fabricated author · whether playground_dev's schema matches what the chain now produces — worth knowing, needs a production query · whether a held shape whose job failed is ever cleaned up.


Waiting on you

The restart. Seven change requests, eight merges — one spans 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 |

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

Two decisions on the queue, blocking nothing. Whether to pursue 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.19 — 2026-08-03