Loomworks — Axis 11 Scoping Note: Conversation Pagination on the Primary Surface — v0.1

Plain-language summary

What this document does. It frames the Axis 11 deferred item ("primary-surface scaling / long-conversation UX") for an Operator decision about what a build phase should contain, and draws a scope line. It does not draft a change request.

What it recommends. Scope this phase as conversation pagination — letting the Operator load conversation turns older than the most recent fifty, which today is impossible on every conversational surface. This is the substantive, cross-surface gap the current-code inspection verified.

What it carves out. The composer-positioning defect (composer scrolls off the bottom) is now a ChatView-only residue — the primary surface, CenterPane, was reshaped to composer-at-top after the diagnostic was written, so the headline defect the diagnostic described no longer applies to the primary surface. It is noted here as a small separate item, not part of this phase. Older-turn summarization, time-windowing, within-engagement segmentation, and the held-state architecture question stay deferred, for the reasons in §5.

What decision is needed. Confirm the scope line (pagination as the phase; composer residue and the deeper candidates carved out), and resolve the four open questions in §6 — chief among them whether pagination lands on CenterPane only or on the shared fetch path that all three surfaces use.

What is in scope. Loading older conversation turns on demand, on the primary surface, against the cursor the engine already exposes. What is out of scope. Any change to Memory, to what is written, or to provenance; any summarization or derived-view work; the composer-layout residue; the held-state lifecycle.

1. What Axis 11 is, and why it surfaced

Axis 11 comes from the Phase-60 post-close personal-memory diagnostic — the eleven-axis investigation of Operator-reported memory loss. Most of that diagnostic shipped (the three-bug cascade fix, the recovery of the lost memories, the voice-input gap). Axis 11 is one of the deferred tails: the diagnostic observed that the Operator's conversational surface does not scale to a long conversation. It named two distinct problems bundled under one axis:

• a pagination problem — the surface fetches only the most recent fifty turns and offers no way to load older ones; and
• a composer-positioning problem — the input composer sat at the bottom of a page that grew without bound, so after enough turns it scrolled off the screen.

This note separates those two, because the current-code inspection shows they are no longer the same shape they were when the diagnostic was written.

2. Current state, verified against the code (not the diagnostic)

The diagnostic was written 2026-05-16 and described one component — ChatView — as "the primary surface." That description has drifted. A current-code inspection on OL main b77b987 (2026-05-31) establishes the present picture. Where the diagnostic and the current code differ, the current code governs.

The primary surface changed. There are now three conversational surfaces:

• CenterPane (src/app/operator/engagement/[engagement_address]/CenterPane.tsx) — the primary conversation surface, the in-engagement default.
• ChatView (src/components/chat/ChatView.tsx) — now secondary: the /chat?project=<id> upload-capable surface, also mounted inside the CompanionPanel slide-over.
• CompanionPanel (src/components/nav/CompanionPanel.tsx) — a slide-over that mounts ChatView.

The diagnostic's "primary-surface scaling" was about ChatView, which is now the secondary surface. The actual primary surface, CenterPane, the diagnostic never examined. This is the §16.3 primary-surface claim corrected by inspection — prior position named, current position established, per the corrections-preserved discipline.

The composer-positioning problem is now ChatView-only. CenterPane was reshaped after the diagnostic (the "composer-placement-and-message-order" work) to place the composer at the top of the surface, with the conversation rendering below it. So on the primary surface the composer does not scroll off the bottom — that defect persists only on the secondary ChatView surface. The deeper layout condition the diagnostic named (a min-h-full ancestor chain with no height-bounded parent, so the page grows rather than the inner container scrolling) appears to still hold on both surfaces — but this is a code-reading inference about CSS behavior, not a runtime observation, and a browser check with a long conversation would confirm whether the inner scroll engages or the page grows.

The pagination problem is still real, and it is cross-surface. Both CenterPane and ChatView fetch /operator/conversation-history once, with limit=50, and never fetch older turns. The engine endpoint exposes a before cursor and returns has_more, but neither surface uses them — no "load earlier," no infinite scroll. Verified against current code on both components, not inferred from the diagnostic. This is the live, substantive Axis 11 gap.

3. The recommended scope: conversation pagination

This phase scopes conversation pagination on the primary surface (CenterPane): when the conversation exceeds the most recent fifty turns, the Operator can load older turns on demand, against the before cursor / has_more the engine already exposes.

The work is Operator-Layer frontend only. The substrate already supports it — the cursor and the has_more flag exist on the endpoint today. The phase wires the surface to them: a load-earlier affordance (or scroll-triggered fetch), scroll-position management so the view does not jump when older turns arrive, and loading / end-of-history states.

It carries no Memory contact. Pagination reads conversation history that already exists; it writes nothing, derives nothing, and does not touch provenance. This keeps it clean against the seed's Memory-as-sole-write-target and accumulate-with-provenance commitments — which matters, because the deeper Axis 11 candidates (§5) are precisely the ones that would approach that boundary.

