Story: Implement the user journeys in ores.web

Every journey in the User Journeys catalogue runs in ores.web, against the real server. The catalogue holds 30 journeys in nine topic groups. This story orders the groups. Each group has its own story, and each of those carries its own completion.

This is the third pass of the sprint 26 mission. The first pass put every component on the Component Clean Standard. The second extracts the journeys and is still in flight. The journeys are design documents and they do not change here. This pass builds from them.

The first group writes the journey runtime, and every later group uses it. The runtime is the reason this is a programme and not one long story: a journey is an ordered list of steps, one page renders the list, and the work of the second group is then the steps alone.

• Every journey in the User Journeys catalogue is implemented in ores.web and runs against the real server.
• Every group below has a story, and that story is DONE.
• The journey runtime and the step-call contract are written once, in the first group, and every later group uses them unchanged.
• Every gap a journey document records is either closed or stated on the screen, and the statement is recorded.

The order follows dependency, not the catalogue's order. The catalogue is ordered by how a reader learns the system; this is ordered by what unblocks what.

Setup is first for two reasons. It is the only group that runs on an empty installation, so it is the only one that can be demonstrated from nothing. And First run expands the new tenant steps inline, so the Setup story lands the shared step library that every later group reads.

Entry is second although First run ends in a sign-in. The sign-in itself already works through POST /api/session; what the Entry story adds is the screen, self-registration, and the failure paths.

Operations is last. It is the catalogue's newest group and the only one whose design arrived settled: its journeys were written and accepted before its story opened. It needs the runtime and nothing else, so this row is a matter of when its group is built, not what it waits on.

• One story per group, and the catalogue's grouping is the implementation grouping. Journeys are grouped by the topic a designer looks them up under, never by component. A component is an implementation concept and it moves; what a person is trying to do does not.
• The runtime is written once. A journey is an ordered list of step definitions. One page renders the flat rail from that same list, so the rail cannot drift from the steps. The first group settles the contract; a later group that needs it changed records why rather than forking it.
• The build targets the accepted contracts. Both sprint 25 decisions are recorded in the prototype tasks and both are the target: the bootstrap workflow catalogue and the seed profile contract. The build does not add a client path to a subject the design has retired. iam.v1.bootstrap.provision-tenant and iam.v1.tenants.provision-acme are used only until the generic request replaces them, and no new code depends on them.
• The journey is not server-side; its state is. The state is a workflow instance, which already carries the kind, the current step, the request, the result and the error. No journey entity is added. Journey execution records the reasoning and supersedes the sprint 25 plan for a /journey/ entity.
• The extraction story owns the journey documents. The build does not rewrite them. Where the build proves a journey document wrong, the correction goes to that document and is recorded in the story that found it.
• The prototype branches are the design record and are ported, not merged. They predate the removal of the generated screens, so they still carry the entity framework. The reduction commit e47043269f names what went and why.
• A cross-sprint story closes DONE and gets a successor. The catalogue needs more than one sprint, so a group that does not close in sprint 26 closes with what landed and continues in a successor story.
• ores.web has its own standard. The Component Clean Standard is written around SQL, a repository, a service and a generated registrar, and the TypeScript packages have none of those. The TypeScript Clean Standard is its sibling: the same shape, one item per convention, and every item naming the check that proves it. It is written before the first line of journey code, because a convention recorded afterwards is a convention nobody followed.
• Every journey has two clients. ores.web and ores.shell run the same server-side operation for each stage, so a journey is implemented once on the server and reached from both. The shell already carries several journeys as porcelain commands, and three recipes under doc/recipes/shell/provisioning/ run a whole system provisioning, one per provisioning path: acme_system_provision.org, barclays_system_provision.org and how_do_i_provision_the_system_with_acme_corporation_holding_group.org. A group's story therefore carries the shell side of its journeys in the same group, and a group that lines up only the browser has moved the disagreement rather than removed it.
• A client's orchestration moves to the server, it is not duplicated. Where the shell drives several calls in sequence today, the accepted contracts put that sequence in one request. Both clients then call the same subject and neither owns the order.

• The journey extraction, which is Extract the user journeys that replace the ores.qt screens.
• The removal of the Qt remnants, which is Remove the legacy Qt remnants.
• ores.qt, which is frozen as reference, and the Wt client, which was removed with it.
• The journeys the catalogue does not hold yet. A component with no UX gets no journey, and its story adds none.