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

---
id: USER-WP-0028
type: workplan
title: "User account journeys and recovery"
domain: communication
repo: user-engine
status: blocked
flavor: implementation
owner: codex
topic_slug: communication
created: "2026-09-13"
updated: "2026-10-11"
state_hub_workstream_id: "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

```task
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

```task
id: USER-WP-0028-T02
status: wait
depends_on: [USER-WP-0026-T03]
blocking_reason: "U09 reuses USER-WP-0026-T03 actual signed-in readback acceptance. T05 separately needs selection of the exact authoritative mutation fact and owner, then scoped mutation/revocation acceptance. Access readback delivers no generic grant API and FLEX-WP-0035 remains finished."
priority: high
state_hub_task_id: "5d1bf977-034d-5448-b4fb-5a8b630af6ba"
```

U09: accept signed-in application discovery using the delivered three-way catalogue and advisory Access readback, reusing USER-WP-0026-T03. T05: first select the authoritative fact to mutate and its owner, then accept the supported scoped mutation and input-specific revocation path. Product memberships are User-owned unless an explicit import contract says otherwise; IAM owns coarse groups/roles, Tenant owns tenant-role grants and Access owns reviewed policy/registry. Every protected mutation remains Access-evaluated. The accepted readback contract gives no user-domain grant API. Static links, membership or advisory availability are never effective permission inside an application.

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

```task
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: actual signed-in human account projection is not
established by SERVICE or synthetic policy checks. Initial application
discovery acceptance does not wait for a new generic Access grant API. 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.


2026-10-11 ownership requalification after Access owner review: the accepted
application-access-readback contract §§2/8 supplies advisory application.access
only; it confers no rights inside applications and supplies no user-domain
grant/revoke API. FLEX-WP-0035 is finished and remains so. Earlier broad
"Access grant/revocation contract" wording does not create a new provider debt.
USER-WP-0026-T03 initial discovery needs real signed-in account projection with
KeyCape human authentication; record this as a separate human decision
commitment, not an unanswered Access message. Ordinary catalogue-management
restoration is a distinct live obligation on the same existing task before
customers. User owns application.register/binding/audit/event/deployment;
Access supports exact check vocabulary and reviewed policy/claims admission
through FLEX-IN-0003. The Custodian projects that bounded obligor-response
case separately; no duplicate User intake or cloned task is created.

USER-WP-0028-T02 U09 reuses signed-in readback acceptance. For T05 first name
the changed authoritative fact and select its owner: User product application
membership, IAM coarse group/role, Tenant tenant-role grant, or Access reviewed
policy/registry. Then review/accept its supported scope and mutation path with
Access evaluation, rather than requesting an invented generic grant endpoint.
Revocation evidence must identify that input class: claim change, policy
activation and allow expiry differ. Membership deletion or logout cannot
establish global revocation of already-issued JWTs. Real U05-U08 MFA journey
acceptance remains the separate existing USER-WP-0028-T03 decision gate.
Native2rows/1ledger/3audits/1unsent-event and honest SERVICE/synthetic boundaries
remain unchanged; no further native action is approved or performed here.