Task: Inventory the routes and operations the credentials journeys need

Give the group one page that says, for every credentials step, whether the operation exists, what carries it, whether the browser can reach it and what permission it needs. The per-screen findings the prototypes recorded mix three different problems — a missing subject, a missing route and a handler that answers with nothing — and each has a different owner and cost. The build tasks are sized from this page.

The answer does not depend on which variant the product owner picks, because no variant changes what the server serves, so this work could proceed while the prototypes are under review.

• Every step of the three journeys has its subject, its ores.http route, its BFF route and its permission, on the investigation.
• Every claim carries the command that produced it, and the snapshot names its commit.
• The four kinds of gap are separated, so a route gap is not sized as a subject gap.
• The defect the census found is filed as its own capture, not as a journey gap.
• The story's * Documents table links the investigation.
• compass lint passes.

1. Count the routes on both HTTP surfaces: the BFF, which the browser reaches, and ores.http, which it does not.
2. List the subjects from the generated protocol, so the census does not inherit a design document's claim.
3. Check the permission each operation needs against the handler's guard, and against the catalogue that grants it.
4. Read the handlers the journeys' subjects reach, to separate a handler that answers with no rows from one that answers.
5. Write the per-journey tables, the gap counts and the recommendations.
6. File the defect the census found.

• The census was run twice: once against the BFF alone, which concluded that nothing serves the credentials data, and once against both surfaces, which is the record. The first pass is kept in the investigation's * Paths taken, because the mistake is the reusable part: an ores.http route is not a browser read.
• The permission column checks the handler's guard, not the catalogue. The two disagree twice: sessions:delete is required and never granted, and sessions:read is granted and never required.

Done 2026-09-30. Snapshot: commit dbbde296d0.

The investigation The routes and operations the credentials journeys need carries a table per journey — step, subject, ores.http route, BFF route, permission — and the totals:

The defect: list_sessions, get_session and get_many_sessions check no permission, while the account reads check iam::accounts:read and the login-record reads check iam::login_info:read. The catalogue grants iam::sessions:read for exactly this purpose. Filed as The session read handlers skip the permission check the catalogue grants.

Verification: compass lint passes, and the durable-document link advisory is unchanged. Every count was produced by the command in the investigation's * Methodology table, run at the snapshot commit. The backlog indexes were regenerated, so the new capture is in the inbox index.