Close recovery acceptance and reconcile blocked workplans
Some checks are pending
CI Smoke / host-smoke (push) Waiting to run
CI Smoke / container-smoke (push) Waiting to run
Account journey acceptance / journeys (push) Successful in 10s

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e38e-e5bb-7b50-968d-a738a0294997
This commit is contained in:
tegwick 2026-09-27 17:54:47 +02:00
parent b73f553c18
commit eca7c54748
9 changed files with 162 additions and 46 deletions

View file

@ -2,9 +2,9 @@
Owner: user-engine, with KeyCape/NetKingdom for sign-in and factors,
tenant-engine for tenant lifecycle, and applications for workload admission.
Acceptance work: USER-WP-0027; OTP dependency: KEY-WP-0035 and NK-WP-0033.
Acceptance work: USER-WP-0027/0028; provider implementation: KEY-WP-0035 (finished).
Reviewed against the portal on 2026-09-13. U01, U09 and U10 were revised on
2026-09-26. This is the browser acceptance contract;
2026-09-26; acceptance dependencies were reconciled on 2026-09-27. This is the browser acceptance contract;
headless capability alone does not mean a journey is usable or verified live.
## Common interaction rules
@ -43,16 +43,16 @@ headless capability alone does not mean a journey is usable or verified live.
| ID / intent | Success | Failure and recovery | Current support / acceptance |
|---|---|---|---|
| U01 — Know whether I am signed in | Header and the home page say “Signed in as” the verified identity when an account-site session exists. With no account-site session they say “Not signed in,” unless the sign-in service confirms an existing NetKingdom identity, which is then named before the account site continues. An application may keep its own session. A one-time code is a higher security level, not another sign-in | Expired/unknown cookie shows signed-out state; a query does not invent a session; a failed identity lookup stays signed out; sign in again, or use a different identity | Implemented; automated anonymous/expired/member/operator tests, including the home identity section and a confirmed NetKingdom sign-in with no account-site session |
| U02 — Sign in to my company application | Personal login lands in the intended tenant and application | Wrong credentials stay on provider; denied membership leads to account help with identity switching | Recovery deployed previously; actual fresh-user acceptance waiting on OTP |
| U02 — Sign in to my company application | Personal login lands in the intended tenant and application | Wrong credentials stay on provider; denied membership leads to account help with identity switching | Fresh application login confirmed on September 24; second-user, setup-to-welcome and company-workflow acceptance remain VERGABE-WP-0019-T06 |
| U03 — Accept an invitation | Confirm intended tenant/role, accept once, then see next setup step | Expired/used/wrong-person invitation explains next step; admin reissues without duplicates | Service/browser routes exist; live delivery and full browser acceptance pending |
| U04 — Set or recover my password | Use actual login name, complete single-use setup, return to sign-in | Missing mail or expired link offers admin-assisted new setup link | Password setup reported successful; login name and sign-in address now named at handoff and in the user entry (2026-09-23 run, USER-WP-0035-T01); email delivery unresolved (USER-WP-0035-T02) |
| U05 — Use password-only access before optional OTP enrollment | Ordinary application permits login when provider confirms no activated factor | Provider unavailable gives recovery, never silently bypasses enrolled OTP | KEY-WP-0035 source tested; live credential/policy gate unresolved |
| U06 — Turn on authenticator codes voluntarily | My account → Sign-in security → provider; confirm identity, scan QR, verify current code, see activation confirmed, test fresh login | Bad code retries; cancellation does not report enabled; interruption can resume safely; support reachable without portal login | Help and configurable provider handoff implemented; provider activation/cancel semantics and live enrollment unverified |
| U05 — Use password-only access before optional OTP enrollment | Ordinary application permits login when provider confirms no activated factor | Provider unavailable gives recovery, never silently bypasses enrolled OTP | Renewable factor-reader and optional policy deployed (KEY-WP-0035/RPF-WP-0040); installed-provider checks pass; attended full U05–U08 acceptance remains USER-WP-0028-T03 |
| U06 — Turn on authenticator codes voluntarily | My account → Sign-in security → provider; confirm identity, scan QR, verify current code, see activation confirmed, test fresh login | Bad code retries; cancellation does not report enabled; interruption can resume safely; support reachable without portal login | Installed-provider activation/cancellation checks pass (P06); real-user enrollment and verified portal handoff remain USER-WP-0028-T03 |
| U07 — Sign in with an enrolled authenticator | Current code completes login; existing AAL1 session cannot skip OTP | Invalid code explains retry; lost device has a recovery route | Issuer policy tested; real-user enrolled/recovery acceptance pending |
| U08 — Replace or remove my authenticator | Provider reauthenticates; replacement verified before old factor removed; status and recovery instructions clear | Lost old factor triggers verified recovery, not a bypass link; policy-required MFA cannot be disabled | Required provider journey; not verified/available from portal yet |
| U08 — Replace or remove my authenticator | Provider reauthenticates; replacement verified before old factor removed; status and recovery instructions clear | Lost old factor triggers verified recovery, not a bypass link; policy-required MFA cannot be disabled | P04 recovery and P06 replacement guards deployed and verified with disposable provider fixtures; real-person recovery/replacement acceptance remains USER-WP-0028-T03 |
| U09 — See my tenants and usable applications | Account page and home show login state, the tenants and privileges active on this sign-in, and allowed memberships separately. An ordinary sign-in has one active tenant. An administrator, vendor, or multi-hire sign-in may show more than one active tenant when the verified token lists them. A recorded workload membership is an allowed record | An empty allowed list says nothing is recorded. A tenant account or the token tenant is not shown as a membership. A missing catalogue decision is not checked, which is neither access nor a denial | Login state, active sign-in, and allowed memberships are shown (USER-WP-0036). Allow, deny, and unavailable workload decisions remain USER-WP-0026-T03 and USER-WP-0028-T02 |
| U10 — Change tenant or account | Explicit reauthentication confirms the new tenant. Other allowed tenants stay inactive until that sign-in. Switching does not claim to end sessions an application already has | Denied tenant leaves a clear recovery route; stale shared identity can be cleared. A portal control does not mark a second tenant active by itself | Reauthentication handoff is the only tenant switch; real multi-identity acceptance pending |
| U11 — Sign out | Confirmation states scope; portal session ends; correct signed-out controls appear | CSRF rejection retains session; shared-provider failure explains remaining scope and retry | Portal automated tests; prior shared logout browser checks; current real-user acceptance pending |
| U10 — Change tenant or account | Explicit reauthentication confirms the new tenant. Other allowed tenants stay inactive until that sign-in. Switching does not claim to end sessions an application already has | Denied tenant leaves a clear recovery route; stale shared identity can be cleared. A portal control does not mark a second tenant active by itself | Account switching confirmed by the founder on September 24 with fresh issuer sequences (USER-WP-0026-T02); multi-user workload acceptance remains VERGABE-WP-0019-T06 |
| U11 — Sign out | Confirmation states scope; portal session ends; correct signed-out controls appear | CSRF rejection retains session; shared-provider failure explains remaining scope and retry | Automated scope/CSRF tests, live shared-logout checks and September 24 attended account-switch receipt complete USER-WP-0026-T02; existing application JWTs are not revoked |
| U12 — Recover from denied access or service outage | Plain explanation, reference for support, and account/help navigation | No automatic login loop; no private claims/codes echoed; safe retry only | HTML browser denial/recovery implemented; JSON API semantics retained |
| U13 — Update my profile and finish onboarding | Saved values and required steps are confirmed; external steps reflect provider evidence | Validation keeps safe input; provider-owned steps cannot be manually faked complete | Existing routes; form-preservation and external completion UX acceptance pending |
@ -63,7 +63,7 @@ headless capability alone does not mean a journey is usable or verified live.
| T01 — Enter the right tenant administration | Header shows identity; managed tenant is explicit; only permitted admin navigation | Non-admin/cross-tenant request denied with account recovery | Existing authorization/navigation tests; broader browser matrix pending |
| T02 — Invite someone with the right role | Review name, email, tenant and role; show invitation state and next action | Duplicate, wrong address, expired invite: inspect, correct/reissue or expire without making a second account | Invitation routes and checks exist; delivery/preview usability pending |
| T03 — Prepare an account that can actually log in | Distinguish profile, directory login name, invitation, password setup, and tenant access; admin can give the correct login name | Partial provisioning shows what exists and retry reconciles it; never show display name as login implicitly | Create-login/setup-link routes exist; login name and sign-in address presented in the user entry (USER-WP-0035-T01); lifecycle state view pending |
| T04 — Help someone who cannot sign in | Identify affected tenant/account; distinguish password, OTP, membership, and outage; give safe recovery step | No access to passwords, OTP seed or current codes; provider failure has support reference/escalation | Password setup and help page exist; verified lost-factor recovery/provider status pending |
| T04 — Help someone who cannot sign in | Identify affected tenant/account; distinguish password, OTP, membership, and outage; give safe recovery step | No access to passwords, OTP seed or current codes; provider failure has support reference/escalation | P04 recovery and provider status implemented/deployed; tenant admins escalate to authorized platform recovery; real-person lost-factor acceptance remains USER-WP-0028-T03 |
| T05 — Grant/change/revoke application access | Review exact tenant/application/role; apply authorized change; confirm effective result | Policy denial or stale version explains reason and refresh; no silent broad grant | Service capabilities vary; consolidated browser application-access management pending |
| T06 — Suspend/reactivate/remove a tenant account | Confirm target and scope; show resulting state and whether access propagation is pending | Stale or failed operation leaves truthful state; retry after readback; shared identity in other tenants preserved | Existing lifecycle routes; confirmation/propagation UX and cross-tenant browser drills pending |
| T07 — Track incomplete onboarding | See invited, identity missing, password pending, OTP problem, and access denied as distinct actionable states | Stale/unknown provider state is labelled; administrator gets the correct owner/action | Headless diagnostics exist; consolidated browser status and retry workflow pending |
@ -119,8 +119,9 @@ delivery readout, onboarding follow-up, tenant audit, and platform delivery retr
## Acceptance and remaining work
USER-WP-0027 tracks the matrix and role-based usability gaps. KEY-WP-0035 tracks
OTP policy/provider rollout. USER-WP-0026 retains authoritative workload catalogue
USER-WP-0027 tracks the matrix and role-based usability gaps. KEY-WP-0035
completed OTP policy/provider rollout; USER-WP-0028-T03 retains attended OTP
acceptance. Credential custody is no longer a blocker. USER-WP-0026 retains authoritative workload catalogue
work. Do not close these based solely on this document or a unit-test pass.
Run every journey with an ordinary member, tenant admin, and platform operator as
@ -133,3 +134,11 @@ Automated portal coverage: test_account_clarity.py, test_account_recovery.py,
test_portal_navigation.py and existing test_web.py authorization/lifecycle tests.
Automated issuer coverage: KEY-WP-0035 optional MFA tests. Actual provider OTP,
notification delivery and multi-user workload acceptance remain separate evidence.
September 27 reconciliation: the credential/policy deployment gate above passed
under RPF-WP-0040 and P06; it is still a prerequisite for any future handoff
configuration. KEY-WP-0034 and the September 24 attended receipt close the prior
account-switch wait. Mail infrastructure is available, but provider setup-link
delivery and invited-person receipt remain USER-WP-0035-T02. See
[evidence review](evidence/2026-09-27-loose-ends-review.md) for the exact evidence
and remaining owner dependencies.

