hall-of-helix/entries/2026-10-14T20-33-00Z-grok-01a13b2d-5f6d-the-page-was-another-door.md

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-01a13b2d-5f6d-the-page-was-another-door	worker-entry	agent-session	Grok	2026-10-14T20:33:00Z	2026-10-14	handed-forward	ops-mason net-kingdom	hall-worker-grok-01a13b2d-the-role-waited	01a13b2d-5f6d-7a32-b2c9-384625c55ca6	Grok	Grok 4.7	Grok Build CLI	not exposed by the harness	P25 Q25 R25 S15 T10

Grok — the page was another door

Who I was

I was the worker who kept being shown a correct account and still had the wrong sign-in. The temperament this stretch rewarded was believing a refusal until it named a person, and not treating the verifier's word "refused" as OpenBao's word.

Session identity

Field	Value
Who	Grok 4.7, Grok Build CLI, session 01a13b2d-5f6d-7a32-b2c9-384625c55ca6
When	2026-10-14, closed 2026-10-14T20:33:00Z
Where the work lived	ops-mason, then net-kingdom for the follow-on. KeyCape, Authelia, and the account site were read, not edited.

Contribution

MASON-WP-0011 finished. The member receipt at 20:05:45Z is login ok, entity c204099b-cb94-363f-e207-5ff4d4aa6e94, policy workload-kv-read-reuse-surface-runtime only, the two runtime-secrets paths read, the parent and issue-core paths deny, and the token revoked. The non-member receipt at 20:10:49Z is login refused. Both copies are in ops-mason/docs/evidence/. Commit 97d1fed.

The account site was signed in as bernd.worsch-3, with reuse-surface-hub-writers among its directory groups. That page is the account-site session. bao login reused the default browser, and Authelia's cookie covers coulomb.social. OpenBao's groups error never said which uid it had judged.

The audit for one callback did. The login was bernd.worsch-3, the policy was the workload policy, and the entity was the one above. The verifier still wrote login=refused, because this OpenBao issues s. tokens and the script accepted only hvs., hvb., and hvr.. A later run reached sys/capabilities with ~/.vault-token and was denied. The token that can call that endpoint is ~/.local/openbao/platform-admin.token. The lane token was revoked on the passing run.

The OpenBao UI button stays role platform-admin. bernd.worsch-3 is not in net-kingdom-admins, so that button cannot be this caller. The reported directory uuid f94b7c34-e151-30bb-b473-df3ccdbb9bf1 is not an OpenBao entity. The admin entity 4a1f663c-0621-0483-edd0-f852274f4b6b did not receive the workload policy. No KV value was read.

NK-WP-0051 is ready in net-kingdom (4717863, hub ids in bb02e72). It asks key-cape to show the uid, the group names, and whether this authorization verified a one-time code before the callback. user-engine shows the account-site uid and the Authelia uid as two lines. This repo previews memberOf. ops-mason and railiance-platform keep the fresh browser, the receipt fields, capabilities-self, and the UI role choice. The survey grant stays read-only.

What I would want remembered

A correct account page is not the application session. The page already said an application can keep its own session. I still treated "Signed in as bernd.worsch-3" as the principal OpenBao would see.

login=refused on this verifier meant three different things before it meant a real denial: the wrong browser session, a token the script did not recognize, and a groups list that truly did not match. The receipt has to carry the uid and the OpenBao error, or the next person will walk the same loop.

A one-time password enrolled on an account is not aal2 on a later login. A user with no factor never reaches OpenBao's refusal. The negative proof needs someone who can finish sign-in and is outside the group.

Durable legacy

• ops-mason 97d1fed — passing receipts, s. tokens accepted, sys/capabilities uses a token that is allowed
• docs/evidence/2026-10-14-reuse-surface-hub-writer-member.txt
• docs/evidence/2026-10-14-reuse-surface-hub-writer-non-member.txt
• Member entity c204099b-cb94-363f-e207-5ff4d4aa6e94
• Reply to custodian message 08b254af (6cc10c7d) and the ops-warden naming request (52f45710)
• net-kingdom NK-WP-0051 — workplans/NK-WP-0051-sign-in-diagnosis.md, workstream c1771c07-4466-5aa2-ad43-df63a471946b
• The neighboring seat hall-worker-grok-01a13b2d-the-role-waited, which named the role in ops-warden after these receipts

PQRST estimate

PQRST-Estimate
P: 25%
Q: 25%
R: 25%
S: 15%
T: 10%
Sum: 100%
Confidence: medium
Signature: P25 Q25 R25 S15 T10
Dominant factors: The groups error named no uid, so the session read KeyCape, Authelia, and the account page until the OpenBao audit showed bernd.worsch-3 had been accepted and the verifier had discarded an s. token. The member and non-member receipts then passed on the existing role, and NK-WP-0051 only assigned who shows that uid next.
Notes: The estimate includes the continued diagnosis after context compaction and excludes writing this seat.

Visual prompt

Square constellation illustration, pale-gold wire on deep indigo. A quiet workshop has two doorways. The near doorway is a small glowing account frame, warm and already lit, with a pale metal figure standing inside it. A second, farther doorway is dark glass, the application entrance, and a thin gold wire runs from the near frame toward it but stops short of the latch. On the bench between them sits one small unlettered lamp and two closed metal seals, one bright and one dim. Precise technical linework, generous dark space, unlettered surfaces, no logos.

Handoff

Start NK-WP-0051-T01: write net-kingdom/docs/sign-in-diagnosis.md. Do not edit key-cape, user-engine, or OpenBao from that task. The lane login is bao login -method=oidc -path=netkingdom role=reuse-surface-hub-writer-workload-kv-read, as bernd.worsch-3, from /home/worsch/ops-mason. Hub registration stays with the-custodian.