This is the plain-English plan for Phase 63. It describes what we're going to fix in the editor at record.dunin7.com, and what we're going to start recording about who changes what over time.
This document is for you, the Operator. It explains intent and proposed solution. The matching technical document — the change request — describes how Claude Code will execute the work, with file paths and exact steps. You don't need to read the change request to understand the plan. The change request lives at phases/phase-63-editor-refinement/loomworks-phase-63-cr-v0_1.html.
Phase 62 closed yesterday with the editor on record.dunin7.com working. This morning, the editor got its first real use — updating the architecture specification from v0.2 to v0.3. That use surfaced friction that was tolerable in testing but is unpleasant in everyday work.
Three specific problems came up:
Underneath these, a fourth question surfaced. When the editor saves a change to a document, who made the change? Right now the answer is "editor@record.dunin7.com" — a generic placeholder, not the actual person. There's no record of the changes themselves either; the GitHub commits exist, but they're scattered across many documents with no way to see "all the changes to this document" or "all the changes I made yesterday."
The project already has the audit infrastructure to record this kind of thing — it's called FORAY, and the engine writes audit rows whenever someone changes a Companion setting. Editor commits are conceptually the same kind of event, and the existing system can record them with a small extension.
Phase 63 fixes the editor friction and wires the editor into the audit system. Doing them together makes sense because they touch the same code paths and they make sense as a coherent piece of work.
Three parts. Each one stands on its own; the editor improvements work without the audit system, and the audit system works for documents that have already been edited. But shipping them together gives a coherent improvement.
Version numbers update intelligently. When you click "Save as New Version," the editor scans the document for the current version number and shows you each place it found one. For each match, you decide whether to update it or leave it alone. Most matches will be safe to update — the title, the footer, the version line at the top. Some matches are intentionally backward-looking — references like "we considered X in v0.1 but rejected it" should stay at v0.1, even when the document moves to v0.3. The editor proposes; you decide; what you approve gets updated atomically with the version bump.
The editor follows you to the new version. After a successful save-as-new-version, the editor closes and reopens automatically pointing at the new versioned file. Your browser's URL bar updates to match. The document you think you're editing is the document you're actually editing.
The save buttons get visual treatment that distinguishes them. The primary action becomes "Save as v0.4" (or whatever the next version is) — the label tells you exactly where the save lands. The secondary action becomes "Correct in place" — clearly different, clearly smaller. You can tell at a glance which produces a new version and which doesn't.
Every successful commit through the editor — whether a new version or a correction in place — emits an audit row to the engine's audit database. The row carries: who made the change, what document was changed, when the change happened, the commit's identifier, and a hash of the content before and after.
You don't see this happening. It's invisible during normal use. But it accumulates. After a week of editing, there's a record of every change. After a month, a substantial history.
If the audit write fails — say the engine isn't reachable for a moment — the editor still completes the commit. The commit is what matters; the audit row is a record of what already happened. We don't block the work to wait for the recording to land. This matches the existing convention for other audit events in the engine.
A new section appears on record.dunin7.com called "Audit." Reachable from the landing page like the other sections.
The default view shows recent changes — newest first. Each entry shows who made the change, when, what document, and a link to that document. You can filter by date range (the "show me what happened last week" question), by who made the change (when there's more than one editor someday), or by specific document (the "what's the history of this file" question).
From any document's viewer page, a small link reads "View audit history for this document." Click it, and the audit viewer loads pre-filtered to that file's history. One click from any document to its trail.
The viewer covers editor commits only at first ship. The engine has other kinds of audit data too — credit transactions, memory events — but those are different shapes and trying to merge them now would slow this down. They can join later if the need surfaces.
Six decisions got resolved during the scoping conversations. They're restated here because they shape what gets built and because the time to disagree is now, not during execution.
For record.dunin7.com to talk to the engine, the two systems need a way to recognize each other. We generate a long random token, store it as a secret on both sides, and use it for the conversation. Simplest mechanism that works, and it's appropriate for a system with one Operator. If we ever open record.dunin7.com to multiple editors, we'll need something more sophisticated — but that's a problem for a future phase, not this one.
When you open the editor, your email is already known from Cloudflare Access. The editor sends that email to the engine, which looks up the matching person record and returns your unique identifier. From then on, every commit you make is recorded as being by you. This works because you're currently the only person with edit access — even though the engine's data layer technically allows multiple people to share an email, in practice there's just you, so the lookup always returns the right person.
The engine has three different audit systems: one for credit transactions, one for change records like editor commits, and one for memory events. They have different shapes. Phase 63's viewer reads the change-record system only. If we want a unified view of all three later, that's its own piece of work — different schemas, different time-ordering questions, different scoping.
The scanner does not auto-substitute. Even though most version references could safely be auto-updated, some references are intentionally backward-looking ("we did this in v0.1") and some are references to other documents at specific versions (the operating instructions document mentioning "the architecture specification at v0.2"). Auto-substituting either of those would produce wrong content. The scanner proposes each match with enough surrounding context that you can tell at a glance whether to approve or decline.
If the audit row fails to land for any reason — engine unreachable, network blip, anything — the editor commit still completes. The commit is what matters operationally; the audit row is a record. We log the failure for review but we don't make you wait. This matches how other audit events in the engine are handled.
The audit viewer needs to reach the engine over the internet. The engine is supposed to be deployed at api.loomworks.doneinseven.com or api.loomworks.dunin7.com, but it's not certain that it's actually live and reachable right now. If it turns out not to be reachable when this work begins, that's a separate scoping conversation — we don't absorb engine deployment into Phase 63.
Two places in the execution plan deliberately pause for you. They're flagged in advance so they aren't surprises.
The shared service token from Settled Decision 1 has to actually be generated and added to two different places — Cloudflare Pages secrets and the engine's environment configuration. Generating a secure random token is easy. Adding it to the engine depends on how the engine is currently deployed, which you know better than I do. This pause happens between "the engine endpoint exists and accepts the token" and "the editor's Pages Function sends the token." When we hit this point, I'll surface it; you generate the token and configure both sides; we continue.
Per Settled Decision 6, engine deployment is its own question. The first step of building the audit viewer is verifying the engine is reachable. If it is, we proceed. If it isn't, you decide: do we deploy the engine as part of this phase, do we defer the audit viewer until separate deployment work is done, or do we re-scope Phase 63 to ship just the editor improvements and the audit-write wiring without the viewer? The choice affects the rest of the plan substantially, so it has to be made when we get there, not now.
Named so the boundary of Phase 63 is visible.
FORAY's anchoring layer. The audit rows accumulate as records in the engine's database, but they aren't anchored to anything tamper-evident yet — no blockchain commitment, no signing. That's a separate piece of work for when it becomes important. The columns to support anchoring are already in place; nothing about Phase 63 makes it harder to add later.
A unified view of all FORAY audit data. Phase 63's viewer covers editor commits. Credit transactions and memory events live in different tables with different shapes; unifying them is its own scope.
Multi-Operator support. The simplifications in Settled Decisions 1 and 2 work because there's currently one Operator. Opening record.dunin7.com to additional editors is a future arc with its own design questions.
Stronger audit guarantees. Phase 63 makes audit writes best-effort. A future phase could make them required — the editor refuses to commit unless the audit row lands. That's possible with the same substrate, but it has costs and isn't load-bearing today.
The smaller polish items from Phase 62 not related to the version-bump operation. Specifically: new-document creation accepts a slug instead of a full title (the title can be added after creation), and a harmless Monaco loader double-load warning. These stay queued for future polish.
The architecture specification update that started this whole arc. The friction we hit this morning was that updating the architecture spec was unpleasant. Phase 63 makes the editor pleasant enough that the architecture spec update becomes a clean piece of substantive content work — but that work itself is separate from Phase 63.
Places where the right answer isn't obvious. The plan proposes an answer; the proposal might change during execution if something surfaces.
How prominent should cross-document references be in the scanner's surface? When you're bumping document A from v0.2 to v0.3, and document A contains a reference to "the methodology document at v0.20" — should the scanner surface that as something you might want to approve? Showing it gives you visibility into possibly-stale cross-references. Hiding it keeps the approval surface focused on self-references. The plan proposes showing them with a low-confidence default-declined treatment; we can refine if the surface gets noisy.
How should editor commits be scoped in the audit data? Audit events in the engine usually attach to an "engagement" — the engine's word for a unit of work that has its own context. record.dunin7.com isn't currently modeled as an engagement; it's just a website. We could leave the engagement field blank and use the document path for scoping, or we could create a synthetic engagement representing record.dunin7.com itself. The plan proposes blank for first ship; the column is nullable so we can change later without migrating data.
Should the audit viewer require additional authentication? record.dunin7.com is already behind Cloudflare Access, so anyone who can reach the site is authenticated. The plan proposes no additional gating at first ship — if you can see the documents, you can see the audit. If record.dunin7.com later opens to broader audiences, we can add viewer-side permissions then.
Should we cursor your scroll position when the editor reopens at the new version? After saving v0.2 as v0.3 and the editor reopens at v0.3, should it remember where your cursor was and put it back? Preserving feels smoother. Resetting is simpler to build. The plan proposes resetting at first ship and revisiting if it surfaces as friction.
You read the plan. If anything in it feels wrong — a decision that should be different, a proposed solution that doesn't match what you wanted, an "open question" you have an answer for — we revise.
When the plan is right, Claude Code executes the change request. That document is the technical companion to this plan; it has the file paths, the exact step ordering, the code structures. During execution, when we hit one of the two decision points in Section 4, I'll surface it here; you decide; we continue.
When all three parts are built, tested, and shipped, Phase 63 closes. The editor is pleasant to use. Changes are recorded. You can read the trail.
Then the architecture specification update — the work that triggered all of this — resumes against a trustworthy editor and a system that remembers what's happening over time.
The change request at phases/phase-63-editor-refinement/loomworks-phase-63-cr-v0_1.html is the technical artifact paired with this plan. It has the file paths, line numbers, code structures, and step ordering that Claude Code uses during execution. You don't need to read it. It's there if you want to.