fabro/lib/apps/fabro-cli/tests
Bryan Helmkamp a6ac3f120e
Give a Petri question one identity across the adapter and the projection
The interview adapter derived its own question id from Petri's identity
and posted it on `interview.started`, while the projection over Petri's
records serves the pending question under Petri's `Question.id` with the
firing's stage label. The answer endpoint validates against the
projection, so an answer under the projection's id never reached the
adapter's wait.

The adapter now waits under Petri's id and labels the question's stage
through the projection's own rule: `stage_label`, `is_shown` and
`visit_of` move out of `start_visit` into shared functions, and the
adapter's observer derives each firing's `visit.started` through Petri's
`Projection`, as the projector does, so the label matches by
construction. The full Petri identity stays on `AskedQuestion`.

The legacy `interview.*` events are still posted, under Petri's id, for
the readers that follow the event stream rather than the projection: the
Slack service, `run attach`, the web app's Q&A renderer and the server's
answer claim. The store already derives the `interview.answered` platform
record from `interview.completed` for a Petri run, so who answered is
recorded under Petri's id with the answering principal.

The gate scenarios assert the new identity and encode the id as one path
segment, as the generated clients do. Projection tests cover an expired
question and an auto-approved answer.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-18 00:19:30 -04:00
..
it Give a Petri question one identity across the adapter and the projection 2026-09-18 00:19:30 -04:00
build_git_metadata.rs refactor: organize crates into three layers 2026-07-23 17:59:34 -04:00
manifest_path_round_trip.rs refactor: organize crates into three layers 2026-07-23 17:59:34 -04:00