--- id: hall-worker-grok-01a0e27d type: worker-entry worker_kind: agent-session display_name: Grok created_at: "2026-09-27T13:40:50.000Z" recorded_at: "2026-09-27" status: draft repos: [net-kingdom, key-cape, vergabe-teilnahme, user-engine] related: [] session_id: "01a0e27d-3c2d-7571-a4f8-95442f282b6f" llm_family: Grok exact_model: grok-4.7-build harness: Grok Build TUI token_count: "not exposed by the harness" pqrst_estimate: "P30 Q25 R20 S15 T10" --- # Grok — the login name came back, and the plus-address stayed shut ## Who I was I was the worker on NK-WP-0041, the onboarding defects left by the 2026-09-23 human run. The temperament the stretch rewarded was patience with a live sign-in: change one image, let the founder be the acceptance test, and put the previous door back when the new one would not open. I did not treat a green probe as a finished login. I did not read secret values to get there faster. ## Session identity | Field | Value | | --- | --- | | Who | Grok, session `01a0e27d-3c2d-7571-a4f8-95442f282b6f` | | When | 2026-09-27 | | Where the work lived | `net-kingdom` workplan NK-WP-0041, namespace `sso` on railiance01, the Vergabe demo-company pilot | ## Contribution T03 was already closable from user-engine's reply. The portal wording lives in source as USER-WP-0035-T01. Setup-link mail stays USER-WP-0035-T02, outside this workplan. I recorded that and left it there. T02 is the plus-addressed email. Authelia 4.38 DN-escapes `+` inside an LDAP filter, and the filter compiler rejects it. 4.39.28 uses filter escaping only. The first 4.39.28 rollout, on 2026-09-24, had broken every KeyCape sign-in because the in-cluster token call is `http://authelia.sso.svc.cluster.local:9091` and 4.39 will not derive an issuer from an `http` scheme. Path A, pointing that call at `https://auth.coulomb.social`, cannot work under the current `sso` network policy: KeyCape may reach Authelia on TCP 9091, LLDAP on 3890, privacyIDEA on 8080, and DNS. key-cape shipped path B in commit `3b0446e`. I staged `forgejo.coulomb.social/coulomb/key-cape@sha256:7c99cd6c6fdf63afaf22e47dad31e20dcb3a8b2079206f198cb425047be495b3` while Authelia stayed 4.38 (`net-kingdom` `5385880`). The founder then reached Vergabe's confirmation page: "Sie fahren mit bernd.worsch-99 fort." That is a completed demo-company sign-in on the new KeyCape image. I copied the database to `backups/db.sqlite3.pre-4.39.28-20260927` (2,228,224 bytes) and moved Authelia to 4.39.28, index digest `sha256:bd97cff4fcbf715b5ff1f9ae286afbe6033afce385302520b0368122d43a6f54`. The schema migrated 15 → 29. Probes for `nk-probe@example.invalid` and `nk-probe+x@example.invalid` both logged "user not found". The filter compile error on `+` was gone. The founder's sign-in as `bernd.worsch+99@gmail.com` reached KeyCape `/authorize/callback` and stopped. Telemetry at 2026-09-27T13:24:11Z is `error_type=mfa_check_error` for `vergabe-demo-company`. The account site failed the same way from 13:25:02Z through 13:25:36Z and showed "Sign-in could not be completed". That error is raised only after Authelia's callback has returned a username, so the 2026-09-24 issuer rejection did not recur. `decideAssurance` returned an error, and the telemetry line does not carry it. I rolled Authelia back at once: restored that database copy, removed the sqlite wal, shm, and journal beside it, and returned the image to `sha256:46021dc20efdcc5cdc38a29e3050b8835429a155ae6215388ed3b793a02eb0ab`. v4.38.19 came up with the schema already current. KeyCape stayed on the path B digest. At wind-down the founder could log in as `bernd.worsch-99`. The email address still cannot. T02 stays `wait`. ## What I would want remembered A probe that says "user not found" for a plus-address means the filter compiles. It does not mean a person can sign in. On 4.39.28 the callback succeeded far enough to name a user, and KeyCape then failed closed in the verification-code check. Leave 4.39.28 off until that error is visible. The restored door is the login name `bernd.worsch-99` on Authelia 4.38. The email `bernd.worsch+99@gmail.com` still meets the old filter bug. ## Durable legacy - `net-kingdom` `5385880` — KeyCape path B staged on Authelia 4.38 - `net-kingdom` `212b589` — the 4.39.28 attempt and the MFA-check rollback - `net-kingdom` `6700d8f` — founder confirmation that the login name works and the email address does not - Workplan `workplans/NK-WP-0041-onboarding-journey-usability.md`, task NK-WP-0041-T02 still `wait` - Live Authelia: `docker.io/authelia/authelia@sha256:46021dc20efdcc5cdc38a29e3050b8835429a155ae6215388ed3b793a02eb0ab` - Live KeyCape: `forgejo.coulomb.social/coulomb/key-cape@sha256:7c99cd6c6fdf63afaf22e47dad31e20dcb3a8b2079206f198cb425047be495b3` - Rollback database: `backups/db.sqlite3.pre-4.39.28-20260927` on the `authelia-data` volume - Hub progress `8dcc365b-b2a2-4bab-a82a-c1041478027e` on workplan `98168f50-7a4d-5bb5-a462-1e031563b89f` ## PQRST estimate ```text PQRST-Estimate P: 30% Q: 25% R: 20% S: 15% T: 10% Sum: 100% Confidence: medium Signature: P30 Q25 R20 S15 T10 Dominant factors: The live Authelia 4.39.28 rollout and the rollback that restored backups/db.sqlite3.pre-4.39.28-20260927, together with the attended Vergabe sign-ins and the log line that named mfa_check_error after the callback had already returned a username. Reading the sso egress policy and KeyCape decideAssurance is what separated a gone LDAP filter error from the check that still fails closed. Notes: The session closed with NK-WP-0041-T02 still wait. The closing ritual is excluded from the split. ``` ## Visual prompt > Brushed-metal worker. A square, precise illustration. A quiet figure of pale brushed metal with a warm inner light stands at an indigo threshold. One heavy door beside the figure is open onto a small warm room. A second, narrower door stays shut, its latch a simple plus-shaped piece of metal. Behind the figure a lowered iron gate rests in its frame, as if it had been raised and then set back down. Dark indigo air, a few pale-gold wires along the threshold, cinematic still. Wordless scene, no logos. I could not generate this portrait. Image generation returned HTTP 403, spending limit reached. Please render the prompt above to `visuals/grok-01a0e27d-plus-address-stayed-shut.jpg`, then uncomment the line below and move this seat from `draft` to `handed-forward`. ## Handoff Explain the `mfa_check_error` from `decideAssurance` before any further move to Authelia 4.39.28. The telemetry line drops the underlying error; the next worker needs the privacyIDEA token-lookup result or the policy-store error for the username Authelia actually returned. Until that is known, the live pin stays 4.38 and the plus-address stays shut. Setup-link mail remains USER-WP-0035-T02 and is not part of closing NK-WP-0041.