The scoping note for Phase 62 — adding edit capability to record.dunin7.com so the read viewer becomes a read/edit viewer. Phase 61 closed with the site live, authenticated, and updating on every commit. Phase 62 closes the operational loop: the Operator can edit governing documents from anywhere, not only via Claude.ai-and-Claude-Code pipelines.
This phase ships with explicit architectural seams that preserve the option of layering additional editors later. The substrate built now serves the immediate need (Monaco source editing) without foreclosing future product paths (block editor, WYSIWYG, multi-tenant via GitHub OAuth).
The going-forward operating instructions made loomworks-record the canonical home for governing documents. Phase 61 made that record accessible via the web at record.dunin7.com. But the only way to change a document today still routes through Claude.ai (drafting) → Downloads (staging) → Claude Code (committing). For substantive work that flow is correct. For small corrections — a typo, a date update, a paragraph addition — it is friction.
The friction matters because it discourages keeping documents current. A spotted typo that requires four steps and a build-machine session is a typo that stays in the document. A small clarification that occurs to the Operator while reading on a phone is a clarification that doesn't land unless they remember it later. The repository drifts from correct.
Phase 62 closes that loop. Edits become a one-click affordance from any document on record.dunin7.com. Save commits to the repository. The deploy pipeline rebuilds the site within minutes. Same archive convention, same versioning discipline — the editor enforces both.
Once this lands, the foundation work is operationally complete and the loomworks-the-product build can resume in earnest, with the record itself maintained from anywhere as work touches it.
A fine-grained GitHub personal access token with write access to DUNIN7/loomworks-record only, stored as a Cloudflare Pages secret. Server-side Pages Functions make GitHub API calls using that token. The browser never sees it. Simplest operationally for a single-user repository where the only writer is already authenticated through Cloudflare Access.
Pattern B (client-side OAuth, each user authenticates separately) is reachable later without a rewrite — the substrate is the same, only the authentication mechanism changes. If multi-tenant becomes a target, Phase B-equivalent ships as a future phase.
In scope: Edit existing markdown or HTML documents (the same authoring source the document was created from). Create new documents in any section (chosen from templates). Version-bump assistance at save time. Move a document to archive.
Out of scope: Branch-based workflows, pull request review, edits to product repositories, phase folder scaffolding generation (deferred to Phase 63 if needed).
Source view for both markdown and HTML. The Operator edits the document's authoring source directly. Right for documents authored by people fluent in HTML, which is the case for everything currently in loomworks-record.
Block editor and WYSIWYG are not in Phase 62 scope. The architecture supports adding them later without removing Monaco — see the layered architecture section below.
The editor is built in a way that treats Monaco as a surface, not as the editor itself. The "edit a document" operation has well-defined inputs (document path, current content, format) and outputs (new content, version bump decision, commit message). Monaco implements that interface for Phase 62. Additional surfaces (block editor, WYSIWYG) can be added later without changing the save pipeline, version-bump logic, or commit handling.
The product framing — whether record.dunin7.com-style functionality could later be packaged as one or more products at different tiers — does not affect Phase 62 work but shapes where the architectural seams sit.
Three layers, each independently replaceable. Phase 62 builds all three layers minimally; future phases can extend any of them without restructuring the others.
Phase 62 builds Layer 1 in full, Layer 2 with Monaco only, and Layer 3 implicitly (single product, single tier, Monaco available). The seams between layers are documented in the close handoff so future phases can extend each layer in isolation.
The Edit button is the seam between Layer 1 and Layer 2. In Phase 62, clicking Edit opens Monaco directly because that's the only editor available. The button is configured by an "available editors" list which, for now, contains only Monaco. When a second editor is added in a future phase, the button presents a chooser if the document supports both editors, or opens the single compatible editor directly if it doesn't.
Document compatibility is declared in document metadata. Phase 62 sets all current documents to "monaco" compatibility (the only available editor). When new editors are added, documents declare which editors they're compatible with — the architecture specification's bespoke structure might be "monaco-only", a new simple investigation might be "any-editor".
Two questions surfaced during scoping that only become operationally meaningful when a second editor exists. Named here so they're not lost.
When a user picks an editor for a document, does the system remember the choice next time that document is edited? Per-edit choice, per-document choice, or per-user preference? Tentative answer: per-document, defaulting to the user's preferred editor for first-edit, overridable per edit. Settled when a second editor lands.
When an editor can't handle a document, what happens? Refuse to load? Read-only? Escape hatch back to source editor? Tentative answer: documents declare compatibility in metadata; chooser only shows compatible editors. Settled when a second editor lands.
Both questions get queued in the deferred work document for visibility.
The static site generator gains awareness of editing affordances. The Edit button in the viewer chrome (already in place, currently disabled with a tooltip) becomes active for current-version documents. Clicking it loads the Monaco editor with the document's source content. Archive documents stay read-only.
A "New document" button appears on each section index page. Clicking presents a template chooser appropriate to that section (e.g. on investigations/, choices include "blank investigation," "investigation from existing template," etc.). Selecting a template opens Monaco with template content and a guided filename / version prompt.
Both editing flows include a version-bump UI at save time. The user is asked whether the change is substantive (new version) or minor correction (same version, current content replaced). For substantive changes, the editor handles renaming and archive-move atomically in a single commit.
A small set of Pages Functions handles the server-side authentication and GitHub API calls. Pattern A: the GitHub token lives only in the Pages environment, never in the browser. Functions are written in TypeScript, run at the edge, and have access to the Pages secret store.
Three primary endpoints:
All endpoints are protected by Cloudflare Access (same authentication as the read viewer) and additionally validate that the path being edited falls within loomworks-record and within an editable section.
A fine-grained personal access token is generated by the Operator. Scope: contents (read + write) on DUNIN7/loomworks-record only. No other repositories, no organization-level permissions. Token stored as a Cloudflare Pages secret. If the token leaks (it won't, but planning for the worst), the only damage possible is to loomworks-record, and the token is revoked instantly from the GitHub UI.
Twelve steps. Each named with its actor (Claude.ai produces; Claude Code commits; Operator does dashboard work or token generation).
TypeScript functions in functions/api/ (Cloudflare's convention). Three endpoints (document, save, new), authentication validation, path-safety checks, GitHub API calls. Token referenced via environment variable.
Updates to tools/build_site.py to wire up the Edit button, the New document button, and the editor surface. Monaco loaded from CDN. Save handler calls the Pages Functions. Version-bump UI at save time.
How documents declare editor compatibility. Phase 62 default: "monaco" (the only available editor). Future-facing schema documented in the close handoff.
One template per document kind that supports new-document creation. Investigation, standing note, session handoff, scoping note, etc. Templates land in tools/templates/ in the repository.
Kickoff prompt that commits all artifacts above to loomworks-record in a single phase commit.
GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token. Scope: DUNIN7/loomworks-record only, with contents read+write permission. Save the token; needed in step 7.
Cloudflare dashboard → Workers & Pages → loomworks-record → Settings → Environment variables → Add variable (Production, encrypted). Name: GITHUB_TOKEN. Value: the token from step 6.
Lands all the Phase 62 artifacts (functions, build script updates, templates, scoping note, etc.) as a single commit. Cloudflare auto-deploys.
Visit record.dunin7.com, open any current document, click Edit. Monaco should load with the document's source content. Don't save yet.
Make a trivial edit (e.g. fix a typo, or add a space). Save with "minor correction" option. Confirm a commit appears in the repository attributed to the editor flow, and the page re-renders with the change after redeploy.
Make a substantive edit (e.g. add a paragraph). Save with "new version" option. Confirm the new version lands at folder root, the old version moves to archive/, and both filename and document header carry the new version.
From a section index, click New document. Choose a template. Provide a filename. Save. Confirm the new document lands at the right path with the right version.
Confirm the token is fine-grained (not classic), and that the repository scope is exactly DUNIN7/loomworks-record. If the token is broader than that, the blast radius of a leak is larger than necessary. Re-create the token if scope is wrong.
Confirm the secret is added as Production (not Preview) and marked encrypted. Cloudflare may default to plaintext for environment variables; explicitly switch to encrypted before saving.
If the Monaco editor doesn't open on the first attempt, halt and screenshot what's displayed. Common causes: CDN load failure, missing Pages Function deploy, authentication issue with the GitHub token. Each has different fixes; don't push through without diagnosing.
The first save is the moment of truth for the commit pipeline. If the commit doesn't appear in the repository within a minute, halt. Don't make additional edits on top of an unconfirmed save — that compounds the problem if there's a bug.
The foundation work is complete. The record is canonical, accessible, authenticated, and editable from anywhere.
The next phase, by mutual agreement, returns to the Loomworks-the-product build. The session-context record and operating instructions can be updated to reflect the new edit path (Phase 63 or absorbed elsewhere). The deferred questions about editor choice persistence and incompatibility are filed in queued directions and surface when a second editor is added.
If product direction crystallizes such that the record viewer/editor itself becomes a product offering, the architectural seams from Phase 62 support that path without rework. Layer 1 stays as-is. Layer 2 expands with additional editor surfaces. Layer 3 introduces tier-based packaging. None of that is Phase 62 work.
If you concur with this scoping note, Claude.ai produces the Phase 62 build artifacts (backend functions, frontend updates, templates, kickoff prompt) in the next session. Claude Code lands them in a single commit. The Operator handles the GitHub token generation and the Cloudflare secret addition, then verifies the editor end-to-end.
The kickoff sequence — Claude.ai producing, Claude Code landing, Operator verifying — is the same pattern as Phase 61. Expected total time: comparable to Phase 61, possibly slightly longer if the editor surface introduces unexpected friction during verification.