What this document does. It frames the Axis 11 deferred item ("primary-surface scaling / long-conversation UX") and draws a scope line for a build phase. In v0.1 it asked the Operator to confirm that scope line and resolve four open questions; in v0.2 those decisions are settled and recorded here. 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 filed 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 was decided. The Operator confirmed the scope line (pagination as the phase; composer residue and the deeper candidates carved out) and resolved the four §6 questions at their defaults (2026-05-31): pagination targets the primary surface (CenterPane), with the CenterPane-only-vs-shared-path detail settled at CR drafting once the fetch code is read; an explicit "load earlier" control gated on has_more, not infinite scroll; a runtime scroll-model confirmation as the phase's Step 0; and the ChatView composer residue filed separately.
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.
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:
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.
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:
src/app/operator/engagement/[engagement_address]/CenterPane.tsx) — the primary conversation surface, the in-engagement default.src/components/chat/ChatView.tsx) — now secondary: the /chat?project=<id> upload-capable surface, also mounted inside the CompanionPanel slide-over.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. (This confirmation is now the phase's Step 0 — §6, Q3.)
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.
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, 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.
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.
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:
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.
These four questions were open in v0.1, for Operator decision. The Operator resolved all four at their defaults on 2026-05-31. Each is kept here with its original framing and its resolution, so the trajectory — what was asked, what was decided — is preserved per the corrections-preserved discipline.
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). Resolved (default): pagination lands on the primary surface (CenterPane). Whether it sits on CenterPane alone or on a shared fetch path both surfaces use is an implementation detail settled at CR drafting, once the fetch code is read closely — if the fetch logic is already shared or trivially shareable, the pagination goes there so ChatView inherits it. The scoping decision is "pagination on the primary surface"; the shared-path question is not decided now.
2. Load affordance — explicit button or scroll-triggered? A "load earlier conversation" control 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. Resolved (default): an explicit "load earlier" control, gated on has_more — not infinite scroll. Simpler, testable, and consistent with the surface's deliberate non-chat-app posture.
3. Scroll-model confirmation — confirm before or during the phase? Whether the page grows vs. the inner container scrolling is currently a CSS-reading inference (§2). Pagination interacts with it: loading older turns into an unbounded-growing page behaves differently than into a properly-bounded scroll container. Resolved (default): runtime-confirm whether the page grows or the inner container scrolls — a long conversation in a browser — as the phase's Step 0, before the pagination behavior is built on top of it.
4. The ChatView composer residue — file separately now, or note and move on? Resolved (default): filed separately, as its own small standalone item alongside the ChatView → CenterPane port (which may absorb it), and not scoped into this phase.
The scope line holds and the four §6 questions are resolved at their defaults. 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, now the phase's mandated Step 0), and settles the shared-path question (Q1) against the actual code before any CR rows are written.
The decisions are settled; drafting the change request is the next step.