Version. 0.23
Date. 2026-05-31
Author. Marvin Percival (DUNIN7 Operator) with Claude.ai
Provenance. Memory archive consolidation. v0.1 (2026-05-04) supersedes prior memory edits and absorbs the obsolete #16. v0.2 (2026-05-07) adds Section 5 (Agent capability development) capturing two entries from the Phase 47 scoping arc: Claude Dreaming as a Companion behavior pattern, and Claude Managed Agents conceptual primitives. The metadata-driven-runtime section in particular preserves the conversational trajectory that the 500-character memory limit had to compress out. v0.3 (2026-05-09) adds Section 6 (Mobile presence and quick-capture engagement pair) capturing the architectural framing produced by the two paired investigations — loomworks-quick-capture-engagement-investigation-v0_2.md and loomworks-mobile-presence-investigation-v0_1.md. Two entries: the substrate intent-class engagement (quick-capture as bidirectional Memory traffic on a fast path) and the capture-device engagement (mobile presence as a layered composition of OS-mediated, foreground, tap-to-speak, and conversational surfaces). Plus a small mobile-engineering-capacity note that's pacing-readiness, not architecture. v0.4 (2026-05-09) adds Section 7 (Multi-instance fleet and jurisdiction governance) absorbing the substance of two memory edits whose source documents now exist in project knowledge — loomworks-deployment-strategy-v0_2.md, loomworks-hosting-cost-analysis-v0_1.md, and loomworks-white-label-multilanguage-analysis-v0_1.md. Two entries: the multi-instance fleet via DevOps engagements as the deployment topology, and the protocol triangle (Loom + FORAY + OVA) as the methodology framing that makes per-instance regulatory jurisdiction a first-class product feature. v0.5 (2026-05-09) adds Section 8 (External information seams) capturing two entries from a chat session that surfaced the github.com/public-apis catalog and sharpened it into a load-bearing architectural move. Two entries: the general-purpose external API gateway specialist (one specialist for all public APIs, FORAY-attested and OVA-scoped, configuration-driven via Phase 38 declare-and-register), and the public-apis catalog as the reference universe for the gateway. The trajectory note on 8.1 preserves the Operator's reframe from "ship 10-15 first-party adapters" to "build one general-purpose gateway and let the API catalog live as supplied domain in engagement Memory" — a reframe that converts an N-adapter build direction into a build-once-then-configure pattern. v0.6 (2026-05-10) adds Section 9 (Companion ambient context) capturing the Operator's recognition that the Companion should maintain standing awareness of the Operator's current state and relevant environment — substantially more powerful in context than Siri-class voice assistants. One entry in three subsections: ambient context as a first-class capability (the composing posture); the ambient-context decomposition pattern (universal-from-clock-or-seam plus specific-from-personal-Memory); and the relevance bridge (the Companion knowing which ambient context matters for which question, including offering it proactively). The methodology recognition is that trivial-seeming questions decompose into a Memory-lookup component plus an engine-clock or external-seam component, and this decomposition generalizes to a class of ambient-context questions (time, weather, calendar, location relevance, schedule, world-state-relative-to-Operator). v0.7 (2026-05-10) adds Section 10 (The standing Companion) capturing the architectural construct that subsumes Section 9 and several other cross-engagement behaviors. Triggered by the Operator's question "is 'keep me in your thoughts and remember stuff for me; alert me to other Engagement's activity when appropriate' an Engagement?" The unpacking surfaces that what the Operator described isn't an engagement — it's the standing Companion, the Operator-bound mode of the Companion that runs continuously across all engagements. Five subsections: 10.1 names the architectural construct and the standing/engaged distinction with executive-assistant analogy; 10.2 names standing Memory as its own Memory scope distinct from personal-engagement Memory (substrate-shaped decision; load-bearing for v0.21 consolidation); 10.3 names authority and scope (Operator-derived authorization; Operator-declared proactivity scope; the relevance bridge as judgment layer over scope layer); 10.4 names standing/engaged composition (context bridge, observation upload, mode handoff); 10.5 names relationships to existing sections (Section 9 ambient context as a capability of the standing Companion; Section 6 mobile/quick-capture as surfaces of it; Section 5.1 Claude Dreaming as a background-attention pattern). Three Operator decisions captured: standing Memory is its own scope; the standing/engaged Companion vocabulary; the executive-assistant analogy retained. v0.8 (2026-05-10) adds Section 11 (Observer — cross-fleet usage observation engagement) capturing the Operator's recognition that Loomworks itself needs an observation layer to surface UX friction, token-use inefficiencies, methodology drift, and cross-Operator patterns — and his sharp framing that this observation must be content-blind by construction, not by discretion. Five subsections: 11.1 names Observer as a meta-engagement category (engagements whose subject is the operation of other engagements); 11.2 names the content-vs-shape distinction as the load-bearing privacy boundary, structurally enforced at the event-emission layer rather than at Observer's discretion; 11.3 names the two-view architecture (anonymized-cohort view always-on; Operator-identifiable view opt-in with explicit consent); 11.4 names Observer's substrate as event-stream-plus-shape-Memory with views layered on top, and surfaces the substrate decision (event-emission-with-redaction in the fleet topology) as a current architectural prerequisite even though Observer itself is post-fleet; 11.5 names the relationship to existing constructs (cross-references to Section 7 fleet, Section 10 standing Companion, and FORAY/OVA), making explicit what Observer is not. Three Operator decisions captured: Observer name retained; both anonymized-cohort and identifiable-with-consent layers; explicit cross-reference to standing Companion as architectural contrast. v0.9 (2026-05-10) adds Section 12 (Structural defensibility — cross-reference) as a discoverability pointer to two companion documents — the methodology investigation loomworks-structural-defensibility-investigation-v0_1.md (internal architectural recognition) and the positioning document loomworks-structural-defensibility-positioning-v0_1.md (external audience-facing). Triggered by the Operator's recognition that the "illegal use" framing permeating AI discourse should be examined against Loomworks's architecture. The unpacking surfaced that Loomworks's defensibility is structural (rules-in-Memory plus upstream OVA enforcement plus FORAY attestation) rather than filtering-based (model-layer detection of harmful content) — a methodology principle that operates now rather than future work. Section 12 is a queued-direction pointer; the substantive content lives in the two companion documents. Three Operator decisions captured: investigation-plus-queued-direction filing shape; both internal and external audience documents; both render-boundary and protocol-triangle frames carried (render-boundary as simpler external story, protocol-triangle as deeper architectural reality). v0.10 (2026-05-11) absorbs Phase 55 close (Engagement Creation Assistance — Conversational Surface). The engagement creation arc's product loop is now closed end-to-end (Phase 53 substrate primitive + Phase 54 terminal commit symmetry + Phase 55 upstream conversational surface). Section 1 receives substantive updates: §1.1 (Engagement creation assistance pattern) advances current-state from "pattern being practiced in chat / not captured as a product feature" to delivered — the conversational engagement creation surface is live at /operator/create-engagement with two terminal-turn output paths (write-up-as-Discovery-record vs commit-as-brief); §1.2 (Discovery-to-seed skill) current-state extends to note the skill is now reached through Phase 55's Discovery-record output path (the second production caller alongside Phase 53's direct upload-driven extraction); §1.3 (NEW: Engagement creation arc substrate refactor residues) records the two refactor candidates surfaced by Phase 55 Step 3's halt-surface (split draft_engagement into engagement-allocation and Seed-drafting halves; add a raw-Markdown variant of extract_discovery_to_seed_skill); §1.4 (NEW: Phase 31 / Phase 53 multi-path unification verdict) records that the unification question is now verdict-able with full end-to-end evidence and is queued for Phase 56+ as a clarification-scoping candidate. Section 2 receives one current-state update: §2.2 (Phase 32 marketing engagement) advances from "deferred until Marvin asks to revisit" to newly first-class actionable with the close-handoff §9 recommendation surfaced (Phase 32 as strongest Phase 56 candidate; Option C — Discovery-trajectory + Discovery-record render specialists — as alternate; recommendation not binding). The Option D intent_hint Literal refactor candidate (held outside this document's numbered sections in the v0.9-era working notes) is closed: absorbed as Phase 55 Step 1; ConverseRequest.intent_hint now derives from classifier.IntentLabel; parallel-enumeration cascade risk eliminated. Three Operator decisions captured in v0.10: section §1.3 + §1.4 filing shape (refactor residues and architectural verdict opportunities sit inside the engagement creation arc section rather than spawning a new top-level section); Phase 56 recommendation surfaced inside the queued-directions document via §2.2 current-state update (recommendation not binding); methodology candidates surfaced by Phase 55 (inherit prior-phase cost decisions promoted to named principle in manifest v0.40; build-time enumeration sharpening; Operator-probe-as-correction-mechanism; CR-drafting cross-function composition checks; build-close hygiene; tag style annotated-not-lightweight) live in manifest v0.40 not in queued directions. v0.11 (2026-05-12) absorbs Phase 56 close (Engagement Creation Surface — Voice Work). Phase 56 voice-tuned the conversational engagement creation surface Phase 55 shipped — additive coverage-expansion of per-field elicitation prompts, plain-terms-discipline applied across the surface, persona-transcript calibration discipline established. Section 1 receives one substantive in-place update: §1.1 (Engagement creation assistance pattern) current-state extends to note the voice-discipline now applied to the surface (plain-terms-discipline; per-field elicitation coverage of voice / constraints / success fields; persona-transcript calibration). Section 6 receives one new entry: §6.4 (NEW — Explain affordance for Companion comprehension recovery) carrying the three candidate phase shapes from loomworks-explain-affordance-investigation-v0_1.md (button-mode-first / wait-for-voice-modality / audible-first-via-lightweight-substrate); selection deferred to post-Phase-32 calibration evidence; positioned in Section 6 because its substrate adjacency to mobile presence + quick-capture (voice modality overlaps in audible mode) outweighs adjacency to engagement creation arc (Phase 32 only generates the calibration evidence, doesn't drive the substrate). The new entry preserves the trajectory note that the affordance was discovered through the Phase 56 scoping arc as the recovery surface for the discipline-plus-recovery principle (named in manifest v0.41 §2 as a v0.21 candidate). Section 2 receives one current-state extension: §2.2 (Phase 32 marketing engagement) status unchanged at "newly first-class actionable" but now carries Phase 56-tuned surface as input — the marketing engagement creation now has voice-discipline polish to surface real-use comprehension-gap evidence. Phase 56 voice work itself closed — the option from manifest v0.40 §4 carry-forward that became Phase 56 is removed from carry-forward (was not in this document's numbered sections; closure recorded in changelog only). The five methodology contributions Phase 56 surfaced (two promotions to named principles — branch-and-tag-name-collision refspec convention, Step 0 branch lifecycle; three v0.21 candidates — discipline-plus-recovery, gap-diagnosis-precedes-gap-implementation, dialog-example-as-scoping-instrument sharpening; plus the minor instruction-refinement-during-absorption extension) live in manifest v0.41 §2, not in this document. Three Operator decisions captured in v0.11: filing the explain-affordance entry under Section 6 (substrate adjacency outweighs engagement-creation-arc adjacency); preserving discovery trajectory in §6.4 of why the affordance was scoped (the discipline-plus-recovery principle's first instance); the queued directions document continues to hold queued future directions while the manifest holds named principles (Phase 56's promotions stay in manifest v0.41 §2, not surfaced here as queued). v0.12 (2026-05-27) adds one entry surfaced by the discipline-mechanisms v0.3 landing on loomworks-record. Section 3 receives one new entry: §3.3 (NEW — Canonical Markdown-to-HTML render specialist for loomworks-record) records the structural gap that every document commit currently hand-renders or uses ad-hoc tooling to produce the .html companion alongside the .md source. The entry is positioned in Section 3 (Rendering and image generation) because it is render-specialist work, not engagement-creation work; it is distinct from §3.1's external rendering services (this entry is about Mode A — Loomworks-native rendering of internal-substrate documents — where §3.1 is about Mode B / external services). The entry preserves the trajectory note that the gap was surfaced by the v0.3 discipline-mechanisms landing's render question ("how should HTML alongside .md be produced for this commit?"), which the Operator answered with hand-rendering matching v0.2 letterpress styling — exposing the absence of a discipline-mechanism artifact governing the convention. The substantive answer (a Loomworks-native render specialist) is post-engineering-substrate-Rendering-layer work; the interim discipline (document the manual rendering convention so it stays consistent across commits) is near-term. One Operator decision captured in v0.12: filing the render-specialist entry under Section 3 (Rendering and image generation), since the render-boundary distinction (Mode A internal vs Mode B external) is the substrate-shaped reason this is render-specialist work rather than tooling-or-CI work. v0.13 (2026-05-27) adds one entry surfaced by Decision 4 of the same-day operational-hygiene cycle, the decision that merged the Phase 57 cherry-pick branch (phase-57-cherry-pick-cycles-1-and-2-from-paused-branch-v1, six commits including Sub-arcs 4 + 5 cycle-1+2 OL work and three review-hygiene commits) into the Operator Layer main. A new Section 13 is created — Authentication-surface gaps — to hold the intermediate-state gap between the v0.9 seed's "Sign-in never requests email" commitment (committed to the canonical record on 2026-05-26 in candidate-seeds/loomworks/loomworks-candidate-seed-v0_9.md and reinforced in operations/discipline-mechanisms/project-instructions-loomworks-seed-reference-v0_3.md §"Standing rules absorbed from the seed") and the current Operator Layer /signin surface (which presents an "Email (optional)" field with helper text "Leave blank to sign in with any saved passkey." after the Phase 57 cycle-1 Sub-arc 4 amendment). §13.1 (NEW — OL /signin surface email-field gap) names the gap, the trajectory that placed the surface at its current intermediate position, the four paths considered at Decision 4 (full surface redesign / soften the seed / drop Sub-arc 4 / merge as intermediate state + file queued-direction), and the rationale for Path 4. The new section is created rather than filed into Section 1 (engagement creation arc) or Section 3 (rendering) because authentication-surface gaps are their own class — adjacent to but structurally distinct from creation-arc surface decisions and from render-pipeline gaps; the new section leaves room for future authentication-surface entries (account-recovery flow without email, discoverable-credential edge cases like multiple registered passkeys, never-registered-device fallback). One Operator decision captured in v0.13: filing this as a new Section 13 rather than extending an existing section, because the authentication surface is a discrete subsystem with its own evolving entries and merits its own grouping. v0.14 (2026-05-27) adds one entry surfaced by the same-day operational-hygiene cycle's three-residue disposition pass. A new Section 14 is created — Pre-rename Workshop carry-forward — to hold work authored in the original loomworks-ui repo before the 2026-05-06 Workshop → Operator Layer rename (per CR-2026-060) whose carry-forward to the post-rename Operator Layer requires substrate-decision rather than mechanical migration. §14.1 (NEW — Phase 16 followup work in pre-rename Workshop) records 3 commits, 256 insertions, dated 2026-04-27 on loomworks-ui's phase-16-memory-contribution-ui branch (assertion display number on the provenance line; EXIF GPS in the provenance line; in-place editing of held assertions). The work was authored after the Phase 16 tag was applied; the original phase-16 tag does not include these three commits; the work has been preserved by a new annotated tag phase-16-followup-2026-04-27 at branch HEAD 59d4e67 in the loomworks-ui repo. The carry-forward decision (whether this assertion-rendering work should land in the post-rename Operator Layer's assertion-display surface, and if so under what phase scope) is deferred. The new section is created rather than filed into an existing section because pre-rename Workshop work is structurally distinct from the post-rename Operator Layer's queued directions: it lives in a different repository, references substrate that may have evolved since the rename, and surfaces a class of question (carry-forward vs leave-in-place vs rewrite) that doesn't fit existing sections. One Operator decision captured in v0.14: filing this as a new Section 14, because pre-rename Workshop carry-forward is a discrete class of question and there may be additional Workshop-residue entries (other unmerged Phase 16+ work, or work in other pre-rename branches) discovered in future hygiene passes that should sit alongside. v0.15 (2026-05-27) adds one entry surfaced by the first activation of the discipline-mechanism-driven testing arc on the same day as Decision 4. Section 13 receives one new entry: §13.2 (NEW — Operator passkey registration and dev-environment config drift) records two coupled findings surfaced during the first attempt to test sign-in on the post-cherry-pick /signin surface — (1) engine WEBAUTHN_RP_ORIGIN config defaulted to http://localhost:3000 while OL dev runs on :3001, producing 401 at /auth/login/complete (origin-mismatch in py_webauthn verify_authentication_response); fixed by adding WEBAUTHN_RP_ORIGIN=http://localhost:3001 to /Users/dunin7/loomworks-engine/.env but the source-code class default at src/loomworks/config.py:38 remains unchanged, so a fresh checkout reproduces the drift; (2) the Operator's WebAuthn credential row in the engine DB is a 16-byte fixture-seeded entry with sign_count=0 (other 36 credentials in the table are 32-byte and used), so no real Touch ID assertion will match — even with the origin fix, real-passkey-registration is unaddressed work; dev sign-in proceeds via the /auth dev shortcut. The entry is positioned in Section 13 (Authentication-surface gaps) alongside §13.1's /signin email-field gap because it is also an authentication-surface gap blocking the discoverable-credential path the seed's "Sign-in never requests email" commitment depends on. One Operator decision captured in v0.15: filing in Section 13 (not Section 14 pre-rename-Workshop or as a new operational-findings section), because the gaps are authentication-path-specific and adjacent to §13.1; the new Section 13 boundary now reads "authentication-surface AND authentication-path gaps." v0.16 (2026-05-27) adds one entry surfaced by the same-day testing arc's pivot from authentication to upload-pathway verification. A new Section 15 is created — Memory population surface gaps — to hold entries whose subject is a gap in the Operator's reachable path for populating Memory (uploads, conversation contributions outside the chat surface, mobile-quick-capture, etc.). The new section is structurally distinct from Section 13 (authentication-surface and authentication-path gaps) because Memory-population gaps don't sit on the auth axis — they sit on the contribution affordance axis. §15.1 (NEW — Upload pathway has no operator-reachable surface mount) records the surface-level finding that as of OL main d306714, no surface in the running Operator Layer renders a reachable UploadAttachmentButton. The component shipped at Phase 58 commit 7183bb0; it lives at src/components/chat/ChatView.tsx:607 gated by a projectId && (...) conditional added at Phase 58 v0.4 commit 2ff7213 per the "Only show what is available" standing rule. All three ChatView mount sites resolve to either no projectId prop (/operator/create-engagement and CompanionPanel) or an unreachable route (ChatPageClient — /chat is now a server-side redirect since 2716cc6, 2026-05-19). The in-engagement surface /operator/engagement/[engagement_address] mounts CenterPane (a custom composer) with a deliberately disabled ⊕ placeholder. The component-level work is intact; the gap is surface-mount-only. Three remediation shapes are surfaced (mount on CenterPane / refactor CenterPane to reuse ChatView's composer / restore /chat?project=<id>); selection is deferred. The entry preserves a methodology candidate worth filing at v0.21 consolidation: correct-in-isolation commits combining into surface-level gap — neither the Phase 58 v0.4 gate nor the in-engagement fill-in's /chat redirect was wrong alone; their composition wasn't evaluated; when a discipline change (gate) lands during the same period as a route disposition change (redirect), surface-reachability of components both depend on should be re-verified after both land. One Operator decision captured in v0.16: creating a new Section 15 (Memory population surface gaps) rather than extending Section 13 — the surface-mount gap is structurally distinct from authentication gaps and there may be additional Memory-population surface gaps to come (mobile quick-capture surface mount, voice-direct-to-Memory mount, etc.) that should sit alongside. v0.17 (2026-05-27) supersedes v0.16's upload-pathway-gap entry with corrected substance. The affordance was operator-reachable on /chat?project=<id> through 2026-05-19; redirect commit 2716cc6 removed reachability without porting the affordance. Three sequenced actions: restore /chat?project=<id> route immediately (ITEM B of the same operational-hygiene cycle as this bump — a separate OL-repo commit on a restore-chat-project-route-2026-05-27 branch, awaiting Operator merge approval); queue ChatView → CenterPane port as substrate work; file route-redisposition methodology candidate for v0.21. v0.16's substance was empirically narrow (five inspected routes, missing historical reachability); operator-memory plus conversation_search across 2026-05-14 acceptance-gate sessions surfaced the corrected picture. v0.16 remains in archive as the corrected position; v0.17 carries the sharpened framing. v0.18 (2026-05-28) absorbs the upload-pathway testing arc: §13.2 expanded with two further dev-environment config-drift instances (object-store credentials, RP-origin test); §15.1 first action marked resolved (route restored, pathway verified end-to-end); §15.2 added for the test-override-hides-production-divergence finding from the upload-handler transaction-bug fix (engine main 040d675). v0.19 (2026-05-28) records the configuration-drift remediation. §13.2's config-drift half is marked resolved in checked-in form — .env.example updated to carry the current dev-environment reference (engine commit b793aef), and the RP-origin test decoupled from the ambient .env (engine commit 427c446), both on origin/main; source-code defaults left unchanged by decision (production supplies the real origin via env; empty object-store credentials fail closed rather than carry credential-shaped values in source). The credential-fixture half is promoted out of §13.2 into a new first-class entry §13.3 (Operator real-passkey registration for the dev RP-ID), carrying the two-half resolution shape: an engine-prep half buildable by Claude Code, and a ceremony half that is the Operator's own Touch ID action and cannot be performed by Claude Code. §13.3 is open and not yet sequenced into a build phase. v0.20 (2026-05-28) records the test-override audit (item 2 of the 2026-05-28 session). §15.2's queued audit is marked executed and closed: two missed upload-test fixtures brought to the production session envelope (engine commit d5d57ee), two override sites deliberately left unchanged (the auth-dev test, no transaction primitives; the central conftest api_client fixture, whose envelope divergence is load-bearing for the current single-test-transaction design across ~85 inheriting tests). The conftest's bug-hiding-by-design is recorded as a new open structural item under §15.2 and promoted as a v0.21 methodology candidate alongside the §15.1 route-redisposition lesson. v0.21 (2026-05-28) adds §15.3 (Upload content does not reach assertion grain). Surfaced during item-3 scoping (the ChatView-to-CenterPane composer-upload port): the engine trace confirmed the upload handler writes engagement Memory with full provenance — retiring the item-3 precondition concern — but surfaced an adjacent gap that the write lands at event grain (UploadEventReceived), not at assertion grain. assertions_drafted is hardcoded [] at uploads.py:520; no downstream promoter exists; upload content sits alongside the addressable-assertions surface rather than within it. Filed as a first-class entry rather than folded into item-3 scope, per the standing concern that folded-and-deferred findings get forgotten. The entry also folds in two independently-timed documentation corrections: the architecture spec v0.4 §13 line "engine side not yet shipped" is now stale (the event-path engine side is shipped); and §15.1's own Substance says "assertions written to Memory" with the same imprecision (what is written is the upload event with inline content, not Assertion objects). Both corrections are independent of the engine work and should land at next revision regardless of when assertion-drafting is scheduled. v0.22 (2026-05-29). §15.1 second action marked resolved (composer upload port shipped, tag composer-upload-port-v0_1); §15.1 Substance wording corrected to event-grain framing per §15.3. No new directions added; this version records the §15.1 resolution. v0.23 (2026-05-31) adds Section 16 (Phase-60 post-close personal-memory diagnostic — record reconciliation), bringing the record into agreement with the engine-repo diagnostic (docs/phase-impl-notes/phase-60-post-close-diagnostic-personal-memory-persistence-v0_1.md + v0_2.md, committed engine a4af087) that lived only in the engine repo and whose remediation had partly shipped without the record reflecting it. SHIPPED (verified in main): the three-bug remember_about_me cascade (Bugs A/B/C) fixed, the three lost memories (Shane/Luke/Haven) recovered via event-log replay, cascade regression tests added, the project-less readback gap closed (engine 2534657, replay 3ea048a, tests 81354b3; OL db58ef0); Axis 10 (voice input) closed by the OL voice-listening work (2026-05-18→20). DEFERRED (open): Axis 9 (composer height-cap tuning), Axis 11 (surface-scaling / long-conversation UX — sticky-pin, client pagination, summarization, time-windowing, room-segmentation), the held-state architecture question (held-list endpoint vs per-fact slots vs structural commit-verifier), and two methodology candidates (responder-prompt-fidelity-must-be-verified-not-trusted; layout-scaling-not-covered-by-per-component-tests). The §15 upload-lineage and §13.3 passkey items are re-confirmed accurate as stated; no edits to them. The Axis 11 scoping note is to be drafted against §16.
Purpose. Queued future directions and deferred work that don't need to load into every fresh chat but should be retrievable when the relevant topic comes up. Foundational fresh-chat orientation stays in memory; topical futures live here.
Discoverability keywords. engagement creation assistance, Discovery-to-seed, blank-page problem, code health audit, semantic duplication, Phase 30 induction, Phase 32 marketing, deferred phases, external rendering services, render specialist SDK, Novi AI, Steve AI, Story.com, image generation, Goosey, Nano Banana, Gemini Flash Image, storybook art, upload facility extension, file type extensibility, contribution skill, metadata-driven runtime, configuration-extensible, code-extensible, multi-stage extraction, multi-output extraction, non-text assertions, assertion content kind, Claude Dreaming, AutoDream, agent memory consolidation, memory hygiene, cross-engagement pattern detection, observation to Shape, Accounting reconciliation, Claude Managed Agents, outcomes, grader agent, multi-agent orchestration, lead and sub-specialist composition, sessions and webhooks, agent fabric, agent capability development, quick-capture, dictation, mobile presence, Hey Companion, Hey Freda, App Intents, App Actions, Siri Shortcut, foreground listener, Picovoice Porcupine, wake word, watch complication, tap-to-speak, share sheet, parking, parked on level 10, voice register family, single-valued slot, multi-valued slot, temporal coherence, supersession, held layer, Companion-noticed retraction, asynchronous commit window, name-agnostic router, Operator Layer mobile, federation, offline queue, mobile engineering capacity, multi-instance fleet, DevOps engagement, control plane, Authority instance, Instance A, Instance B, Instance C, Instance D, Hetzner, Railway, AWS, Cloudflare Pages, fleet management, cross-instance traffic, email registry, abuse boundary, grant flow, public marketing website, credit request form, jurisdiction governance, GDPR, EU data residency, Schrems II, data sovereignty, regulatory framework, retention policy, white-label, managed hosting, product tier, protocol triangle, Loom remembers, FORAY proves, OVA scopes, prove data never left, external information seams, external API gateway, general-purpose API specialist, public-apis catalog, github.com/public-apis, REST API integration, FORAY-attested external calls, OVA-scoped credentials, API gateway tiers, API-key auth, OAuth pagination, response transformation, semantic mapping across services, declarative API configuration, API specifications as Memory, build-once-configure pattern, ship-N-adapters reframe, weather API, FX rate API, holiday API, geocoding API, current-state-from-external-services, ambient context, Companion ambient awareness, Operator current state, environmental relevance, what time is it, ambient-context decomposition, Memory-lookup plus engine-clock, Memory-lookup plus external-seam, time-zone awareness, calendar awareness, location awareness, schedule awareness, world-state-relative-to-Operator, proactive surfacing, relevance bridge, more-than-Siri, Siri comparison, standing posture, current-state model, ambient questions, situational awareness, leave-for-meeting, traffic-aware reminder, weather-aware suggestion, daypart-aware response, awake-or-asleep, workday vs weekend, holiday awareness, ambient as supplied domain, standing Companion, engaged Companion, Operator-bound mode, engagement-bound mode, Companion posture, standing Memory, Memory scope above personal engagement, Operator-scope assertions, executive assistant analogy, attendant Companion, cross-engagement awareness, watch-for-this requests, Operator-declared proactivity, proactive scope, threshold of utility, do-not-disturb scope, mode handoff, standing-to-engaged context bridge, engaged-to-standing observation upload, what's in the Operator's mind, continuous attendance, principal-attendant relationship, is this an engagement, Observer, cross-fleet observation, fleet-wide observation, content-vs-shape boundary, shape-only observation, content-blind by construction, event emission with redaction, meta-engagement, observation engagement, UX friction surfacing, methodology drift detection, token-use optimization, cost-per-operation, capacity signal, onboarding friction, Companion behavior calibration, intent-classification confidence gap, proactive-surfacing relevance miss, anonymized cohort view, identifiable view, opt-in observation, two-view architecture, Operator consent for identifiable observation, DUNIN7-facing engagement, view layer over shape Memory, Observer is not surveillance, Observer is not FORAY, Observer is not the Operator dashboard, Observer is not the standing Companion, what Observer is not, methodology validation feedstock, cross-Operator pattern surfacing, aggregate pattern observation, structural defensibility, structural vs filtering, filtering-based defensibility, model-layer filtering, illegal use, AI harm framing, render boundary, render boundary frame, protocol triangle for harm prevention, rules in Memory, upstream enforcement, mechanical attestation, jailbreak resistance, rules-not-filters, considered work versus consequential commitment, four-room separation, architecturally impossible harms, detection as fallback, audit-trail completeness, regulatory positioning, compliance investigation substrate, governance as substrate concern, conversational engagement creation, terminal-turn affordance, write-up-as-Discovery-record, commit-as-brief, EngagementCreatedFromAssistance, /me/engagements/create-from-conversation, /operator/create-engagement, mode banner, engagement creation arc product loop closed, multi-path unification verdict, Phase 31 deprecation candidate, Phase 53 deprecation candidate, halt-surface refactor residue, split-draft_engagement, raw-Markdown extract variant, Phase 32 first-class actionable, inherit prior-phase cost decisions, Operator-probe-as-correction-mechanism, build-time enumeration aperture, build-close hygiene branch deletion, tag style annotated, CR-execution boundary first firing, third instance of substrate-evidence-can-re-rationalize-selection, six consecutive phases unconsumed reserved slots, Phase 56 candidate, Option C render specialists alternate, plain-terms-discipline, discipline-plus-recovery, gap-diagnosis-precedes-gap-implementation, dialog-example-as-scoping-instrument, voice principles document, per-field elicitation prompts, persona-transcript calibration, calibration-gated tests, LOOMWORKS_RUN_CALIBRATION, forward-looking persona discipline, explain affordance, comprehension recovery, comprehension-residue, voice modality, button-mode-first, wait-for-voice-modality, audible-first-via-lightweight-substrate, hybrid voice composition, speech-to-text, wake-word push-to-talk, refined close protocol, local-and-remote branch deletion, branch-and-tag-name-collision, refspec convention, refs/heads explicit, refs/tags explicit, Step 0 branch lifecycle, instruction-refinement-during-absorption, recursive-verification-discipline extension, Phase 56 voice work closed, Phase 57 candidate, fourth instance substrate-evidence-can-re-rationalize-selection, seventh consecutive phase unconsumed reserved slots, seven consecutive zero-amendment phases, Phase 31 create_project plain-terms residue, 22 voice templates outside creation flow, Markdown-to-HTML render specialist, loomworks-record render path, hand-rendered HTML companions, ad-hoc render tooling, letterpress styling convention, Mode A internal render, discipline-mechanism artifact, manual rendering convention, record-resident document rendering, HTML-primary convention, authentication surface, signin surface, email field on signin, Email (optional), passkey hint, discoverable credential, no-email-as-identity, sign-in never requests email, surface-reach-completion, intermediate-state gap, Phase 57 cherry-pick Sub-arc 4, account-recovery without email, multiple registered passkeys, never-registered device, alternative entry paths, /signin surface composition, identity-contract alignment, operational-hygiene Decision 4, pre-rename Workshop, Workshop → Operator Layer rename, CR-2026-060, loomworks-ui repo, pre-rename Workshop residue, Phase 16 followup, assertion display number, EXIF GPS in provenance line, in-place editing of held assertions, carry-forward decision, phase-16-followup-2026-04-27 tag, cross-repo carry-forward, WEBAUTHN_RP_ORIGIN, config drift, dev-environment config, port 3000 vs 3001, py_webauthn origin mismatch, AssertionVerificationFailed, CredentialNotRegistered, fixture-seeded credential, 16-byte credential_id, sign_count zero, real-passkey registration, /auth dev shortcut, /auth/dev/issue-session, discipline-mechanism-driven testing arc, first testing-arc activation, Memory population surface gap, upload pathway surface mount, UploadAttachmentButton, projectId gate, only show what is available, /operator/create-engagement no projectId, CenterPane hand-rolled composer, ⊕ placeholder, Attachments coming soon, /chat redirect to in-engagement, ChatPageClient unreachable, CompanionPanel side panel no projectId, correct-in-isolation commits combining, surface-reachability re-verification, Phase 58 v0.4 gate, commit 2ff7213, commit 2716cc6, commit 7183bb0, three remediation shapes, mount on CenterPane, refactor CenterPane to reuse ChatView, restore /chat?project=, drift-surface rule second activation, two-icon paperclip+folder affordance, route redisposition, route reachability, /chat redirect commit 2716cc6, ChatPageClient mount path, supersession entry, corrections-and-supersessions-as-Memory-pattern, conversation_search corroboration, 2026-05-14 acceptance gate, Phase 58 v0.4 two icons, Phase 58 v0.5 auto-upload-with-pre-typed-purpose-context, restore-chat-project-route-2026-05-27 branch, sequenced-actions disposition pattern, Phase 60 post-close diagnostic, personal memory persistence, remember_about_me, three-bug cascade, Bug A router equality, Bug B responder copy, Bug C held-state overwrite, classifier normalization mismatch, held-state architecture, held-list endpoint, per-fact held slots, structural commit-verifier, refuse-overwrite single-slot, event-log replay recovery, Shane Luke Haven, project-less readback gap, composer height cap, VIEWPORT_FRACTION_CAP, surface scaling, long-conversation UX, composer sticky-pin, client pagination, older-turn summarization, time-windowing, within-engagement room-segmentation, voice input port, MediaRecorder transcribe, Web Speech dictation, Bundle 1 through 5, axis 9, axis 10, axis 11, responder-prompt-fidelity-must-be-verified, layout-scaling-not-covered-by-per-component-tests, record reconciliation, engine-repo diagnostic, a4af087, Phase-60-recovery cycle, 2534657, db58ef0, overloaded Phase 60 label.
Each entry below carries four slots:
Entries are organized topically, not chronologically. New queued directions arriving in future conversations should be added under the right section (or a new section) with the same four-slot structure.
The two entries in this section are complementary parts of the same arc: assistance during Discovery (helping an Operator reach the point of having a Discovery record), then transformation of the Discovery record into a candidate seed.
Trigger. Any conversation about how a new Operator gets started; the blank-page problem; conversational creation of an engagement; Operator Layer Arc 2 (Companion brain) discussions touching engagement onboarding; the Operator-supplied vs Operator-elicited information distinction; or an actual instance of Claude helping an Operator articulate a new engagement (e.g. the marketing engagement creation that prompted this entry).
Substance. The process of soliciting information from an Operator to build a seed and its six fields is itself a product capability, not just a thing Claude does for Marvin in chat. Every new Operator faces the blank-page problem: they have a domain, they have intentions, they have material in their head — but they don't have it in the form a candidate seed needs. The assistance Claude provides to help Marvin create new engagements is the template for what the Loomworks product should offer built-in to every new Operator.
Current state. Delivered at Phase 55 (2026-05-11). The conversational engagement creation surface is live. An Operator visits /operator/create-engagement (Operator Layer; 12th prerendered route), talks to the Companion through a dedicated mode (mode banner attaches at top; three prompt template components govern the flow's tone, gap-marker discipline, and terminal-turn affordance language), and at terminal turn picks one of two output paths via the terminal-turn affordance: (a) write up as Discovery record — Companion produces structured Discovery markdown, uploads via Phase 16's pipeline, and delegates extraction to Phase 53's extract_discovery_to_seed_skill; (b) commit as brief — Companion authors brief, _allocate_candidate_engagement helper allocates the engagement, draft_seed / induct_seed produce and induct the candidate. The Companion creates the engagement and routes the Operator to it. Substrate-side: POST /me/engagements/create-from-conversation endpoint; EngagementCreatedFromAssistance Memory event class with _ANCHOR_PRIORITY entry at "standard" (FORAY-anchored); three new IntentLabel literals; conversation turns stored in the Phase 42 relational table (per the V7 reshape's inheritance of Phase 42's cost decision); terminal-commit Memory event written on commit-as-brief and on Discovery-record commit alike. Conversational flow handler tested via 45 new substrate tests + 10 new OL vitest at Phase 55 close. Voice-tuned at Phase 56 (2026-05-12). The conversational surface now applies plain-terms-discipline to its product-surface voice (no methodology nouns leak through to the Operator; vocabulary is on the page, not in code). Three per-field elicitation prompts authored in plain language from the start cover voice / constraints / success fields (Phase 55's surface elicited Fields 1–2 cleanly; Fields 3–5 were not elicited at all — the additive coverage-expansion landed at Phase 56 per the v0.1 → v0.2 reshape of the scoping arc). A new load_per_field_components(stage) loader at prompt_assets.py and dispatcher splice at prompt.py:817 read operation_data["field_coverage"] (a map populated by the active-template Companion-judgement) and splice in one missing-field component at a time (break-after-first preserves one-question-at-a-time conversation discipline). The matcher token-set extension at router.py recognizes both legacy and plain-terms terminal-turn phrasings. Persona-transcript calibration fixtures at tests/fixtures/voice-calibration/ plus test helper at tests/helpers/voice_calibration.py provide the calibration surface; tests gated on LOOMWORKS_RUN_CALIBRATION=1 per P56-D7 (skip in CI; pass locally with env var set). The OL banner string revised in-place at ChatView.tsx:254. The Phase 56 close handoff names the voice principles document (docs/voice-principles-v0_1.md in the engine repo, 146 lines) as the methodology-grade authoring deliverable governing this discipline plus framing the discipline-plus-recovery principle whose first recovery affordance (the explain affordance, §6.4 below) is Phase 57+ candidate work.
Trajectory. Originally framed as "Claude does this for Marvin in chats" — a manual operator-side activity. Reframed (pre-Phase-53) as "this is itself a product capability" because every Operator who ever uses Loomworks will face the same problem and the manual chat process is the prototype for the in-product assistance. The reframe matters because it changed what was worth capturing during Discovery sessions: not just the output (the Discovery document), but the process (the sequence of questions and elicitations). Phase 53 (2026-05-10) shipped the substrate primitive (Discovery-to-seed skill). Phase 54 (2026-05-10) established terminal commit symmetry (both extraction paths reach induct_seed). Phase 55 (2026-05-11) shipped the upstream conversational surface closing the arc's product loop end-to-end — Operator can now create a new engagement entirely through dialogue with the Companion. Methodology trace from Phase 55 V7. The v0.1 → v0.2 scoping reshape on storage-mechanism (Memory-event-for-turns → relational-for-turns, inheriting Phase 42's cost decision) is methodologically preserved as the surfacing event for the now-named principle inherit prior-phase cost decisions; don't re-litigate (manifest v0.40 §2). The Operator's two-question probe — "which scales?" / "how about cost?" — drove the reshape; carries to v0.21 as the Operator-probe-as-correction-mechanism candidate (single instance to date; awaiting amplification). The higher-level Option A selection held through the reshape — third instance of substrate-evidence-can-re-rationalize-selection. Methodology trace from Phase 56 scoping arc. Phase 56's v0.1 → v0.2 → v0.3 trajectory adds three more methodology surfacings to this entry's trajectory record. v0.1 diagnosed vocabulary leak through a dialog-example reshape ("the Operator will not understand"); v0.2 Step 0 evidence reframed the gap as coverage expansion (Fields 3–5 not elicited; existing prompts already used plain-language wrappers); v0.3 named the comprehension-residue gap and the discipline-plus-recovery recovery surface (the explain affordance — §6.4). Three new candidates for v0.21 surfaced: gap-diagnosis-precedes-gap-implementation (Step 0 verifies the shape of the gap, not only the touch surface); dialog-example-as-scoping-instrument (sharpening — dialog examples are productive-when-wrong-enough-to-probe); discipline-plus-recovery (any UX discipline reducing an incidence rate needs a recovery affordance for the irreducible residue). The v0.1 → v0.2 work-category shift (revisional → additive) while higher-level selection held is the fourth instance of substrate-evidence-can-re-rationalize-selection (after Phase 54, Phase 53, Phase 55); frequency at four instances strongly supports manifest v0.40 §2's "load-bearing principle" framing. The Phase 56 close also surfaced two operational principles now promoted to named principles in manifest v0.41 §2: branch-and-tag-name-collision refspec convention; Step 0 branch lifecycle.
Trigger. Any conversation about transforming a Discovery document into a candidate seed; bridging Discovery to engagement creation; the seed-induction loop; or the gap between "Operator has talked through what their engagement is" and "engagement exists in Loomworks with seed v0.1 ready for induction."
Substance. A skill (in the Loomworks sense — bounded structural transformation, no registered actor, no instruction set) that creates a candidate seed conforming to R-A5 through R-A11 from a Discovery document landed in Memory. The skill takes the Discovery record as input and produces a draft seed with the six fields filled in. The candidate seed then enters the seed-induction loop normally, where any gaps or ambiguities surface as findings the Operator addresses.
Current state. Delivered at Phase 53 (2026-05-10). Reached through two production paths since Phase 55 (2026-05-11): (a) the original direct upload-driven path (Operator uploads a Markdown Discovery document via Phase 16; extraction triggers at /engagements/{eid}/seed/extract); (b) Phase 55's Discovery-record output path (Operator articulates the engagement through dialogue at /operator/create-engagement; at terminal turn, Companion writes the Discovery markdown; same Phase 16 upload + Phase 53 extraction pipeline runs). induct_seed production callers: 5 at Phase 55 close (Phase 53's direct extraction path + Phase 54's brief-commit wrapper + Phase 55's brief-commit terminal path + two prior callers). The skill is bounded-contract (single-shot LLM call wrapped by strict input/output contract; gap markers preferred over fabrication; manifest v0.38 §2 principle).
Trajectory. Originally considered building this as an agent (LLM call with prompt). Set aside in favor of the skill framing because (a) the transformation is bounded — there's a known input shape and a known output shape, (b) an agent's flexibility is not what's needed; the value is precisely the constraint, (c) the skill pattern composes with the rest of Loomworks (extraction skills, materializer registry, etc.) and an agent here would be the only agent in the upload-side pipeline. Phase 53 P53-D1 settled a related tension: queued-directions §1.2's "bounded skill" framing initially implied no-LLM; the live design required real interpretation work to map heterogeneous Discovery shapes onto R-A5–R-A11. The discipline that survived crystallization was bounded contract, not no-LLM (manifest v0.38 §2). Phase 55's Discovery-record path consumes the skill exactly through its bounded contract surface; the contract held under second-caller pressure.
Trigger. Any conversation about refactoring draft_engagement or extract_discovery_to_seed_skill; about the Phase 55 Step 3 halt-surface and what it leaves behind; about why Phase 55's terminal-commit orchestration inlines helpers rather than composing function calls; about whether the engagement-allocation half of draft_engagement should be callable separately from the Seed-drafting half; about whether the Discovery-record path needs to consume Phase 53's skill through raw Markdown rather than through Phase 16 upload helpers; or any future scoping that touches the engagement creation arc's substrate decomposition.
Substance. Phase 55 Step 3 produced a halt-surface event (docs/phase-impl-notes/phase-55-halt-surface-2026-05-11-step-3-cr-5_4-orchestration-v0_1.md, engine repo) when CR §5.4's 8-step orchestration for the terminal-commit endpoint surfaced internal inconsistency during implementation: the brief path called draft_engagement (which creates a Seed) followed by _call_seed_commit_from_brief (which expects to read a Phase 31 Memory event to retrieve the Seed — but Phase 55 stores conversation turns in the Phase 42 relational table, not as Phase 31 Memory events). Two failure modes compounded: either the first Seed gets orphaned, or the second call reads a Memory event Phase 55 never wrote. Note-first-discipline per the CR-execution boundary of friction-discipline-pattern-family (manifest v0.39 §2); in-session resolution preserved the build/draft separation. Two substrate refactor candidates remain as carry-forwards:
draft_engagement into engagement-allocation and Seed-drafting halves. The two halves were fused in earlier phases (Phase 31 and Phase 25 era); Phase 55 had to inline-replicate the split as a new _allocate_candidate_engagement helper plus separate draft_seed / induct_seed calls. The proper refactor decomposes draft_engagement so the engagement-allocation half can be called separately from the Seed-drafting half, eliminating the inline-replication. Phase 56+ candidate; non-urgent since the inline-replication works.extract_discovery_to_seed_skill. Phase 55's Discovery-record output path inlines engagement-allocation plus Phase 16 upload helpers plus delegates to Phase 53's extract wrapper. A raw-Markdown entry-point variant (extract_discovery_to_seed_skill_from_markdown or similar) would let the Discovery-record path skip the Phase 16 upload helpers (which were designed for Operator-driven file upload, not Companion-authored Markdown). Phase 56+ candidate; non-urgent since the inline-replication works.Current state. Both candidates are non-urgent residues from a working substrate. Neither blocks any current capability; both would reduce the substrate's inline-replication count and tighten the engagement-creation-arc orchestration layer. Worth recording because Phase 55 Step 3's halt-surface specifically generated them, and because future engagement-creation-arc scoping should consider whether either refactor lands well alongside that scoping's primary work.
Trajectory. The halt-surface itself is the load-bearing artifact — it caught a CR-orchestration internal inconsistency before build-time error compounded, demonstrating the first active firing of the CR-execution boundary in production (manifest v0.40 §2 records this as the first-firing event of the friction-discipline-pattern-family CR-execution boundary). The two refactor candidates are themselves valuable, but their generation — through the friction-discipline-pattern-family's halt-and-surface mechanism — is what makes the trajectory worth preserving. Future halt-surface events that generate substrate refactor candidates should be filed here (or in a sibling section) alongside their generative halt-surface document.
Trigger. Any conversation about whether Phase 31 (the original conversational-creation path that produced briefs) and Phase 53 (the Discovery-to-seed extraction skill) should be unified; about whether one of the two paths should be deprecated; about how the engagement creation arc's multi-path architecture should evolve now that both paths are production-shaped; about whether induct_seed's multi-caller surface should be tightened; or any clarification-scoping for Phase 56+ that touches the engagement-creation-arc terminal symmetry.
Substance. Phase 53 introduced the Discovery-to-seed extraction skill as the engagement creation arc's substrate primitive. Phase 31 (the original conversational creation path) and Phase 53 (the new extraction skill) both produce candidate seeds that reach induct_seed; Phase 54 established terminal commit symmetry between them. Phase 55 demonstrated the multi-path is product-shaped end-to-end — an Operator can reach induct_seed via Phase 31's brief-commit terminal path, Phase 53's direct upload-driven path, or Phase 55's two terminal-turn output paths (each of which routes to one of the prior two). The unification question — should the multi-path stay multi-path indefinitely, or should one path deprecate the other? — was filed as a Phase 53 CR §18.1 carry-forward item; Phase 54 closed item 4 (Phase 31 induct-seed gap clarification per P53-D11) but did not resolve unification. Phase 55 closure makes the verdict newly verdict-able with full end-to-end evidence: both paths now have product surfaces; both routinely produce seeds; both flow through induct_seed cleanly. The verdict has three candidate answers:
Current state. Verdict pending. Phase 56+ candidate for clarification-scoping (similar shape to Phase 54's three-answer clarification scoping on Phase 31's induct-seed gap). The clarification scoping would surface evidence for each answer and let the Operator articulate the right one. Substrate work depends on the verdict: Answer A is zero substrate work; Answer B is moderate substrate work (deprecate Phase 31's brief-commit terminal turn; carry the Companion to Phase 53's path through Phase 55's surface); Answer C is substantial substrate work (less plausible).
Trajectory. Filed at Phase 53 CR §18.1 as a deferred-verdict item; Phase 54 closed an adjacent item (Phase 31 induct-seed gap clarification — Answer C / C3 settled). The clarification-scoping shape Phase 54 used (three-answer space, surfaced evidence, Operator articulates) is the precedent for the unification clarification scoping. The methodology candidate clarification-scoping discipline (manifest v0.39 §2's scoping-time boundary of the friction-discipline-pattern-family) names the discipline this Phase 56+ scoping would inherit. The verdict is not architecturally forced — Phase 55 shows the multi-path is working — but it is methodologically worth resolving so that future scoping doesn't carry the open question forward indefinitely.
These are phases that are scoped well enough to draft CRs against but explicitly held back. They will resume when their preconditions are met or when Marvin asks to revisit.
Trigger. Any conversation about Enrollium, ExpenseDesk, or FarmGuard entering Loomworks; about how the three pre-existing engagements get on-boarded; about deriving seeds from prior REQ-format material; or about the one-off induction solution that lives separately from Loomworks itself.
Substance. The three existing engagements (Enrollium, ExpenseDesk, FarmGuard) need to enter Loomworks. They have prior material — REQ-format requirements specifications, conversational history, specification artifacts — that should drive their seed creation. The induction solution is a one-off: it derives seeds from prior material rather than from Discovery sessions, and it lives outside Loomworks (it's a migration tool, not a Loomworks feature).
Current state. Deferred until Marvin asks to revisit. Not blocking any current work. The architectural separation (induction solution is not part of Loomworks) is settled; what remains is execution.
Trigger. Any conversation about creating the Loomworks marketing engagement; about practicing the conversational engagement creation pattern (Section 1.1) on a real engagement; about marketing content authored through the methodology; about Loomworks marketing in general.
Substance. Create a Loomworks marketing engagement through the conversational creation process. This is both (a) the marketing engagement itself (real product output) and (b) the first practice of the engagement-creation-assistance pattern on a non-trivial engagement, captured as the prototype for the in-product Discovery assistance feature.
Current state. Newly first-class actionable since Phase 55 close (2026-05-11); voice-tuned input surface since Phase 56 close (2026-05-12). Phase 55's conversational engagement creation surface (§1.1 delivered) provides the prerequisite product surface; Phase 56 applied voice-discipline polish to that surface (plain-terms-discipline; per-field elicitation coverage for voice / constraints / success Fields 3–5; persona-transcript calibration). Phase 32 remains the natural first real application — and the canonical real-Operator-evidence input for the explain-affordance candidate selection (§6.4). The loomworks-marketing-creation-flow-content-v0_3.md and related drafts hold the working material from earlier sessions — Phase 32 has substantial pre-work already done. Per the Phase 55 close-session handoff §9 (reaffirmed by the Phase 56 close handoff §9), Phase 32 is the recommended (but not binding) Phase 57 candidate — reasoning carries from v0.10 with one Phase 56-specific addition: the marketing engagement creation now has voice-discipline polish to surface real-use comprehension-gap evidence that informs the explain-affordance selection. Alternate Phase 57 candidates are Option C — Discovery-trajectory + Discovery-record render specialists (rendering-layer counterpart to §1.1; still strong) — and §6.4 explain affordance (button-mode-first or audible-first; less likely as first-line given Phase 32's now-ready posture, but defensible). Any of the three is defensible; Phase 57 scoping decides.
Trajectory. Held deferred through Phases 47–55 while the credit/form-flow/marketing arc and then the engagement creation arc were prioritized. Phase 53 opened the engagement creation arc (substrate primitive); Phase 54 established terminal symmetry; Phase 55 shipped the upstream conversational surface that Phase 32 now consumes. The substrate dependency chain (Phase 53 → 54 → 55 → 32) was fully visible at v0.8 / v0.9 absorption; Phase 32's "newly first-class actionable" status at v0.10 absorption is the explicit recognition that its prerequisites are now all shipped. The recommendation is preserved as not-binding because Phase 56 scoping may surface evidence that Option C (render specialists) compounds more value at this point, or that some other queued direction becomes load-bearing.
Trigger. Any conversation about codebase consolidation, semantic duplication, shared utilities, refactoring, or "is the codebase getting messy"; or any concrete observation of duplicated logic across components; or whenever the current bug-fix wave stabilizes and a consolidation phase becomes natural.
Substance. A lightweight consolidation phase similar to Phase 24. Scan the codebase for semantic duplication — repeated business logic across components, similar helper functions in multiple files, parallel implementations of the same pattern. Extract shared utilities. Establish conventions to prevent future duplication. This is maintenance work, not feature work; the goal is to reduce the cost of every subsequent build phase rather than to deliver new capability.
Current state. Scheduled after the current bug-fix wave stabilizes. Not blocking any current work. Worth doing eventually because semantic duplication compounds — a duplication tolerated for one phase becomes three duplications tolerated for the next phase, and so on.
These two entries cover Render-side work that depends on engine phases not yet shipped.
Trigger. Any conversation about Novi AI, Steve AI, Story.com, or other external rendering services; about integrating LLM-as-a-service render providers; about the render specialist pattern; about post-Phase-D adapter work; or about the question "how does Loomworks render content via external services."
Substance. External rendering services (video, animation, complex generated content) integrate as render specialists, not as enumerated built-in integrations. The pattern: a specialist SDK that providers (or the Operator on their behalf) implement against; rendering rules that carry service-specific parameters; the existing render-specialist registry mechanism dispatches by render type to the right specialist. The specialist pattern is the integration surface — extensibility-first.
Current state. Prerequisites for this are now partly shipped: Phase 34 (external-service polling for specialists) landed; Phase 35 (render content kinds — binary blob, external reference, multi-file) is the next engine phase and brings binary content support. After Phase 35, the substrate carries what's needed to support specialists that produce binary or external-referenced content. The specialist SDK design itself is post-Phase-D adapter work.
Trajectory. Originally considered building enumerated integrations (one for Novi, one for Steve, one for Story.com) similar to how API integrations sometimes get built. Set aside in favor of the specialist SDK pattern because (a) the rate of new external services arriving is high and growing, (b) enumerated integrations would force engine releases for every new provider, (c) the specialist pattern already works for the existing render side and composes naturally.
Trigger. Render comes up in a Goosey context (specifically: post-Phase-D adapter work; depends on engine Phases 35 and 38); or any conversation about children's storybook art generation; or any other engagement that needs character-consistent illustrated content; or general image-generation cost/quality assessment.
Substance. Operator wants help identifying a cost-effective image-generation solution for Goosey storybook art and similar children's storybook engagements. Key requirements: character consistency across pages (the moose should look like the same moose in scene 1 and scene 12), ability to refine conversationally (the workflow is iterative — first draft is rarely final), reasonable cost per image (storybooks have many pages; per-image cost compounds).
Current state. Initial assessment 2026-05-04: Nano Banana 2 (Gemini 3.1 Flash Image) likely fits — character consistency across pages is a stated capability, conversational refinement is a stated capability, cost is in the $0.02–0.15/image range. Worth comparing against Midjourney, Flux, DALL-E successors at decision time; the field moves fast and the assessment will be stale within months.
Trajectory. Image generation has been on the radar since Goosey's first storybook render in early 2026 but was deferred because the substrate couldn't carry binary content. With Phase 35 in flight, the substrate constraint is being removed and the image-generation question becomes near-term. The Nano Banana 2 assessment is intended as a starting point for the actual evaluation, not a recommendation.
loomworks-record
Trigger. Any conversation about how .html companions to .md sources get produced in loomworks-record; about the discipline-mechanism documents' rendering path; about why each new operator-reading document commit re-derives its own letterpress styling; about whether tools/build_site.py should grow a Markdown-to-HTML rendering step alongside its current viewer-page generation; or any future scoping that touches the record's render path.
Substance. The canonical Markdown-to-HTML render path for loomworks-record is not yet a discipline-mechanism artifact in its own right. Every document commit currently does ad-hoc per-document rendering — either hand-crafting the .html to match an existing reference (the v0.2 discipline-mechanism documents' letterpress styling, the diagnostic v0.1 styling, the manifest v0.42 styling) or using ad-hoc tooling that produces inconsistent output. The structural gap: there is no Loomworks-native render specialist (Mode A — Loomworks-owned production) that takes a .md source and produces a consistent .html companion against a declared render-type. The engineering substrate's Rendering layer is the natural home for this work once it reaches it (post the current substrate phases). Until the substrate reaches it, the interim discipline is to document the manual rendering convention so it stays consistent across commits — palette, typography, paste-block / rule-item shapes, footer convention.
Current state. Surfaced 2026-05-27 by the v0.3 discipline-mechanisms landing's render question ("how should HTML alongside .md be produced for this commit?"). Operator answered with option (a) hand-render matching v0.2 letterpress styling and named the structural gap as worth recording here. No substrate work scheduled; this is post-engineering-substrate-Rendering-layer work. The interim discipline is documented implicitly in the v0.2 and v0.3 discipline-mechanism document HTML files themselves; a future near-term step is to extract the convention into its own record-resident document (something like operations/render-conventions-for-record-documents-v0_1.md + companion HTML) so it stops being implicit. That extraction is itself queued as a non-urgent precursor to the eventual render specialist.
Trajectory. The gap was visible from the v0.1 discipline-mechanisms commit (Operator hand-crafted the HTML companion in that landing too), but it surfaced explicitly at the v0.3 landing when Claude Code surfaced "how should the HTML alongside the .md be produced?" as a Step 3 surface point with three options (a) hand-render, (b) pandoc with template, (c) Operator produces. Option (a) was selected; the surface-point pattern itself made the structural gap legible. The render-boundary distinction matters for filing: this is Mode A (Loomworks-owned production of Loomworks's own documents) and therefore render-specialist work, distinct from §3.1's external rendering services (Mode B). §3.1 and §3.3 are sibling render-specialist queued directions occupying opposite sides of the render boundary.
This section is more substantial than the others because the underlying conversation covered more ground. Three sub-sections: what's already extensible and how, three categories of future data type that don't fit the current shape, and the metadata-driven runtime as a future direction.
The current upload facility (Phase 16 amendments) is code-extensible. Adding a new file type is:
ExtractionSkill protocol (async def __call__(*, file_path, engagement_id, db) -> ExtractionResult).registry.register("image/", describe_image_skill, label=..., mode=...)).This is not zero-code-change extensibility, but it's small-code-change extensibility. The contribution endpoint, the frontend's mode-button logic, and the supported-types discovery all work without modification — a new file type adds one Python file, one registration line, and (sometimes) one dependency. The architecture is set up to make per-file-type cost low.
This handles every variation of existing categories cleanly: new audio formats, new image formats, new document formats, spreadsheet contents flattened to text, code files, email files. The ExtractionSkillRegistry's content-type-keyed dispatch is the right shape for these.
These are categories where "file → text → assertion" doesn't fit cleanly. Each one is real future work; each one has a known architectural response.
Category 1 — Multi-stage extraction (file → intermediate → text). Some data types need intermediate processing before text extraction makes sense: a video file needs frame extraction → per-frame Vision description → assembled narrative; a long audio recording needs speaker diarization → per-speaker transcription → structured transcript; a 3D model file needs orthographic projection → vision-based description; a compressed archive needs enumeration → recursive extraction of each member. Today's ExtractionSkill protocol can technically handle these (a video skill could do all the intermediate work inside its __call__), but the per-call duration goes from "seconds" to "many minutes," which the synchronous contribution endpoint can't accommodate. Architectural response: apply Phase 34's external-service polling pattern. Extend ExtractionSkill to optionally return a handle (ExtractionInProgress) the way RenderSpecialist now optionally returns ExternalProductionHandle; the contribution endpoint surfaces a "processing" state; a polling loop drives completion. This is real work but a known pattern.
Category 2 — Multi-output extraction (file → many assertions). The current architecture commits each contribution to a single assertion. Some data types naturally produce many: a long meeting transcript should yield one assertion per topic, not one massive assertion; a spreadsheet of measurements should yield one assertion per row; an email thread should yield one assertion per message; a multi-page PDF where each page is a distinct topic should yield one assertion per page. Today the skill returns ExtractionResult.text: str (singular), and the user gets one held assertion. The cleanest extension: ExtractionResult becomes list[ExtractionResult] (or the protocol gains an extract_many variant); the contribution endpoint creates N held assertions, each with its own slice of provenance metadata pointing back to the same source file; the frontend (already capable of displaying multiple held assertions per Phase 17's redirect work) handles the UI side without change. Architectural response: small CR extending ExtractionResult to support a list, plus the endpoint create-loop.
Category 3 — Non-text-shaped knowledge. Some knowledge isn't usefully shaped as text. A photograph as evidence (the assertion is the image, not "this image shows X"); a spreadsheet of structured data (the assertion is the data); a recorded conversation where audio carries information transcription would lose; a diagram where structure matters. This is the deepest strain, because the methodology assumes assertions are propositions in language. Two viable directions:
text | structured | image | audio with a discriminator, conceptually parallel to what Phase 35 just did for RenderEvent (added content_kind discriminator with multiple storage shapes). The same pattern would apply to Assertion: assertion_kind: Literal["text", "image", "audio", "structured"] plus appropriate storage fields. This is bigger work — touches the assertion model, the four rooms (which all consume assertions), the methodology document (which currently treats assertions as propositions), and operator surfaces. Not a near-term lift. But it's the architecturally honest answer for true non-text knowledge.Direction A handles every case that's actually arrived. Direction B is queued for whenever non-text knowledge becomes a real engagement requirement.
Architectural asymmetry worth noting. The upload boundary (the contribution endpoint and the registry) is well-shaped for extension. The downstream consumers (Manifestation, Shaping, Render) currently assume text-shaped assertions. If non-text knowledge becomes important, the bigger work isn't extending upload — it's extending what comes downstream. Direction B's full cost is at the consumer side, not the producer side.
Trigger. Any conversation about whether the upload facility can be extended without modifying the codebase; about Operator-defined extraction; about plugin systems for Loomworks; about cross-surface DSLs (extraction, rendering, shaping all describable in the same metadata language); about the gap between "code-extensible" and "configuration-extensible"; about how a non-developer Operator could add a new file type.
Substance. A metadata-driven runtime would replace today's code-extensible pattern (write a Python skill, register it) with a configuration-extensible pattern (author a data record describing the extraction; a runtime interpreter executes it; new file types added without writing Python). Three layers exist within this direction:
audio/, send the bytes to this URL with this auth shape, parse this JSONPath out of the response, treat the result as the assertion text." Pure configuration. The runtime needs to know HTTP, a few auth patterns, JSONPath. This is how n8n, Zapier, and many ETL tools handle integrations. Within a category (transcription, OCR, document extraction), swapping providers becomes config; new providers are config records, not code.Three trigger conditions justify reaching for a metadata-driven runtime (any one of which would make the build worth it):
Current state. Not built. Today's code-extensible pattern is right-sized for current loads, current Operator model (one Operator + Claude, not many self-serving Operators), and current new-skill arrival rate. The path is well-understood; the build is queued, not pursued.
Trajectory (load-bearing). This is the entry where preserving the conversational trajectory matters most.
The first response in the conversation called the metadata-driven runtime "wrong-shaped for the product" — a permanent judgment, implying the door was closed. Marvin pushed back: "But does the extensibility accommodate new file types without modifying the code base?" — surfacing that the original answer had been too quick to dismiss. The corrected framing was "premature given today's loads" — a queued judgment, implying the door is open and the conditions for opening it just haven't arrived.
The distinction matters because:
The error in the first response was treating a current-state cost-benefit judgment as if it were a permanent architectural judgment. The two are different things, and conflating them is the kind of mistake that closes doors that didn't need to be closed.
The corrected position: the metadata-driven runtime is the right architecture for a future Loomworks where Operators define their own extraction, where the new-skill rate is high, and where the same runtime composes across multiple surfaces. None of those conditions bind today. All of them are plausible in the medium term. Reach for it when at least one of them starts to bind, not before.
The two entries in this section emerged from the Phase 47 scoping arc (2026-05-07) when external-platform agent developments at Anthropic — Claude Dreaming and the broader Managed Agents primitives — surfaced as relevant to Loomworks' Companion and specialist trajectory. Neither is Loomworks-native; both are external work that maps usefully onto Loomworks elements. Captured here so the mapping survives across sessions and so the relevant Loomworks attachment points are explicit.
Trigger. Any conversation about agent memory consolidation; about pruning, merging, or reorganizing accumulated knowledge; about "is the engagement Memory getting messy" or similar concerns about long-running engagements accumulating low-signal assertions; about Claude Dreaming, AutoDream, or /dream (the Claude Code variant); about cross-session pattern detection; about whether the Companion should observe and act on patterns across an engagement's history; about Accounting engagement reconciliation as a recurring evaluator task; about observation-to-Shape transitions where accumulated Memory becomes a structured specification proposal; about whether Loomworks should incorporate dreaming-style behaviors as agent capabilities mature.
Substance. Anthropic shipped Claude Dreaming for Managed Agents in research preview on 2026-05-06: a scheduled process that reviews past sessions and memory stores, extracts patterns, prunes stale entries, merges duplicates, and resolves contradictions. In Claude Code specifically, Auto Dream consolidates CLAUDE.md and MEMORY.md files between sessions. The capability addresses a real problem: as agent memory accumulates, it becomes redundant, contradictory, and stale; the agent's effective context degrades.
The same problem applies to Loomworks engagement Memory at scale. As an engagement runs over months, assertions accumulate. Some become redundant (different assertions saying overlapping things). Some contradict newer assertions. Some become stale. The Companion's context window fills with low-signal material.
The governance model is what differs. Claude Dreaming modifies memory autonomously by default (with optional human review). Loomworks is built on Operator authority — the machine surfaces and signals, the Operator approves. Autonomous memory modification is a category error in Loomworks. Loom Protocol's no-erasure guarantee is structural.
The Loomworks-native version of dreaming routes through the engagement pipeline. The Companion proactively reviews Memory and proposes consolidations or retractions. "Assertions #12 and #23 say overlapping things — want me to retract #12 and amend #23 to cover both?" That proposal enters Shaping. The Operator approves. The retraction is FORAY-attested. The provenance survives.
Specific applications across Loomworks:
Current state. The infrastructure exists. Phase 44 trigger evaluator + proactive observation pathway + four-room pipeline give the Companion everything it needs to "dream" — the missing pieces are specific evaluator implementations and prompt instructions for each application above. None are urgent today. They become valuable when:
Trajectory. Originally framed as "should Loomworks adopt dreaming?" The corrected framing: dreaming is not a capability to adopt — it's a use case for capabilities Loomworks already has. The substantive question is which evaluator tasks and prompt instructions to build, not whether to graft external machinery onto the substrate. The methodology and governance differences (autonomous vs. pipeline-governed) are what they are; they're not in tension because Loomworks isn't trying to compete with Managed Agents on agent infrastructure — they're at different altitudes.
The relationship: Anthropic is publicly working out the conceptual primitives for long-running agent memory. Loomworks borrows the vocabulary (consolidation, hygiene, pattern extraction) and applies it through Loomworks' governance model. The borrowing is honest because both are addressing the same underlying reality.
Trigger. Any conversation about agent infrastructure platforms; about Anthropic's Managed Agents service; about lead/sub-agent orchestration patterns; about grader agents or outcome-based evaluation; about session lifecycle, vault credentials, or webhooks for agent platforms; about whether the Companion should be implemented on Managed Agents or on Loomworks' own substrate; about specialist composition extending to multi-agent decomposition; about how external systems should subscribe to engagement lifecycle events (post-Arc-2 external connectors); about render review or quality assessment for composed Render outputs; about the relationship between Loomworks-as-methodology and external agent platforms.
Substance. Anthropic's Managed Agents (GA April 2026; expanded 2026-05-06 with Outcomes, multi-agent orchestration, and webhooks alongside the Dreaming research preview) is a managed agent infrastructure platform. The platform's vocabulary gives Loomworks four conceptual primitives worth tracking as the Companion and specialists develop into full agents.
Primitive 1 — Outcomes and grader agents → Shape-as-acceptance-criteria + review specialist. Managed Agents lets users define criteria for what "good" looks like; a grader agent evaluates output against those criteria. Loomworks already has the criteria — the Shape is a complete specification (Phase 38 grammar declaration formalizes this). What's missing is the explicit grader. A review specialist that reads the Shape and the Render and produces an acceptance assessment is a natural extension of Loomworks' specialist pattern. Becomes important when (a) render specialists compose other specialists' work (Phase 37 territory) and "is this Render faithful to the Shape?" needs to be answerable without the Operator personally reading every output, (b) automated quality gates become valuable at platform scale.
Primitive 2 — Multi-agent orchestration → lead/sub-specialist composition with engagement Memory as shared substrate. Managed Agents supports lead agents that decompose work and assign to sub-agents working in parallel on a shared filesystem, with results consolidated through the lead agent's context. Loomworks has render specialists, and Phase 37 introduced adapter chaining and composition — partway there. The Managed Agents pattern points where this extends: a lead specialist that orchestrates sub-specialists, with the engagement's Memory as the shared substrate (instead of a generic filesystem). The shape-grammar declaration work (Phase 38) makes this more tractable because sub-specialists can declare what fragments they produce and the lead can compose them. As specialists become richer, this orchestration vocabulary becomes the way to describe them.
Primitive 3 — Memory + Dreaming → engagement Memory + governed consolidation. See 5.1. The conceptual primitive: persistent agent memory needs active maintenance. Dreaming validates the problem; Loomworks governs the solution differently.
Primitive 4 — Sessions and webhooks → engagement participation periods + lifecycle events. Managed Agents treats sessions as first-class objects with lifecycle events that external systems can subscribe to. Loomworks has engagement participation but no equivalent first-class session boundary or webhook surface. When Arc 2's external service connectors come online (Stripe link, messaging, calendar, third-party render services), the question "how do external systems know what's happening in an engagement?" needs answering. Webhooks on engagement state transitions, render completions, approval events — that's the integration surface. The Managed Agents shape gives the primitive without prescribing the implementation.
The relationship between Loomworks and Managed Agents. Managed Agents is an agent infrastructure layer. Loomworks is a methodology and governance environment for agent-mediated work. They're at different altitudes. Loomworks could run on Managed Agents under the hood, or run its own substrate; the methodology doesn't change either way. What matters is that Anthropic is publicly working out conceptual primitives — outcomes, orchestration, memory, dreaming, sessions — and those primitives compose well with what Loomworks is building. Borrowing the vocabulary is cheaper than inventing parallel terms, and the mapping is honest because both are addressing the same underlying reality of long-running agent work.
Current state. None of the four primitives are built into Loomworks today. Each maps to a specific future direction:
Trajectory. Considered framing as "should Loomworks build on Managed Agents?" Set aside because the question conflates two layers. Managed Agents is infrastructure; Loomworks is methodology. The implementation choice (own substrate vs. Managed Agents) is independent of the conceptual borrowing. The conceptual borrowing is the load-bearing insight: vocabulary that Anthropic is making canonical in the broader ecosystem can be adopted in Loomworks without coupling Loomworks' substrate to Anthropic's platform.
The corrected position: Loomworks builds its own substrate and borrows external vocabulary where it composes well. The Managed Agents primitives are the most useful current example — outcomes/grader, orchestration, memory/dreaming, sessions/webhooks all map cleanly onto Loomworks elements (Shape, specialist composition, engagement Memory, engagement lifecycle). Track new primitives as they emerge from external work; absorb the ones that map cleanly; don't import implementations.
The two entries in this section are the substrate side and the capture-device side of the Operator's mobile experience of the Companion. They emerged from the conversation initiated by the question "Would it be possible to have the Companion present and listening on my mobile (iPhone or Android) similar to how Siri is always present on my iPhone? I would like to be able to say 'Hey Companion, I parked on level 10.'" The conversation surfaced two engagements rather than one, and produced a pair of investigations that should be read together: loomworks-quick-capture-engagement-investigation-v0_2.md and loomworks-mobile-presence-investigation-v0_1.md.
The pair is paced by three constraints worth flagging up front: (i) the substrate side is prerequisite to the capture-device side (mobile is the highest-value surface but cannot ship before /quick-capture exists); (ii) persona-emergence dependency (the voice register fires at much higher frequency than the conversational surface; persona instability is felt sharply at this volume); (iii) mobile-engineering-capacity is the larger pacing constraint (native iOS + native Android is a substantial build, larger than any single substrate phase Loomworks has shipped, and warrants engineering capacity beyond the current DUNIN7-M4 + CC cadence). All three are pacing-readiness concerns, not architecture concerns; the architecture is settled enough at investigation level for scoping to begin when capacity allows.
Trigger. Any conversation about dictation surfaces, fast-path Memory contribution, "Hey Companion, ..." utterance shapes, the parking / grocery-list / "I just parked" use case, append-only Memory contribution with terminal acknowledgment, single-valued vs. multi-valued slot semantics, Companion-noticed supersession, the held-layer-as-supersession-resolution-surface, or any conversation about when an utterance should bypass the full Phase 42 converse pipeline because it's structurally not a conversation. Also: any conversation about queries against quick-captured Memory ("Where did I park?"), or about disambiguation between same-day same-slot facts ("I parked at level 7" after earlier "I parked at level 10").
Substance. Quick-capture is one class of bidirectional Memory traffic on a fast path with three modes: write-clean, write-with-resolution, and read. Capture is dictation-class (capture, route, author held assertion, brief acknowledgment, stop). Routing is engagement-determined via the Companion's three-layer router (Operator-declared rules → engagement-context default → light heuristic). Writes that conflict with structurally similar prior held assertions surface either Companion-noticed supersession (clean cases; auto with naming acknowledgment) or one focused disambiguation question (ambiguous cases). Reads against quick-captured Memory are a sibling mode on the same surface.
The architectural question — intent-class extension on the existing classifier path vs. pre-classifier fast path vs. hybrid — is open. Most likely hybrid: fast path for dedicated capture surfaces (mobile shortcuts, watch complications, keyboard shortcuts), intent extension for chat-pathway invocation. Same router, two entry points.
The methodology-finding-grade observation: single-valued vs. multi-valued slots as an engagement-declared property; Companion-noticed supersession on the held layer as distinct from Operator-explicit retraction. Single-valued slots ("current parking location") supersede on update; multi-valued slots ("items on the grocery list") accumulate. The engagement declares which is which. The held layer is the cheap-supersession layer because supersession before commit doesn't require retraction ceremony. The asynchronous-commit window doubles as the supersession window. Phase 38's declare-and-register pattern is a natural extension surface for slot-semantics declaration.
The voice register expands from one template to four: clean-ack ("Got it. Level 10."), query-response ("Level 10 — at 9:13 this morning."), disambiguation-question ("Got it — earlier today you said level 10. Replace it?"), resolution-ack ("Done. Level 7 it is."). All short; all dictation-class; resistant to the conversational pipeline's tendency toward warmth and elaboration. Likely ships through a voice loader at loomworks/orchestration/quick_capture_voice.py analogous to the credit_voice loader from Phases 49 and 50.
The router is name-agnostic: wake-word recognition is upstream of the substrate; the router receives an utterance and a destination, not a wake-word-keyed dispatch. Companion-name authority lives in the companion_name column (Phase 41); every surface reads from there.
Current state. Not built. Investigation v0.2 is the architectural framing. A scoping note is the next deliverable, paired with the mobile-presence scoping (6.2). The CR follows after scoping.
Trajectory. v0.1 of the investigation framed quick-capture as a third class of turn in a methodology trinity (Companion-proposes/commits, Companion-converses, Companion-routes-and-records). v0.2 reverted that framing: quick-capture is one class of bidirectional Memory traffic with sub-modes, not a third write-class peer. The methodology distinctions live on the write-vs-read and clean-vs-conflicting axes within quick-capture, not at the class-of-turn level. The reversion happened because a three-utterance example ("I parked on level 10" / "where did I park" / "I parked at level 7") surfaced that reads (the second utterance) don't fit "routes-and-records" — they're a sibling mode on the same surface, not a separate class. The trinity framing was making a class distinction at too coarse a level; v0.2 lands it at the right level (sub-modes within quick-capture). Preservation of the v0.1 framing matters because someone reading "third class in a trinity" without the trajectory would not know to look for the sub-mode framing — they'd assume the original answer was the right one.
A second trajectory note: the held-vs-committed posture for alpha was framed in v0.1 as Option 2 (held + asynchronous batch commit), recommended on methodologically-conservative grounds. v0.2 sharpens — Option 2 is more than conservative; it's the architecturally-required layer for the temporal-coherence pattern. Companion-noticed supersession needs the held layer to operate cheaply; without it, every supersession would require explicit Operator-side retraction. The alpha posture has a methodologically-positive reason, not just a defensive one. This is worth preserving because future scoping might be tempted to skip the held layer for "performance reasons" or similar, and the methodology cost of doing so would be high.
Trigger. Any conversation about iPhone / Android Companion presence, "Hey Siri" / "Hey Google" routing to Loomworks, App Intents, App Actions, Siri Shortcuts, foreground wake-word detection, on-device wake-word libraries (Picovoice Porcupine, Snowboy), tap-to-speak surfaces (widgets, watch complications), the Operator Layer extending to mobile, federation between web/desktop and mobile surfaces, the mobile chat surface, push notifications for proactive Companion behavior, offline quick-capture queueing, or the parking-garage example use case (which is literally often spoken offline, in a parking garage, before the substrate is reachable).
Substance. Mobile presence is multi-surface, not single-surface. The literal "always listening like Siri" interpretation is closed for third parties on iOS (Apple reserves system-level wake-word for Siri) and effectively closed on Android (foreground services with persistent notifications are the closest available; battery and OEM-killer dynamics make them unreliable for always-on). The right framing is composition of surfaces, each appropriate for a different posture:
companion_name); gets Siri-class always-on for free. Closest to Siri-equivalent.companion_name literally ("Hey Freda"). On-device detector (Picovoice Porcupine recommended). Most flexible; bounded by foreground posture.companion_name. No wake word; tap is the invocation. The watch complication is the highest-value form factor for quick-capture — phone-in-pocket, wrist-accessible posture is the actual peak case for the parking-garage scenario.
The federation framing is methodology-finding-grade: mobile is an Operator Layer surface, not a forked substrate. Same companion_name, same engagements, same Memory, same converse pipeline, same approval cards. The web Operator Layer is "Operator Layer (web)"; mobile is "Operator Layer (mobile)." Same family, different form factor. The principle is naming-neutral and form-factor-neutral; the same composition would apply to a future TV surface, car surface, or kiosk surface.
Offline posture is a first-class concern, not a footnote. The Operator's exact opening example — "I parked on level 10" — is literally often spoken in a parking garage, where mobile data is unreliable. Local timestamping with replay-time idempotency is the cleanest answer: captures land in a local queue with their original timestamps; queue drains on connectivity return; voice acknowledgment speaks immediately on capture (the on-device voice template is loaded; ack isn't network-gated). Substrate idempotency on (utterance, time-window, person) tolerates offline-replay edge cases.
The recommended primary form is native (iOS Swift/SwiftUI, Android Kotlin/Jetpack Compose). PWA loses most of mobile-presence's value (App Intents, foreground wake-word, watch complication, widgets all require native). Cross-platform (React Native, Flutter, Kotlin Multiplatform) trades platform-native feel for code reuse; some integrations need native bridges anyway.
Current state. Not built. Investigation v0.1 is the architectural framing. A scoping note is the next deliverable, paired with quick-capture's scoping (6.1). The build follows after scoping and after the substrate-side /quick-capture endpoint exists. The build is paced by mobile-engineering-capacity (see 6.3) more than by methodology readiness.
Trajectory. Originally framed as "achieve Siri-equivalence." Set aside because the literal interpretation is closed for third parties on both platforms. Reframed as "compose a set of surfaces such that the Operator experiences the Companion as present and reachable, with as little friction as the platforms permit." The composition turns out to be richer than a single wake-word surface would have been — different surfaces serve different postures, and that's a feature. Worth preserving the trajectory because future sessions might revisit the question "why don't we just make the app always-listen like Siri does," and the answer is Apple and Google reserve that capability for themselves; the App Intents Siri-Shortcut pattern is the closest a third party gets, and it's actually good.
A second trajectory note: the watch complication observation. Initial framing treated the watch as a thin extension of the iPhone/Android app, mostly an afterthought. On reflection, the watch is the highest-value form factor for quick-capture — phone-in-pocket, wrist-accessible posture is exactly when "I parked on level 10" wants to be said. The watch surface eliminates the friction of getting the phone out, which is the highest friction of any surface in the composition. Worth preserving because scoping might otherwise treat the watch as "we'll do that later" when the actual usage pattern says it's the peak case.
Trigger. Any conversation about when to begin Loomworks mobile-app construction; about whether DUNIN7's current build cadence (one substrate phase at a time on DUNIN7-M4 + CC) is appropriate for a native iOS + native Android build; about specialist contractors for mobile work; about cross-platform frameworks (React Native, Flutter, Kotlin Multiplatform) as a way to compress effort; about the relationship between methodology readiness and engineering readiness; or about the pacing of mobile vs. desktop / substrate work generally.
Substance. Native iOS + native Android is a substantial build, plausibly larger than any single substrate phase Loomworks has shipped. The current build cadence is well-tuned for substrate work but is unlikely to be the right cadence for mobile. Three options surface:
The decision is organization-level, not methodology-level. The methodology is settled enough at investigation level for any of the three to work. What changes between them is timing, cost, and platform-native feel.
Current state. No decision; flagged for the next manifest pass and for whichever scoping pass elevates 6.1 / 6.2 from queued direction to active scope.
Trajectory. Originally not surfaced as a separate concern — the assumption was that mobile would proceed through DUNIN7-M4 + CC like substrate phases. The mobile-presence investigation surfaced the build-volume estimate explicitly: native iOS + native Android is comparable in effort to the Operator Layer's web frontend, which has been a multi-phase undertaking. Treating mobile like a single substrate phase would underestimate the effort by an order of magnitude. Worth preserving because future scoping needs to know that mobile is not a small build, even if the methodology investigations make the architecture look tractable. Architecture being tractable doesn't make execution small.
Trigger. Any conversation about the Operator not understanding what the Companion just said; about disambiguating Companion vocabulary in product context; about the comprehension residue that plain-terms-discipline cannot reduce to zero; about Operator-driven what did you mean by that? surfaces; about button-mode explain on the OL converse view; about audible explain through a voice-modality surface; about voice-modality substrate prerequisites for an audible explain (speech-to-text, push-to-talk, wake-word, microphone access, optional TTS); about the relationship between explain affordances and quick-capture (output low-friction vs input low-friction) or mobile presence (shared voice-modality substrate); or about Phase 32 marketing-engagement calibration evidence informing which explain-affordance candidate ships.
Substance. The explain affordance is the first concrete instance of the discipline-plus-recovery principle named at Phase 56 close (manifest v0.41 §2 as v0.21 candidate). The principle: plain-terms-discipline reduces the incidence of vocabulary-comprehension gaps, but does not reach zero — the irreducible residue (Operator encountering a word, phrase, or framing they don't quite grasp in product context) needs a recovery affordance. The explain affordance is the surface where the Operator says what did you mean by that? and the Companion replies with a bounded, on-discipline clarification.
Two trigger modes are anticipated and scoped in loomworks-explain-affordance-investigation-v0_1.md:
Voice composition for the affordance is likely hybrid: LLM-composed by default; pre-authored for the most-encountered explanation triggers (a small library of bounded explain templates); voice-templated scaffolding to keep LLM composition on-discipline. Pre-authoring overhead is moderate; full LLM-composition risks vocabulary drift back toward methodology-noun language unless scaffolded. The voice principles document (Phase 56) anchors the discipline; the explain affordance's voice templates inherit it.
Three candidate phase shapes are scoped:
Current state. Investigation v0.1 (project knowledge) is the design-space framing. Selection deferred to post-Phase-32 calibration evidence — the marketing engagement creation surfaces real-use comprehension-gap data; Operator's actual experience with the now-voice-tuned surface (Phase 56's discipline applied) informs which candidate fits. The three persona transcripts at tests/fixtures/voice-calibration/ may surface candidate comprehension-gap questions when calibration is exercised, but those are forward-looking persona authorship, not real-Operator evidence. Phase 32's lived-Operator-evidence is the load-bearing input to candidate selection.
Trajectory. Surfaced during the Phase 56 scoping arc through the Operator's explain-affordance observation at v0.2 → v0.3: plain-terms-discipline reduces comprehension gaps but doesn't eliminate them; the residue needs a recovery surface. The principle discipline-plus-recovery was named at v0.3 of the scoping note; the affordance was scoped as forward-looking companion artifact (loomworks-explain-affordance-investigation-v0_1.md); Phase 56 named the principle but did not build the affordance. Generalizable lens preserved: any UX discipline reducing an incidence rate needs a recovery affordance for the irreducible residue — explain affordance is one first instance; security defaults / override paths, structured fields / free-text escape, canonical workflows / bypass affordances, calibration-by-persona / Operator-correction loop are sibling instances anticipated. Worth preserving the discovery-arc detail because future scoping might miss the recovery-surface framing if only the explain affordance landed as a feature without its principle context.
The adjacency to §6.1 quick-capture and §6.2 mobile presence is substrate-shaped: audible-mode explain shares speech-to-text + audio capture + activation gating with both. Voice-modality substrate is the shared prerequisite. The three threads may merge into a single mobile-and-voice arc, or stay parallel with shared substrate; the choice is downstream-scoping. The adjacency to §2.2 Phase 32 marketing engagement is calibration-shaped: Phase 32 is the calibration evidence input to the candidate-selection decision.
The two entries in this section emerged from the deployment-strategy work that paralleled Phase 47 credit-substrate scoping. Together they describe the deployment topology that lets Loomworks ship as a fleet of instances, and the methodology framing (Loom + FORAY + OVA composition) that turns per-instance regulatory jurisdiction into a first-class product feature rather than a custom build for each customer. Captured here so the topology and the methodology survive together — neither is useful without the other.
Trigger. Any conversation about Loomworks deployment topology; about hosting jurisdictions or regulatory residency; about white-label and managed-hosting product tiers; about the Authority instance and how grant issuance crosses the fleet; about cross-instance traffic and resilience to instance outages; about how a partner runs their own Loomworks deployment under their own brand; about Hetzner / Railway / AWS / Cloudflare Pages or other hosting choices for production instances; about the public marketing website and how it relates to the Authority; or about fleet management as a Companion task.
Substance. Each Loomworks deployment is a DevOps engagement on DUNIN7's own Loomworks (the control plane). Loomworks manages its own distribution through its own pipeline — fleet management is not a separate tool, it's engagements on Loomworks managing other Loomworks deployments. The pattern carries five load-bearing properties that hang together:
destination_instance recorded. The marketing website is a deployment artifact in its own right, not a feature of any instance.
Current state. Substrate built and tagged through Phase 49. The credit schema is ready (phase-47-credit-substrate-foundation, phase-48-credit-completion-and-operator-signin). Phase 50 brings the public credit-request form and the conversion-credit asset_id override — completing the Authority-side surfaces the website needs to talk to. Fleet deployment itself is post-Phase-50 work: standing up Instance A on Hetzner CPX22, then Instance B on Railway, then Instance C on Hetzner Frankfurt for GDPR, plus the marketing website on Cloudflare Pages. Minimum viable test (website + A + B + C, skipping D) costs roughly $77/month plus Anthropic credits — small enough to prove the pattern before AWS-class spend. Source documents: loomworks-deployment-strategy-v0_2.md, loomworks-hosting-cost-analysis-v0_1.md, loomworks-white-label-multilanguage-analysis-v0_1.md.
Trajectory. v0.1 of the deployment strategy framed credit data as a separate database on each instance and centralized the credit store. v0.2 corrected on five points after credit-scoping v0.7 surfaced the underlying architecture: credit data co-locates in the engine DB under the credit schema (trigger atomicity and transactional signup require this); two-engagement governance with Credit Management as Authority and Accounting as state-keeper (replacing the single "Credit Management" framing); email registry on Instance A only (replacing distributed registries with their abuse-boundary holes); grant flow replacing invitation-code flow (the website is the entry point; codes aren't the abstraction); and the marketing website added as a first-class deployment artifact (the form needs somewhere to live). Worth preserving because the v0.1 framing would have produced a fleet that looked superficially similar but failed at exactly the points where the corrections matter — abuse, atomicity, and the form's home.
Trigger. Any conversation about regulatory jurisdiction as a product feature; about GDPR or EU data residency; about Schrems II or "prove data never left X soil"; about per-instance regulatory framework or retention policy configuration; about how Loomworks handles data sovereignty for regulated customers; about why an Operator might choose Hetzner Frankfurt over Railway US; or about the role each protocol (Loom, FORAY, OVA) plays in compliance posture.
Substance. Jurisdiction is a first-class deployment parameter, and the three protocols compose to make it so:
The composition is what makes jurisdiction selectable. Operators choose hosting based on regulatory need (their domain requires GDPR-bound residency) or privacy preference (they prefer EU jurisdiction even when not strictly required). DUNIN7 doesn't custom-build jurisdiction support per customer — the protocols already compose to give it.
Current state. Conceptually intact because all three protocols already exist: FORAY is live, OVA seam shipped in Phase 45 (per-instance authorization broadened by Phase 49's bimodal dispatch), Loom remembers per-engagement. The per-instance jurisdiction config is implementation work not yet done — Loom-side rule storage, FORAY-side instance-tagged attestations, OVA-side jurisdiction-scoped credentials. Instance C (Hetzner Frankfurt) is the planned EU/GDPR instance per the deployment strategy; the protocol-triangle implementation lands when that instance is stood up.
Trajectory. Original framing (memory-edit era) treated FORAY as carrying the entire compliance story — "FORAY proves it." The conversation sharpened to the triangle once the question "how does an EU operator know their data isn't readable by a US instance?" surfaced — FORAY proves what did happen, but it doesn't prevent unauthorized reads in the first place. Naming the triangle distributes the load: Loom holds the rules, FORAY proves observance after the fact, OVA enforces ahead of the fact. Worth preserving because future implementation might be tempted to lean on FORAY alone (the audit-trail framing is more familiar to compliance-minded customers), and missing the OVA leg would leave the system reactively compliant rather than proactively secure.
Two entries covering how Loomworks engagements pull current state from external services. The architectural move is to build one general-purpose specialist rather than N service-specific adapters; the public-apis catalog is the reference universe of services that specialist can be configured against.
Trigger. Any conversation about Loomworks accessing external APIs; about per-service adapter sprawl; about pulling current state into engagement working state from external sources (weather, FX, holidays, geo, market data, news, image services, etc.); about how the protocol triangle wraps external data; about the seam-and-stub pattern; about whether to ship N specialists or one generic adapter; about MCP versus REST integration patterns; or about the github.com/public-apis catalog and its relationship to Loomworks.
Substance. Build one general-purpose external API specialist that handles all public APIs through a uniform FORAY-attested, OVA-authorized interface, rather than building N service-specific specialists. The specialist takes a declarative API description (URL, method, authentication pattern, parameters, expected response shape) — held as Memory in the engagement that uses it — and produces calls wrapped with full protocol-triangle discipline:
The architectural payoff is that constraint-creep is bounded. Adding the 200th external service is the same shape as adding the second; the gateway scales linearly while specialist count stays at one. The Specialist SDK consumption pattern (Population 1 / 2 / 3) gets a load-bearing first instance — the gateway is itself a Population-1 DUNIN7-built specialist that handles a class.
The pattern has tiers, each progressively more capable but each independently shippable:
Tier 1 covers most cases. Tiers 2-4 are progressive enhancements driven by what real engagements need.
Current state. Not built. Architecturally compatible with existing pieces — Phase 34 shipped external-service polling for specialists, Phase 38 shipped declare-and-register grammar, OVA credential storage exists, FORAY attestation surface is live. The trigger to build is the second engagement that requires live external data on the hot path: Credit Management didn't need it (its operational data is engine-internal), but FarmGuard (weather, sensor data) and ExpenseDesk (FX rates, vendor lookup) both will, and Goosey image generation is a render-side analogue of the same pattern. When two of those land in close succession, the gateway specialist becomes the right shared substrate to build first rather than building per-engagement.
Trajectory. Originally framed as "ship 10–15 first-party specialist adapters for high-leverage services" — weather, geo, FX, holidays, identity verification, etc. Reframed by the Operator on 2026-05-09 to "build one general-purpose API gateway with FORAY/OVA wrapping; let the catalog of API definitions live as engagement Memory." The reframing is load-bearing because it converts a build-direction (write more specialists per service) into a build-once-then-configure pattern (write the gateway, configure per-engagement). It also surfaces a sharper observation: external API specifications are themselves a class of supplied domain knowledge — the public-apis catalog is structured external knowledge that becomes more valuable to Loomworks when held as Memory than when retrieved ad-hoc. This composes with the supplied-domain thesis from the methodology engagement: the Operator (or DUNIN7 as a default seed) supplies the catalog of "what external services exist and how to call them"; the gateway acts on it. The reframing also addresses the constraint-creep concern raised in the earlier MCP discussion — instead of N specialists or N MCP servers proliferating, one configurable gateway scales.
Trigger. Any conversation about which external APIs Loomworks should support; about the universe of free/public APIs available to draw from; about github.com/public-apis as a resource; about discovery of external services for new engagements; about populating the gateway specialist's known endpoints; or about external information seams in general.
Substance. The public-apis repository (github.com/public-apis/public-apis) is a community-curated catalog of free public APIs across roughly 50 categories — weather, finance and FX, geocoding and geo data, holidays, government data, news, sports, identity verification, image services, vehicles, animals, anime, blockchain, and more. Each entry follows a standardized format: name, description, authentication requirement (none / apiKey / OAuth), HTTPS support, CORS support, optional Postman collection link. The catalog is actively maintained, sponsored by APILayer, and contains roughly 1,500+ entries.
For Loomworks, the catalog is the reference universe for the general-purpose API gateway specialist (8.1). Three ways it composes:
Current state. Not ingested. The catalog is a resource to draw on; ingestion is gated on the gateway specialist (8.1) being built. The catalog should be treated as a living external resource — community-maintained, will continue to evolve — not as a fixed snapshot. Ingestion patterns should accommodate periodic refresh.
Trajectory. Originally surfaced as "this might be useful" by the Operator in a chat session. Sharpened in the same session into the gateway specialist pattern (8.1) once the recognition landed that one wrapper handles the class. The catalog without the gateway is just a list; the gateway without the catalog still works (engagements can declare any endpoint); the two compose into a coherent external-information-seam architecture in which the catalog supplies the universe and the gateway supplies the discipline.
One entry in three subsections, capturing the Operator's recognition that the Companion should maintain standing awareness of the Operator's current state and relevant environment — meaningfully more powerful in context than Siri-class voice assistants.
The architectural recognition is that what looks like "the Companion answers a question" decomposes into a Memory-lookup component plus an engine-clock-or-external-seam component, and that this decomposition generalizes to a whole class of ambient-context capabilities. The Companion's standing posture is to maintain a current-state model of the Operator's situation and the relevant environment, and to draw on it (and offer from it) without being asked to fetch each piece individually.
Trigger. Any conversation about the Companion knowing what time it is, where the Operator is, what's on their calendar, what the weather is, what's happening relevant to them today; about Siri-comparison or any "this should be more powerful than Siri" framing; about why the Operator should not have to re-explain context in each interaction; about proactive Companion behavior anchored in current state ("you should leave in 8 minutes for that meeting"); about the difference between cold-start question-answering and standing-context question-answering; or about composing personal Memory, engine state, and external seams into a coherent moment-to-moment picture of the Operator's situation.
Substance. The Companion's standing posture should include continuous awareness of the Operator's current state and the environmental factors relevant to their work and life. Three strands compose:
This standing-context capability is what distinguishes the Companion from cold-start voice assistants. Siri answers the question literally asked; the Companion described here understands the question in context because the context is already loaded. "Should I head out?" is answerable without specifying for what, because the Companion has ambient awareness of what's coming up. "Does this work for everyone?" is answerable in the context of who "everyone" is, what their time zones are, and what their calendars say. The Companion can also be proactive: surfacing what the Operator hasn't yet asked but would benefit from knowing, anchored in standing awareness rather than triggered by an explicit question.
Current state. Pieces are shipped or filed:
What's not yet filed as a coherent capability is the composing layer — the standing posture itself. The pieces exist; the discipline of "the Companion maintains an ambient-context model and draws on it without being prompted to fetch each piece" is the gap. The composing layer is methodology-finding-grade work: it's a behavior pattern that ties together capabilities the substrate already supports, rather than new substrate.
The build trigger is when ambient-context behavior becomes load-bearing for an engagement — most likely the mobile-presence engagement (Section 6.2), where ambient awareness is the value proposition. Watch complications and Lock Screen surfaces showing "Companion knows it's 9:13am, you have a 9:30 meeting, traffic is light, leave in 8 minutes" are exactly this capability operationalized.
Trajectory. Originally surfaced when the Operator asked about time-of-day awareness in the context of "what time is it." The narrow question (engine clock + Operator time-zone Memory = local time) is trivial once the time-zone assertion is in personal Memory. The recognition that landed was broader: this trivial-seeming pattern is an instance of a general capability, and that general capability is what makes the Companion meaningfully more useful than Siri-class assistants. The reframe converts "Companion knows what time it is" (a feature) into "Companion has ambient-context standing posture" (a capability shape that subsumes time, weather, calendar, location, schedule, and world-relevance under one discipline). Worth preserving because the ambient-context framing changes how downstream features get built — they get built as additions to the standing model, not as one-off feature flags.
Trigger. Any conversation about how the Companion answers ambient questions; about composing personal Memory with engine clock or external seams; about generalizing trivial questions into a discipline; about why "what time is it" is the same shape as "should I bring an umbrella" or "is my colleague awake."
Substance. Ambient-context questions decompose into two or three components:
This pattern generalizes to a class of capabilities: time-of-day, weather, calendar context, traffic, holidays, daylight, world-events-relevant-to-the-Operator. All decompose the same way. All benefit from the same Memory discipline. All compose with the API gateway specialist (8.1) for the universal-component side and with personal Memory (Phase 41) for the specific-component side.
The methodology recognition is that this is the supplied-domain thesis applied to ambient context. Universal facts about the world (current UTC, current weather in Miami, current traffic on I-95) are findable by anyone. They become useful to the Companion when they're composed with what the Operator has supplied about themselves — where they are, what they care about, what's relevant to them. Same shape as deeper domain knowledge: the universal is available; the specific has to be supplied; the value is in the composition.
Current state. Pattern is named here for the first time. Each instance of it that gets built (time, weather, calendar) should follow the same structural shape so the discipline compounds rather than fragmenting into ad-hoc per-feature code. The first instance (time) is essentially shippable today given Phase 41 personal Memory and engine clock; subsequent instances depend on Section 8.1's API gateway specialist landing.
Trajectory. No prior framing to preserve — the decomposition pattern is new with this entry. Worth recording for v0.21 methodology consolidation as a candidate methodology principle: ambient-context capabilities decompose into universal (engine or seam) plus specific (Memory) plus bridging (Companion reasoning), and benefit from being built to that shape rather than as one-off features.
Trigger. Any conversation about the Companion knowing which context to surface; about proactive ambient-context offers; about why standing awareness is more powerful than answering-when-asked; about how the Companion decides when traffic information matters versus when it doesn't.
Substance. Maintaining ambient context is necessary but not sufficient. The Companion also needs to know which subset of ambient context is relevant to a given moment or question. This is the relevance bridge: the disciplined judgment about what to surface, what to compose into an answer, and what to leave silent.
Three patterns:
The relevance bridge is the discipline that prevents ambient awareness from becoming noise. Siri's failure mode (and most voice-assistant failure modes) is that they answer literally, even when the literal answer isn't what was wanted. The Companion's relevance bridge is the antidote: ambient context informs the answer, but the answer is shaped by what was asked, by what the Operator cares about, and by what's currently load-bearing in their work.
Current state. Not built as a discipline. Pieces of relevance reasoning happen ad-hoc in Phase 42 intent classification and Phase 44 proactive behavior. Naming it as a discipline lets future builds follow the pattern rather than reinvent per-feature relevance logic.
Trajectory. No prior framing. Worth filing because the relevance bridge is the difference between a Companion that's useful and a Companion that's annoying. Both have the same ambient context; only one knows when to deploy it.
The architectural construct that subsumes ambient context (Section 9), proactive cross-engagement awareness, the Operator's standing relationship with the Companion, and several other behaviors that are Operator-bound rather than engagement-bound.
Why this section exists. The Operator asked, in conversation, whether "keep me in your thoughts and remember stuff for me; alert me to other engagements' activity when appropriate" was itself an engagement. The unpacking surfaced that it isn't — engagements are bounded, four-room, domain-holding things; what the Operator described is continuous, cross-engagement, Operator-bound. The thing without a name is the standing Companion, and naming it as a first-class architectural construct is the move this section makes. The naming is methodology-finding-grade and load-bearing for v0.21 consolidation; this section is the queued-directions filing of it pending that consolidation.
Trigger. Any conversation about the Companion's behavior across engagements rather than within one; about what the Operator means when they say "keep me in mind"; about the difference between Companion-as-chatbot and Companion-as-attendant; about why the personal engagement isn't sufficient to capture the Companion's continuous role; about cross-engagement alerting; about the executive-assistant framing. Also: any question of the form "is X an engagement?" where X is a behavior pattern, a posture, or a continuous relationship rather than a bounded domain — the answer template lives here.
Substance. The Companion has two operating modes:
These aren't two Companions. They're the same Companion in two postures, switching based on what the Operator is doing and what the moment requires. The standing Companion is what makes Loomworks Companion meaningfully more than a chatbot inside an engagement — it's the continuous relationship that engagement-bound mode then specializes into when the Operator enters a specific engagement.
A useful analogy: in a company, there are projects (bounded, with deliverables, with teams) and there are executive assistants (continuous, attending to the principal, holding context across all projects, surfacing what's relevant when it's relevant, governed by the principal's standing preferences). Projects are engagements. The standing Companion is the executive assistant. The analogy isn't perfect — the Companion is not a separate person, it's a posture of the same Companion — but it captures the relationship cleanly: continuous attendance, principal-derived authority, judgment about when to surface what.
The standing Companion has these load-bearing properties:
Current state. Pieces are shipped or filed:
What's not yet built is the composing layer — the standing Companion as a named, disciplined construct with its own working state, its own authority model, its own composition rules with engaged mode. The composing layer is methodology-finding-grade and substrate-shaped: 10.2 (standing Memory as its own scope) is a substrate move; 10.3 (authority and scope) and 10.4 (standing/engaged composition) are behavioral disciplines that compose over the substrate.
Trajectory. Originally, cross-engagement Companion behavior was framed informally as "what the Companion does between engagements" or "personal Companion behavior" — neither name was load-bearing. The Operator's question "is this an engagement?" surfaced the deeper recognition: the behaviors being asked about (keep-in-mind, remember-for-me, alert-across-engagements) don't fit the engagement shape. They're a different category. Naming the standing Companion as a first-class construct, distinct from engagements and distinct from the personal engagement, is the architectural move that makes those behaviors filable, designable, and buildable. Worth preserving because future builds otherwise risk being modeled as either "another engagement" (wrong shape) or "a feature inside the personal engagement" (also wrong shape — confuses Operator-declared content with Companion-tracked working state). The standing Companion is its own thing.
Trigger. Any conversation about where the standing Companion's working knowledge lives; about whether personal-engagement Memory is the right home for cross-engagement attention state; about what the Companion tracks about the Operator versus what the Operator declares about themselves; about new Memory scopes; about the substrate work the standing Companion requires.
Substance. Standing Memory is its own Memory scope, distinct from personal-engagement Memory, sitting in the Operator's Memory access set alongside personal Memory and the Operator's engagement Memories.
The distinction the substrate needs to carry:
These are different categories of held information with different governance shapes. Conflating them — putting the standing Companion's working state into personal-engagement Memory — would muddy two distinctions that should stay clean: declared-vs-tracked, and durable-vs-current.
Standing Memory composes naturally with the existing N-space Memory pattern. The Operator's access set becomes:
Standing Memory has its own backing decisions — likely assertion-backed for some of its content (durable preferences the Operator has set), database-backed for the higher-velocity working state (current calendar, current location, current pending items). The resident-engagement investigation's Memory-backings axis (v0.2) applies; standing Memory uses the same calibration.
Current state. Not built. Substrate work — likely a Phase, possibly load-bearing for the standing-Companion build. The work involves: declaring standing Memory as a Memory scope; defining its assertion and database-backed sub-shapes; integrating it into the Operator's Memory access set; building the read and write APIs the standing Companion needs; the governance discipline (some standing Memory writes are Companion-initiated and Operator-acknowledged rather than Operator-initiated).
Trajectory. Originally considered (in the same chat session that produced this section) the simpler option of putting standing Companion working state into personal-engagement Memory. Set aside in favor of standing Memory as its own scope because (a) it preserves the cleaner separation of declared-vs-tracked content, (b) governance shapes differ and shouldn't be forced through one channel, (c) personal-engagement Memory is content-oriented (the Operator's own assertions about themselves) while standing Memory is state-oriented (the Companion's working model of the Operator's current situation), (d) future composition with organization or team Memory cleanly slots beside standing Memory in the access set. The Operator's call to take the cleaner-but-substrate-heavier option is recorded here because it has implementation consequences — the standing-Companion build is bigger than it would be if everything lived in personal Memory.
Trigger. Any conversation about what authorizes the standing Companion to read across engagements; about whether the Companion can act on its own initiative; about how the Operator controls when the Companion interrupts; about do-not-disturb patterns; about the threshold of utility; about why the standing Companion can't accumulate authorization beyond the Operator's; about the difference between reactive and proactive surfacing.
Substance. The standing Companion's authority model has two parts.
Authorization derives from the Operator, not independently. The standing Companion operates with the Operator's credentials and access set. OVA's per-Operator credentials are the mechanism. The standing Companion can read whatever the Operator can read; it cannot read what the Operator cannot read. It cannot accumulate authorization the Operator hasn't granted. This is structurally important: it means the standing Companion is exactly as bounded as the Operator is, no more, no less. The only thing the standing Companion adds is attention — it watches what the Operator could watch, and surfaces what the Operator would care about.
Proactive scope is Operator-declared, not Companion-determined. The standing Companion's right to interrupt or surface unprompted comes from explicit Operator declarations held in standing Memory. The default posture is silence. Examples:
These declarations form the scope layer of the standing Companion's proactivity. The Operator can add, modify, or retract them; they're held in standing Memory; they're queryable each time the standing Companion considers surfacing.
The judgment layer over scope is the relevance bridge (Section 9.3). Scope says "I'm allowed to surface this category of thing under these conditions." Judgment says "given that I'm allowed, is this specific instance more valuable to surface than the cost of interrupting?" Both are required. Scope without judgment produces noise (alerting on every authorized event, regardless of whether the Operator currently cares). Judgment without scope produces overreach (the Companion surfacing things the Operator never authorized it to attend to).
Current state. Not built as a discipline. Pieces of the authority side exist (OVA per-Operator credentials, Phase 49 bimodal dispatch). Proactive-scope declarations don't have a Memory home yet (they belong in standing Memory per 10.2, which isn't built). Authority is the easier piece because it falls out of OVA naturally; scope-declaration substrate is the harder piece and pairs with 10.2's substrate work.
Trajectory. No prior framing for the scope/judgment distinction; it lands here. Worth preserving because future implementations might collapse the two layers (treating proactive surfacing as a single "decide whether to interrupt" gate). The two-layer pattern — Operator-declared scope plus Companion-judged relevance — keeps the Operator in authority over the what while letting the Companion exercise judgment over the when and whether. This composes with the manifest's Operator-authority principle: the machine surfaces and signals; the Operator approves the rules under which surfacing happens.
Trigger. Any conversation about how the Companion behaves when the Operator transitions between engagements; about pre-loading context when the Operator enters an engagement; about how engagement events propagate to the standing Companion's awareness; about mode handoff during a session; about whether standing Companion interjections disrupt engaged-Companion working state.
Substance. Three composition patterns govern how the standing Companion and engaged Companion(s) work together.
Standing-to-engaged context bridge. When the Operator enters an engagement, the standing Companion can pre-load context that the engaged Companion will benefit from. "Marvin's coming to FarmGuard now; he was in ExpenseDesk an hour ago worrying about cash flow; the soil sensor reading from this morning is unusual." The engaged Companion picks up with awareness of where the Operator is mentally, not just where they are functionally. This is a read from standing Memory plus a snapshot to the engaged Companion's working context.
Engaged-to-standing observation upload. When something happens in an engagement that the standing Companion should know about, it propagates upward. "FarmGuard just produced a render that needs Operator approval" → standing Companion now tracks pending approvals across engagements, and the next time the Operator surfaces, the standing Companion can mention it. This is an event from the engagement (via Phase 44's SSE substrate) being absorbed into standing Memory's working state.
Mode handoff. The Operator transitions between modes continuously during a session — "I'm working on FarmGuard… wait, what time is it… okay back to FarmGuard." The standing Companion's interjection ("It's 4:15pm; you have a 5pm call") happens without losing the engaged Companion's working state. Mode handoff is short, transparent, and resumes cleanly. The mechanism is shared session context that both modes read from and write to, with engaged-mode writes treated as the engagement's own work and standing-mode writes treated as cross-engagement observation.
The three patterns compose through the Phase 44 SSE substrate plus standing Memory (10.2). Engagement events flow up to standing Memory via SSE; standing Memory state flows down to engaged Companion sessions via context bridge at engagement entry; mid-session mode handoff is mediated by shared session context.
Current state. Not built as a discipline. Phase 44's SSE substrate provides the wire layer; standing Memory (10.2) provides the durable working state; the composition patterns are the missing behavioral layer. Building this is the integration work that turns the standing Companion from a queued direction into a shipped capability.
Trajectory. No prior framing. Worth filing because the three patterns are easy to confuse with each other if not named separately — context bridge is anticipatory (loading context for the Operator's near-future activity), observation upload is reactive (absorbing what just happened in an engagement), mode handoff is interruptive (the standing Companion stepping in mid-session). Each has its own discipline, its own latency profile, its own failure modes. Conflating them produces sloppy implementations.
The standing Companion subsumes or composes with several queued directions that were previously filed independently. Naming the standing Companion as the architectural construct lets these compose cleanly rather than overlap awkwardly:
This composition surfaces a methodology recognition worth absorbing in v0.21: the standing Companion is the connective tissue across engagements; engagements are bounded systems; together they form the Operator's full working environment. The architecture has both layers; conflating them — treating the standing Companion as another engagement, or treating engagement behavior as standing-Companion work — produces wrong-shaped builds.
Build trigger for the standing Companion overall. The first non-chat surface that needs continuous standing attention. Mobile presence (Section 6.2) and quick-capture (Section 6.1) are both candidates; whichever lands first triggers the standing-Companion substrate and discipline as its prerequisite. Until then, the standing Companion's behaviors run informally through the engaged Companion's session-bound posture (which is functional but doesn't generalize to the surfaces those engagements need).
The DUNIN7-facing engagement whose subject is the operation of Loomworks itself across the fleet. Observer surfaces UX friction, token-use inefficiencies, methodology drift, cross-Operator patterns, capacity signals, and Companion-behavior calibration data — so that the DUNIN7 team can make Loomworks better as a product. It is content-blind by construction: it observes the shape of activity (frequencies, latencies, sequences, mode transitions, error rates) but never the content within that activity (engagement domains, contribution bodies, render text, conversation transcripts).
Observer is the first instance of a new architectural category — meta-engagements, whose subject is the operation of other engagements. It is filed here pending fleet deployment; its substrate prerequisite (event emission with content/shape redaction in the fleet topology) is a current architectural decision that has to be made before the fleet ships, because retrofitting clean content/shape separation into a system that's already emitting events is much harder than building it in.
Trigger. Any conversation about observing Loomworks usage across the fleet; about surfacing patterns or friction points across Operators; about token-use optimization at the fleet level; about cross-Operator product signal; about Loomworks management facilities; about "watching how it gets used." Also: any conversation about the relationship between an engagement and other engagements as its subject (the meta-engagement category Observer instantiates).
Substance. Observer is a meta-engagement: an engagement whose domain is the operation of other engagements. It is structurally distinct from both classes named in the resident-engagement investigation:
The category — meta-engagement, observing other engagements' operation — is worth naming as a new class because Observer might not be the only one. Conceivable future meta-engagements include a Compliance Observer (jurisdiction-specific regulatory observation), a Security Observer (anomaly detection in access patterns), a Cost Observer (deeper financial-modeling-side analysis distinct from Observer's product-side token observation). These would all be meta-engagements: shape-only, DUNIN7-or-tenant-facing, observing rather than acting.
Observer holds in its Memory the shape of fleet activity — typed event records carrying timing, identity (or anonymous cohort identifier; see 11.3), sequence, and outcome, but never the payload of the underlying activity. Its renders are analytical views — dashboards of friction points, token-use heatmaps, methodology-drift surfaces, cohort-pattern reports — produced for DUNIN7 consumption.
The value Observer produces breaks into several distinct streams that share the same substrate but answer different questions:
These are not eight separate capabilities to build. They are eight views over the same substrate. The substrate (event stream + shape Memory) is built once; the views are layered on top incrementally as DUNIN7 needs them.
Current state. Not built. The substrate prerequisite (event emission with content/shape redaction at the instance boundary) is a current decision — it must be specified as part of the fleet's deployment architecture before instances start emitting events, because the redaction has to happen at emission, not at ingestion. The Observer engagement itself can wait until there's a fleet to observe.
Trajectory. Originally framed by the Operator with the load-bearing constraint already articulated: "It would not observe what the Engagements are that Operators are creating, simply the interface and methods of Loomworks as they are utilized." This framing landed the content/shape distinction at the very first articulation, which is rare and worth preserving — most observation-system designs have to discover this constraint through privacy incidents. The unpacking sharpened the framing in three places: (a) the constraint must be structural rather than discretionary (Observer can't be trusted to look away; the architecture must prevent looking); (b) the category Observer instantiates is new and deserves its own name (meta-engagement); (c) Observer is not a single capability but a substrate plus a view layer, and the views can be many. Worth filing because future implementations might be tempted to either over-collect (capture content and trust Observer to ignore it — wrong shape) or over-restrict (treat all observation as suspect — leaves real product value on the table). The middle path is structural content/shape separation with a substrate that earns trust mechanically.
Trigger. Any conversation about Observer's privacy boundary; about what Observer can and cannot see; about whether content-blind observation is real or a promise; about event-emission design at instance boundaries; about how the architecture earns Operator trust mechanically rather than rhetorically.
Substance. The privacy boundary between Observer and the rest of Loomworks is content versus shape:
Observer reads shape. Observer never reads content. This is enforced structurally, at the event-emission layer:
This structural design means Observer's content-blindness is not a behavior of Observer — it is a property of the channel between instances and Observer. Even if Observer code wanted to read content, no content would be reaching it. The boundary is mechanical, not behavioral. This is the critical difference between "we promise not to look at your data" (which is a behavioral commitment and can be broken) and "the data never reaches us" (which is an architectural property and cannot be broken without changing the architecture).
The emission service composes naturally with the multi-instance fleet architecture (Section 7.1) and the jurisdiction-governance posture (Section 7.2):
Current state. Not built. The substrate decision — that event emission with content/shape redaction is a fleet-level architectural feature — is the load-bearing call to make now. The actual emission service ships when the fleet ships; Observer engages with it when Observer ships post-fleet. But the commitment to emission-with-redaction has to be made in the fleet's deployment architecture, not retrofitted later. Retrofitting introduces both technical debt and trust debt; building it in is straightforward.
Trajectory. The Operator articulated the content/shape distinction at the very first framing of Observer ("not observe what the Engagements are... simply the interface and methods"). The architectural reframe was: this needs to be enforced structurally rather than left to Observer's discretion. The reframe matters because discretion-based privacy fails (someone eventually peeks; or an incident reveals that "we don't look at X" had quietly become "we do look at X under condition Y"). Structural privacy doesn't fail that way — it can be audited mechanically, and the audit is the design. Worth preserving because future implementations might prefer the easier-to-build discretion-based version; the cost of doing so shows up later, usually catastrophically.
Trigger. Any conversation about whether Observer can identify specific Operators; about Operator consent for observation; about how DUNIN7 reaches out to Operators based on observed friction; about anonymized cohort patterns versus Operator-specific patterns; about layered observation governance.
Substance. Observer maintains two distinct view scopes, each with its own governance:
The two-view architecture has several consequences worth naming:
Current state. Not built. The two-view distinction is the architectural commitment; the implementation is part of the Observer engagement and the emission service. Consent infrastructure (Operator-side opt-in declarations) is a small substrate addition that pairs with the standing Memory work in Section 10.2.
Trajectory. The Operator chose "both with explicit consent for the identifiable layer" over "anonymized only" or "identifiable by default." The reasoning — cleaner-but-substrate-heavier — preserves the high-privacy default while enabling identifiable observation for the cases where Operator-specific help is genuinely useful. This is a real product capability and worth the substrate cost. Worth preserving because the simpler "anonymized only" option was set aside; future implementations could regress to it if the consent infrastructure proves complicated, and the trajectory note flags that the cleaner choice was made deliberately.
Trigger. Any conversation about phasing the Observer build; about which Observer capabilities ship first; about distinguishing substrate work from analytical-view work; about why the emission service can't wait until Observer engages.
Substance. Observer breaks into two architectural layers:
The substrate layer is load-bearing for everything Observer might do. The view layer is incremental — start with a couple of high-value views, add more as needed.
The substrate layer's emission-service component has a current architectural prerequisite call-out: it must be specified as part of the fleet's deployment architecture (Section 7.1) before the fleet ships, because every instance must emit events from day one in the shape-only schema. Retrofitting redaction into already-emitting instances is hard; building it in from the start is straightforward and is the basis for the structural privacy guarantee in 11.2.
The view layer can wait. There's nothing to observe pre-fleet — a single-instance Loomworks doesn't produce cross-fleet signal. Once the fleet has a small number of instances (3+), the substrate starts producing real data; once it has 10+, the views start producing real signal. Observer's first views likely sit in the product-improvement category (UX friction, abandonment patterns) because those are highest-leverage for early product iteration; token-cost views become more valuable as fleet scale grows.
A reasonable phasing:
Current state. Pre-fleet. The substrate prerequisite is the actionable filing; the engagement build itself is queued for post-fleet.
Trajectory. The two-layer split (substrate vs views) emerged from the unpacking — the Operator's question implied a single "Observer agent," but the architecture is cleaner when separated into the substrate (event stream + shape Memory) and the views (many small analytical surfaces over the substrate). Worth preserving because the view layer's incremental shape makes Observer's build cost much lower than "build Observer" would imply — each view is small, each view is independently shippable, the substrate carries the architectural weight.
Trigger. Any conversation about whether Observer is similar to other named constructs; about whether the standing Companion does what Observer does; about whether FORAY makes Observer redundant; about whether the Operator Layer dashboard is Observer-for-Operators; about whether Observer is surveillance.
Substance. Observer is distinct from several other constructs in the architecture, and the distinctions are worth naming explicitly to prevent conflation:
Observer is not the standing Companion (Section 10). This is the most important distinction because the two are shaped similarly. Both maintain continuous, cross-engagement awareness. Both run as observation layers rather than within bounded engagements. Both have rich relationships with the Phase 44 SSE substrate. But:
The right intuition: the standing Companion is the Operator's attendant; Observer is the fleet's instrument. Both watch continuously; they watch different things, for different audiences, with different authority.
Observer is not FORAY. FORAY is the per-action attestation substrate for compliance and traceability within engagements, on behalf of the Operator. Observer is a cross-engagement, shape-only signal stream for DUNIN7. They have different audiences (Operator/regulator vs DUNIN7 team), different scopes (within-engagement vs cross-engagement), different content access (FORAY has access to action content for the engagement it logs; Observer never has content access). FORAY logs Observer's emission events as a meta-attestation that the emission policy was honored (mentioned in 11.2), but the two systems are otherwise structurally separate.
Observer is not the Operator Layer dashboard. The Operator Layer (Phase 46+) is the Operator-facing interface to their own engagements, their own state, their own Companion. Observer is DUNIN7-facing. Operators don't see Observer's outputs; DUNIN7 sees Observer's outputs.
Observer is not surveillance. Surveillance, by usage, implies covert and content-rich observation. Observer is transparent and content-blind. Operators know it exists (it's part of the platform terms); Operators control the identifiable layer through consent; Observer never has content access. The architectural shape is closer to telemetry-with-privacy than to surveillance.
Observer is the first meta-engagement. It instantiates a new category — engagements whose subject is the operation of other engagements. Future meta-engagements (Compliance Observer, Security Observer, Cost Observer mentioned in 11.1) would follow the same structural pattern: shape-only event stream from instances, dedicated Memory in a DUNIN7-or-tenant-facing engagement, view layer producing audience-appropriate outputs. The meta-engagement category may deserve its own section in methodology v0.21 once it has more than one inhabitant.
Current state. Naming is the work this subsection does. No substrate is implied here beyond what's already in 11.2 and 11.4.
Trajectory. The standing Companion contrast was the Operator's explicit request — to name what Observer is by reference to what it isn't, so that the cross-engagement-observation shape doesn't get conflated with the Operator-attendant shape. The two constructs ended up in the same v0.7/v0.8 versions of this document, which is unusual but appropriate — they're architecturally adjacent enough that filing them together prevents future confusion. Worth preserving because if Observer had been filed alone, the temptation to model it through the standing-Companion lens (or vice versa) would have been strong. Naming the contrast at filing time makes the distinction durable.
This section is a discoverability pointer rather than a substantive filing. Two companion documents carry the content:
loomworks-structural-defensibility-investigation-v0_1.md — methodology investigation. Internal architectural recognition. Names structural defensibility as a methodology principle that operates now (rather than future work), traces where it already operates in the architecture (held-then-commit, approval-card pattern, OVA per-Operator credentials, FORAY append-only attestation, Section 11's content-vs-shape boundary, Section 7.2's jurisdiction-governance triangle), and articulates the discipline for future builds.loomworks-structural-defensibility-positioning-v0_1.md — external positioning document. Audience-facing version of the same argument. For use in investor conversations, partner discussions, regulatory communications, talks, and articles. Foregrounds the render-boundary frame as the simpler external story, with the protocol-triangle frame as the deeper architectural reality available to anyone who wants to look closer.Why this is filed here. Structural defensibility is methodology-finding-grade — it's a methodology principle that operates now rather than future work, which is why the primary filing is a methodology investigation. The queued-directions entry exists for discoverability: future readers searching this file for "harm prevention," "AI safety," "structural defensibility," "render boundary," "regulatory positioning," or "compliance" find this cross-reference and follow it to the substantive documents.
The principle in one paragraph. Most AI products defend against harm by filtering at the model — trying to make the model refuse to produce harmful content. Filtering is brittle: it fails when adversarial inputs find new edges, when models leak, when the line between harmful and not moves, when filters become so aggressive they impair legitimate work. Loomworks's defensibility runs through a different vector: structural defensibility makes certain harms architecturally impossible by virtue of how the architecture works. Rules are declared as Memory artifacts (inspectable, governable, composable). Enforcement happens upstream of implementation at OVA (the authorization gate prevents what isn't permitted from reaching the implementation layer). Attestation is mechanical and complete via FORAY (the audit trail is built into every decision rather than being optional logging). Harms the rules prohibit are architecturally impossible to commit, not detected and refused after generation. Harms the rules don't yet prohibit are immediately auditable, so the rules can be updated and future occurrences become impossible.
The render-boundary frame versus the protocol-triangle frame. The simpler external story — "renders are where things happen, and renders are governed" — is correct for the external-delivery case (engagements that produce documents, deployments, contracts, or other artifacts that ship outside Loomworks). The investigation document examines three places where the render-boundary frame is incomplete: resident engagements (where renders are internal information delivery, not external action), operational renders (which legitimately ship without per-action approval, as in Credit Management's automated reconciliation), and the production-vs-policy distinction (render specialists are implementation; they can't carry policy responsibility on their own). The complete defensibility argument runs through the protocol triangle operating across all four rooms, not just at rendering. Both frames are carried in the two companion documents — render-boundary as the communicable external story, protocol-triangle as the deeper architectural reality.
Current state. The principle operates now. The investigation traces six instantiations already in the architecture (5.1 held-then-commit, 5.2 approval-card pattern, 5.3 OVA per-Operator credentials, 5.4 FORAY append-only attestation, 5.5 Section 11's content-vs-shape boundary at instance emission, 5.6 Section 7.2's jurisdiction-governance triangle). What's missing is naming the principle explicitly so future capability work can attach to a consistent discipline.
Methodology v0.21 absorption. The investigation's §9.1 lists what v0.21 should absorb from this filing: structural defensibility as the methodology principle, the protocol triangle's role beyond jurisdiction governance, the render-boundary frame as a correct partial observation with named gaps, and detection-as-fallback rather than primary defense as a discipline call.
Trajectory. The recognition that became these documents moved through three turns: (1) Operator surfaced the AI-harm framing and proposed render-boundary defensibility; (2) unpacking sharpened that the render-boundary frame is correct but incomplete, with the protocol-triangle frame as the complete argument; (3) three Operator decisions selected the filing shape (investigation plus queued direction; both internal and external documents; both frames carried with render-boundary as simpler story and protocol-triangle as deeper reality). The architecture had been instantiating the principle in multiple places; the recognition was that the principle deserves naming so future builds attach to it rather than reinvent the discipline.
This section holds queued directions whose subject is the Operator Layer's authentication surface — /signin, /auth, account recovery flows, credential management, and adjacent identity-contract-alignment work. Authentication surface is a discrete subsystem with its own evolving entries, distinct from the engagement creation arc (Section 1) and from the substrate's rendering or upload subsystems. Entries here name the present-state gaps between the seed v0.9's authentication commitments and the live surface, so the intermediate states are visible discipline rather than silent drift.
/signin surface email-field gap
Trigger. Any work that touches /signin surface composition; the authentication flow on the Operator Layer; identity-contract alignment between the engine and the OL surface; interpretation of the v0.9 seed's "Sign-in never requests email" commitment; account-recovery flow design (which must not use email-based reset); WebAuthn discoverable-credential edge cases (multiple registered passkeys, never-registered device, alternative entry paths).
Substance. The Loomworks engagement seed v0.9 (candidate-seeds/loomworks/loomworks-candidate-seed-v0_9.md, committed 2026-05-26) and the discipline-mechanism project-instructions v0.3 (operations/discipline-mechanisms/project-instructions-loomworks-seed-reference-v0_3.md, same commit) carry the standing rule:
> "Email and mobile are not identity. They are user-maintained communication attributes. Identity is the system-assigned UUID; authentication is by credentials the user controls (passkey, authenticator code, organizational SSO). Sign-in never requests email; sign-in never keys lookup by email; recovery never uses email-based reset."
Strict reading: no email field on /signin at all.
The current Operator Layer /signin surface (post the Phase 57 cycle-1 Sub-arc 4 amendment merged into main at the Decision 4 cherry-pick merge — commit subject "Phase 57 Operator Layer (CR-2026-090 v0.2 §5 Sub-arc 4 / Step 2a): OL signin alignment with engine identity contract") presents an input labeled "Email (optional)" with helper text "Leave blank to sign in with any saved passkey." The engine side (/auth/login/begin) accepts an empty body and runs the WebAuthn discoverable-credential path; the OL form conditions the POST body to omit the email field when empty. Identity is not derived from email at any layer. But the field is still on the surface.
The surface is closer to the seed than the prior empty-email-guard state (Phase 57 cycle-1 moved it from email-required to email-optional) but does not yet match the seed's strict commitment (the field is still present as a passkey hint, not absent). The gap is acknowledged and named here; surface-reach-completion is queued for a future phase.
Current state. Intermediate. Engine side honors WebAuthn discoverable credentials with no email requirement at the data-model level (LoginBeginRequest.email: str | None = None; identity lookup is by credential_id at /auth/login/complete). OL side presents the field as an optional passkey hint at src/app/signin/components/IdentifierStep.tsx. Trajectory has been toward no-email-as-identity across Phase 47 → 48 → 57; Phase 57 paused at cycle 3 before the full surface redesign landed (cycle 3's Sub-arc 6 work — response-shape engagement on /operator/create-engagement — was deliberately excluded from the Decision 4 cherry-pick, and there is no Phase 57 sub-arc that scoped removing the email field from /signin entirely).
The full no-email-field surface requires real surface work, not operational hygiene: different first-screen composition (passkey-discovery as the primary entry, no input field); Operator-facing affordance for discoverable-credential edge cases (multiple registered passkeys on the same device, never-registered device, alternative entry paths for new accounts); an account-recovery path that doesn't use email-based reset. None of those are scoped in any current phase; all are queued.
Trajectory worth preserving. At 2026-05-27, the operational-hygiene cycle's Decision 4 surfaced this gap via the discipline mechanism — specifically the project-instructions v0.3 rule "When the proposed work appears to conflict with what the seed commits to, do not proceed silently. Raise the concern to the Operator in plain English before proceeding. Name what the seed commits to. Name what the proposed work appears to do. Name where the apparent conflict sits." Four paths were considered:
/signin without an email field, with passkey-discovery as the primary entry path. Rejected — full surface redesign is a substrate phase, not an operational-hygiene task; the substrate work to make discoverable-credential flow the primary surface (rather than the optional path) requires multiple Operator-facing decisions (edge-case affordances, recovery flow without email, never-registered-device fallback) that the operational-hygiene cycle is not the right venue to resolve./signin at its main-branch pre-cherry-pick state (empty-email-required guard still present). Rejected — main's pre-cherry-pick /signin is further from the seed than the cherry-picked surface (empty-email-required contradicts the seed more strongly than email-as-optional does); reverting toward main would move backwards, not forwards.The cherry-pick merge commit on the Operator Layer's main carries the six commits forward; this queued-direction entry carries the acknowledgement forward. The two land together as one decision cluster — the queued-direction is what makes the intermediate state visible discipline rather than silent drift.
Trigger. Any work touching authentication, the /signin surface, WebAuthn registration, dev-vs-production environment configuration, or interpretation of the v0.9 seed's "Sign-in never requests email" commitment.
Substance. Two findings surfaced during 2026-05-27 sign-in testing (the first activation of the discipline-mechanism-driven testing arc following Decision 4's cherry-pick merge):
(1) WEBAUTHN_RP_ORIGIN config drift. The engine's webauthn_rp_origin config default at src/loomworks/config.py:38 is http://localhost:3000, but the OL dev server runs on :3001 (per the OL repo's package.json dev script). The mismatch produced a 401 at POST /auth/login/complete because py_webauthn's verify_authentication_response (called from src/loomworks/persons/webauthn.py:207 with expected_origin=config.rp_origin) rejects assertions whose clientDataJSON.origin doesn't match the configured value. Fixed at 2026-05-27 by adding WEBAUTHN_RP_ORIGIN=http://localhost:3001 to /Users/dunin7/loomworks-engine/.env. The class default in source remains :3000; either update the default or add the override to a checked-in dev-env reference document so future fresh-checkouts don't reproduce the drift.
(2) Operator's WebAuthn credential row is a fixture, not a real registration. Marvin Percival's row in webauthn_credentials (id 585f1134-6311-4429-b326-6550b7bef5e3, credential_id hex 6311603229c178d5aa52439084912b8a, 16 bytes, sign_count 0, created 2026-04-26 11:52:46 EDT) is an outlier against the table's 36 other rows (all 32-byte credential_ids, sign_count ≥ 1 — real WebAuthn registrations that have been used). No source-code provenance for the specific row id; the credential was inserted by a fixture / manual seed, not by a real registration ceremony. A real Touch ID assertion from the Operator's device will carry a different credential_id (the device-bound passkey's actual id) and the engine's lookup will return CredentialNotRegistered → 401. The /signin → PasskeyStep flow is therefore broken end-to-end on this dev environment until either (a) a real passkey is registered for Marvin's Person row against the dev RP-ID, or (b) the fixture row is replaced with a real-registration row. To proceed with testing in the interim, the Operator uses the /auth dev shortcut (POST /auth/dev/issue-session with the Person ID 6d867b23-655a-440a-b377-e6bf4fb3882b, which mints a session cookie bypassing WebAuthn + TOTP per src/loomworks/api/routers/auth_dev.py:40-86).
Two further config-drift instances surfaced during 2026-05-27 upload-pathway testing, confirming this is a pattern rather than a single knob. (1) OBJECT_STORE_ACCESS_KEY and OBJECT_STORE_SECRET_KEY default to empty strings at src/loomworks/config.py:60-61; .env carried no override; the MinIO client constructed with empty credentials makes anonymous requests, which MinIO denies. Fixed by appending both keys to .env (minioadmin/minioadmin for local dev). (2) The pre-existing failing test test_phase_48_lifecycle_evaluator::test_compose_reactivate_url_uses_rp_origin asserts against RP origin port 3000 while the dev environment runs on 3001 — the same WEBAUTHN_RP_ORIGIN drift surfacing in the test suite. All three drifts share one shape: the source-code defaults reflect an older dev environment (MinIO-absent, port-3000), the corrections live only in .env, and a fresh checkout reproduces every drift because nothing is checked in. The standing remediation: either update the source defaults to match the current dev environment, or check in a dev-environment reference document (a .env.example or a docs/dev-environment.md) that names every override a fresh checkout needs. Until then, every fresh clone reproduces the passkey-origin, object-store-credential, and RP-origin-test drifts.
Resolved 2026-05-28 (config-drift half only). The standing remediation landed in checked-in form. .env.example was updated to carry the current dev-environment reference — LOOMWORKS_ENV=development, WEBAUTHN_RP_ORIGIN=http://localhost:3001, and OBJECT_STORE_ACCESS_KEY/OBJECT_STORE_SECRET_KEY=minioadmin, with REPLACE_ME placeholders for the two real secrets — so a fresh checkout runs cp .env.example .env and is configured (engine commit b793aef). The RP-origin test (test_compose_reactivate_url_uses_rp_origin) was decoupled from the ambient .env by monkeypatching the setting to a fixed value, so it is deterministic regardless of what the dev environment sets (engine commit 427c446). Both are on origin/main. The source-code defaults are intentionally left unchanged: :3000 for the RP origin (production supplies the real origin via env) and empty strings for the object-store credentials (so source never carries credential-shaped values and fails closed rather than silently). The decision was to make the correct values visible in a checked-in reference rather than bake them into source. This closes the config-drift half of §13.2. The credential-fixture half is promoted to its own entry §13.3 below.
Current state. The config-drift half is resolved in checked-in form as of 2026-05-28 (see the resolution note above). The credential-fixture half is promoted to its own first-class entry §13.3 as of 2026-05-28 and tracked forward there; it remains open — the Operator's webauthn_credentials row is still a 16-byte fixture, so the production passkey path against localhost:3001 is still broken end-to-end, and dev sign-in remains on the /auth dev shortcut. Testing the "Sign-in never requests email" commitment (v0.9 seed §Authentication framework) end-to-end is blocked on §13.3.
Trajectory worth preserving. At 2026-05-27, sign-in testing began against the Decision 4 cherry-pick which (i) fixed three /signin production bugs (api-helper redirect, AppShell nav-hidden, mount-time probes) and (ii) landed the Phase 57 Sub-arc 4 intermediate "Email (optional)" state. The test surfaced two underlying authentication-path gaps that the cherry-pick was not designed to address — the cherry-pick was a surface-level fix; the engine-level passkey path requires separate work. The surface-level cherry-pick was successful in its scope; the engine-level passkey gap is a separate class of work. Filed during the first activation of the discipline-mechanism-driven testing arc — the seed-reference discipline (v0.9 seed + v0.3 discipline-mechanism documents) and the operational-hygiene cycle's branch cleanup both landed on 2026-05-27; sign-in testing was the immediate next step after both lands, and surfacing these two gaps within hours of those landings is the kind of finding the discipline mechanism was designed to make visible. Two paths considered at disposition: Path A (fix config + register passkey) — substantial engine work; not in scope for an operational-hygiene cycle. Path B (use /auth dev shortcut, file gap, defer) — selected; preserves testing momentum while making the underlying gap visible.
Trigger. Any work touching the dev passkey sign-in path, WebAuthn registration ceremonies against the dev environment, or end-to-end testing of the "Sign-in never requests email" commitment (v0.9 seed §Authentication framework).
Substance. Carried forward from §13.2's credential-fixture finding (filed 2026-05-27, promoted to its own entry 2026-05-28). The Operator's webauthn_credentials row (id 585f1134-6311-4429-b326-6550b7bef5e3, credential_id hex 6311603229c178d5aa52439084912b8a, 16 bytes, sign_count 0) is a fixture, not a real registration — an outlier against the table's 36 real 32-byte rows. A real Touch ID assertion from the Operator's device carries a different credential_id, so the engine lookup returns CredentialNotRegistered → 401 at POST /auth/login/complete. The /signin → PasskeyStep flow is therefore broken end-to-end on the dev environment. Dev sign-in runs through the /auth dev shortcut (POST /auth/dev/issue-session, Person ID 6d867b23-655a-440a-b377-e6bf4fb3882b) in the interim.
What resolving it requires — two halves. (1) Engine-prep half (buildable by Claude Code): verify the WebAuthn registration ceremony functions against the dev RP-ID on localhost:3001 — the registration endpoint, the RP-ID configuration, the challenge/response round-trip — and decide between registering a new credential for the Operator's Person row versus replacing the fixture row. This half can be scoped as a phase and built. (2) Ceremony half (Operator's own action): the actual registration is a Touch ID interaction on the Operator's own device. A passkey is a credential the Operator controls; it cannot be performed by Claude Code. The ceremony half is the Operator's action against a working registration surface produced by the engine-prep half.
Status. Open. Not yet sequenced into a build phase. Unaffected by the §13.2 config-drift remediation; it remains the blocker on testing the passkey path end-to-end.
This section holds queued directions whose subject is work authored in the original loomworks-ui repo before the 2026-05-06 Workshop → Operator Layer rename (per CR-2026-060). The rename moved Operator-Layer development to a fresh repository at DUNIN7/loomworks (per memory: "namespace freed for Phase 46 Operator-frontend"); the pre-rename loomworks-ui repo became the Workshop and has been dormant since. Work that lives on Workshop branches and was not merged or migrated at rename time creates carry-forward questions: whether the work should land in the post-rename Operator Layer's equivalent surface, and under what phase scope, given that the substrate the work assumed may have evolved.
Entries here are surfaced when operational-hygiene cycles uncover unmerged Workshop work whose disposition is non-mechanical.
Trigger. Any conversation about the Operator Layer's assertion-display surface; the provenance line on assertion cards; held-assertion editing affordances; EXIF GPS surfacing; or any question about whether work that lives on the pre-rename loomworks-ui repo should be carried forward to the post-rename Operator Layer.
Substance. Three commits on the loomworks-ui phase-16-memory-contribution-ui branch were authored on 2026-04-27 after the original phase-16-memory-contribution-ui tag was applied. The commits add real assertion-rendering capability that the tagged Phase 16 close did not include:
59d4e67 — Phase 16: surface assertion display number on the provenance line. 14 insertions in AssertionCard.tsx + api.ts.7e5f4ef — Phase 16: surface EXIF GPS in the assertion provenance line. 29 insertions in AssertionCard.tsx + api.ts.790793a — Phase 16 fix: held assertion content is editable in place. 213 insertions across AssertionCard.tsx, HeldAssertionCard.tsx, api.ts, and a new revise route at /engagements/[id]/assertions/[aid]/revise/route.ts.
256 total insertions; not docs-only; real assertion-rendering UI work. The work was authored before the 2026-05-06 Workshop → Operator Layer rename and lives in the pre-rename loomworks-ui repo. The post-rename Operator Layer at DUNIN7/loomworks has its own assertion-display surfaces (built from Phase 46 onward); whether these three followup commits should be carried forward to the post-rename surface — and if so, under what phase scope — is the deferred decision.
Current state. Preserved by an annotated tag phase-16-followup-2026-04-27 at branch HEAD 59d4e67 in loomworks-ui. The local phase-16-memory-contribution-ui branch was deleted on 2026-05-27 as part of the operational-hygiene cycle's residue disposition. The work is recoverable from the tag at any future point. Carry-forward to the post-rename Operator Layer is deferred — no current phase scopes it; no Operator decision has been made on whether the post-rename assertion-display surfaces should adopt these three capabilities. The trigger for revisiting is either: (a) a future Operator Layer phase that touches assertion-display surface composition and the question of whether these followup capabilities should land surfaces; (b) an Operator-side observation that one of these capabilities is missing from the post-rename surface and worth bringing forward; (c) a substrate decision that ends up requiring assertion-display surface rework, at which point the followup work is a candidate input.
Trajectory worth preserving. At Phase 16 close on loomworks-ui (the original Workshop), the canonical work was tagged; the followup commits then landed on the branch but were never merged or re-tagged. The 2026-05-06 namespace rename then moved Operator Layer development away from loomworks-ui, leaving the pre-rename Workshop dormant with these three commits in a not-merged-but-not-lost limbo. The operational-hygiene cycle of 2026-05-27 surfaced this during the cleanup pass: the existing phase-16-memory-contribution-ui tag did not cover the followup commits (it points at the pre-followup state); deleting the branch without first preserving the followup work would have lost it. The two paths considered at disposition:
phase-16-followup-2026-04-27 at branch HEAD; push tag to origin; force-delete the branch. Preserves the work behind an explicit pre-rename Workshop tag; the disposition decision (whether to carry forward) is deferred to a future moment when the question is in scope.phase-16-memory-contribution-ui tag to point at branch HEAD instead of the original Phase 16 close commit. Rejected — would rewrite the original phase-16 tag's commit pointer, breaking the "tag at close" discipline and making the existing tag mean something different from what it historically meant.
The Path A choice preserves both the original phase-16-at-close state (existing tag, unchanged) and the followup work (new phase-16-followup-2026-04-27 tag). Two tags for two distinct states. This is the same pattern as the engine's phase-57-paused-2026-05-13 tag (Decision 2 of the same operational-hygiene cycle) — when work surfaces that didn't fit a phase's existing tag, a new dated tag preserves it for future disposition.
This section holds queued directions whose subject is a gap in the Operator's reachable path for populating Memory — uploads, conversation contributions outside the chat surface, mobile quick-capture, voice contribution to Memory, and any other affordance the Operator uses to write into Memory (distinct from reading or navigating it). Memory-population gaps sit on the contribution affordance axis: the work the affordance does may be fully shipped at the component, contract, and engine layers — but the Operator can't reach it. These gaps are structurally distinct from authentication gaps (Section 13, where the gap is on the access axis) and from rendering gaps (Section 3, where the gap is on the output axis).
Trigger. Any work touching /chat route disposition, /operator/engagement/[engagement_address] composer composition, ChatView vs CenterPane composer composition, Phase 58 upload pathway, the two-icon paperclip+folder affordance, or interpretation of the architecture spec v0.4 §13 "Memory population surface unification" framing.
Substance. This entry supersedes the v0.16 framing, which incorrectly described the gap as "the upload affordance exists at the component level, blocked only by the surface-mount gap." The corrected picture: the upload affordance was operator-reachable, used, and working on 2026-05-14 at the route /chat?project=<engagement_id>. Phase 58 v0.4 specified two icons at the composer's left edge — an attachment icon (paperclip) and a folder-picker icon adjacent to it — both opening native OS pickers; Phase 58 v0.5 specified auto-upload-with-pre-typed-purpose-context interaction. The Operator verified the affordance working that day ("Buttons are there"; both pickers fire; CR §7 compliance live). The full pathway — paperclip click → file picker → multi-file selection → engine detection registry interrogates file types → seven-skill pipeline (pdf_extraction, image_metadata, image_ocr, image_vision_analysis, audio_transcription, plus auxiliaries) → the UploadEventReceived event with inline content written to Memory (event grain, not Assertion objects — see §15.3) → UploadResultCard rendering — was operational.
On 2026-05-19, commit 2716cc6 (in-engagement surface fill-in CR §C) made /chat a server-side redirect. Routes that previously rendered ChatView with projectId populated from the URL now redirect to /operator/engagement/<engagement_address>. The redirect target mounts CenterPane (a hand-rolled composer), not ChatView. CenterPane renders a deliberately disabled ⊕ placeholder per its own fill-in scope ("Attachments coming soon"). The redirect did not preserve, port, or migrate the working upload affordance; the affordance still exists in the codebase (UploadAttachmentButton + ChatView at line 607 gated on projectId) but no operator-reachable route mounts it with a projectId.
Three sequenced actions land in response:
First (immediate, operational, this entry's resolution): restore /chat?project=<engagement_id> as a non-redirecting route alongside /operator/engagement/<engagement_address>. The Phase 58 ChatView surface with the two-icon affordance becomes reachable again. /chat without a project parameter continues to redirect to /operator/engagement-navigation per the in-engagement surface CR's intent. The in-engagement surface remains unchanged. Two surfaces co-exist: /chat?project=<id> for upload-pathway work; /operator/engagement/<address> for conversation work without uploads. Acknowledged-as-intermediate state. (Resolved 2026-05-27: the /chat?project=<id> route was restored on OL main at commit 2186d13; the Phase 58 two-icon upload affordance is operator-reachable again. The upload pathway was then verified working end-to-end — single-file, folder, and multi-file uploads all route through the engine detection registry to the text-extraction skill and render per-file UploadResultCards — after the dev-environment config drifts and the upload-handler transaction bug were cleared. The Second and Third sequenced actions, the ChatView→CenterPane port and the route-redisposition methodology candidate, remain open.)
Second (queued, substrate-phase work): port the upload affordance from ChatView onto CenterPane (or refactor CenterPane to reuse ChatView's composer components). This is the architectural-intent destination — files brought in through the in-engagement composer rather than through a separate surface. Substantive scoping required; not operational hygiene. (Resolved 2026-05-29: the composer upload port shipped on Operator Layer at tag composer-upload-port-v0_1 (commits d67173c through c2ca4db), built as Shape 2 — a shared useEngagementUpload hook consumed by both ChatView and CenterPane, with CenterPane draft persistence added in the same arc — and verified live on both surfaces. The architectural-intent destination is reached: files are now brought in through the in-engagement composer itself, the disabled ⊕ placeholder removed.)
Third (queued, methodology candidate for v0.21 consolidation): the route-redisposition methodology candidate. When a CR changes how an existing route resolves (redirect, mount-different-component, or absorb-into-different-surface), surface-reachability of affordances dependent on the old route should be explicitly verified — either preserved, migrated, or named as deferred — before the CR closes. Phase 58 shipped the upload affordance correctly per its own scope; the in-engagement surface fill-in CR redirected /chat correctly per its own scope; neither CR had responsibility for surface-reachability across the boundary. Worth filing for v0.21 absorption as a sharpening of the existing "correct-in-isolation commits combining into surface-level gap" pattern this entry's prior version named.
Current state. The immediate action restores operator-reachability for the upload affordance. The proper port remains queued as Memory-population-surface-unification work — the architecture spec v0.4 §13's open question, sharpened with the now-known concrete fix-shapes: (a) extend CenterPane's hand-rolled composer with the upload affordance; (b) refactor CenterPane to reuse ChatView's composer components; (c) maintain both surfaces indefinitely if dual-purpose intent justifies it.
Trajectory worth preserving. At 2026-05-27, the discipline-mechanism-driven testing arc surfaced absent upload affordance on the in-engagement surface. Initial finding (v0.16, this morning) framed the gap as "no surface mounts upload" — empirically narrow on five inspected routes but missing the historical reachability via /chat?project=<id>. Operator memory ("I have used this; the icons existed adjacent to the text field") prompted conversation_search across project chat history, surfacing the 2026-05-14 acceptance-gate session where the Operator verified the affordance live. Discipline mechanism's drift-surface rule (project-instructions v0.3 §"4. Drift-surface rule") caught the propagation when Claude.ai propagated CC's "no upload exists" without verifying against historical use. The v0.16 entry's substance was filed before that verification. v0.17 supersedes per the discovery-trajectory-preservation discipline (corrections-and-supersessions-as-Memory-pattern); v0.16 remains in the archive as the corrected position.
Trigger. Any work touching upload-handler tests, dependency-override fixtures in the engine test suite, session/transaction management in API handlers, or interpretation of a green test suite as evidence a substrate path works end-to-end.
Substance. During 2026-05-27 upload-pathway testing, the upload handler at src/loomworks/api/routers/uploads.py was found to crash in production with sqlalchemy.exc.InvalidRequestError ("A transaction is already begun on this Session") at two sites using async with db.begin(). The root cause: get_db_session (src/loomworks/api/deps.py) yields a session whose transaction is autobegun by SQLAlchemy 2.0 on the first DB operation, then committed or rolled back by the dependency's envelope at request end. The explicit async with db.begin() in the handler attempted to open a second transaction on the already-autobegun session, which SQLAlchemy refuses. The upload handler was the only handler in the entire src/loomworks/api/ tree using this pattern; every other handler trusts the get_db_session envelope. The fix removed the two redundant begin() blocks (engine main commit 040d675).
The finding that matters beyond the bug: the upload tests were green on main while production was broken. The test override (_override_db_session in five upload-test files) yielded a session with NO commit/rollback envelope — so the tests relied on the handler's explicit begin() to commit the upload event mid-request. The redundant begin() the production code didn't need was exactly what made the tests pass. The tests never exercised the production transaction path; they exercised a path that exists only when the redundant begin() is present. Removing the begin() to fix production broke five tests, which then required the test overrides to gain the production-mirroring envelope (try/yield/commit/except/rollback) so they verify the actual production behavior. After the fix, the tests verify the real path; before it, they verified the bug.
Current state. The specific bug is fixed (engine main 040d675). The queued audit has now been executed (2026-05-28): every app.dependency_overrides[get_db_session] across the engine test suite was found and classified against the production envelope. It surfaced three override sites beyond the six already-fixed upload-test fixtures. Two were missed siblings of the original five — test_phase_59_upload_streaming.py and test_phase_59_object_store_wiring.py, same upload endpoint, missed only because their assertions do not read substrate state back — and were brought to the production envelope (engine commit d5d57ee, on origin/main); all eight upload-test override fixtures now carry the identical try/yield/commit/except/rollback shape. Two were deliberately left unchanged: tests/test_auth_dev.py (the /auth/dev/issue-session handler does no transaction-primitive work, so the envelope-less override cannot admit the bug class), and the central tests/conftest.py api_client fixture (see the design-choice note below). The narrow audit is closed; one structural item remains, recorded next.
Open structural item — the suite-wide conftest fixture (v0.21 methodology candidate). The tests/conftest.py api_client fixture overrides get_db_session with a yield-only session carrying no commit/rollback envelope, and roughly 85 test files inherit it. This is the same structural shape that hid the upload-handler bug — a test fixture that does not mirror the production envelope — but it is not currently hiding any active bug: the audit confirmed no handler other than the (already-fixed) upload handler uses an explicit-transaction pattern, so no handler depends on the divergence to pass. It was left unchanged deliberately, not overlooked: mechanically applying the production envelope would commit each request's writes between a test's setup and its assertion, breaking the large fraction of those 85 tests that assert against same-session reads of uncommitted writes. The divergence is therefore load-bearing for the current test design. The methodology candidate for the v0.21 consolidation: a suite-wide override fixture that diverges from the production envelope is a standing bug-hiding surface even when no bug is currently present; the remediation is not a mechanical envelope change but a finer instrument — per-test envelope opt-in, or commit-on-clean-yield paired with a lint that flags any handler reintroducing an explicit-transaction pattern. This sits alongside the route-redisposition methodology candidate (§15.1) as a "structural-condition-that-will-hide-the-next-bug" finding headed to the same v0.21 pass.
Trajectory. The bug had existed since the explicit begin() was written (Phase 58/59 upload work, mid-May). It was invisible because the Operator's 2026-05-14 verification was UI-level (icons render, pickers fire) and never exercised the substrate path, and because the test suite was green. The bug surfaced only on 2026-05-27 when the upload affordance became operator-reachable again (after the /chat?project= route restoration, OL 2186d13) and the Operator uploaded a real file through the live engine + MinIO + browser stack — the first true end-to-end exercise of the pathway. Three cascading infrastructure findings preceded it in the same session (WEBAUTHN_RP_ORIGIN drift, object-store credential drift, MinIO not running), each masking the next; the transaction bug was the final layer, reachable only once the prior three were cleared. Filed during the first sustained activation of the discipline-mechanism-driven testing arc.
Trigger. Any work touching the upload handler's Memory write, the UploadEventReceived event, the assertions_drafted field, the manual-content fallback (ManualContentContributed), Manifestation queries that compose assertions, the held-to-committed assertion lifecycle as it applies to upload-contributed content, or interpretation of the architecture spec v0.4 §"Provenance — where assertions come from."
Substance. The upload handler (src/loomworks/api/routers/uploads.py, operator_upload at line 300) writes each uploaded file into engagement Memory as a typed UploadEventReceived MemoryObject carrying full provenance — contributor (operator_initiator), channel (file via the upload route), receipt timestamp (upload_moment), content hash, filename, size, content-type, and the transformation chain that touched the bytes (selected_chain). The seed's "Memory accumulates with provenance" commitment is satisfied at the event grain. The extracted text lives inline on the event as transformed_content_inline.
What is not done: assertions_drafted is hardcoded [] at uploads.py:520. The field is typed list[UUID], intended to hold the ids of held Assertions drafted from the upload (per the UploadEventReceived docstring at upload_event.py:136-138, and the executor docstring at executor.py:476, which advertises "the upload endpoint reads the result to construct the UploadEventReceived MemoryObject + draft held assertions"). The second half — drafting held Assertions — is unimplemented. A grep across src/ for any consumer of UploadEventReceived that produces Assertion MemoryObjects returns none: no evaluator, no scheduled task, no promoter. The same gap holds for the manual-content fallback.
The structural consequence: upload content is searchable Memory and provenance-attributable, but it does not exist at the assertion grain the rest of the Memory pipeline operates on. The held-to-committed assertion lifecycle, individual assertion addressability (spec §"Addressable assertions at the surface"), and Manifestation queries that compose multiple Assertions all operate on Assertion objects (src/loomworks/engagement/types.py:199). Upload content sits alongside that surface, not within it. An Operator cannot affirm, correct, or compose an individual claim extracted from an uploaded file the way they can a claim contributed through conversation.
This is present on the path ChatView uses today; it is not introduced by item 3 (the ChatView-to-CenterPane composer-upload port, §15.1 second action) and is not a regression of any frontend shape. Item 3 mounts the affordance; it does not change what the engine does with the bytes. The gap is independent of item 3 and does not gate it.
Two documentation corrections, independently timed from the engine work above. (1) The architecture spec v0.4 §13 "Memory population surface unification" says the upload "engine side not yet shipped." That is stale — the event-writing engine side is shipped and verified end-to-end (§15.1 resolution note, 2026-05-27). The precise picture the spec should carry at v0.5: the event-path engine side is shipped; assertion-drafting from upload events is the part not yet built. (2) §15.1's own Substance describes the pathway as "assertions written to Memory" — the same imprecision; what is written is the UploadEventReceived event with inline content, not Assertion objects. Both should be corrected to the event-grain framing at next revision, regardless of when the engine work below is scheduled, because the current text is wrong now.
Status. Open. Not yet sequenced into a build phase. A real engine work item — draft held Assertions from UploadEventReceived events, carrying provenance from event to assertion — distinct from item 3's frontend port. The two documentation corrections are independent fixes to make at spec v0.4-to-v0.5 and at the next queued-directions revision, not gated on the engine work.
Trajectory. Surfaced 2026-05-28 during item 3 scoping. The item 3 precondition check — does upload write Memory with provenance, or only store blobs — was raised as a possible blocker on the composer-upload port. The engine trace retired the blocker (Memory write with provenance confirmed) but surfaced this adjacent gap: the write lands at event grain, not assertion grain. The two were distinguished so the port could proceed (precondition met) while the assertion-grain gap was filed rather than folded into the port's scope. Filed as a first-class entry rather than an out-of-scope note in the item-3 scoping document, per the standing concern that folded-and-deferred findings get forgotten.
This section reconciles the record with the actual Phase-60 post-close state. The personal-memory diagnostic and its remediation bundles lived only in the engine repo, never the record; meanwhile a substantial fraction of the remediation shipped to main without the record's open-items framing (manifest §4.D / §5; §15 here, which tracked only the upload lineage) reflecting it. This section brings the record into agreement with what shipped and what remains. It is the basis the Axis 11 scoping note is drafted against.
Source. A pair-document in the engine repo (not the record): docs/phase-impl-notes/phase-60-post-close-diagnostic-personal-memory-persistence-v0_1.md (the technical findings record, 11-axis investigation) and …-v0_2.md (the §A–§I remedy-detail addendum), both committed at engine a4af087. It packages remediation into "Bundle 1–5" terminology (§4.3 / §F) — which is why a record search for "remediation bundle" finds nothing. The filename carries a phase-60-* prefix but the document is explicit that it is not a Phase 60 close artefact — it is post-close diagnostic work that drove the Phase-60-recovery cycle.
The label is overloaded — three distinct bodies of work share "Phase 60":
tune_setting handler).phase-60-…-upload-pathway-v1 branch name — a separate lineage (manifest Entry 101 correction), tracked in §15 of this document.The Phase-60-recovery cycle executed the diagnostic's "Bundle 1-equivalent" (persistence reliability + recovery) and landed in main — verified by git ancestry on current main, not assumed:
remember_about_me cascade fixed (engine main 2534657): Bug A (router equality check too strict against classifier-normalized text — raw "Nov 1" held vs normalized "November 1." extracted → refinement-not-commit, router.py:1472); Bug B (responder LLM emits committed-copy "Got it, I'll remember that." for action=refined, masking Bug A); Bug C (held-state single-slot overwrite-by-next-fact — the silent data-loss vector). Fixed via classifier-normalization tolerance + responder-prompt discipline + refuse-overwrite single-slot (shape β).3ea048a): Shane (orphan held → committed) + Luke + Haven re-created via event-log replay — the raw memory_events table preserves prior versions of revised assertions (v0.2 §H materially corrects v0.1's "unrecoverable" framing; what was gone from the current view survived in the event log).81354b3) — the end-to-end test that would have caught the 2026-05-13 loss.db58ef0): /chat now defaults to the LOOMWORKS commons when the URL carries no ?project=, addressing the §2.4 side-observation (personal memory was invisible in project-less converse because the converse.py:594-603 guard short-circuits on project_id=None).voice-listening-v0_1, silence-submit, recognizer E-prefix, voice-provenance) added it via Web Speech dictation, a different mechanism than the MediaRecorder→/seed/converse/transcribe port the diagnostic's §D specified, but the "OL has no voice input" gap is closed.From the diagnostic's deferred bundles (2 / 3 / 5):
VIEWPORT_FRACTION_CAP=0.4 (MessageTextarea.tsx) dominates at viewports ≤ ~1090px, yielding fewer than the spec'd ~20 rows; raise to 0.5/0.6 (small). Diagnostic §C / Bundle 2.limit=50 once on mount with no follow-up pagination, no summarization, no time-windowing, and no within-engagement segmentation; the composer is pinned to end-of-content (page-level scroll via a min-h-full flex chain), not end-of-viewport, so after ~50 turns it sits below the fold. Fix shapes (diagnostic §E): (a) composer sticky-pin + min-height:0 flex fix; (b) client pagination via the existing before-cursor / has_more; (c) older-turn summarization; (d) time-windowing UI; (e) within-engagement room-segmentation. This is the item queued for scoping next.action=committed. Diagnostic §4.1 / Bundle 5 — the deepest memory-experience item.
Trigger. Any work on the Operator's chat surface at scale (composer reachability, conversation pagination, long-history UX); composer height/multi-paragraph composition; the remember_about_me held-to-committed lifecycle or a held-assertion surface; or any revisit of the engine-repo Phase-60 post-close diagnostic. Status. Persistence (Bundle 1) + Axis 10 shipped; Axis 9, Axis 11, and the held-state architecture question open and unsequenced.
A few things worth being explicit about, so this file's scope is clear:
current-status-manifest-vN_M.md), not this file's. This file holds queued futures; the manifest holds active present.what-dunin7-is-building-vN_M.md's job.This file is for: queued directions that will be reached for someday and shouldn't be lost in the meantime; deferred work whose preconditions haven't been met; and explicit trajectory preservation for cases (like 4.3, 5.1/5.2, 6.1/6.2, 7.1/7.2, 8.1, 9.1/9.2, 10.1/10.2/10.3, 11.1/11.2/11.3/11.5, and 12) where the path that got us here matters as much as the destination.
v0.1 (2026-05-04). Initial consolidation. Sections 1–4. Memory archive consolidation supersedes prior memory edits #1, #18, #19, #20, #21, #22, #23 (and absorbs the obsolete #16).
v0.2 (2026-05-07). Adds Section 5 (Agent capability development):
v0.3 (2026-05-09). Adds Section 6 (Mobile presence and quick-capture engagement pair):
companion_name), tap-to-speak surfaces (Lock Screen widget, home-screen widget, watch complication), non-voice (share sheet, keyboard shortcut, typed quick-capture), conversational chat. Methodology-finding-grade observation: mobile is an Operator Layer surface, not a forked substrate — federation through shared substrate APIs; per-surface UX optimization; Companion-name authority unified. Two trajectory notes preserved: the "Siri-equivalence" → "compose surfaces" reframing, and the watch-complication-as-highest-value-form-factor observation.loomworks-quick-capture-engagement-investigation-v0_2.md and loomworks-mobile-presence-investigation-v0_1.md.v0.4 (2026-05-09). Adds Section 7 (Multi-instance fleet and jurisdiction governance) absorbing the substance of two memory edits (multi-instance fleet via DevOps engagements; protocol triangle for jurisdiction governance) into a discoverable section paired with their source documents. Two entries:
loomworks-deployment-strategy-v0_2.md, loomworks-hosting-cost-analysis-v0_1.md, loomworks-white-label-multilanguage-analysis-v0_1.md.v0.5 (2026-05-09). Adds Section 8 (External information seams) capturing two entries from a chat session in which the github.com/public-apis catalog was flagged as a future-useful resource and the Operator's follow-up reframe sharpened it into a load-bearing architectural move. Two entries:
v0.6 (2026-05-10). Adds Section 9 (Companion ambient context) capturing the Operator's recognition that the Companion should maintain standing awareness of the Operator's current state and relevant environment — meaningfully more powerful than Siri-class voice assistants. One entry across three subsections:
v0.7 (2026-05-10). Adds Section 10 (The standing Companion) capturing the architectural construct that subsumes Section 9 and several other cross-engagement behaviors. Triggered by the Operator's question "is 'keep me in your thoughts and remember stuff for me; alert me to other Engagement's activity when appropriate' an Engagement?" The unpacking surfaced that what the Operator described isn't an engagement — it's the standing Companion, the Operator-bound mode of the Companion that runs continuously across all engagements. Five subsections:
v0.8 (2026-05-10). Adds Section 11 (Observer — cross-fleet usage observation engagement) capturing the Operator's recognition that Loomworks itself needs an observation layer to surface UX friction, token-use inefficiencies, methodology drift, and cross-Operator patterns. The Operator articulated the load-bearing privacy constraint at first framing: observation must be content-blind (substrate and methods, not engagement domains). The unpacking surfaced that the constraint must be enforced structurally rather than discretionally, and that Observer instantiates a new architectural category — meta-engagements, whose subject is the operation of other engagements. Five subsections:
v0.9 (2026-05-10). Adds Section 12 (Structural defensibility — cross-reference) as a discoverability pointer to two companion documents. The companion documents — loomworks-structural-defensibility-investigation-v0_1.md (methodology investigation, internal architectural recognition) and loomworks-structural-defensibility-positioning-v0_1.md (external positioning, audience-facing) — carry the substantive content; this section exists so future readers searching for "harm prevention," "AI safety," "render boundary," "regulatory positioning," or related terms find the cross-reference and follow it. Triggered by the Operator's recognition that the "illegal use" framing permeating AI discourse should be examined against Loomworks's architecture. The unpacking surfaced that Loomworks's defensibility is structural (rules-in-Memory plus upstream OVA enforcement plus FORAY attestation) rather than filtering-based (model-layer detection of harmful content) — a methodology principle that operates now rather than future work. The investigation document traces six instantiations already in the architecture (held-then-commit, approval-card pattern, OVA per-Operator credentials, FORAY append-only attestation, Section 11's content-vs-shape boundary, Section 7.2's jurisdiction-governance triangle); the positioning document carries the audience-facing version with the render-boundary frame as the simpler external story and the protocol-triangle frame as the deeper architectural reality. Three Operator decisions captured: investigation-plus-queued-direction filing shape; both internal and external audience documents; both render-boundary and protocol-triangle frames carried. Discoverability keywords extended (structural defensibility, structural vs filtering, illegal use, AI harm framing, render boundary, protocol triangle for harm prevention, rules in Memory, upstream enforcement, mechanical attestation, jailbreak resistance, considered work versus consequential commitment, architecturally impossible harms, detection as fallback, regulatory positioning, compliance investigation substrate). Provenance note updated. Trajectory-preservation cross-reference updated to include Section 12.
v0.10 (2026-05-11). Absorbs Phase 55 close (Engagement Creation Assistance — Conversational Surface). The engagement creation arc's product loop is now closed end-to-end via Phase 53 (substrate primitive) + Phase 54 (terminal commit symmetry) + Phase 55 (upstream conversational surface). This is a status-update + structural-extension bump rather than a new-section bump — Section 1's structure extends from 2 sub-entries to 4 sub-entries; Section 2's §2.2 advances from deferred to newly first-class actionable; no new top-level section is added. Changes:
/operator/create-engagement (Operator Layer; 12th prerendered route). Substrate: POST /me/engagements/create-from-conversation endpoint; EngagementCreatedFromAssistance Memory event class (FORAY-anchored at "standard" priority); three new IntentLabel literals; conversation turns stored in Phase 42's relational table per the V7 reshape's inheritance of Phase 42's cost decision. Two terminal-turn output paths: write-up-as-Discovery-record (consumes Phase 53's skill via Phase 16 upload pipeline) and commit-as-brief (uses _allocate_candidate_engagement helper plus draft_seed / induct_seed). Trajectory note extended with the methodology trace from Phase 55 V7: v0.1 → v0.2 reshape on storage-mechanism (Memory-event-for-turns → relational-for-turns, inheriting Phase 42's cost decision); preserved as the surfacing event for the now-named principle inherit prior-phase cost decisions (manifest v0.40 §2); Operator's two-question probe ("which scales?" / "how about cost?") carries to v0.21 as Operator-probe-as-correction-mechanism candidate; higher-level Option A held — third instance of substrate-evidence-can-re-rationalize-selection./engagements/{eid}/seed/extract plus Phase 55's Discovery-record output path (Companion-authored Markdown uploaded through Phase 16; same extraction skill). induct_seed production callers: 5 at Phase 55 close. Trajectory note extends with the bounded-contract-not-no-LLM crystallization (manifest v0.38 §2) holding under second-caller pressure.draft_engagement into engagement-allocation and Seed-drafting halves; add a raw-Markdown variant of extract_discovery_to_seed_skill). Both non-urgent; both would reduce the inline-replication count in the engagement-creation-arc orchestration layer. The halt-surface itself — first active firing of the CR-execution boundary of friction-discipline-pattern-family in production — is the load-bearing trajectory artifact, named in manifest v0.40 §2 as the first-firing event.ConverseRequest.intent_hint now derives from classifier.IntentLabel; parallel-enumeration cascade risk eliminated. No further v0.10 action — the candidate is delivered.EngagementCreatedFromAssistance, /me/engagements/create-from-conversation, /operator/create-engagement, mode banner, engagement creation arc product loop closed, multi-path unification verdict, Phase 31 deprecation candidate, Phase 53 deprecation candidate, halt-surface refactor residue, split-draft_engagement, raw-Markdown extract variant, Phase 32 first-class actionable, inherit prior-phase cost decisions, Operator-probe-as-correction-mechanism, build-time enumeration aperture, build-close hygiene branch deletion, tag style annotated).v0.11 (2026-05-12). Absorbs Phase 56 close (Engagement Creation Surface — Voice Work). Phase 56 voice-tuned the conversational engagement creation surface Phase 55 shipped. This is a status-update + structural-extension bump (Section 1's §1.1 status extended in place; Section 6 grows from 3 sub-entries to 4 sub-entries; Section 2's §2.2 status extended in place); no new top-level section is added. Changes:
load_per_field_components loader + dispatcher splice at prompt.py:817 plus matcher token-set extension at router.py plus persona-transcript calibration discipline at tests/fixtures/voice-calibration/ plus OL banner string revision at ChatView.tsx:254. Voice principles document at docs/voice-principles-v0_1.md (engine repo; 146 lines) anchors the discipline and names the discipline-plus-recovery principle whose first recovery affordance is §6.4. Trajectory note extended with the methodology trace from the Phase 56 scoping arc: v0.1 dialog-example reshape (vocabulary leak); v0.2 Step 0 reshape (coverage expansion — work category shifted revisional → additive while higher-level selection held — fourth instance of substrate-evidence-can-re-rationalize-selection); v0.3 Operator-observation extension (comprehension-residue gap and discipline-plus-recovery recovery surface). Three new candidates for v0.21 surfaced and live in manifest v0.41 §2: gap-diagnosis-precedes-gap-implementation; dialog-example-as-scoping-instrument sharpening; discipline-plus-recovery. Two named principles promoted at v0.41 absorption from Phase 56 close: branch-and-tag-name-collision refspec convention; Step 0 branch lifecycle.loomworks-explain-affordance-investigation-v0_1.md into queued directions. The first concrete instance of the discipline-plus-recovery principle (manifest v0.41 §2 candidate). Two trigger modes scoped (button; audible). Three candidate phase shapes (button-first / wait-for-voice-modality / audible-first-via-lightweight-substrate). Voice composition likely hybrid (LLM-composed by default; pre-authored for most-encountered triggers; voice-templated scaffolding). Substrate adjacency to §6.1 quick-capture and §6.2 mobile presence via voice-modality substrate overlap (audible mode). Calibration adjacency to §2.2 Phase 32 marketing engagement. Selection deferred to post-Phase-32 calibration evidence. Filed in Section 6 (not Section 1) because substrate adjacency outweighs engagement-creation-arc adjacency.discipline-plus-recovery; gap-diagnosis-precedes-gap-implementation; dialog-example-as-scoping-instrument sharpening). One minor candidate (instruction-refinement-during-absorption extending recursive-verification-discipline). The queued directions document holds queued future directions; the manifest holds named principles. The distinction continues to be preserved.discipline-plus-recovery principle's first instance); manifest-vs-queued-directions distinction continues to be preserved (Phase 56's promotions stay in manifest v0.41 §2, not surfaced here as queued).
v0.13 (2026-05-27). Adds one entry surfaced by Decision 4 of the same-day operational-hygiene cycle — the decision that merged the Phase 57 cherry-pick branch (phase-57-cherry-pick-cycles-1-and-2-from-paused-branch-v1, six commits including Sub-arcs 4 + 5 cycle-1+2 OL work and three review-hygiene commits) into the Operator Layer main. The cherry-pick's Sub-arc 4 commit moves the OL /signin surface from "email required to sign in" to "email optional, leave blank to sign in with any saved passkey" — closer to the v0.9 seed's "Sign-in never requests email" commitment but not at it. Decision 4 chose Path 4 — merge as intermediate state + file queued-direction acknowledging gap over the three rejected alternatives (full surface redesign, softening the seed, dropping Sub-arc 4). This bump is a structural-extension bump; one new top-level section is added. Changes:
/signin, /auth, account recovery, credential management, identity-contract alignment./signin surface email-field gap). Names the intermediate-state gap between the v0.9 seed's strict "Sign-in never requests email" commitment and the current OL /signin surface presenting an "Email (optional)" field as a passkey hint. Trajectory preserved across Phase 47 → 48 → 57 (cycle-3 paused before full surface redesign landed). Four paths considered at Decision 4; Path 4 selected with reasoning recorded. Cross-references the cherry-pick merge commit on the Operator Layer main (recorded at decision execution; the exact hash sits in the commit log of DUNIN7/loomworks main)./signin surface composition, identity-contract alignment, operational-hygiene Decision 4).v0.14 (2026-05-27). Adds one entry surfaced by the same-day operational-hygiene cycle's three-residue disposition pass. Filed during the cycle's pre-rename Workshop residue disposition. This bump is a structural-extension bump; one new top-level section is added. Changes:
loomworks-ui (the pre-rename Workshop, dormant since 2026-05-06) that surfaced during operational-hygiene cycles as not-merged-but-not-lost. Pattern follows Section 13's: discrete subsystem, room for future entries.loomworks-ui's deleted phase-16-memory-contribution-ui branch — assertion display number on provenance line, EXIF GPS in provenance line, in-place editing of held assertions. Cross-reference: phase-16-followup-2026-04-27 annotated tag in loomworks-ui repo (commit 59d4e67) preserves the work. Carry-forward to post-rename Operator Layer is deferred; no current phase scopes it. Trajectory note records the two paths considered (Path A tag-then-delete selected; Path B overwrite-existing-tag rejected) and the parallel to the engine's phase-57-paused-2026-05-13 tag from Decision 2 of the same cycle.v0.15 (2026-05-27). Adds one entry surfaced by the first activation of the discipline-mechanism-driven testing arc. This bump is an in-section extension (no new top-level section); §13.2 attaches under the existing Section 13. Changes:
WEBAUTHN_RP_ORIGIN config drift between class default :3000 and OL dev runtime :3001, fixed in local .env but checked-in source default still drifts; (2) Marvin's WebAuthn credential row is a 16-byte fixture, not a real registration, so the real Touch ID assertion produces CredentialNotRegistered even with the origin fix. Dev sign-in proceeds via the /auth dev shortcut. Trajectory note records this as the first finding produced by the discipline-mechanism-driven testing arc (the surface-level cherry-pick + queued-direction discipline introduced 2026-05-26–27)./signin email-field gap) rather than as a new operational-findings section or a Section 14 pre-rename-Workshop sibling, because the two findings are tightly coupled to the authentication-path the surface depends on — and the seed's "Sign-in never requests email" commitment names the same architectural target §13.1 names.v0.16 (2026-05-27). Adds one entry surfaced by the testing arc's pivot from authentication verification to upload-pathway verification. The Operator's empirical screenshot did not match CC's prior orientation report's framing of "Upload pathway shipped at Phase 58 + 60 on ChatView"; the discrepancy triggered the drift-surface rule and produced surface-level verification revealing that no surface in the running OL renders a reachable UploadAttachmentButton. This bump is a structural-extension bump; one new top-level section is added. Changes:
UploadAttachmentButton component shipped at Phase 58 commit 7183bb0 is gated by projectId && (...) at ChatView.tsx:607 (added Phase 58 v0.4 commit 2ff7213); all three ChatView mount sites either pass no projectId (/operator/create-engagement, CompanionPanel) or are unreachable (ChatPageClient, since /chat became a server-side redirect at commit 2716cc6); the in-engagement surface at /operator/engagement/[engagement_address] mounts CenterPane (a custom composer with a disabled ⊕ placeholder), not ChatView. Three remediation shapes surfaced (mount on CenterPane / refactor CenterPane to reuse ChatView's composer / restore /chat?project=<id>); selection deferred. The component-level work is intact; the gap is surface-mount-only.
v0.17 (2026-05-27). Supersedes v0.16's §15.1 entry with corrected substance. v0.16 framed the gap as "no surface mounts upload" — empirically narrow on five inspected routes but missing the historical reachability via /chat?project=<id>. Operator memory ("I have used this; the icons existed adjacent to the text field") plus conversation_search across 2026-05-14 acceptance-gate sessions surfaced the corrected picture: the affordance was operator-reachable, used, and working through 2026-05-19, when commit 2716cc6 (in-engagement-surface fill-in CR §C) made /chat a server-side redirect — removing reachability without porting the affordance. Changes:
/chat-route disposition and Phase 58 two-icon paperclip+folder affordance), corrected substance throughout. Three sequenced actions specified in the entry: (1) restore /chat?project=<id> route immediately as ITEM B of the same operational-hygiene cycle (a separate OL-repo commit on restore-chat-project-route-2026-05-27 branch awaiting Operator merge approval); (2) port the upload affordance onto CenterPane as substrate-phase work; (3) file route-redisposition methodology candidate for v0.21 — sharpening of the v0.16 correct-in-isolation commits combining into surface-level gap pattern./chat correctly per its own scope; neither CR had responsibility for surface-reachability across the boundary. The v0.16 methodology candidate stays; v0.17 sharpens it from "correct-in-isolation commits combining" to "route-redisposition CRs should verify cross-boundary reachability."/chat?project=<id>) is operational (lands in same cycle as the bump); the second and third actions are queued.
v0.18 (2026-05-28). Absorbs the upload-pathway testing arc that followed Operator-reach restoration of /chat?project=<id> (OL 2186d13) and the cascading three-layer infrastructure diagnosis (WEBAUTHN_RP_ORIGIN drift → object-store credential drift → MinIO not running → upload-handler transaction bug). This bump is one in-section extension to §13.2, one resolution annotation on §15.1, and one new subsection §15.2; no new top-level section is added. Changes:
WEBAUTHN_RP_ORIGIN drift; v0.18 adds (1) OBJECT_STORE_ACCESS_KEY and OBJECT_STORE_SECRET_KEY defaulting to empty strings at src/loomworks/config.py:60-61 with no .env override (MinIO denies anonymous requests; fixed with minioadmin/minioadmin in .env); (2) the pre-existing failing test test_phase_48_lifecycle_evaluator::test_compose_reactivate_url_uses_rp_origin asserting against port 3000 while dev runs on 3001 — the WEBAUTHN_RP_ORIGIN drift surfacing in the test suite. All three drifts share one shape: source-code defaults reflect an older dev environment, corrections live only in .env, fresh checkouts reproduce every drift because nothing is checked in. Standing remediation: update the source defaults to match the current dev environment, or check in a dev-environment reference document (a .env.example or a docs/dev-environment.md).2186d13; the Phase 58 two-icon upload affordance is operator-reachable again; the upload pathway was verified working end-to-end (single-file, folder, multi-file uploads all route through the engine detection registry to the text-extraction skill and render per-file UploadResultCards) after the dev-environment config drifts and the upload-handler transaction bug were cleared. The Second and Third sequenced actions (the ChatView→CenterPane port and the route-redisposition methodology candidate) remain open.sqlalchemy.exc.InvalidRequestError at uploads.py:529 and :688; the upload handler was the only handler in src/loomworks/api/ using the explicit async with db.begin() pattern; fix at engine main 040d675 removed both begin() blocks). The substantive finding beyond the bug: the upload tests were green on main while production was broken because the _override_db_session override in five upload-test files yielded a session with no commit/rollback envelope — the tests relied on the handler's redundant begin() to commit mid-request, so they verified a path that exists only when the bug is present. Removing the begin() to fix production broke five tests; the test overrides were updated to mirror the production envelope (try/yield/commit/except/rollback) so they verify the actual production path. Pattern open beyond the specific bug: dependency-override fixtures that do not mirror production middleware/dependency envelope semantics can make a test green for the wrong reason. A test-suite audit (find every app.dependency_overrides[get_db_session] and analogous override and verify each mirrors production semantics) is queued, not scoped.DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Queued Future Directions and Deferred Work — v0.23 — 2026-05-31