diff --git a/workplans/NK-WP-0041-onboarding-journey-usability.md b/workplans/NK-WP-0041-onboarding-journey-usability.md
index 0a5a356..deaa8e4 100644
--- a/workplans/NK-WP-0041-onboarding-journey-usability.md
+++ b/workplans/NK-WP-0041-onboarding-journey-usability.md
@@ -9,7 +9,7 @@ flavor: implementation
 owner: claude-code
 topic_slug: netkingdom
 created: "2026-09-23"
-updated: "2026-09-23"
+updated: "2026-09-27"
 related: [NK-WP-0036, NK-WP-0037, KEY-WP-0033]
 state_hub_workstream_id: "98168f50-7a4d-5bb5-a462-1e031563b89f"
 ---
@@ -95,7 +95,7 @@ digest. The daily backups continue.
 
 ```task
 id: NK-WP-0041-T03
-status: todo
+status: done
 priority: low
 state_hub_task_id: "7350f35a-6893-5ac8-bfc5-fb2e40b3cf5d"
 ```
@@ -107,7 +107,23 @@ These belong to user-engine:
 - The derived login name (`bernd.worsch-99`) is not obvious to the recipient.
 - There is no sign-in link from the user entry once a password has been set.
 
-Send these to user-engine and record the reply.
+Sent, and the reply is recorded (user-engine, 2026-09-23, hub message
+`a500cc67`, thread `21b0b7e4`). user-engine opened USER-WP-0035
+(`35aa6adf-255a-5705-9294-a50d98e45f00`).
+
+Findings 2 and 3 are implemented in source as USER-WP-0035-T01
+(`a26b22ae-05fd-52f4-accc-068ccba7bbda`): the tenant-admin user entry shows
+the sign-in address beside the login name and states that the email address
+is not the login name, and the password-setup handoff repeats the sign-in
+address and says the portal does not deliver the link. Their regression is
+`test_journey_roles.UserJourneys.test_password_handoff_names_actual_login_and_failure_can_retry`.
+That is source, not a live release. They will not suggest that email sign-in
+works while NK-WP-0041-T02 is open.
+
+Finding 1 stays USER-WP-0035-T02
+(`fae614ba-ffc0-511d-9d22-2d91fbab057f`, status wait). Delivery needs the
+governed transactional mail lane, which is operator-owned. A portal-rendered
+link is not delivery evidence.
 
 ### Incident 2026-09-24: 4.39.28 rollout broke KeyCape sign-in; rolled back
 
@@ -172,3 +188,30 @@ variable changing:
 Then retry 4.39.28. The acceptance must include a real human sign-in
 through KeyCape, and the `+` email sign-in. The task waits on the choice
 of A or B, with key-cape consulted.
+
+2026-09-27, checked through the Vergabe demo-company pilot
+(`https://vergabe-teilnahme.coulomb.social/demo-company/`, customer
+`tenant:trial:demo-company`). The welcome page is up. Starting sign-in
+returns 302 to KeyCape `client_id=vergabe-demo-company` with PKCE, `prompt=login`,
+and the company callback. KeyCape then sends the browser to
+`https://auth.coulomb.social/api/oidc/authorization` with `max_age=10` and
+client `keycape`. No credential was submitted.
+
+The plus-address defect is still live on that same Authelia 4.38. A first-factor
+probe for `nk-probe@example.invalid` is logged as user not found. The same probe
+for `nk-probe+x@example.invalid` is logged as LDAP Result Code 201 Filter Compile
+Error on `+`. Both responses to the browser are the generic authentication
+failure, so the filter error is not visible on the sign-in page. Vendor
+`tenant:friendly:binky` is a different tenant and is not admitted by this
+client.
+
+Path A is not reachable with the current network policy. Namespace `sso` is
+default-deny. KeyCape egress allows only TCP 9091 to Authelia pods, TCP 3890
+to LLDAP, TCP 8080 to the mfa namespace, and DNS. The pod has no egress to
+the ingress or to port 443, so `tokenBaseURL: https://auth.coulomb.social`
+would fail before any hairpin. The in-cluster token URL remains the only
+allowed back-channel. key-cape is asked whether it will send
+`X-Forwarded-Proto: https` and `X-Forwarded-Host: auth.coulomb.social` on
+that existing call (path B). Authelia 4.39 trusting those headers from a
+pod, rather than from Traefik, is still unverified. No live config or image
+was changed.