Version. 0.40
Date. 2026-08-07
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.39. B-69's standing instruction is complete — the heading is named, and the instruction now says what NOT to do as well as what to record.
Changes from v0.38, carried. B-69 is added, and it carries a standing instruction for every change request until it is resolved. Whether a seed can change after an engagement is running, and what that would ripple into.
Changes from v0.37, carried. B-47 is rewritten with its placement settled and the work it actually needs. The change request assumed a credentials screen already existed to add a button to. None does.
Changes from v0.36, carried. B-68 is added: the accounting machinery names things for itself and those names reach the screen.
Changes from v0.35, carried. The phrase everything about B-63 rested on was never written down. B-65 has its scaffold; B-63 is reclassified from a possibly-forgotten commitment to a new one.
Changes from v0.34, carried. Six items said READY and were already done — for six versions, including three written in this session. Every status is now checked against the tag that closed it rather than against the previous version of this list.
> What went wrong, because the shape of it matters more than the six corrections. Nobody follows a status. A pointer gets walked — reading one item sends you to another, and a stale pointer is caught the moment someone arrives. A status is read only when somebody opens the item, and an item that says READY when it is DONE costs nothing until that happens. That is why incidental discovery found two stale pointers and none of the six stale statuses. > > The cost is already paid three times this session. B-13, B-12 and B-17 were each opened for building and each turned out to be already built or already satisfied. That is the same failure arriving from the other direction. > > And the list was contradicting itself. When items closed in v0.30, the closures were recorded in the grouped small-work line and not in the items' own entries — so two places in this document disagreed about the same six items, and either half read as authoritative alone. That contradiction was introduced while fixing a different staleness, which is exactly the walk-audit finding already recorded above: the sweep reported the files containing stale text and never asked whether those files were the current version. The same question went unasked here — whether the entry agreed with the grouped line.
Changes from v0.33, carried. B-61 is fixed for the case that carries note content; the smaller remaining case is separated rather than folded in. B-67 is added.
Changes from v0.32, carried. A question about one missing topic found a hole where four should be. B-65 is added and it outranks the question that found it: the foundation document defers four topics to a document that does not contain them, and that document does not exist here. B-66 is added: a live misattribution that has been sitting in the architecture specification as a known gap without ever reaching this list.
Changes from v0.31, carried. One item turns out to have been built and then quietly unbuilt. B-17 is rewritten against what it actually is now; B-43 comes back untouched with its costing still good. A control that had been offering a choice it could not deliver is gone.
Changes from v0.30, carried. B-14 is done, and one more untracked thing is tracked. Spreadsheets and slide decks are read. B-64 is added: a list of what the system accepts that is wrong and currently unread.
Changes from v0.29, carried. Five items that existed only as comments, notes, or nobody's job are now tracked — and two of the old ones closed by being measured rather than built. B-59 to B-63 are added; B-12 and B-30 close. Nothing waits on you, but B-63 is a seed-level question when you want it.
> Why five at once. Each was produced by a change request in the 175–182 run and filed with a document behind it, but none was on this list. The one that prompted the sweep is B-60: it lived as an in-code comment describing itself as a follow-on, which is not the same as being tracked. The other four were in the same state.
Changes from v0.28, carried. Nothing waits on you. Both open questions are answered, B-12's unread fact was measured, and B-16 is closed — **the first time this list has had an empty Waiting on you section since it was written. Also: the foundation document's two-month-old error is corrected and so are the documents that inherited it. A duplicated block in the previous version's Waiting on you is removed.**
Changes from v0.27, carried. Everything is deployed, and looking at the deployed product found six things. Thirteen change requests went live in one act and were verified one at a time in the running system. Six new items, B-53 to B-58, five of them found by using the product rather than by reading the code.
Changes from v0.26, carried. B-8 scoped and joined B-12 on the Operator's side of the line.
Changes from v0.25, carried. B-12 scoped; the fourteen small items grouped.
Changes from v0.24, carried. B-11, B-50 and the gates are all closed.
Changes from v0.23, carried. One claim about a tag corrected.
Changes from v0.22, carried. B-49 is closed, and it was worse than the item described.
Changes from v0.21, carried. The clean-report cluster is closed and one item opened.
Changes from v0.20, carried. A recommendation corrected and three items added that nobody knew were there.
Changes from v0.19, carried. B-10 is closed.
Nothing waits on you. Both questions are answered, the one unread fact is measured, and everything merged is running.
The largest thing available: B-8 slice two — teaching the Companion to do things in the other three rooms rather than only describe them. Q-6's answer unblocked it. It has a scoping note and needs a change request.
Or the small work, grouped below so it can be swept. The single-line group is now entirely closed; what remains is the small-builds group and the scoping items.
B-48 is closed — both checkers now gate every push, one at zero tolerance.
The one thing that will eventually want you: B-65. The foundation document points four topics at a document that does not hold them. B-63 waits behind it and is on hold rather than open. Neither blocks anything being built today.
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.
The foundation document named the wrong authorization mechanism for two months, and so did everything built on it.
A decision in June moved authorization from OVA to GRANTHA — and the seed, which every session reads first, kept describing the old model. Five places. Anything written against the seed in that window inherited it: a scoping note, two vertical documents, an investigation. A correction note filed in July swept the arc it was written inside and never looked at what was written in parallel.
All of it is now corrected, and the correction took three seed versions rather than one:
v0.13 replaced the superseded model with the current one. v0.14 removed the mechanism entirely — because describing a mechanism is what made the seed go stale in the first place, and swapping one description for another leaves it exposed to the same failure on a slower clock. The seed now names which seat each substrate occupies and nothing more. (Operator direction: while basic functionality is being tested, these are named by placement, not function.)
Two of the four inherited documents were corrected. One needed nothing — its stale text lives in a version two behind the current one, and the version anyone actually reads was already clean. Naming it as a live problem was itself the error, and that is recorded.
> The finding worth keeping. The sweep searched for stale text and reported the files containing it. It never asked whether those files were the current version of their document. A superseded version carrying a superseded claim is the record working; the question is always whether the current version carries it.
B-1 to B-7. DONE. The four rooms exist: Memory, Manifestation, Shaping, Rendering.
B-8. Teach the Companion the last three rooms. SLICE ONE DONE · slice two READY, unblocked by Q-6.
Slice one shipped and is live. Three words came off a forbidden list and the Companion can now name and describe all four rooms. Verified in the product. (CR-2026-170; engine 1706248, tag companion-room-reads-v0_1.)
Slice two — the writes. One test governs it: can you know what you are approving from the sentence you typed? Deriving a summary passes. Asking for a draft passes in kind but not in cost — you would not know the price. Confirming a Shape fails outright, which is why its control stays on a screen that shows the outputs first (Q-7, answered: defer).
Q-6's answer is the prerequisite it was waiting for. Every answer a model writes will show the notes it was given; answers the system assembles will not, because they already show their own material. A write proposed from material the Companion cannot show would be an approval you could not check — that is now handled. (scoping-notes/loomworks-b8-slice-two-scoping-note-v0_1.)
B-9. The "show me where this came from" walk. DONE.
B-10. Outside contributors, safely. DONE.
B-11. Make answers truthful. DONE.
B-12. Make the record searchable. DONE — closed as already satisfied. Nothing was built and no constant was raised.
The measurement that closed it also corrected it. Every figure in the previous version of this line is right, and they count the wrong thing. Twenty-three engagements hold notes and the largest holds fifty-eight — but that fifty-eight counts notes in every state, and recall reads only the settled ones. That engagement holds ten settled. The largest anyone actually works in holds thirteen, against a window of fifty.
The window has never bound anything. Raising it would have solved a problem no project has. Every settled note in the entire system would fit in the model's context several times over.
> Why the error was invisible. The counts were all correct. Only the quantity was wrong. (CR-2026-179; completion-records/loomworks-cr-2026-179-b12-completion-note-v0_1.)
One thing is near binding, and it is the one already parked. The universal commons holds thirty-nine settled notes against the window of fifty — eleven of headroom, and it grows with every person who joins rather than with work on any project. The parked question now has a number.
> One thing does grow without bound, and it is not a project. The universal commons — the engagement every account joins automatically — holds the most of anything, and it grows with every person who signs up and contributes. Any window will be exceeded there eventually; raising the limit only moves the date. That is a different question from search, and probably a different answer: a shared space everyone contributes to is not the same thing as your own notes.
What remains before the constant is raised: measure what the model's prompt actually holds against fifty-eight notes, and raise the limit to a figure someone measured rather than a round number that sounds safe. Small. (scoping-notes/loomworks-b12-scoping-note-v0_6.)
B-13. Ask your engagement. READY — and the ask itself is already built. B-61 is closed for the case that blocked it: on a recall turn the model no longer receives notes the answer cannot cite. B-67 remains, but it concerns the organized view rather than notes, and whether it blocks this item is a scoping question rather than a known blocker. A read against the code found the question, the truthful answer, the stated boundary and the sources all in place — the ask was never the gap. (CR-2026-180 halted rather than building what was already there; inspection-briefs/loomworks-cr-2026-180-b13-step-1-findings-v0_1.)
B-14. Read spreadsheets and slide decks. DONE. A cap table, a financial model and a pitch deck can now be taken in. Each file becomes one note, the way every other document type does; a deck's speaker notes come in too, marked as notes — the argument is often there rather than on the slide.
The file chooser needed no widening. It never restricted anything: these files were always selectable and simply failed on the way in. The item's original note anticipated greying-out that the surface does not do. (CR-2026-181; completion-records/loomworks-cr-2026-181-b14-completion-note-v0_1 §3.)
B-33, B-34, B-42. DONE. Three symptoms of one problem: 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. They were three of six; the other three are below. (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, and the ones covering real defects carry the item that will fix them.
Twenty items, and grouping them is the point. Each is currently its own change request; taken in one or two passes they are perhaps two days. Ordered by how self-contained they are.
Single-line or near it. (All closed. B-26, B-35, B-44, B-53, B-57, B-58 and B-59 are DONE — see their entries.)
Small builds, one file or two. B-52 (an answer's sources vanish on refresh) · B-32 (no way to rebuild a summary the record has moved past) · B-37 (a failed production looks identical to a running one) · B-47 (credentials can only be issued through the interface) · B-54 (partly done — the code half landed; the fixtures and the rule remain) · B-55 (a screen claiming something it cannot check) · B-56 (a development sign-in on the live perimeter) · B-60 (where a document came from is dropped before Memory) · B-64 (the list of what the system accepts is wrong) · B-66 (a contributor who speaks is credited as the Operator). (B-36 and B-38 have since closed.)
Small but needing a decision first. B-45 (wrap the five stand-up commands, or leave them visible) · B-46 (where implementation notes should live) · B-51 (four components rebuilt on every change — and whether anyone loses anything is unread).
Scoping, not building. B-69 (whether a seed can change once an engagement is running — carries a standing instruction for every change request) · B-39 (agent identities invented and recorded) · B-40 (where contributed Markdown should route) · B-67 (the organized view cannot be pointed at) · B-62 (two windows on the same notes) · B-63 (nothing marks an answer as written by a model — seed-level). All five now have scoping notes or findings filed.
B-48. The engine has quality tooling it has never run. DONE. Both checkers now run on every push — one as a ratchet against its existing backlog, one at zero tolerance with its backlog cleared. Every gate was deliberately broken and observed failing before it was trusted. (CR-2026-173, CR-2026-174.) Originally: Two standard checkers are configured and shipped, neither has ever been run as a gate, and both report large backlogs. This is not a cleanup item. 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.
B-49. Nothing was checking anything. DONE. The engine's single check had never passed — not once since June — and the surface had none at all. A permanently-red check is worse than none, because it teaches everyone that red means nothing. Both repositories now check themselves on every push, and every gate was deliberately broken and observed failing before it was trusted. (CR-2026-167.)
> One thing to keep an eye on. The engine's suite takes about a quarter of an hour on a fresh machine. That is a real cost on every push, and if it grows it will start to be paid in people not waiting for it.
B-50. Building the surface is not the same as checking it. DONE. The build only inspects what the running application reaches, so the test tree was invisible to it — and that is where the errors were. All drift in test fixtures; none silenced with an exception.
B-16. Update the foundation document. DONE. See What just closed. The seed is at v0.14, committed.
B-17. The portfolio filter. READY to re-scope — and it is no longer the small thing this list has said for twenty versions.
It was built, and then it was unbuilt. A grouping of engagements into workspaces, with the list filtered to the one you were in, shipped in the engagement-navigation fill-in. A later redesign replaced that page with the current home surface and deleted the section that did the filtering, leaving every other part standing: the engine still filters, the data adapter still accepts the parameter, the chooser still exists. Only the thing that used them went. (Built in 194d060; removed in ba99d6e — both recorded so nobody re-derives this.)
"One parameter" is no longer true of either place it could live. The home surface deliberately has no workspace chooser, so filtering there would be a filter nobody can reach. The dashboard has the chooser but its data comes from three cross-project reads, none of which can be scoped to a workspace — that is engine work across three routes and their schemas.
What it needs is a decision about where the portfolio view lives, then a build sized to that answer. (CR-2026-182 halted rather than build to the old description; completion-records/loomworks-cr-2026-182-b17-b43-completion-note-v0_1 §2.)
> The chooser is no longer shown. It offered a choice that changed nothing, on every screen it appeared on, for a full redesign cycle. That is a separate correctness fix and not progress on this item — nothing is filtered that was not filtered before. The component is kept, so putting it back is one line once there is something to filter.
B-18. File the four protocol requirements. READY.
B-19. Keep this list alive. IN PROGRESS — and it now carries a standing check.
> When an item closes, update every place it appears — its own entry, every grouped line that names it, and every other item that points at it. Six items said READY for six versions while being done, because closures were recorded in a grouped line and not in the entries. Check a status against the tag that closed it, never against what the previous version of this list said — copying a version forward carries its errors forward with it. > > And the statuses are not the only thing drifting. Five items opened for building this session turned out to be already built or already satisfied — B-12, B-13, B-17, B-43, and B-37's engine half. A READY item can be wrong not because its status was never updated but because nobody knew the work existed: the capability is there, unreached, and the list has no way to notice. Before building an item, read the code for it first. Every one of the five was found in minutes by looking.
B-25, B-27, B-28, B-29, B-41. DONE.
B-26. Correct the record about door 3. DONE. Two corrections, filed beside the audit rather than edited into it: the finding blamed door 3, but the fault was eight unregistered event types — every door and every upload — and it is now fixed, all eight verified registered. (inspection-briefs/loomworks-walk-audit-w1-door-3-correction-note-v0_1.)
B-30. The trap that caused B-27. DONE — closed as detectability, not as repair. There was nothing to repair: the dependency is correct for the routes that carry the path segment, and a walk of all 228 routes found no live instance. The defect the item names is the suite's blindness, and that is gone — a guard now walks every route's dependency tree and fails if one requires something its own path cannot supply. Measured while proving it: the same broken route a request-based test answered 200 for would have refused every real caller. (CR-2026-178.)
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. DONE. A missing model key reported a crash instead of saying the service was unavailable. (CR-2026-171, engine tag cr-2026-171-small-work-sweep-engine.)
B-36. A way to retire a render. DONE. (CR-2026-172, surface tag cr-2026-172-small-work-sweep-surface.)
B-37. Show when a shape's production has failed. READY — small (engine).
B-38. Bring the Rendering screen onto the shared contract. DONE. (CR-2026-172.)
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, and the costing was re-checked and still holds. From a note, forward to everything built on it. The data is already there — the route exists and answers exactly this question, version-pinned. Nothing on any screen asks it yet, and that is the whole of the work.
The costing stands as written in v0.15 and is not restated here: the wiring is cheap, where it lives is not — its own room, its own presentation, its own tests. A second feature sharing infrastructure, not a ride-along. (Verified both halves during CR-2026-182; it left that change request for being larger than its pairing implied.)
B-44. Things with titles displaying as untitled. DONE. Both places: a Shape's title came back empty on a walk, and every shape in the Shaping room displayed as "Untitled shape." (CR-2026-171.)
B-45. One command instead of five. READY — deliberately deferred.
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-47. The issuance screen for contributor credentials. READY — placement settled; larger than "a screen was not built."
The engine half is complete. Issue, list and revoke all exist and are Operator-only. Nothing on any screen calls them — there is no credentials surface at all, so the earlier framing of "add a reveal and a revoke to the existing list" described adding to something that is not there.
Where it goes, decided. A panel opened from the in-engagement header, the way the seed viewer already opens. That surface is where the Operator lands on opening an engagement and persists across all four rooms, so the panel is reachable wherever the engagement is — which is the requirement, since a credential can be issued at creation or any time after.
> What the survey found. In an engagement but outside the four rooms, three things persist: the header (engagement name, focus chip, home, view-seed), the room tab strip, and the conversation. There is no engagement-level page above the rooms and no per-engagement settings surface. The header-opened panel is an established shape — the seed viewer and the voice-listening panel both use it.
Three placements were rejected, and why matters. A fifth room tab would change the list of rooms, which is the single source of that vocabulary and seed-level — it would assert that credentials are a room. A new route invents one where the address resolves to a single surface. The person-level settings page would need a selector to bridge person scope to engagement scope, which is the mismatch that ruled it out.
> One thing the precedent does not cover, and it is the important part. The seed viewer only reads. This panel acts — it issues and revokes write access to the engagement. The precedent settles where the panel lives and how it opens, and nothing more. The issue and revoke affordances need their own care and do not inherit the seed viewer's weight: a credential is shown once and cannot be shown again, and revoking cannot be undone.
What is left to build: the list, the issue form, the one-time reveal, and revoke — a surface, not a control added to one. (CR-2026-188 halted at Step 1 rather than build to the wrong premise; change-requests/cr-2026-188-loomworks-b47-credential-issuance-v0_2 carries two further corrections.)
B-51. Four components rebuilt on every change. READY to scope. What is unread decides the priority: whether any of the four holds something a user would notice losing — a scroll position, a selection, where the cursor is.
B-52. The sources vanish on reload. READY — small. The answer survives a refresh; its sources do not.
B-53. A render's sequence number never arrives. DONE. The list query never asked for the column, so the reader got nothing back — indistinguishable from a record that genuinely has no number. The same defect was later found in the Shape path and closed as B-59. (CR-2026-171.)
B-54. Nothing requires that number to exist. PARTLY DONE — the code half landed; the fixtures and the rule itself remain. The only rule prevents two records from sharing a number; nothing requires one at all.
The code half is closed. Three production paths were creating records with no number — every Operator-approved reconciliation correction, and every non-produce composition step. They now assign one. (CR-2026-176.)
What remains: roughly seventy test fixtures build records without a number, and the rule that would require one cannot land until they do. Order matters — the rule last, or it breaks the live paths at runtime rather than in tests.
B-55. The screen says "of its type" without knowing what type is. DONE. It now names the type — or says nothing at all. The claim is checkable because the name travels with the thing.
Where it could not be named, the phrase disappears rather than trailing off. That instinct was already in the code for a missing number and had simply never been applied to a missing name; this made it uniform rather than adding a rule. (CR-2026-186.)
> The same divergence has now been found twice. A list of things and a single thing are built by different code, and fixing one leaves the other — first in B-44, and again here across four places. A third time and the question changes: not "check both" but "why can they differ at all." (Recorded in the completion note.)
B-56. A development sign-in is reachable on the live perimeter. READY — small. It refuses correctly and nothing is exposed. But it offers something it cannot do.
B-57. A screen that appears to argue with itself. DONE. (CR-2026-172.)
B-58. A superseded document still says it was never done. DONE. Corrected. The proposal was installed the same day it was written; the header was the only thing that disagreed. (Perimeter persistent-run proposal v0.2; v0.1 stands as a sibling.)
B-59. A shape's sequence number never arrives. DONE. The same defect B-53 fixed for renders, in the Shape path — the list query never asked for the column, so the reader got nothing back, which is indistinguishable from a shape that genuinely has no number. Found and deliberately left by CR-2026-171. Two queries carried it, not one; the second fed the downstream-impact screen. (CR-2026-175.)
B-60. Where a document came from is recorded, shown once, and then dropped. READY — small, and it affects everything already built. When a file is read, the extraction records its structure — a Word document's headings, a PDF's per-page markers, which path the image reader took. That structure reaches the screen that uploaded it and is then discarded before Memory. The Memory event stores an empty list where it should store the chain.
It is not a limitation of the model. The field is deliberately free-form and already carries per-page and per-path detail elsewhere; the writing step simply leaves it empty, and has since it was built. Today it lives as a comment in the code describing itself as a follow-on — which is why it is here now. Whatever lands for spreadsheets and slide decks inherits the same drop on arrival. (uploads.py:956; found during CR-2026-181 Step 1.)
B-61. An answer can be shaped by material it cannot cite. DONE for the case that carries notes — see B-67 for what remains.
The defect was narrower than this line said, and sharper about who it hit. The standing block of recent notes does not reach every turn: it belongs to one of three mutually exclusive tiers and appears only while an engagement has notes but no organized view. That is the early-life state — new engagements, which is the worst place for it.
The fix was free, which is why it was the right one. On a recall turn the standing block was a truncated subset of the notes the answer already retrieves and already cites — same source, same order, fewer of them, cut to 150 characters. It is now omitted on that one turn. The model sees strictly more than before, in fuller form, all of it citable. (CR-2026-183.)
> Two remedies were rejected on their merits. Citing the truncated copy would have produced a source entry that misstates what the model saw. Telling the model not to rely on the block would have been a rule nobody can watch fail.
Originally: Every conversational turn carries a block of recent notes into the model's context. That block never appears in the answer's sources; only the notes fetched by an explicit recall question do. So on the one turn where the product promises every source is shown, the model has been handed material the answer cannot point at.
This is why B-13 is still open — "every source shown" is B-13's own wording. It sits against B-11's guarantee and the posture that claims should be checkable. Not a sizing question: making the two windows match, in either direction, leaves it exactly as it is. (scoping-notes/loomworks-recall-window-tier-2-relationship-scoping-note-v0_2 §3.)
B-62. Two windows on the same notes, and nobody chose the relationship. READY to scope — small. The standing context carries twenty notes; an explicit recall question fetches up to fifty. They are not required to match, but the code claimed they already did and that comment was false for as long as it stood. What relationship they should have is undecided. Measure first: a standing context of fifty would run roughly three times its stated budget, which likely settles it. (Same note, §5.)
B-63. Nothing marks an answer as written by a model. OPEN — and it would be a NEW commitment, not a forgotten one. Blocks nothing.
The thing this rested on does not exist. The foundation document defers to an "AI-as-faithful-clerk posture" and treats it as settled — the rule that you approve state transitions is described as consonant with it. That posture was never written down. It appears in the foundation document as a deferral and nowhere else, and the destination it defers to did not contain it (B-65).
> A correction, recorded rather than smoothed. The Operator confirms he does not recall writing it and considers it a good framing — which is not the same as having decided it. It was nonetheless asserted as settled, in a change request's acceptance criteria and in his own working notes. That assertion was unfounded.
Why this changes the item rather than just annotating it. A forgotten commitment gets recovered; a new one gets decided. Treating this as the first would have skipped the deciding entirely — the marking would have shipped as though someone had already weighed it. Nothing about marking model-written answers has been weighed.
What it would cost is real: a mark on every answer a model writes, non-suppressible, permanently. That is worth a decision, and the decision has not happened.
B-64. The list of what the system accepts is wrong, and nothing reads it. READY — small, and the decision is the point. There is an endpoint that answers "what kinds of file can I contribute?" It names four kinds and the system reads at least eight — Word documents, web pages, spreadsheets and slide decks are all missing from it. It has been wrong since the second pathway was built.
Nothing is broken today because nothing consumes it. The upload screen does not ask; it offers everything and lets the engine answer per file. That is exactly what makes it worth deciding now rather than later — an endpoint that is wrong and unread is harmless until the first thing that trusts it, and whoever wires that up should not be the one to discover it.
The decision is small: correct it, or remove it. Correcting means teaching it about the second pathway; removing means saying the honest answer is per-file rather than a list. Either is defensible; drifting is not. (Found during CR-2026-181 Step 5; affects Word documents identically and predates that change request.)
B-65. The foundation document points four topics at a document that does not hold them. IN PROGRESS — the destination now has four sections and they are deliberately empty. NEEDS YOU: content.
The foundation document defers four things — the AI-as-faithful-clerk posture, the six-stage engagement lifecycle, the badge mechanism, and retirement-with-dignity — to "the philosophy and architecture document." The architecture specification held none of them and no philosophy document exists.
Four sections now exist for them (architecture specification v0.7, Section 16). Each records what the foundation document promises it explains, quoted, and the questions that explanation must answer. None of them says what the four are — none of it is inferable from the record, and writing it would produce the exact failure worth finding here: a governing document that appears to answer a question nobody asked it.
> The lifecycle was deliberately not reverse-engineered. There is a lifecycle in the running system. Whether its stages are the six meant here is unknowable, and reading them off the implementation would record as decided something nobody decided.
The pointer is deliberately still wrong. The foundation document still points at this document, which still holds no content. Correcting it now would move the false pointer rather than remove it — it gets corrected as its own act, once the sections hold something.
What is needed is your content, not a session's. Four sections, each with its questions already written out.
B-66. A contributor who speaks is credited as the Operator. READY — small, and it has been known and untracked. The substrate knows the difference between the Operator and a contributor. The screen does not — every turn is labelled as though the engagement's Operator said it, so a contributor's words appear over the Operator's name.
This is attribution being wrong, not missing, in a product whose whole posture is that claims should be checkable. It has been sitting in the architecture specification as a known gap — "role-aware author labels need wiring" — without ever reaching this list, which is the same failure B-60 was added for. (Architecture specification v0.6, §613.)
B-67. The organized view is shown to the model and cannot be pointed at. READY to scope — small, and narrower than B-61 was. Once an engagement has an organized view, that view — its group headings, how many notes are in each, and the reasoning behind the arrangement — goes into every turn, and an answer cannot point at any of it.
It is not the same shape as B-61. No note content is involved: the individual notes are deliberately left out and only the arrangement is shown. So the model is not reading unsourced material; it is reading a summary it cannot attribute.
And the thing to point at already exists. The organized view is a real object with its own identity and version — a remedy could cite it rather than trying to cite the notes underneath. That likely makes this cheaper than B-61 was, and it is the first thing whoever scopes it should check.
Deliberately not folded into B-61. Different material, different shape, different remedy; B-61's fix does not touch it. (Found during CR-2026-183 Step 1.)
B-68. The accounting machinery names things for itself, and you see those names. READY — small, and fixable in one place rather than at each screen. The credit-reconciliation path creates objects an Operator can see, and gives them names written for code rather than for a reader.
Three, all from the same bootstrap:
ReconciliationCorrectionCorrectiveForayFlowTwo of these were found by accident while making a screen name the kind of thing it was showing, and the third turned up on the check for whether the first two were a habit. They are.
> Measured, not assumed. A sweep of every declared kind of work and kind of artifact in the system found exactly these two written as code identifiers — the rest are ordinary prose (Concept reference, Discovery record, Phase change request). So it is not general drift; it is one path that names things the way its code reads.
The fix belongs where the names are declared, not where they are displayed. Renaming them once at the source corrects every screen at once; correcting them at display would install a permanent translation that quietly stops working the next time something is declared this way. The prose fields on those same objects are well written — only the names and the engagement's title were left as they were.
(Found during CR-2026-186; the two type names are in the accounting bootstrap, the missing title is an insert that sets only an id.)
B-69. Whether a seed can change after an engagement is running. NEEDS SCOPING — seed-level, and nothing is decided.
The Operator's position: a seed should be editable. It is unlikely everything about an engagement is known at creation, and a seed that can never change forces people either to get it right up front or to work against a document they have outgrown.
Two cases, with different answers, and they have not been separated:
A candidate seed, before it is inducted. Editing it is a draft revision. Uncontroversial.
A running engagement's seed. Harder. Memory is append-only and corrections are preserved rather than smoothed — and every note contributed under an earlier seed was contributed against different stated commitments. That argues not against editing but for versioning: a new seed version with the prior versions kept as siblings, which is the discipline this project already applies to every other governing document.
Why it is not a small build. It touches what a seed is, which the foundation document defines. It is also adjacent to B-65 — "seed lifecycle" sits close to the six-stage lifecycle deferred to a document that does not hold it.
What comes first is a read, not a build. Can a seed be revised at all today? Is there version history? What happens to a running engagement whose seed changes — what reads it, what caches it, what derives from it and would not notice?
> ### Standing instruction, in force until this item is resolved
>
> During any build, if something you touch would be affected by a seed changing after an engagement is running — anything that reads the seed, caches it, assumes it fixed, or derives from it — record it in that change request's completion record under a seed-mutability impact heading.
>
> Do not design for it. Do not build around it. Just record the contact point.
>
> The point is an inventory, not a search. When this is eventually scoped, the question "what breaks if a seed changes" should be answerable by reading a list that was written as the code was touched — rather than by a sweep conducted afterwards by someone reconstructing it.
>
> Why it rides along with every change request instead of being gathered once: what depends on a seed being fixed is visible when you are inside the code touching it, and invisible from outside. A sweep finds the obvious readers; the build finds the assumptions.
>
> Use the heading verbatim. Entries are only findable as a set if every session writes the same words.
B-20. The marketing website. READY. B-22. Package Stele. WAITING (background). B-23. The security story. READY. B-24. Investor-visible FORAY. READY.
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 · how the universal commons should be searched — it grows with adoption rather than with work, and it is a different question from B-12.
Nothing. For the first time since this list was written.
Everything merged is running, deployed 2026-08-06 and verified in the product one item at a time.
Both questions are answered. Sources will appear on every answer a model writes, and not on answers the system assembles, because those already show their own material (Q-6: split). Confirming a Shape stays on the screen for now, and reopens after the Companion's other writes have been used (Q-7: defer).
B-12's unread fact is measured. The largest engagement anyone works in holds fifty-eight notes against a window of fifty. Raising a constant closes it for everything that exists — and the commons, which grows with adoption rather than with work, is parked as its own question.
The seed is current and committed at v0.14.
Two decisions sit on the queue and block nothing, unchanged: per-statement provenance, and whether a walk should use the event identifier. Neither has a deadline and neither stops anything.
Everything else proceeds without you.
DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — the build list — v0.40 — 2026-08-08