user-engine/workplans/USER-WP-0028-user-journey-acceptance.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	state_hub_workstream_id
USER-WP-0028	workplan	User account journeys and recovery	communication	user-engine	blocked	implementation	codex	communication	2026-09-13	2026-10-11	145df9d5-a7e9-5d20-8280-9d3ea069838b

Implements docs/account-journeys.md under USER-WP-0027. A passing local suite is not evidence that an external provider flow works live.

Complete self-service feedback and safe retries

id: USER-WP-0028-T01
status: done
priority: high
state_hub_task_id: "baa9938e-271b-5590-bdc0-5c844070144c"

U01–U04/U10–U13: preserve safe profile input on validation failure; confirm saves, expose actual login name at password handoff, keep invitation/expired/session recovery reachable. Cover success, denial, provider interruption and retry.

Connect authoritative application access

id: USER-WP-0028-T02
status: wait
depends_on: [USER-WP-0026-T03]
blocking_reason: "Actual one-app catalogue/readback verified under native R1 exception. Reuses USER-WP-0026-T03 for supported scoped grant/revocation, signed-in human account projection and ordinary authenticated management restoration; no complete U09/T05 claim from SERVICE/synthetic evidence."
priority: high
state_hub_task_id: "5d1bf977-034d-5448-b4fb-5a8b630af6ba"

U09 and T05: integrate a supported catalogue/admission source and scoped grants/revocation. Do not present static links or membership as effective authorization. Continues USER-WP-0026-T03; establish provider contract before deployment.

2026-09-27: blocked on the provider-owned catalogue/admission and scoped application grant/revocation contract described in USER-WP-0026-T03. Current membership CRUD and PDP evaluation cannot supply fleet-wide admission or mutate application-owned grants. Resume integration after owners identify the supported source, entry-point registry, identity/action mapping and mutation contract.

Complete optional OTP onboarding with provider evidence

id: USER-WP-0028-T03
status: wait
needs_human: true
decision_id: cef97ccd-4ee7-40fe-859e-1df9c9360ecb
blocking_reason: "Attended live acceptance of U05-U08 (enrollment, cancel, replace, lost-factor recovery, old-AAL1-session behavior) against the real provider factor before enabling live handoff; no stub acceptance."
priority: high
state_hub_task_id: "40e46e52-31ac-5abd-8793-04c1b7b82df3"

2026-10-03: depends_on targets terminal (C-40); re-qualified by CUST-WP-0075: KEY-WP-0035 and NK-WP-0033 are both finished (custody gap closed 2026-09-23), so credential custody is no longer the gate. What remains is attended live acceptance of U05-U08 with a real OTP factor; see USER-WP-0027-T04 for the still-unresolvable net-kingdom-privacyidea-admin-token route (owner railiance-platform).

U05–U08: depends on KEY-WP-0035 and NK-WP-0033 credential custody. Verify enrollment/cancel/replace/lost-factor recovery and old-AAL1-session behavior before enabling live handoff. No stub acceptance.

Validation: 210 database-enabled regression tests passed with no skips, including independent-connection last-admin protection and nested bootstrap rollback. Thirteen isolated Chromium checks passed. Provider OTP and application access integration remain explicitly open; no complete-journey claim is inferred.

2026-09-27: credential custody and optional-policy rollout are complete (KEY-WP-0035, RPF-WP-0040); NK-WP-0033 is also finished. The earlier missing- credential dependency is superseded. P04/P06 installed-provider evidence covers enrollment/cancellation, recovery/replacement and old-session enforcement. The remaining blocker is attended real-user U05–U08 acceptance and verified portal setup handoff, not another service token. See USER-WP-0027-T04 and docs/evidence/2026-09-13-p06-authentication-policy.md.

2026-10-03: human gate routed to hub decision cef97ccd-4ee7-40fe-859e-1df9c9360ecb (D10: Identity record and MFA: accept NK-ADR-0017, choose the record read surface, agree the MFA user experience) by CUST-WP-0075; resolving that decision raises C-40 here.

