Loomworks — Axis 11 CR Drafting Handoff: Conversation Pagination — v0.1

Plain-language summary

What this document does. It hands Claude Code the settled Axis 11 scope and tells it to run a pre-flight (Step 0) before drafting any change request. It does not authorise a build, and it does not authorise writing CR rows yet.

What the phase is. Conversation pagination on the primary surface (CenterPane): when a 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. Operator-Layer frontend only; no Memory contact (pagination reads history that already exists — it writes nothing, derives nothing, touches no provenance).

What Step 0 must establish before any CR is drafted. (1) Read the current CenterPane and ChatView conversation-fetch code closely and report what is actually there. (2) Runtime-confirm the scroll model — whether the page grows or the inner container scrolls — with a long conversation in a browser. (3) Resolve the surface-target question (CenterPane-only vs a shared fetch path both surfaces use) against the actual fetch code.

Then halt. Step 0 ends in a halt for Operator confirmation. No CR rows are written until the Operator confirms the Step 0 findings.

What is out of scope. Any Memory write, derivation, or provenance change; summarization, time-windowing, room-segmentation; the ChatView composer-scrolls-off residue; the held-state architecture question. These are deferred per the scoping note and the queued-directions record.

1. Settled scope (from scoping note v0.2 — not re-opened here)

• The phase is conversation pagination on the primary surface, CenterPane. Load conversation turns older than the most recent fifty, on demand, against the existing engine cursor.
• Load affordance: an explicit "load earlier" control, gated on has_more — not infinite scroll. It appears only when older turns exist (consistent with "only show what is available").
• ChatView composer residue: carved out, filed separately, not in this phase.
• Deferred, not in this phase: older-turn summarization, time-windowing, within-engagement room-segmentation, the held-state architecture question.
• Memory boundary: the seed's Memory section (§31) establishes that every operation draws from Memory and that derivations are readings, not copies. Pagination is a pure read — it does not write, derive, supersede, or touch provenance. This phase must not cross into anything that writes Memory. If at any point the work appears to require a Memory write, halt and surface it rather than proceeding.

2. Step 0 — pre-flight, before any CR rows

Run all three, then halt. Apply the current-state-verification discipline throughout: report what the current code on main actually does, naming the source of each fact, rather than relying on the scoping note's or the diagnostic's description of it.

Step 0a — read the fetch code. Read closely, on OL main, the conversation-fetch path in both surfaces:

• CenterPane (src/app/operator/engagement/[engagement_address]/CenterPane.tsx) — its /operator/conversation-history fetch (the scoping note cites a single limit=50 fetch on mount, no cursor; confirm against current code).
• ChatView (src/components/chat/ChatView.tsx) — its fetch of the same endpoint.
• The engine endpoint /operator/conversation-history — confirm it exposes a before cursor and returns has_more, and report the exact response shape the client receives.

Report what each does now, with file:line.

Step 0b — runtime-confirm the scroll model. The scoping note's §2 layout claim (the min-h-full ancestor chain with no height-bounded parent → the page grows rather than the inner container scrolling) is a CSS-reading inference, not a runtime observation. Confirm it empirically: load CenterPane with a long conversation (50+ turns) in a browser and report whether the inner conversation container scrolls or the whole page grows. This determines how pagination must insert older turns — into a bounded scroll container behaves differently than into an unbounded-growing page. State plainly what you observed.

Step 0c — resolve the surface-target question. The scoping note left "CenterPane-only vs a shared fetch path" as an implementation detail for this step. Read the two surfaces' fetch logic (from 0a) and determine: is the fetch already shared or trivially shareable between CenterPane and ChatView? If yes, the pagination should go on the shared path so ChatView inherits it; if the two are meaningfully separate, build on CenterPane (the primary surface) alone and leave ChatView to its later port. Recommend one, with the code reason.

Then HALT. Print a Step 0 report covering 0a/0b/0c and await Operator confirmation. Do not write CR rows, do not begin building.

3. After Step 0 (for context — not yet authorised)

Once the Operator confirms the Step 0 findings, the change request gets drafted against them: the load-earlier control gated on has_more, the fetch-and-prepend behavior with scroll-position management (so the view does not jump when older turns arrive), loading and end-of-history states, and frontend tests. The CR goes through the normal pre-flight-then-Operator-approval cycle before any build step. None of that is authorised by this handoff — this handoff authorises Step 0 only.

4. What this handoff does not do

It does not draft a change request. It does not authorise a build. It does not re-open the settled scope or the four resolved §6 decisions. It authorises exactly the Step 0 pre-flight in §2, ending in a halt.