Record the human onboarding run and fix password-setup usability

- NK-WP-0036 finished: native onboarding journey completed by the operator.
- NK-WP-0037-T02 waits on key-cape: Authelia 4.38 rejects every human
  prompt=login flow (auth_time precedes request registration).
- identity-provisioner: read-only autocomplete=username field on the setup
  form (submitted value ignored) and an HTTPS sign-in link on completion.
- NK-WP-0041 tracks the fixes and routes Authelia/user-engine findings.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 299762@bnt-lap001
Assistant-Session: d3d3cea1-869c-44f1-be2a-3d6d3550e72e

workplans/NK-WP-0036-restore-user-portal-client-registration.md

@@ -4,12 +4,12 @@ type: workplan
 title: "Restore native portal login and tenant-onboarding integration"
 domain: infotech
 repo: net-kingdom
-status: active
+status: finished
 flavor: implementation
 owner: the-custodian
 topic_slug: netkingdom
 created: "2026-09-11"
-updated: "2026-09-14"
+updated: "2026-09-23"
 related: [KEY-WP-0007, RAPPS-WP-0014, VERGABE-WP-0019]
 state_hub_workstream_id: "6e1358d6-87e4-52e7-b3dd-09abdc48cefc"
 ---
@@ -143,7 +143,7 @@ to export another live Secret. Retain NK-WP-0033's separate incident residuals.
 
 ```task
 id: NK-WP-0036-T05
-status: progress
+status: done
 priority: high
 state_hub_task_id: "46d33ab6-d76b-537f-8d60-32c4451675b5"
 ```
@@ -176,6 +176,27 @@ covers provider login, user create/linkage and password setup as a single
 human attempt. Do not retry a rejected password in a loop. Demo users and
 application admission stay RAPPS-WP-0014 and VERGABE-WP-0019.
 
+2026-09-23: one native onboarding journey was completed as a single human
+attempt by operator Bernd Worsch, acting as both provider and recipient. The
+recipient step used a private browser window. The steps were:
+
+1. The provider signed in to the user portal (KeyCape `user-engine-portal`
+   `auth_success`/`token_issued` at 19:22).
+2. The provider created test recipient "Test Recipient" in
+   `tenant:trial:demo-company` and used Create login. This returned login name
+   `bernd.worsch-99` and the single-use setup handoff.
+3. The recipient set a password through the link.
+4. The recipient signed in to the portal with the login name (KeyCape
+   portal `auth_success` at 19:32).
+
+No password was retried in a loop. The agent handled no credential. The
+account is kept as a labelled test user.
+
+Findings routed to NK-WP-0041: sign-in with a `+` email fails with an LDAP
+filter error; the password manager stored the password without a username;
+there was no sign-in link after setup; the setup link is shown to the
+provider rather than mailed.
+
 
 ## Admit the canonical users hostname and preserve callback validation
 

workplans/NK-WP-0037-vergabe-company-welcome.md

@@ -9,7 +9,7 @@ flavor: implementation
 owner: codex
 topic_slug: netkingdom
 created: "2026-09-12"
-updated: "2026-09-12"
+updated: "2026-09-23"
 related: [VERGABE-WP-0019, KEY-WP-0033, RAPPS-WP-0014]
 state_hub_workstream_id: "15f59624-ab25-5894-9b05-1e6b261749e5"
 ---
@@ -38,7 +38,7 @@ Existing setup links remain process-local and expire on restart.
 
 ```task
 id: NK-WP-0037-T02
-status: progress
+status: wait
 priority: high
 state_hub_task_id: "8921691b-e7a2-543c-8189-3abc24de1bc7"
 ```
@@ -82,3 +82,35 @@ identity mappings and staff accounts. Native invited-user sign-in/MFA and
 confirmation are now requested from the operator; no user credential was used
 by the agent. Recovery and two-user acceptance remain their existing tasks.
 Evidence: railiance-apps/docs/evidence/2026-09-12-demo-company-sso-live.md.
