Story: Implement the entry journeys in ores.web

The two Entry journeys run in ores.web against the real server. Sign in is finished: every refusal says which refusal it is, the forced password change blocks the workspace until the member sets a password of their own, the party step names the places a person works and marks their default, and a lapsed party-selection token returns them to the door with words rather than a generic failure. Sign up is added end to end: the deployment states whether it accepts self-registration, the screen reads that answer before it offers a form, the server refuses the registration it should never have accepted, and the person is told exactly what their new account has and what it still waits for. Registration's end state is the subject of the analysis this story opens with, because where a new account lands is a platform decision, not a screen decision.

• Every item of the User Journey Extraction Standard's Entry-journey section passes, with its evidence recorded.
• The sign-up process is analysed end to end, and the target state it lands on is recorded in a knowledge document before any registration code changes.
• The server refuses a registration when the deployment's self-registration flag is off, and every refusal carries a code the client can branch on.
• Sign in runs against the real server from an empty installation through to the workspace, and every branch the journey document names has a screen state.
• Sign up runs against the real server, and the confirmation states what the new account received and what it still waits for.
• Both journeys are reachable and behaved on the shell as well as the browser, or the difference is stated and recorded.

• A default lives on the row its actor may write. Row-level security decides who may set a value, so a default nobody can set is not a default. The tenant flag belongs to the super administrator, because only a system-tenant session may write a tenant row; the party and role flags belong to the tenant administrator, because those tables are tenant-isolated.
• A boolean stays a setting; a reference becomes a flag. The two registration flags have no referent and stay in the variability settings, where they already live. A default party or role is a reference, and stored as a string it can name a row that does not exist — which is the failure mode of the hard-coded Viewer it replaces.
• Waiting is a state, not an absence. A new account_status of pending is written when the tenant nominates no default party, read by the roster, and refused by sign-in with its own code and its own words.
• The door asks one policy read, iam.v1.auth.registration-policy, separate from the bootstrap read: one answers what the deployment offers a person who is not in it, the other whether the deployment has been set up.
• The address names the tenant. Both Entry journeys resolve the tenant from the address they are served at, so the person types a username and not a user@hostname. A registration that resolves to no tenant is refused with a reason; it never falls back to the system tenant by omission.
• A refusal is a code. Both responses gain error_code, so a screen branches on a value rather than on English prose.
• The authorisation flag closes the door honestly. Until the approval workflow exists, system.signup_requires_authorization closes registration and the policy read states why. It must not claim an approval that nothing performs.
• The setup journeys own the defaults, not the sign-up screen. The person who opens the door is not the person who decides what it opens onto, so First run confirms the first tenant as the default tenant and states whether the installation accepts self-registration, and its first sign-in lets the tenant administrator nominate the party and the role. New tenant and New party ask the same questions when they create a tenant or a party later. The three Setup journey documents now carry those steps. The screen work belongs to the setup story, which owns the setup screens; this story supplies the model, the policy read and the write paths they call.
• The switch is the deployment's, and it is read at system scope. system.user_signups is seeded on the system tenant and defaults to false, so a deployment nobody has asked refuses registration. A tenant override is possible but nothing sets one, and the door reports the deployment's answer rather than inventing a per-tenant one.
• The door is a step rail, and it is the provisioning rail. The registration screen uses the same flat rail the setup journeys use: one step at a time, a circled mark per step, the step in a card, the action in a footer under a rule, and the write deferred to a review step. The design was accepted as a prototype and reworked to that shape; the losing variants stay on the prototype page as the record.
• Every Entry dialog carries the ORE Studio banner. The setup screen already leads with the project's artwork, so the sign-in and sign-up dialogs carry it too. Because this is about every door and not about one screen, it is a task of its own rather than a line in the screen work.
• Asking for more roles is its own journey. Registration grants one default role. A person who needs more than that asks for it, after registration, and somebody else answers, which is two actors and two endings: it is not a step of the door. The journey document is a task here; its screens belong to the Access group.
• The rail and the splash header are the application's, not each screen's. Every screen that sets something up renders on JourneyPage's rail and carries JourneyHeader's splash, unchanged. The setup journeys do, the registration door will, and the sign-in dialog carries the same splash above its form even though it has no rail. The splash keeps its 964:323 ratio and nothing crops it: a stated height that is not the ratio's is what cut the top and the foot off the wordmark. A screen that draws its own rail or banner is a defect, not a variation, and the prototype was corrected on both counts.
• The target state lands with the fix, by the product owner's choice. The open registration door stays open until the implementation lands. That is a known and accepted risk for the duration of the work, and it is the reason the flag enforcement is the first implementation task rather than the last.

• The approval workflow behind system.signup_requires_authorization, which is a workflow in ores.workflow.
• Email verification, invitation delivery and the notification that tells an administrator somebody is waiting.
• Self-service password recovery from the door, which needs a delivery mechanism outside IAM.
• The Directory screens that release a pending account and show it on the roster. The target state states the requirement; Directory journeys owns the screen.

Both journeys run. The server refuses the registration it should never have accepted, resolves the tenant from the address, and writes the state; the BFF serves the policy read and the sign-up route; and the door renders the closed notice or the same rail the setup journeys use, with the confirmation naming what the account received and what it still waits for. The sign-in dialog and the door carry the same banner element as the setup journeys. Asking for more roles is the Access group's own journey, and it is written.