user-engine/workplans/USER-WP-0026-account-recovery.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	state_hub_workstream_id
USER-WP-0026	workplan	Account recovery and visible identity and access	communication	user-engine	blocked	implementation	codex	user-engine	2026-09-12	2026-10-09	0aea0a52-13f9-515b-bda8-665f8a4f2d5e

The operator reports a dead-end authentication error after using an account outside the product tenant. Recent issuer telemetry indicates token exchange failure; tenant rejection and provider failure must not be conflated.

Implement and validate recovery

id: USER-WP-0026-T01
status: done
priority: high
state_hub_task_id: "86324ec8-cf2f-5e9e-bb60-670c4d792828"

Route failed browser login to the public account recovery surface without codes, state or unverified identity. Show verified portal identity, tenant memberships, and recorded workload memberships; preserve operator/customer separation. Provide CSRF-protected portal logout and confirmed shared provider sign-out with fixed owner-configured return locations. No automatic reauthentication loops, MFA downgrade, global JWT revocation claim or inferred workload entitlements.

Publish and verify the recovery flow

id: USER-WP-0026-T02
status: done
priority: high
state_hub_task_id: "ad5b0a77-d8ec-5e07-9a9e-2fa231a6f792"

Publish immutable images, update canonical runtime pins, verify anonymous recovery and sign-out confirmation live, and record actual account switching only after browser evidence. Existing application sessions may outlive provider logout. Related: USER-WP-0025-T03 and VERGABE-WP-0019-T06.

Source verification: 182 tests passed with three optional integration skips; layer conformance passed. Immutable publication and live checks are in progress.

2026-09-27: closed against the completed release and attended owner evidence. The 2026-09-12 release receipt is supplemented by key-cape/docs/evidence/2026-09-24-fresh-login-and-account-switch.md: the founder confirmed fresh login and account switching, and the issuer recorded three fresh portal authentication/token-issuance sequences after an MFA failure. KEY-WP-0034-T02 is done. Existing application JWTs may still outlive provider logout. This does not accept the remaining multi-user Vergabe pilot.

Discover workload access from authoritative application records

id: USER-WP-0026-T03
status: wait
blocked_on: message-from:access-engine
blocking_reason: "Needs access-engine's per-identity decision/grant/revocation/readback contract and a readable protected-system registry (with key-cape client binding) as the workload catalogue; the membership store cannot represent the allow list."
priority: high
state_hub_task_id: "95e9a6d4-7e57-5483-97c5-3f4a45bb6767"

The requested cross-application allow list is not represented by the current User Engine membership store. Establish a provider-owned workload catalogue and read current application access decisions for the signed-in identity. Link only registered HTTPS workload entry points. Distinguish allow, deny and unavailable; never turn a tenant membership, platform role, application registration or a missing access record into an inferred grant. Current UI displays recorded workload memberships only; no complete fleet entitlement inventory is claimed.

2026-10-09: net-kingdom answered (hub message 19a0cbcd, 2026-10-03) that it owns neither record. Decisions, scoped grants, revocation and readback belong to access-engine, the only PDP. The workload catalogue is the binding of three records: access-engine protected-system registration, key-cape OIDC client (entry points) and the user-engine application record. A workload is listed only when all three exist and are bound. "Unavailable" is the PEP outcome when no decision is returned, never an inferred allow. Wait retargeted to access-engine. Ask filed for the decision/readback contract and a readable protected-system registry. If access-engine declines, return to net-kingdom for an orchestration workplan.

Live recovery rollout — 2026-09-12

Recovery is deployed in KeyCape 4d8b8fe, User Engine e54b6ee and Vergabe c067993 (Helm revision 3). All three are Ready. Six provider checks, eleven product checks and six fresh anonymous Chromium checks pass, including actual provider logout POST and return to the portal without test overrides. Real-user identity switching is still awaiting operator evidence; no authenticated/MFA acceptance is inferred. Detailed receipt: railiance-apps/docs/evidence/2026-09-12-account-recovery-live.md.

2026-09-27: blocked on an owner-supported workload catalogue/admission and scoped grant/revocation contract. The access-engine policy evaluator and local user-engine application/membership records do not establish that contract. Need registered HTTPS entry points, exact identity/tenant/action mapping, authoritative allow/deny/unavailable results, and scoped mutation/readback semantics from the application and authorization owners. Continues jointly with USER-WP-0028-T02; no local grant inference or substitute catalogue was added.

2026-10-03 (CUST-WP-0075 inbox sweep): the net-kingdom reply of 2026-09-29 (f1b61ee9) concerns root-grant custody for USER-WP-0037-T02 and does not address the workload catalogue. No request had ever been sent for this task despite its message-from:net-kingdom qualifier (added 2026-09-28). Sent one now (message db1b7d6e): does NetKingdom own the workload catalogue/admission record and the scoped access-decision contract, and if not, who does. The qualifier stays on net-kingdom until it answers or names another owner.