Split the shared data types out of core/pipeline

Start by reading the listed data files in core/pipeline, especially extensions.go, session.go, promptcontext.go, client.go, and context.go, then trace their imports into core/session and core/cost/event. The issue leaves package boundaries and the transition strategy open, so settle those design questions before moving types. Done means the named session and cost packages build without importing core/pipeline and go test ./... passes in every module.

Part of #1437 (assessment: laptop data plane on Praxis) · prep work, useful to Cortex on its own

Status: there is no shipped Cortex–Praxis integration today (the paused cmd/cortex-praxis converter is not one), and the interim path is not decided (LLM traffic to praxis-ai as an inference server, or all traffic through Praxis via #1491). This is a refactor with no behaviour change: it is useful to Cortex on its own, and would make a possible move to Praxis easier whichever path is taken.

Problem

core/pipeline (about 6,900 non-blank lines) holds two different things:

• Shared data types: the parsed request (InferenceExtension, MCPExtension, A2AExtension), the recorded event (SessionEvent), PromptContext, EventClient.
• The plugin engine: the request context Context, actions, plugin capabilities, redirects, the runner.

46 non-test packages import it (39 in core, plus cmd/cortex, cmd/cortex-envoy, four agentop packages and scripts/readme-demo). Several use only the data half directly:

Package	Uses from core/pipeline directly
core/cost/pricing	InferenceExtension only
core/session/archive	SessionEvent, RawJSON
core/cost/usage	event and parsed-request types, plus the client and agent-name helpers (ParseUserAgent, IsKnownAgent, AgentName, IsControlRune)
core/cost/ledger	event types, plus AgentName, IsControlRune, ParseUserAgent, UnknownClientLabel (pipeline.Context appears only in a test)

But they also reach the engine indirectly:

• core/session imports pipeline, and returns *pipeline.SessionView from View, ViewTail and ViewPage. The archive imports core/session (Recorder, History, Interner, SummaryFold), and the ledger imports it for one compile-time check (var _ session.Recorder, writer.go:335).
• core/cost/event imports pipeline (event.go:569, :594), and usage and ledger both import it.

So anything that wants to read or store a Cortex event — the session store, the archive, the cost ledger, agentop — pulls in the whole plugin engine with it.

Proposal

Move the data types into their own package (e.g. core/event or core/model) that imports no engine code, and have core/pipeline re-export or import them.

What moves to the data package:

• the parsed-request types, SessionEvent and sessionEventWire with its JSON (un)marshalling;
• PromptContext, EventClient, and the client and agent-name helpers in client.go;
• Direction and its constants and JSON methods (they live in context.go:45);
• SessionView and its query methods (session.go:675-787): pure data plus filters over events, and core/session returns it. Alternatively, have the store return []SessionEvent and leave SessionView in the engine;
• SnapshotInference and PluginEventSuffix.

What stays in the engine: Context, SetState/GetState (they take *Context), the *Context helpers in snapshot.go, and Extensions.Custom.

Obstacles found (checked by compiling the data files as a standalone package, with no cycle):

• extensions.go mixes data with SetState/GetState, so it has to be split.
• content.go's Fragments() methods implement capabilities.ContentSource, and methods can't leave their type's package, so the data package imports core/capabilities (a leaf; no cycle).
• cost/event also has to move off pipeline, and ledger's session.Recorder assertion move or go.

Also:

• agentop uses some engine symbols too (ErrorPolicy*, Metric/MetricsProvider), so it won't drop the engine import entirely.
• Unused exported SessionView methods (Intents, ToolCalls, ToolResponses, FailedEvents, LastError) are public API; keep them.

This should land before #1503 and #1504, so their libraries and decision cores can depend on the data package instead of the engine.

Design questions

1. One data package, or one per concern (inference, event, client)?
2. Type aliases in core/pipeline for a transition period, or a single rename across the tree?
   • core is consumed outside this repo: core/README.md names the operator and rossoctl-cli. Today both pin the old module path …/authbridge/authlib, so they break only when they bump, which is a module-path move anyway.
   • Aliases work for types. Constants and functions need re-declared wrappers.

Done when

• core/session, core/session/archive, core/cost/event and core/cost/{ledger,usage,pricing} build without importing core/pipeline (go list -deps).
• go test ./... passes in every module with no test changed other than imports.

Evidence read at main @ e455a04 (2026-10-25); not built.