2026-10-09: founder chose coulomb-social as the MFA pilot (docs/mfa-pilot-decision.md). MFA stays optional there, and all MFA code stays in NetKingdom infrastructure: the issuer plus user-engine. Admin-required MFA is deferred and would be an issuer-side client policy. The attended run accepts U05-U08 for a coulomb-social user: optional enrollment, then return, then lost-factor recovery. cef97ccd stays open for that acceptance.

2026-10-10: founder asked (via ops-mason, hub ab89a591) for self-service MFA setup for all users, with tegwick as the first attended run. The run is prepared in docs/mfa-attended-run.md. It covers the start point, the attended steps, evidence rules (no seeds, codes or QR), the handoff URL and what stays deferred. It needs the founder's go to set USER_ENGINE_MFA_MANAGEMENT_URL, and a decision on whether tegwick joins the coulomb-social pilot.

2026-10-10 (later): the founder approved both points. tegwick runs U05-U08 on coulomb-social; there is no pilot member list, a first sign-in is enough. The handoff URL change was sent to net-kingdom (hub 58e999b3), env only. Next: net-kingdom's rollout reply, then the attended run with tegwick.

2026-10-10: net-kingdom replied (7ee2459e) that the handoff URL was already live from rapp-user-engine manifests/runtime.yaml, the apply home. The net-kingdom file is migration input only. Public /security verified showing the pink-account link. Next: the attended run with tegwick.

2026-10-11 actual native integration update: confirmed scoped R2 approval0dd18a5a-5555-461e-8470-931d530435cf allowed root to apply only the published User Engine Deployment and runtime NP; Ready1 generation73 on imagef239. The admitted User Engine workload's installed adapter now reaches the real readback registry and produces bounded allow/deny/stale-MFA synthetic policy results; tenant-separated cache, allow expiry and unavailable transport checks pass. Existing enforcement remains healthy and denies the checked unknown action; purpose-bearing application.access also denies, but current source's explicit400 purpose rejection is not proven on the older native provider. That is a distinct Access owner runtime gap, not a consumer regression or new grant.

Read-only actual catalogue query found zero local application bindings/apps. Access advertises informed-decision and the actual KeyCape informed-decision-approver client independently rejects an unregistered redirect, but the third User Engine application record is absent. The local catalogue registration implementation is User Engine-owned; informed-decision owns its application registration facts and Access owns the protected system/client contract. Obtain an exact supported registration/admission proposal and application-owner return before any native record mutation; no seed or fake record was created under the two-object approval. USER-WP-0026-T03 / USER-WP-0028-T02 remain open for actual bound catalogue and broader scoped grant/revocation acceptance. Browser login/MFA tasks retain their separate human gates. Full receipts: rapp-user-engine/docs/evidence/2026-10-11-native-readback.

2026-10-11 native R1 catalogue milestone (02:10Z): the founder accepted infd-20261011-user-catalogue-bootstrap-r1, approval b859698b-5d08-4da5-9599-4760c6a799f1. Root's exact approved standalone dry-run and apply committed Application informed-decision and its OIDC informed-decision-approver / protected-system informed-decision binding. Independent READ ONLY verification proves 2 rows, 1 digest-bound consumed ledger, 3 truthfully maintenance SERVICE-attributed audits including genuine ordinary PDP deny and no maintenance PDP allow ID, and 1 attributed registered event. Fresh Access registry and native KeyCape known-client/wrong-redirect check bind the actual three-way catalogue. The installed account reader joins real rows and renders the maintenance SERVICE denied; native labelled policy fixtures pass allow/deny/expiry/unavailable/tenant-cache checks. Evidence: docs/evidence/2026-10-11-one-app-catalogue-native-acceptance/README.md.

The missing local catalogue record and consumer runtime-wiring blockers are resolved for this one application. This task stays wait: owner-supported scoped grant/revocation semantics and actual signed-in human account projection are not established by SERVICE or synthetic policy checks. Ordinary authenticated catalogue-management admission must be implemented and verified before customer production; retain this follow-up on existing USER-WP-0026-T03 and its reuse in USER-WP-0028-T02, linked to the single Custodian close-down exception row. No duplicate intake or leftover only in prose is created. Never infer entitlement from catalogue/membership facts. Real OTP/browser journey acceptance remains separate. At verification the original event was unclaimed/undelivered with no consumer receipt; maintenance authority grants no targeted delivery/replay.