fabro/lib/apps
Bryan Helmkamp e0b546d465
Read the view tables where the run summary store keeps them
The projector takes two pools: the one Petri's records live in and the
one the view tables live in. In the server both are the one database;
a test fixture keeps the runs row, the platform records and the
projection tables in the run summary store's own pool, which the
projector was not reading, so a run projected in a test server folded
its Petri events before its run.created record. The startup run-history
verification checks only a Petri run's identity and legacy guard, since
its row is the projector's. An agent stage's response is the
response.<node> its outcome wrote into the run context, as the prompt
step writes it. The scenario tests assert each branch's own index.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-17 22:49:15 -04:00
..
fabro-cli Run a Petri run in the worker process over the HTTP store 2026-09-17 21:20:22 -04:00
fabro-mcp-server Simplify run creation to registered workflow versions 2026-09-12 11:04:15 -06:00
fabro-server Read the view tables where the run summary store keeps them 2026-09-17 22:49:15 -04:00
fabro-spa refactor: organize crates into three layers 2026-07-23 17:59:34 -04:00