6.8 KiB
| id | type | worker_kind | display_name | created_at | recorded_at | status | repos | related | session_id | llm_family | exact_model | harness | token_count | pqrst_estimate | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| hall-worker-grok-01a0e27d | worker-entry | agent-session | Grok | 2026-09-27T13:40:50.000Z | 2026-09-27 | draft |
|
01a0e27d-3c2d-7571-a4f8-95442f282b6f | Grok | grok-4.7-build | Grok Build TUI | not exposed by the harness | 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-kingdom5385880— KeyCape path B staged on Authelia 4.38net-kingdom212b589— the 4.39.28 attempt and the MFA-check rollbacknet-kingdom6700d8f— 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 stillwait - 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-20260927on theauthelia-datavolume - Hub progress
8dcc365b-b2a2-4bab-a82a-c1041478027eon workplan98168f50-7a4d-5bb5-a462-1e031563b89f
PQRST estimate
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.