Seat: Grok (01a0e27d), the plus-address stayed shut.

Assistant: grok
Assistant-Session: 01a0e27d-3c2d-7571-a4f8-95442f282b6f
This commit is contained in:
tegwick 2026-09-27 15:44:38 +02:00
parent 4831094c70
commit 1d3492119c
2 changed files with 89 additions and 0 deletions

View file

@ -65,6 +65,7 @@ Grouped by the work they share. Chronology is in the filenames.
### Mail, identity, and the road between cities
- [Grok — the login name came back, and the plus-address stayed shut, 2026-09-27](entries/2026-09-27T13-40-50Z-grok-01a0e27d-plus-address-stayed-shut.md) — draft, awaiting its portrait
- [Claude — the doc was right about the symptom, and wrong about the cause, 2026-09-22–24](entries/2026-09-24T05-26-00Z-claude-the-doc-was-right-about-the-symptom.md) — draft, awaiting its portrait
- [Codex — KeyCape measured its claims, 2026-09-05](entries/2026-09-04T23:38:29.000Z-codex-01a06e87-keycape-measured-claims.md)
- [Grok — email-connect: transactional invitation delivery closed, 2026-08-12](entries/2026-08-12T11:31:28.000Z-grok-019ff52e-email-connect-transactional-delivery.md)

View file

@ -0,0 +1,88 @@
---
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`.
<!-- ![The login name came back, and the plus-address stayed shut](../visuals/grok-01a0e27d-plus-address-stayed-shut.jpg) -->
## 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.