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

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	related	state_hub_workstream_id
NK-WP-0041	workplan	Fix onboarding-journey defects found in the 2026-09-23 human run	infotech	net-kingdom	active	implementation	claude-code	netkingdom	2026-09-23	2026-09-23	NK-WP-0036 NK-WP-0037 KEY-WP-0033	98168f50-7a4d-5bb5-a462-1e031563b89f

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

id: NK-WP-0041-T01
status: done
priority: medium
state_hub_task_id: "82ce581a-b635-5b5b-9b08-91b61e7eb9bd"

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.

Released on 2026-09-24. CI published main-6c4fcaf as identity-provisioner@sha256:ffacd5d7…, and the operator applied the declaration on railiance01. Only the image and the new env changed; the other resources were unchanged. The new pod checks out:

• /healthz returns 200 and /readyz returns 200 (dependency: directory).
• An invalid setup link returns 400.
• The served code carries the autocomplete="username" field.
• PASSWORD_SETUP_SIGNIN_URL is set.

Rollback digest: 3317a261…. The next real setup link will show the field to a user; note it here if the password manager still misbehaves.

Plus-addressed email sign-in fails with an LDAP filter error

id: NK-WP-0041-T02
status: progress
priority: medium
state_hub_task_id: "83633649-3e5c-57e7-8207-609380a29c25"

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.

Diagnosis, 2026-09-24. This is an upstream Authelia defect. internal/authentication/ldap_util.go ldapEscape() in v4.38.0 through v4.38.19 (the last 4.38 release) and in v4.39.0 applies ldap.EscapeFilter and then DN-escapes , # + < > ; " = as \c. Inside a filter, an escape must be \XX hex, so the go-ldap filter compile fails for any username or email containing one of those eight characters. v4.39.28 (2026-09-17) builds the filter with ldap.EscapeFilter(input) only (ldap_user_provider.go:720). No configuration workaround exists.

Upgrade prepared. The target is authelia/authelia:4.39.28, pinned as sha256:bd97cff4…. The live image is the floating tag 4.38 (sha256:46021dc2…). The live authelia-config was validated locally with placeholder secrets under both versions: each returned exit 0 with no errors and the same set of auto-mapped deprecation warnings. Storage is SQLite on the PVC, and 4.39 migrates the schema on start. The rollback therefore needs the pre-upgrade copy (backups/db.sqlite3.pre-4.39.28) as well as the old digest. The daily backups continue.

Route the portal findings to user-engine

id: NK-WP-0041-T03
status: todo
priority: low
state_hub_task_id: "7350f35a-6893-5ac8-bfc5-fb2e40b3cf5d"

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.