Companion build — running queue + list-loading cross-cutting concern — v0_1

> ⚠️ SUPERSEDED by loomworks-companion-build-queue-v0_3.md (2026-06-27). v0.3 is the single canonical queue (this lineage's broader framing won the reconciliation). Kept alongside per discovery-trajectory discipline — do not maintain this file; maintain v0.3.

Version. v0.1 Date. 2026-06-27 For. Operator (Marvin) + Claude.ai build-scoping continuity. HTML companion to follow if this stabilizes; Markdown source canonical for now. Home. loomworks-record (build-briefs/ or current-status-adjacent — CC to place). Purpose. Keep the Companion build queue visible and ordered so the capability-gaps found by live review don't scatter, and establish the cross-cutting list-loading pattern once rather than per-surface.

Where the build stands

In-engagement surface — built, conformant, on feat-companion-surface (unpushed). Fresh build to mockups 1 & 2, behavior included; roomier type scale (tokens, deferred-type-debt paid down); file upload restored. Live on the tunnel (loomworks-dev.dunin7.com). Suite green. The conversation-content issue (below) is its one parked defect.

Engine + API — settled, untouched. Foundation. Not in question.

The running queue (ordered)

| # | Item | State | Notes | |---|------|-------|-------| | 1 | List-loading pattern (cross-cutting) | Scope first — this doc | Settle the pattern before building the home, so the home is built to it rather than retrofitted. Largely pre-decided across two precedents (below). | | 2 | Across-engagements home (mockups 3 & 4) | Queued — build to the loading pattern | Replaces the OLD /operator/engagement-navigation three-column list. Includes the back-path (in-engagement → home), decided on sight. Watch for old-page capabilities the new mockup omits (e.g. "+ Engagement" create, "+ New workspace", cross-cutting system views) — keep-or-drop each deliberately, like sort-order/upload. | | 3 | Folder upload | Queued — own scoped piece | Real build, not a button: frontend must transmit webkitRelativePath (currently sends bare file.name, silently flattening) + the Phase 60 OL composer-completeness piece (system-file filtering, folder-as-one-contribution). File upload already restored; folder is the remaining half. | | 4 | Conversation-content fix | Parked — engine-side decision | The stale "you're not in a project" history in the in-engagement left pane. Root cause: "close"/navigation chatter is written into the engagement's permanent conversation history, so it surfaces as current. Decision needed: engine STOPS writing navigation chatter into engagement history (lean), or surface FILTERS it from the view. Touches the engine = real decision. |

Decided-on-sight, not queued as build work: the back-path affordance (item 2) — CC builds the proposed default ("Loomworks" top-left → home; focus-chip × → home), Operator reacts live and confirms or redirects.

Item 1 — The list-loading pattern (cross-cutting concern)

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.

Every surface it touches

The four rooms (in-engagement):
Memory — Settled/In record — grows unboundedly (the permanent record). Paginate.
Memory — Held — small by nature (unconfirmed working set). Wholesale OK.
Manifestation / Shaping / Rendering — grow with the record (Goosey already has 13 renders). Paginate the grown sections.
Conversation (in-engagement) — already solved (Axis 11 "load earlier" control). This is the precedent, not an open item.
Across-engagements home (item 2):
Your engagements list — fine at 7, not at 200. Paginate.
Needs you lens — can be long. Paginate.
Recent lens — inherently a growing log. Paginate.
Personal memory — already has the "limit 500 visible backstop, total_count surfaced" pattern (a second precedent).
Future surfaces — anything listing assertions, renders, engagements, events, or history inherits the pattern.

The pattern (unifying the two existing precedents into one rule)

From Axis 11 (conversation pagination) and personal-memory wholesale-with-backstop, the settled Loomworks list-loading rule:

First page loads on mount (a sensible page size per section — conversation used 50).
total_count always visible — the Operator sees "13 settled" and, at scale, "showing 50 of 2,000." No silent truncation.
Explicit "load more" control — NOT infinite scroll. The settled Axis 11 §6 Q2 decision. Operator-authority: the Operator chooses to load more; the surface does not auto-fetch endlessly.
The control appears only when more exists — gated on the engine's has_more. Only-show-what's-available (absent when the list is fully shown).
Cursor is composite (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.
Held-type/small working sets stay wholesale — pagination targets the unboundedly-growing sections (settled/in-record, renders, engagements, recent), not the small-by-nature ones (held).

What this implies for the engine

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.

Sequencing rationale

Scope-first (this doc) before the home build, so the home's three growing lists (engagements / Needs you / Recent) are built to the pattern from the start — the home becomes the first surface that does loading right, rather than another wholesale surface retrofitted later. We have found three capability-gaps by building-to-a-known-gap (upload, navigation, loading); scoping this one first breaks that cycle.

Open decisions (for the full scoping note / per-surface CRs)

Page size per section — conversation used 50; rooms and engagement lists may want different sizes. Tune when real volume exists.
Experience at scale — whether settled at thousands needs search/filter on top of "load more" (a "load more" through 2,000 one page at a time is mechanically correct but a poor experience; search/filter is the real answer at high volume). Named as a follow-on; the mechanism lands first, the at-scale experience tunes against real volume.
Which endpoints already paginate vs. need extending — Step-0 inspection (CC) before the engine CR.

Method note

This queue exists because live review keeps surfacing real capability-gaps the mockups didn't cover (upload-folder, navigation, list-loading). That's the live view doing its job. The discipline: each gap becomes a named, ordered queue item, scoped deliberately — not patched reactively surface-by-surface, and not lost. The queue is maintained here as the single visible order.

DUNIN7 — Done In Seven LLC — Miami, Florida Companion build — running queue + list-loading cross-cutting concern — v0_1 — 2026-06-27