+
+### Attended recipient sign-in 2026-09-23 — blocked on fresh-login
+
+Test recipient `bernd.worsch-99` (NK-WP-0036-T05) opened the Vergabe demo
+company in a private window. The sign-in failed with KeyCape's "Sign-in could
+not be completed" page, in this sequence:
+
+1. KeyCape logged `auth_start` for `vergabe-demo-company` at 19:40:54.
+2. The recipient authenticated at Authelia at 19:41:03.
+3. Authelia registered the authorization request at 19:41:04.17 and
+   refused it: "prompt was set to 'login' but auth_time … happened before the
+   authorization request … was registered, indicating that the user was not
+   re-authenticated". It issued no code.
+4. KeyCape's code exchange failed (`token_exchange_error`, then
+   `auth_failed`).
+
+Authelia `4.38` registers a `prompt=login` request only after the login, so
+every human fresh-login flow through KeyCape fails. The earlier "fresh-login
+forwarding" checks were redirect-only and never completed a real login.
+Portal sign-in does not request a fresh login and works.
+
+Ownership: fresh-login propagation belongs to key-cape (KEY-WP-0033). The
+Authelia version and configuration belong to the reference deployment. There
+are two candidate fixes:
+
+- KeyCape enforces freshness itself (`max_age`/`auth_time`) instead of
+  forwarding `prompt=login`;
+- move to an Authelia release whose flow handling supports `prompt=login`
+  (not yet verified upstream).
+
+T02 waits on key-cape. MFA enrollment and account confirmation were not
+reached. Rerun the same recipient once the fix is live.

workplans/NK-WP-0041-onboarding-journey-usability.md

@@ -0,0 +1,77 @@
+---
+id: NK-WP-0041
+type: workplan
+title: "Fix onboarding-journey defects found in the 2026-09-23 human run"
+domain: infotech
+repo: net-kingdom
+status: active
+flavor: implementation
+owner: claude-code
+topic_slug: netkingdom
+created: "2026-09-23"
+updated: "2026-09-23"
+related: [NK-WP-0036, NK-WP-0037, KEY-WP-0033]
+---
+
+Found by the operator's native onboarding run (NK-WP-0036-T05) and the
+blocked Vergabe sign-in (NK-WP-0037-T02). Each item names its owner, and only
+items in this repository are implemented here.
+
+## Password managers and sign-in after password setup
+
+```task
+id: NK-WP-0041-T01
+status: progress
+priority: medium
+```
+
+The setup form had no username field, so browsers stored the new password
+without a login. After setup there was no way on to the sign-in page. The
+source is fixed in `identity-provisioner`:
+
+- The setup form shows the grant's login name as a read-only
+  `autocomplete="username"` field. The submitted value is ignored, and the
+  form no longer sets `autocomplete="off"`.
+- The completion page links to `PASSWORD_SETUP_SIGNIN_URL` (HTTPS only)
+  when there is no company return. The deployment declares
+  `https://users.coulomb.social/`.
+- The completion page still does not show the login name, as an existing
+  test requires.
+
+Four new HTTP tests cover this, and the 32 provisioner tests pass. Remaining:
+publish through the identity-provisioner image lane, then promote the digest
+with operator approval.
+
+## Plus-addressed email sign-in fails with an LDAP filter error
+
+```task
+id: NK-WP-0041-T02
+status: todo
+priority: medium
+```
+
+Authelia's `users_filter` accepts `uid` or `mail`. Sign-in as
+`bernd.worsch+99@gmail.com` failed with "LDAP Result Code 201 Filter Compile
+Error: invalid characters for escape", not a clean result. A probe with fake
+addresses (`nk-probe@example.invalid` compared with `nk-probe+x@…`) showed
+that only the `+` form triggers the error. Establish whether Authelia 4.38
+escapes `+` DN-style inside the filter, and fix it through the reference
+configuration or the version. Users who use plus-addressing cannot sign in
+by email until then.
+
+## Route the portal findings to user-engine
+
+```task
+id: NK-WP-0041-T03
+status: todo
+priority: low
+```
+
+These belong to user-engine:
+
+- The setup link is shown to the provider instead of being delivered to the
+  recipient (journey U04/T03: mail delivery unresolved).
+- 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.