Version. v0.3
Date. 2026-06-27
For. Operator (Marvin) + Claude.ai + Claude Code build continuity. Markdown canonical; HTML companion if it stabilizes.
Home. loomworks-record/current-status/ (where the live orientation artifacts live).
Purpose. The SINGLE ordered queue for the Companion build + the cross-cutting concerns + the trust-boundary principle. Supersedes all scattered queue-tracking.
v0.3 change log — RECONCILIATION. Two queue documents had diverged: this lineage (v0.1→v0.2, the broader cross-cutting framing) and a separate loomworks-companion-build-queue-v0_1 CC filed during the home build (a narrower "landed/up-next/gaps" list). v0.3 merges them into one, with the broader framing winning. Key correction: CC narrowed "list-loading" to "the home's loading/empty/error states (skeletons, retry)"; that is a sub-item, not the concern. List-loading is the cross-cutting PAGINATION concern (Operator-confirmed 2026-06-27) — unbounded-growth lists across every surface. CC's home-build findings (Shared-visibility signal, omitted counts, etc.) are absorbed as open gaps below. v0.1 and v0.2 preserved per discovery-trajectory discipline.
loomworks branch feat-companion-surface — PUSHED 2026-06-27)loomworks-dev.dunin7.com loads via the same-origin proxy.Push: branch pushed to origin; the conversation-content issue rides along knowingly (queued). Merge-to-main is a separate decision — not done without separate authorization.
Engine + API — settled, untouched. Foundation.
| # | Item | State | Notes |
|---|------|-------|-------|
| 1 | List-loading pattern (cross-cutting PAGINATION) | Scope next | NOT "loading states/skeletons" — that's item 4. The unbounded-growth pagination concern across EVERY surface. Pattern pre-decided (below). Engine extends its existing has_more/cursor pattern to room + engagement listings. |
| 2 | Conversation-content fix | Parked — engine-side decision | Stale "you're not in a project" history in the in-engagement left pane. "close"/navigation chatter written into permanent engagement history. Decision: engine STOPS writing it (lean) vs. surface FILTERS it. Touches engine. |
| 3 | Folder upload | Queued — own piece | Frontend must send webkitRelativePath (currently bare file.name, silently flattening) + Phase 60 OL composer-completeness. File upload already restored; folder is the remaining half. |
| 4 | Loading STATES (home + rooms) | Sub-item of #1 | The loading/empty/error UX CC flagged: today a single "Catching you up…"; needs/recent fall back to empty silently on failure. Decide skeletons vs. spinner, per-lens error, retry. Can ride with #1. |
| Concern | Posture | See |
|---|---|---|
| List-loading / pagination | Explicit load-more, total_count visible, has_more-gated, composite cursor; engine paginates | Item 1 below |
| Provenance display | Surface SHOWS provenance (origin threads, AI-origin non-suppressible); FORAY attests underneath. Already in Memory cards; must stay first-class on every surface — not dropped to match a mockup that omits it | § Provenance display |
| Grant-gating | Surface HIDES unavailable affordances (UX courtesy); ENGINE enforces authorization (the guarantee). Owner-view-first; add surface-hiding when GRANTHA's model settles into the seed | § Grant-gating |
Decided-on-sight (DONE): the back-path affordance — built + verified (Loomworks link + chip × + mobile back → home).
The concern (Operator, 2026-06-27). Loading is not a per-room fix; it is a cross-cutting concern touching every surface where a list can grow. Considered surface-by-surface, the same decision gets re-made five times with five slightly different answers. Settle it once; every surface applies it.
total_count surfaced" pattern (a second precedent).From Axis 11 (conversation pagination) and personal-memory wholesale-with-backstop, the settled Loomworks list-loading rule:
total_count always visible — the Operator sees "13 settled" and, at scale, "showing 50 of 2,000." No silent truncation.has_more. Only-show-what's-available (absent when the list is fully shown).(created_at, id) — the R2 lesson already learned from Axis 11 (a created_at-only strict-< cursor can skip a turn sharing the exact boundary timestamp). Engine-side.
The engine already has the pattern on /operator/conversation-history (before cursor + has_more; the client type already carries has_more). The work is extending that same pattern to the room-listing and engagement-listing endpoints that currently return wholesale — limit + composite cursor + has_more. This is "extend a known, settled pattern," not invent one.
The original intent was scope-loading-first so the home was built to the pattern. The home was built first instead (wholesale, with simple loading states), so the home's three lists (engagements / Needs you / Recent) and the rooms' grown sections all now need the pagination retrofit — this is the work item 1 covers. The home is small (7 engagements today) so wholesale is fine for now; the retrofit matters before any surface hits real volume. No urgency, but named and owned.
Absorbed from CC's home-build findings (reconciled into this queue):
/engagements carries no visibility field. Current heuristic: Shared = title === BRAND.productName (single white-label-keyed predicate; degrades gracefully — unmatched engagements stay under Your engagements). A real visibility='automatic' engine projection would replace it. Real engine gap.Operator principle, 2026-06-27. Any trust-bearing operation — attestation (FORAY), authorization (GRANTHA), identity/attribution (Stele) — must be invoked at the layer where the event actually occurs: the engine substrate, the chokepoint every recordable action must traverse. It must NOT be pushed outward to the Operator Layer / frontend.
Why. The surface is replaceable — custom Companions are a core Loomworks direction (engagement-as-universal-adapter; methods and verticals specialize and are sold). If a trust-bearing operation lived in the surface, a custom or careless or malicious surface could simply not perform it — silently producing unattested / unauthorized / unattributed actions that look identical to correct ones. The hole would be invisible. Emission/enforcement at the engine means a replaceable surface inherits the guarantee whether or not it cooperates, because it cannot perform the action without traversing the engine seam.
This is the same family as "correctness guarantees in code, not prompts" — structural enforcement beats asking nicely. Here: guarantees in the substrate, not the surface. Trust must not depend on the surface's cooperation.
What the surface DOES do (the permitted relationship to each substrate):
Build consequence. Nothing in the Companion frontend may be the sole guarantor of attestation, authorization, or attribution. The frontend is a display-and-request layer; the engine is the authority. Every cross-cutting concern below is a surface-side reflection of an engine-side guarantee, never a replacement for it.
The concern. Provenance is the surface manifestation of the attestation substrate (FORAY) and of the provenance-threads model (each contribution carries typed origin threads — outward to person / document / sensor / query / scope, or inward via inference from existing assertions; trust axis is tie-to-source, not human-vs-machine; AI origin marked non-suppressibly; origin extensible, threads walkable).
Where it surfaces. Every card that represents a contribution — across all four rooms and any future surface that shows assertions, shapes, renders. Currently present in Memory cards ("noted by Marvin Percival (Operator)"; the Definition/type chips). Must carry to Manifestation, Shaping, Rendering, and the home wherever contributions appear.
The requirement. Provenance display stays first-class as the remaining surfaces are built — not dropped to match a mockup that happens to omit it (same trap as upload/navigation). Specifically: origin is shown; AI-origin is marked and non-suppressible; the tie-to-source is legible. When FORAY goes live underneath, these displays become FORAY-attested with no surface change — because the surface was already showing provenance.
Build posture. Make provenance-display an explicit conformance item in each room/home build, checked like loading. Don't invent new provenance UI ahead of the threads model settling; do faithfully display the provenance the engine already carries.
The concern. What an Operator can see and do is governed by GRANTHA (the access-control substrate; replaced OVA in that seat, consuming OVA for blind ZK verification underneath; GRANTHA v0.3 — grant is the sole primitive, holder-set never readable).
The split (per the trust-boundary principle):
Build posture. Owner-view-first. Build the surface for the owner (Marvin-as-owner passes all checks today), with affordances shown. Add surface-side grant-hiding when GRANTHA's grant model settles into the seed (the seed amendment for GRANTHA v0.3 is flagged pending; the C5 external-reference decision is gated on the grant model settling). Do NOT build surface grant-gating against an unsettled model — risks building to a moving target. The engine's enforcement is the real protection and holds regardless of whether the surface hides.
Why queued, not now. GRANTHA v0.3 is recent; the seed predates it and needs amendment; the grant model is still settling. Surface grant-hiding waits for that to lock. Engine enforcement is not blocked by this — it's the engine's existing responsibility.
This queue exists because live review keeps surfacing real capability-gaps the mockups didn't cover (upload-folder, navigation, list-loading) and real cross-cutting concerns the mockups never addressed (provenance display, grant-gating). That's the live view and the architectural review doing their job. The discipline: each gap or concern becomes a named, ordered queue item or a settled cross-cutting principle — not patched reactively surface-by-surface, and not lost. Cross-cutting concerns (list-loading, provenance, grant-gating) are settled once and applied to every surface; one-off gaps are scoped as their own pieces. The queue is maintained here as the single visible order.
Three cross-cutting concerns now governed here, all surface-side reflections of engine-side guarantees per the trust-boundary principle: list-loading (item 1 — explicit load-more, engine paginates), provenance display (item 6 — surface shows, FORAY attests), grant-gating (item 7 — surface hides, engine enforces).
DUNIN7 — Done In Seven LLC — Miami, Florida Companion build — running queue + cross-cutting concerns — v0_3 — 2026-06-27