Evaluate structured storage for core runtime context

[dcramer]

Background

Issue #1074 and PR #1089 introduce typed, versioned structured context for plugin user-prompt contributions. A plugin owns the structured content and its prompt renderer; Junior records the normalized structured content without retaining the rendered prompt labels.

Core runtime turn context is still assembled directly into the prompt. Some of those facts may benefit from the same separation between structured data, prompt rendering, and authorized UI/reporting—but moving everything would create duplication and event-log bloat.

Goal

Evaluate which core-owned runtime context, if any, should have a typed and versioned structured representation that can:

• render into the model-visible user prompt;
• be retained safely as structured event data; and
• appear in the turn context UI without storing rendered prompt markup or labels.

A valid outcome is that existing dedicated events and prompt-only rendering are already the better owners.

Candidate areas

Evaluate compact, prompt-visible facts that may otherwise be difficult to reconstruct:

• active skill invocation;
• active MCP catalog summaries;
• dispatch or plugin identity;
• explicitly allowlisted, retention-safe configuration values.

Guardrails

• Do not store rendered <runtime-turn-context> text, XML, field labels, or other presentation output.
• Do not retain full skill descriptions, tool guidance, complete configuration objects, credentials, or secrets.
• Do not duplicate actor/message facts or routing, handoff, tool-call, lifecycle, and artifact data already represented by authoritative events.
• Account for authorization, privacy, schema versioning, payload budgets, replay behavior, and event-log growth.
• Prefer projecting existing events into the context UI over introducing a second stored representation when possible.

Questions to answer

• Which core runtime facts are currently lost after prompt assembly?
• Which facts are already reconstructible from authoritative events?
• Should the UI aggregate existing events alongside plugin turn_context events instead of persisting a core snapshot?
• If a core snapshot is justified, what is the smallest stable schema and who owns its prompt renderer and version upgrades?

Deliverable

Produce an inventory of core runtime-context sections, map each to its current authoritative source, and recommend one of:

1. keep prompt-only;
2. project an existing event into the context UI; or
3. add a small typed, versioned structured context record.

Follow up with implementation issues only for proven gaps.

Related: #1074, #1089

[dcramer]

this roughly exists