Rituals views: how each StreamEvent looks during a run #185

New issue

Open

opened 2026-10-04 20:20:35 +00:00 by peterswimm · 0 comments

peterswimm commented

2026-10-04 20:20:35 +00:00

Owner

Part of #177. Revised: the streaming contract already exists, so this issue is now about how it looks.

What it's for: a run streams as StreamEvents, ratified in rituals-api-spec PR #6 (anchor wish 0bcc6c47). It always opens with frame_status and ends with exactly one done or error. Output arrives as block_start / block_delta / block_end, so a run already renders as blocks. Design how each event type looks.

Event types to design for

Content: frame_status, the block events, reference, tool_call, lineage_sync
Routing: tier_assignment (which tier or model is handling it)
Load: resource_pressure, consumer_lag, model_evicted, topic_provisioned. Probably quiet by default.
Governance: familiar_response, rubric_gate, groom_signal
End: done, error

Please design

The step and status display driven by frame_status
Live output while a block is still streaming, and how it settles once the block ends
Which load events are shown, and how quietly
Cancel while running (always visible), error and retry, and "try another backend"

This also answers the open "streaming output slot" question in SHAPES.md.

Acceptance criteria

A treatment for every StreamEvent type, including "hidden by default" where that's right.
Running, cancelled, error and retry states.
CLI rendering.

Part of #177. **Revised:** the streaming contract already exists, so this issue is now about how it looks. **What it's for:** a run streams as `StreamEvent`s, ratified in rituals-api-spec PR #6 (anchor wish `0bcc6c47`). It always opens with `frame_status` and ends with exactly one `done` or `error`. Output arrives as `block_start` / `block_delta` / `block_end`, so a run *already* renders as blocks. Design how each event type looks. ## Event types to design for - **Content**: `frame_status`, the block events, `reference`, `tool_call`, `lineage_sync` - **Routing**: `tier_assignment` (which tier or model is handling it) - **Load**: `resource_pressure`, `consumer_lag`, `model_evicted`, `topic_provisioned`. Probably quiet by default. - **Governance**: `familiar_response`, `rubric_gate`, `groom_signal` - **End**: `done`, `error` ## Please design - The step and status display driven by `frame_status` - Live output while a block is still streaming, and how it settles once the block ends - Which load events are shown, and how quietly - Cancel while running (always visible), error and retry, and "try another backend" This also answers the open "streaming output slot" question in `SHAPES.md`. ## Acceptance criteria - [ ] A treatment for every `StreamEvent` type, including "hidden by default" where that's right. - [ ] Running, cancelled, error and retry states. - [ ] CLI rendering.

ville was assigned by peterswimm

2026-10-04 20:20:35 +00:00

~~peterswimm referenced this issue from Toilville/rituals-api-spec 2026-10-04 20:21:33 +00:00~~

Events → commands → views contract: available_commands, command submit, view/lens registry, events stream #15

peterswimm referenced this issue

2026-10-04 20:24:17 +00:00

Rituals: house-style views over ritual events, with user lenses #177

peterswimm changed title from ~~Rituals pattern: run progress, streaming and cancel~~ to Rituals views: how each StreamEvent looks during a run

2026-10-04 20:34:14 +00:00

peterswimm referenced this issue

2026-10-04 20:34:28 +00:00

Rituals: house-style views over ritual events, with user lenses #177