Bryan Helmkamp 523f831a7a Serve a Petri run's events as one stream with a stream_seq cursor ... `GET /runs/{id}/events` and `GET /runs/{id}/attach` serve a Petri run's public events and Fabro's platform records as one ordered stream in a Fabro envelope (`RunStreamItem`: `run_id`, `stream_seq`, `kind`, `id`, `recorded_at`, `item`), read from the projector's `petri_stream` table. The cursor is `stream_seq` (`?after=`); the item's own identity (the Petri `EventId` as `<log>/<seq>/<index>`, or the platform record's seq) travels beside it for deduplication. A legacy run keeps its envelope on the same endpoints; the OpenAPI response is the union of the two lists, and the stream list reports Petri's `EVENT_CONTRACT_VERSION`. The attached stream follows the projector's commit signal (a wake-up, with a poll as the fallback) and ends after the platform record of the run's terminal lifecycle transition, the analog of the legacy stream's `run.completed`, or a bounded grace after the projection went terminal. `RunSpec.engine` (`RunEngine`, `PetriAdmission`, `PetriGraphRef`) is named in the spec and reuses the Rust types. `fabro-client` matches the union and adds `list_run_stream`, `list_run_stream_page` and `attach_run_stream`. A server test attaches to a two-branch parallel run, disconnects once both branches started, records a platform notice while both branch scripts run, reconnects from the last `stream_seq`, and checks the union is the whole stream: every item once, in order, no gap, no duplicate, the notice between the branch events, and the same as the paged listing. The Petri scenarios capture their settled projection and stream as JSON fixtures for the web app under `FABRO_CAPTURE_PETRI_FIXTURES`. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>		2026-09-18 00:47:26 -04:00
..
fixtures/spa	refactor: organize crates into three layers	2026-07-23 17:59:34 -04:00
it	Serve a Petri run's events as one stream with a stream_seq cursor	2026-09-18 00:47:26 -04:00