View file

@ -0,0 +1,42 @@
# Loose-end review — 2026-09-27
Reviewed all 37 workplan files: 32 finished and five active. No ready,
proposed, backlog or already-blocked workplans were present. The five open
workplans are now blocked; no task or workplan was created.
## Completed existing task
USER-WP-0026-T02 is done. The immutable release and anonymous browser evidence
in `railiance-apps/docs/evidence/2026-09-12-account-recovery-live.md` is now
supplemented by `key-cape/docs/evidence/2026-09-24-fresh-login-and-account-switch.md`.
The founder confirmed fresh login/account switching; issuer telemetry records
three fresh portal authentication/token-issuance sequences following an MFA
failure. KEY-WP-0034-T02 is also done. U10 now reflects this evidence.
Application JWTs may outlive provider logout. The receipt does not complete the
second-user/company-workflow pilot in VERGABE-WP-0019-T06.
## Remaining blockers
| Workplan / tasks | Current dependency and resumption condition |
| --- | --- |
| USER-WP-0026-T03, USER-WP-0028-T02 | Application/authorization owners must establish the supported workload catalogue, registered HTTPS entry points, identity/tenant/action mapping, authoritative decisions and scoped grant/revocation contract. Local application records, memberships and the PDP evaluator do not supply fleet admission. |
| USER-WP-0027-T04, USER-WP-0028-T03 | Attended real-user OTP enrollment, cancellation, replacement/lost-factor recovery and fresh-login acceptance; verified portal setup handoff. KEY-WP-0035 and RPF-WP-0040 already delivered credential custody, renewal and optional policy. P04/P06 prove the implementation using disposable installed-provider fixtures. NK-WP-0033's separate incident also closed on September 23. |
| USER-WP-0027-T06 | Full matrix depends on the preceding application/OTP work, setup-link delivery and VERGABE-WP-0019-T06 second-user/setup-to-workflow acceptance. |
| USER-WP-0034-T02 | FLEX-WP-0020 section 8 still waits for the renamed canonical checkout. `/home/worsch/access-engine` is absent; `/home/worsch/flex-auth/docs/iam-profile-consumption.md` exists. Keep the current source link until registration. |
| USER-WP-0035-T02 | The provider-owned password-setup link still needs a supported delivery handoff and intended-person receipt evidence. EMAIL-WP-0004 and P05 delivered the mail service; its invitation outbox adapter is not a setup-link delivery contract. |
The review corrects stale missing-credential and missing-mail-infrastructure
claims rather than requesting replacement secrets or rebuilding working provider
features. Existing tasks retain all remaining work. No production configuration
or real account was changed, and no email was sent.
## Validation
- `make test`: 264 tests run, eight optional integration skips, no failures;
layer conformance passed.
- `make test-journeys`: 66 tests passed, no skips. The report remains incomplete
for U02–U09, T02, T04 and T05; account switching U10 is no longer a blocker.
- `git diff --check`: passed.
Local tests validate the implementation and journey mappings. They do not
substitute for the external acceptance evidence listed above.