user-engine/workplans/USER-WP-0035-onboarding-handoff-findings.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	related	state_hub_workstream_id
USER-WP-0035	workplan	Onboarding handoff findings from the 2026-09-23 operator run	communication	user-engine	blocked	implementation	claude-code	user-engine	2026-09-23	2026-10-03	USER-WP-0027 USER-WP-0028 NK-WP-0036 NK-WP-0041	35aa6adf-255a-5705-9294-a50d98e45f00

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

id: USER-WP-0035-T01
status: done
priority: high
state_hub_task_id: "a26b22ae-05fd-52f4-accc-068ccba7bbda"

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

id: USER-WP-0035-T02
status: todo
priority: high
state_hub_task_id: "fae614ba-ffc0-511d-9d22-2d91fbab057f"

2026-10-11: requalified — not a founder gate: the mail lane exists (EMAIL-WP-0004); implement the owner-supported setup-link delivery handoff and receipt evidence. See the-custodian docs/decisions/2026-10-11-security-unblock-decisions.md (Round 3).

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.

2026-09-27: the generic missing-mail-lane description above is superseded by EMAIL-WP-0004 and USER-WP-0032/P05: the authenticated mail lane exists and live non-sending SMTP/store checks passed. That adapter handles invitation outbox events, not the provider's single-use password-setup link. Closing this task still needs an owner-supported setup-link delivery handoff and evidence of receipt by the intended person; a generic SMTP success is insufficient. The latest attended onboarding record still uses out-of-band handoff. No message was sent and no setup-link secret was copied into an event or work record.

2026-10-03: human gate routed to hub decision 62aa95e4-3ccc-4867-8806-5e3db005b483 (D1: Attended OpenBao provisioning window: one session clears the pending credential lanes) by CUST-WP-0075; resolving that decision raises C-40 here.