Going-forward operating instructions

The two paths for landing edits

Loomworks-record is now a multi-writer repository. Edits to documents in the record flow through one of two paths, depending on what's being edited.

How to pick

The question to ask: does this change need careful drafting and review, or do I know exactly what I want to land?

If careful drafting is needed — go through Path A. The Operator and Claude.ai work through the document together, the result lands in Downloads, Claude Code commits it. The trajectory is preserved (the conversation that produced the document is reachable later if needed).

If the change is small or you already know what you want — go through Path B. Open the document, edit, save. Done in under a minute. No conversation to preserve, no kickoff to write.

Some edits are ambiguous. When in doubt, default to Path A — it's the more careful path. Path B is the convenience option for when carefulness isn't the bottleneck.

Where things live

Three locations matter. They each play a different role.

The repository — DUNIN7/loomworks-record

This is the source of truth. Every governing document for the Loomworks project lives here: methodology, architecture, protocols (Loom, FORAY, OVA), current status, candidate seeds, queued directions, standing notes, investigations, discovery records, session handoffs, brand assets, analyses, examples, change requests, and phase folders.

When two copies of the same document disagree, the version in loomworks-record wins. Files in Downloads are working copies. Content in Claude.ai project knowledge is a reference snapshot. The repository is the real version.

The live site — record.dunin7.com

This is the read/edit surface for the repository. It auto-deploys on every commit. The Operator authenticates via Cloudflare Access (One-time PIN to marvinp@dunin7.com), then has full read access to every document and edit access to current-version markdown and HTML documents.

Documents are reachable at predictable URLs:

• record.dunin7.com — the landing page (sections grid)
• record.dunin7.com/sections/<section>/ — section index with sortable document list
• record.dunin7.com/view/<section>/<file>.html — viewer for an individual document

URLs are stable for currently-published documents. After a version bump, the old URL no longer points to a current document (the file has been moved to archive/); use the section index to find the new path.

The build machine — DUNIN7-M4

This is Claude Code's working environment. The repository is cloned at /Users/dunin7/loomworks-record. Claude Code commits from here. Path A flows through here.

Under the new multi-writer posture, the build machine's local clone is no longer guaranteed to match origin/main. The editor at record.dunin7.com commits directly to origin without involving the build machine. Standard git practice applies: every Claude Code session pulls first.

Session discipline

The discipline that runs every working session, named explicitly.

Claude.ai session opening

Each new Claude.ai session opens with the project knowledge already loaded. The current state of the repository can be checked by visiting record.dunin7.com directly during the session — particularly when the project knowledge might lag (e.g., if Path B edits have landed since the last project knowledge sync).

If a session needs to read a specific document not in project knowledge, the URL pattern above retrieves it. Claude.ai can read those URLs and reason about their content.

Claude Code session opening

Every Claude Code session starts with:

git pull --ff-only origin main

This is now step 1 of every CC kickoff. Origin is the source of truth; the local clone reflects origin's state. Pulling first prevents the class of "wait, what's on disk locally" confusion that surfaced once at the Phase 62 verification cleanup before being absorbed as discipline.

Operator session opening at record.dunin7.com

Each visit opens with the Cloudflare Access authentication challenge (One-time PIN to marvinp@dunin7.com) if the session token has expired. Session lifetime is 24 hours. After authentication, full read access to the site; edit access to current-version markdown and HTML documents via the Edit and New document affordances.

Session-context records (preserved from v0.2)

Some sessions produce a per-session markdown file in session-handoffs/context-records/ documenting what was loaded into project knowledge, what drift was detected, what was decided. This was new in v0.2 and remains in place. The need for these records is reduced (but not eliminated) by the new ability to reach the live site for current state.

Document format rule (preserved from v0.2)

If the Operator reads it, HTML. If only Claude.ai or Claude Code reads it, markdown.

This rule was new in v0.2 and remains the active policy. Forward-acting only — existing markdown documents migrate at next version bump rather than all at once.

Two clarifications worth noting now that the editor at record.dunin7.com exists:

• The editor handles both formats. Monaco's syntax highlighting works for HTML and markdown both. The format choice is about the reader's experience, not the editor's capability.
• HTML documents authored via Path A get full control. Custom layout, embedded styling, visual hierarchy. HTML documents authored via Path B (from a template, in the editor) get the template's defaults. For documents that warrant rich layout, Path A is the right path.

Naming conventions (preserved from v0.2)

Every artifact carries a version in its filename. The format is name-v0_1.ext, name-v0_2.ext, and so on, with underscores instead of dots.

Before v1.0, all versions are working drafts and increments are minor (v0.1 → v0.2 → v0.3). The transition to v1.0 marks a document being declared released. After v1.0, patch versions are for small fixes, minor versions for additions, and major versions for substantive reworkings.

The version also appears at the top of the document — in the title, in a header field, or both — so that if filename context is lost, the version is still recoverable from the content. Filename and document title must agree.

The editor at record.dunin7.com enforces this convention automatically:

• New documents start at v0_1 (the New document affordance refuses anything else)
• The version-bump UI on save produces v0_2 from v0_1, etc., and atomically moves the previous version to archive/
• Minor-correction saves replace content at the same path without bumping the version

Path A artifacts follow the same convention by Claude.ai's own discipline rather than mechanical enforcement.

The current state of the editor

Phase 62 closed with the editor functional but unrefined. Five findings were captured in the Phase 62 close handoff (in phases/phase-62-record-editor/):

• Post-save navigation is poor. After version bump or create, the user is left on a stale page with no obvious next step. Manual navigation back to the section index is the workaround.
• New-document creation only asks for a slug, not a title. Titles are auto-derived from slugs by capitalize-and-replace-hyphens. Acceptable for most cases; refine the title via a follow-up edit if needed.
• Commits show generic email attribution. The Cf-Access-Authenticated-User-Email header isn't forwarded to Pages Functions; commits read "Edited by editor@record.dunin7.com" instead of the real authenticated email. Filed for fixing in Access app configuration.
• Monaco loader double-load warning. Non-fatal but noisy when Edit is clicked twice in one session.
• CC's local clone routinely behind origin. Absorbed as discipline above (pull first).

None of these is blocking. All are queued for Phase 63 or later. The editor works for its intended purpose; the polish is incremental.

What this document does not cover

Several things sit outside the scope of operating instructions and are governed by their own documents:

• Methodology principles. The substantive principles of how Loomworks-the-project works — Discovery posture, halt-and-surface discipline, change request lifecycle, the layered architecture of the editor and beyond — live in the methodology document (what-dunin7-is-building-v0_20.md currently, v0_21 candidate material in current-status-manifest).
• Product architecture. What Loomworks-the-product is, what FORAY and Loom and OVA are, how engagements work — lives in the architecture specification (loomworks-architecture-specification-v0_2.html currently).
• Phase scoping and execution. Each phase has its own folder under phases/ with scoping note, change requests, handoffs, and close documents.

This document covers only the operational layer: how the work flows, where things live, what discipline runs each session.

What comes next

This is v0.3 of an evolving document. Future versions will absorb further changes as the project's posture evolves.

Likely candidates for v0.4:

• If a second editor surface lands (block editor or WYSIWYG per the Phase 62 architecture), the document format rule may evolve — block editors can produce HTML that's authored by non-HTML-fluent users, which expands when Path B is appropriate
• If the commit-attribution finding is fixed, the editor commits will carry real Operator identity; small note worth adding
• If a different writer appears (e.g., automated agents committing to the repository as part of Loomworks-the-product operation), the multi-writer posture extends beyond Operator + CC

None of these is on the immediate horizon. v0.3 is the current operational picture.