4. Why pagination is the center, and not the composer fix

When this item was first considered, the framing was composer-first: fix the composer that scrolls off the bottom, with pagination as a possible follow-on. The inspection inverted that. The composer-scrolls-off defect was the headline problem in the diagnostic, but it has already been addressed on the primary surface by the composer-at-top reshape; it now survives only on the secondary ChatView surface. Pagination, by contrast, was the quieter of the two problems in the diagnostic and turns out to be the one still live on every surface.

So the substantive cross-surface work is pagination, and the composer-positioning fix is a small, secondary-surface-only residue. The scope line follows the verified problem, not the diagnostic's original emphasis.

The composer residue (carved out). ChatView's composer still sits after the scroll container in normal flow, with no sticky positioning, so it scrolls off the bottom of a long conversation. This is a contained ChatView-only layout fix. It is filed as a separate small item, not folded into this phase — both because it is a different surface from the pagination work's primary target, and because the standing ChatView → CenterPane port (queued-directions §15.1) may make ChatView's layout moot, so a layout fix to ChatView should be weighed against the port rather than done reflexively.

5. Deferred candidates, and the boundary they touch

The diagnostic's §E listed three further Axis 11 candidates beyond pagination and composer-positioning. All stay deferred, and the reason is the same seed boundary in each case:

• Older-turn summarization — condensing old turns to keep a long conversation manageable. This is the one that most directly approaches the Memory boundary. Done as a derived view (a Manifestation/Shaping-style condensation read off existing Memory), it is consistent with the seed. Done as a write — storing a summary back, or pruning what is readable in a way that drops provenance — it would violate Memory-as-sole-write-target and accumulate-with-provenance. It must not ride along in a pagination phase; it needs its own design pass that settles the derived-vs-written question explicitly.
• Time-windowing — showing the conversation by time ranges. A presentation concern if it is purely a view over loaded turns; a Memory concern if it changes what is retained. Same boundary, same need for deliberate design.
• Within-engagement room-segmentation — segmenting the conversation by room (Memory / Manifestation / Shaping / Rendering). Touches how conversation maps to the four-room model; a methodology question, not a UX quick-win.

Also deferred, and explicitly its own item: the held-state architecture question (held-list endpoint vs per-fact held slots vs a structural commit-verifier), which §16.3 already files as the deepest memory-experience item. It is not Axis 11 surface work and is out of scope here.

The principle: pagination is bounded and Memory-clean; the rest are deeper and Memory-adjacent. Shipping the bounded, clean slice now and scoping the Memory-adjacent candidates deliberately is the same substrate-soundness-before-momentum discipline applied throughout.

6. Open questions for the Operator

These need resolution before a change request is drafted.

1. Surface target — CenterPane only, or the shared fetch path? Both CenterPane and ChatView fetch /operator/conversation-history the same way and share the same gap. Pagination could be built on CenterPane alone (primary surface, clear win) or on a shared fetch hook both surfaces use (fixes both at once, slightly more refactoring). Best-guess default: build it on CenterPane primarily, but if the fetch logic is already shared or trivially shareable, put the pagination there so ChatView inherits it — decided at change-request drafting once the fetch code is read closely. The scoping decision is "pagination on the primary surface"; the shared-path question is an implementation detail to settle at CR drafting, not now.

1. Load affordance — explicit button or scroll-triggered? A "load earlier conversation" button is simpler, more predictable, and respects "only show what is available" (it appears only when has_more is true). Scroll-triggered (infinite scroll) is smoother but fiddlier and interacts with the composer-at-top layout. Best-guess default: explicit affordance, gated on has_more. Simpler, testable, and consistent with the surface's deliberate non-chat-app posture.

1. The layout-chain inference (§2) — confirm before or during the phase? Whether the page grows vs. the inner container scrolling is currently a CSS-reading inference. Pagination interacts with it: loading older turns into an unbounded-growing page behaves differently than into a properly-bounded scroll container. Best-guess default: a quick runtime confirmation (long conversation in a browser) as the phase's Step 0, so the scroll model is known before the pagination behavior is built on top of it.

1. The ChatView composer residue — file separately now, or note and move on? Best-guess default: file it as a small standalone item in queued-directions §16.3 (or §15 alongside the ChatView → CenterPane port, since the port may absorb it), and do not scope it into this phase.

7. Recommended next step

If the scope line holds (pagination as the phase; composer residue and deeper candidates carved out) and the four questions above resolve to their defaults or your alternatives, the next artifact is a change-request drafting handoff for Claude Code — beginning with a Step 0 that reads the current CenterPane and ChatView fetch code closely, runtime-confirms the scroll model (Q3), and resolves the shared-path question (Q1) against the actual code before any CR rows are written.

No change request is drafted until this scoping note's decisions are settled.