Implement role-based account journeys with database and browser acceptance suites
Some checks failed
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Build and Publish Container Image / build-and-push (push) Successful in 20s
Account journey acceptance / journeys (push) Failing after 0s

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a092fe-13b1-7f12-ac74-7d258af4d79c
This commit is contained in:
tegwick 2026-09-13 12:20:02 +02:00
parent 75750c0036
commit 1127f852dd
24 changed files with 1554 additions and 148 deletions

View file

@ -94,6 +94,20 @@ must be tested against controlled accounts; self-service credentials are not an
administrative lookup credential. The portal help page is reachable before login
so OTP-required login does not hide recovery.
## Executable implementation status
Implementation workplans: USER-WP-0028 (users), USER-WP-0029 (tenant admins),
USER-WP-0030 (platform admins), USER-WP-0031 (automated suites), and NK-WP-0038
(scoped provider lifecycle). The original review column above records the starting
gaps. For the current per-journey implementation state and executable tests, use
`tests/journey-coverage.json` and `make test-journeys`; the report never equates
provider-boundary tests with real OTP or mail acceptance.
Now implemented: actual login-name handoff, profile validation/retry, scoped
provider lifecycle, role succession, cross-connection last-admin protection,
confirmation/stale-state checks, first-admin bootstrap rollback/retry, invitation
delivery readout, onboarding follow-up, tenant audit, and platform delivery retry.
## Acceptance and remaining work
USER-WP-0027 tracks the matrix and role-based usability gaps. KEY-WP-0035 tracks