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-11	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
needs_human: true
blocking_reason: "Actual one-app catalogue/readback is verified. Initial discovery acceptance needs real signed-in account projection, not a generic Access grant API. Separate ordinary catalogue-management restoration remains on this task before customers, supported by bounded Access policy/claims proposal FLEX-IN-0003; do not reopen finished FLEX-WP-0035."
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.

2026-10-09 (later): access-engine accepted the ask as FLEX-WP-0035 and sent the draft contract docs/application-access-readback.md (9d9ca69, FLEX-DEC-2026-019) for review. user-engine reviewed it and replied (hub message f54df082). Shape accepted: dedicated readback pin, purpose=readback in the hashed request, per-package application.access, no grant surface. Answers: forward verified claims, in the same subject shape as /v1/check, plus subject.tenant; informed-decision first; 64 per request is enough; reuse each row until expires_at, per session and only on account-page views. Requested: application.access rules may use only realm-level IAM Profile claims, because the session claims carry user-engine's audience. Render deny, not_applicable, failure and expired as not available, never as allow. Use a separate USER_ENGINE_READBACK_TOKEN_FILE. Wait stays on access-engine T02/T03 code and its T04 founder go.

2026-10-10: access-engine folded amendments (a)-(c) into the contract, accepted FLEX-DEC-2026-019 and shipped T02/T03 (8f2ba75). T05 (b5da745) gives informed-decision a separate application.access rule. user-engine's client is now in the repo, off by default: application_access.py, adapters/application_access.py, the account-page section, and USER_ENGINE_READBACK_URL / USER_ENGINE_READBACK_TOKEN_FILE (see docs/configuration.md). A workload is listed only when all three records are bound. Rows follow the agreed rendering table, and none is inferred as allow. Remaining before this task is done: access-engine T04 (readback pin values, digest-equality test, founder go), operator-installed readback URL and token file, and a live check against the pin.

2026-10-10: access-engine gave the T04 values (hub 12cefad4), not live yet. URL http://flex-auth-application-readback.flex-auth.svc.cluster.local.:8080 (the trailing dot is required). Projected service-account token audience flex-auth, the same as the /v1/check pin. The admitted caller is system:serviceaccount:user-engine:user-engine, for readback routes only. The operator change goes into the apply home, rapp-user-engine manifests/runtime.yaml: set USER_ENGINE_READBACK_URL, mount a second projected token, and set USER_ENGINE_READBACK_TOKEN_FILE. T04 itself waits on informed-decision accepting lifecycle v2, then the founder go.

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.

2026-10-10 security consolidation review: FLEX-WP-0035-T04 is done. Its founder-run Helm upgrades placed lifecycle v2 and application-readback on image e8c57c18; Ready and anonymous 401/non-enforcement 404 checks passed. Those provider receipts do not establish user-engine caller acceptance. The canonical apply home, rapp-user-engine/manifests/runtime.yaml, currently has no readback URL or dedicated projected-token mount and permits flex-auth egress only to the enforcement pin. Remaining owner work: wire USER_ENGINE_READBACK_URL and USER_ENGINE_READBACK_TOKEN_FILE to a separate audience flex-auth projection, permit only the application-readback pod selector, promote the immutable image containing this client, and verify native consumer readback without disclosing a token. Reuse that acceptance for USER-WP-0028-T02; it is the same integration boundary. No grant, browser acceptance or live deployment is inferred here.

The local readback cache now binds each row set to tenant as well as session, issuer and subject. A tenant switch within the same session therefore performs a fresh read instead of displaying another tenant's unexpired allow. A focused regression exercises an allow in tenant-a followed by a deny in tenant-b.

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.