2026-09-23 22:10:38 +02:00
|
|
|
---
|
|
|
|
|
id: USER-WP-0035
|
|
|
|
|
type: workplan
|
|
|
|
|
title: "Onboarding handoff findings from the 2026-09-23 operator run"
|
|
|
|
|
domain: communication
|
|
|
|
|
repo: user-engine
|
|
|
|
|
status: active
|
|
|
|
|
flavor: implementation
|
|
|
|
|
owner: claude-code
|
|
|
|
|
topic_slug: user-engine
|
|
|
|
|
created: "2026-09-23"
|
|
|
|
|
updated: "2026-09-23"
|
|
|
|
|
related: [USER-WP-0027, USER-WP-0028, NK-WP-0036, NK-WP-0041]
|
2026-09-23 22:11:14 +02:00
|
|
|
state_hub_workstream_id: "35aa6adf-255a-5705-9294-a50d98e45f00"
|
2026-09-23 22:10:38 +02:00
|
|
|
---
|
|
|
|
|
|
|
|
|
|
Intake for the net-kingdom findings from the human onboarding run on
|
|
|
|
|
2026-09-23 (NK-WP-0036-T05, net-kingdom@6c4fcaf; hub message 21b0b7e4).
|
|
|
|
|
Provider sign-in, Create login, single-use setup link, password set and
|
|
|
|
|
portal sign-in all worked. Three findings touch journeys U04 and T03 in
|
|
|
|
|
`docs/account-journeys.md`. This records them against user-engine; the
|
|
|
|
|
provider-side items stay with net-kingdom.
|
|
|
|
|
|
|
|
|
|
## Name the login and the sign-in address at every handoff point
|
|
|
|
|
|
|
|
|
|
```task
|
|
|
|
|
id: USER-WP-0035-T01
|
|
|
|
|
status: done
|
|
|
|
|
priority: high
|
2026-09-23 22:11:14 +02:00
|
|
|
state_hub_task_id: "a26b22ae-05fd-52f4-accc-068ccba7bbda"
|
2026-09-23 22:10:38 +02:00
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Findings 2 and 3. The derived login name (`bernd.worsch-99` from a
|
|
|
|
|
plus-addressed mail) is not obvious to the recipient, users try the email
|
|
|
|
|
address first, and the tenant-admin user entry offered no sign-in address to
|
|
|
|
|
pass on. Plus-addressed email sign-in additionally fails at Authelia, which
|
|
|
|
|
net-kingdom tracks as NK-WP-0041-T02; user-engine must therefore not imply
|
|
|
|
|
that the email address works.
|
|
|
|
|
|
|
|
|
|
2026-09-23: the tenant-admin user entry now shows the sign-in address next to
|
|
|
|
|
the login name and states that the email address is not the login name. The
|
|
|
|
|
password-setup handoff page repeats the sign-in address for after the
|
|
|
|
|
password is set and says plainly that this portal does not deliver the link.
|
|
|
|
|
Regression coverage is in
|
|
|
|
|
`test_journey_roles.UserJourneys.test_password_handoff_names_actual_login_and_failure_can_retry`.
|
|
|
|
|
No claim about password or factor state is added, and no delivery is claimed.
|
|
|
|
|
|
|
|
|
|
## Deliver the setup link to the recipient
|
|
|
|
|
|
|
|
|
|
```task
|
|
|
|
|
id: USER-WP-0035-T02
|
|
|
|
|
status: wait
|
|
|
|
|
priority: high
|
2026-09-23 22:11:14 +02:00
|
|
|
state_hub_task_id: "fae614ba-ffc0-511d-9d22-2d91fbab057f"
|
2026-09-23 22:10:38 +02:00
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Finding 1: the setup link reaches the provider's screen only. A real handoff
|
|
|
|
|
depends on the operator passing it on out of band. Closing this needs the
|
|
|
|
|
governed transactional mail lane (`email-connect` plus the OpenBao delivery
|
|
|
|
|
token) that SCOPE records as operator-owned; U04 and T02 in
|
|
|
|
|
`tests/journey-coverage.json` stay `external-blocked` until then. Do not
|
|
|
|
|
substitute a portal-rendered link for delivery evidence.
|
