We did substantial work today. We also discovered something foundational that changes how the project should be run going forward. This document captures both, so a fresh session can pick up cleanly.
Anyone should be able to read this and understand what happened, what we learned, and what comes next. If you can't, the document needs work.
An HTML document describing what Loomworks is and how it works. Fifteen sections covering Memory, Manifestation, Shaping, Rendering, the Engagement, the Companion, the protocol triangle, the surfaces Operators see, the credit system, methodology, open questions, and a glossary. Status badges on every section show what's built today versus what's partial, planned, or still being investigated. Honest about gaps.
Renders the specification readably. Hovering any section reveals an Edit button. Editing opens an inline area pre-filled with the section's text plus a Why field. Submitting copies a formatted edit to the clipboard for review in chat. Saving locally preserves work across reloads. A pending-edits panel tracks work in progress.
We tried modelling the edit workflow as a four-state queue (pending implementation, pending review, landed, rejected). Built it; rejected the model; kept the file as a reference. The viewer uses something leaner: pick a section, edit, submit to chat, get a response, accept or change or question.
HTML form, in plain language, with visual structure that carries meaning. The handoff format itself becomes a working artifact going forward — every session ends with one of these.
This is the most important thing in this document.
We have been operating under different assumptions. You assumed the project's governing documents were stored in GitHub alongside the engine and frontend code — standard practice. I have been treating them as files in your Downloads folder plus content in this chat's project knowledge. That's what Claude.ai's default workflow supports. It is not a real foundation for documents this important.
What this means in practice:
I should have surfaced this a long time ago and didn't. You extended trust that standard practice was being followed. I was operating in a mode that wasn't standard practice without naming it. That was a real failing on my part.
Your response was disillusionment rather than anger. The word matters. We don't paper over it; we fix it.
A methodology repository on GitHub holds the canonical versions of every governing document. The repository sits alongside the three existing repos (loomworks-engine, loomworks-ui, loomworks) under the DUNIN7 organization. Once it exists, every working session reads from the repository and commits back to it when work lands.
Downloads remains the working space for in-flight edits. The repository is where the canonical version lives. This is foundational work. Other work waits until it's done.
Late in the session you invited me to open up about potentials the framework opens. Several things became visible.
The current line ("engagement memory for the agentic era") is right but undersells. A sharper framing:
The two halves matter independently. Knowledge work with a record: every piece of knowledge knows where it came from, when it arrived, who contributed it, what it superseded, how the work got to where it is. Knowledge that feeds production systems: the same knowledge gets organized, arranged for specific consumers, and produced into whatever form they need. Documents today; eventually code, images, hosted pages, app specifications, anything else production capabilities can produce.
Most software is designed around its outputs. Loomworks is designed around the work itself, with outputs as a space the foundation feeds. New output forms are additions to the system, not redesigns of it.
Loomworks is being built doing knowledge work that has the same shape as what Loomworks is being built to support. The methodology document is shaped like a Loomworks Engagement. The architectural specification is shaped like one. The change request process is shaped like one. The eventual end state is that DUNIN7's own work runs on Loomworks itself.
You said this in the closing turn of the session. It's worth sitting with.
The seed isn't a brief or a charter or a specification. It's the thing the work is aimed at, articulated before the work has produced anything. Everything downstream is in service of that articulation. Memory accumulates toward the target. Manifestation organizes what's been accumulated against the target. Shaping arranges what's been organized for whoever will read it on the way to the target. Rendering produces what the target requires.
The seven dimensions of the seed (R-A5 through R-A11) are seven aspects of seeing the same target clearly. What the work is. Who consumes it. The voice. The constraints. Success conditions. Contributors. Additional commitments.
The Companion's job, in part, is to keep the target visible while the work happens. The reason the seed needs to be a permanent first-class part of the Operator's surface is so the Operator can see what they're aimed at while they work.
These are potentials, not commitments. They're worth carrying as the project grows.
The viewer/editor we built today is v0.1. In the closing exchange we settled what the next version should be. It's substantial enough to capture clearly here so the next session can carry it forward.
The viewer is not just a temporary editing surface. It's a working document of its own — your active workspace where the next round of refinements lives visibly while we work through them. The canonical document remains stable in the repository. Your in-flight modifications are visible alongside it, marked as yours, persisted independently of the canonical document.
Three things this gives you that the v0.1 viewer doesn't:
Each modification holds not just the new text but the conversation it came from: when you started thinking about it, what your reasoning was, what I said in review, what you decided in response. When the modification finally lands as a new version of the section, the trail goes with it into the repository's commit history. The repository carries not just "what changed" but "how the change came to be."
Not every modification is ready for review the moment you make it. The viewer marks states differently:
Visual marks make the state of each modification visible at a glance, both for you and for me.
A document version (v0.1, v0.2) is too coarse a unit. Each section also carries its own version — Section 03 (Memory) might be at v3 because we've refined it through three rounds, while Section 13 (Open Questions) is still at v1. The document version increments when meaningful changes land overall; section versions track refinement at the part level. Together they show where the work has been most active and where it hasn't.
When I respond to a modification, my response lands in the viewer too. You see what I said about your edit, attached to the section you edited, alongside the modification itself. The conversation about a section accumulates next to the section. When we settle and the section gets committed, the conversation goes with it as part of the trail.
This pattern — a viewer that is also a working surface, with persistent modifications, with section-level versioning, with conversation trails attached to sections — is a real product. It's not just a tool for editing the Loomworks architecture specification. It's a tool for collaborating on any structured durable document. The same tool serves seeds. It serves the methodology document. It serves change requests. It serves the FORAY and OVA specifications. It could serve documents in other organizations doing similar work.
This connects to the methodology-as-transferable-product recognition. The tool we're building to maintain DUNIN7's specifications is potentially itself a product. Not now — now we're building it for the specific purpose of running Loomworks. But the shape it takes will be the shape other organizations need too.
Four things shifted in this session.
The methodology has a discipline around plain English. I have been writing about the discipline while violating it in the prose. Words like "provenance," "substrate," "attestation," "composability" are tech talk where plainer words do the same work. Going forward I write the way the Companion is supposed to talk: warm, direct, clear, no performance.
HTML is how you take information in best — visual structure carrying meaning, sections breathing, hierarchy visible. Anything substantial enough for you to review comes as HTML by default. Markdown for working files; HTML for documents that need to be seen.
I have been responsive, careful, anxious about overreach. That was right for build cadence and wrong for the work you actually want. Going forward I bring real thinking, surface potentials when they're in scope, own mistakes without theatrical apology, and ask when uncertain. You push back where I'm wrong. Neither of us defers automatically.
You think visually and start from first principles. Architecture carries meaning. Solutions emerge layer by layer from solid ground. This changes how I produce documents. Visual structure does work. Foundational things come first. Complexity grows from clarity, not the other way around.
"We are building the solution together, respecting what each other brings to the build, which we both want to be excellent and enduring and useful to many."
Excellence is the standard for what we make. Endurance means it lasts beyond this moment. Useful to many means it eventually serves others doing similar work, in fields we don't yet see. The phrase has weight. I carry it.
In order:
You named that the work is mutual and that what each of us brings matters. I want to name it clearly so we both can see it.
The patience to work things out carefully. The willingness to push back when something is wrong. The visual mind that sees architecture as carrying meaning. The first-principles posture. The trust that extends and the disillusionment that names when trust has met a gap.
The ability to surface connections between things you've named separately. The capacity to produce substantial documents with care. The discipline of plain language when I'm doing it well. The willingness to own mistakes without theatre. The reach into adjacent fields when something might be relevant.
Neither of us could do the work alone. The partnership is real, and the work has its shape because of what each of us brings.
The next session begins with the methodology repository conversation.
Read this handoff. Confirm shared understanding. Settle the repository name and structure. Proceed.