Implementation Runtime Core
Implement the shared engine
Keep process bootstrap facts, mutable session state, durable conversation state, and background work as separate lifetimes. Build one semantic engine that all interactive, headless, SDK, bridge, and remote adapters can drive without redefining messages, turns, limits, tools, or terminal outcomes.
Use the architecture diagram to orient the core ownership and dependency flow.
Preserve this dependency direction:
entrypoint and policy
-> session/bootstrap state and registries
-> normalized input and effective context
-> recursive query/model loop
-> capability and continuity boundaries
-> semantic events consumed by presentation adapters
Do not let presentation state become authoritative conversation state. Do not let a transport-specific retry, permission response, or display event invent a different meaning for a shared operation.
Specialized workflows
- Use implementation-startup-settings to implement entrypoint selection, early initialization, trust, settings precedence, migrations, and managed policy.
- Use implementation-state-context to implement bootstrap lifetimes, the observable application store, state reactions, working-directory identity, and effective prompt/context assembly.
- Use implementation-query-model to implement input submission, the recursive query state machine, message normalization, model streaming, retries, continuation, limits, and terminal results.
Core acceptance criteria
- A session restored after interruption reaches the same semantic state regardless of presentation surface.
- A UI-only progress update never enters model context or durable conversation history unless explicitly translated into a message.
- A new surface consumes shared events and permission contracts instead of forking the conversation engine.
- Cancellation, budget exhaustion, model failure, and successful completion each produce one explicit terminal outcome and leave recoverable evidence.
1---2name: implementation-runtime-core3description: Implement the shared session runtime from process startup through context composition and the recursive model loop. Use when defining runtime ownership, tracing a turn across bootstrap, state, and query boundaries, or deciding whether a core behavior belongs to startup/settings, live state/context, or model orchestration.4---56# Implementation Runtime Core78## Implement the shared engine910Keep process bootstrap facts, mutable session state, durable conversation state, and background work as separate lifetimes. Build one semantic engine that all interactive, headless, SDK, bridge, and remote adapters can drive without redefining messages, turns, limits, tools, or terminal outcomes.1112Use the [architecture diagram](assets/architecture.drawio) to orient the core ownership and dependency flow.1314Preserve this dependency direction:1516```text17entrypoint and policy18 -> session/bootstrap state and registries19 -> normalized input and effective context20 -> recursive query/model loop21 -> capability and continuity boundaries22 -> semantic events consumed by presentation adapters23```2425Do not let presentation state become authoritative conversation state. Do not let a transport-specific retry, permission response, or display event invent a different meaning for a shared operation.2627## Specialized workflows2829- Use [implementation-startup-settings](../implementation-startup-settings/SKILL.md) to implement entrypoint selection, early initialization, trust, settings precedence, migrations, and managed policy.30- Use [implementation-state-context](../implementation-state-context/SKILL.md) to implement bootstrap lifetimes, the observable application store, state reactions, working-directory identity, and effective prompt/context assembly.31- Use [implementation-query-model](../implementation-query-model/SKILL.md) to implement input submission, the recursive query state machine, message normalization, model streaming, retries, continuation, limits, and terminal results.3233## Core acceptance criteria3435- A session restored after interruption reaches the same semantic state regardless of presentation surface.36- A UI-only progress update never enters model context or durable conversation history unless explicitly translated into a message.37- A new surface consumes shared events and permission contracts instead of forking the conversation engine.38- Cancellation, budget exhaustion, model failure, and successful completion each produce one explicit terminal outcome and leave recoverable evidence.
greenpau