fabro/lib/apps/fabro-server
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
..
migrations Run fabro exec through pebble's command-line session 2026-09-11 20:51:01 -06:00
src Read the view tables where the run summary store keeps them 2026-09-17 22:49:15 -04:00
tests Read the view tables where the run summary store keeps them 2026-09-17 22:49:15 -04:00
build.rs refactor: organize crates into three layers 2026-07-23 17:59:34 -04:00
Cargo.toml Run a workflow through Petri in the server, behind the engine flag 2026-09-17 20:27:44 -04:00