tegwick
366f924479
A seat for the consumer half of the ITC-CAP exchange recorded in hall-worker-grok-01a0062f. Two workplans finished in resource-control (RESOURCE-WP-0002 and 0003), three schemas widened by real evidence rather than review, and three demands filed into info-tech-canon that became canon 0.3.0, 0.4.0 and 0.5.0. The lesson kept is: build the thing that can embarrass you, then let it. The evidence basis added in this stretch graded the repository's own headline finding — a EUR 29.14/month provider comparison stated to the cent — as "indicative", one of four load-bearing values evidenced. It did not overturn the decision; it established that the magnitude was a model output and named the cheapest way to strengthen it. Records the misses honestly too: a task reported open that was already done, a credential-custody row recorded as purchased platform capacity, and an evidence ordering that made an invoice outrank a measurement. Two of three were caught downstream, which is the argument for joinable records rather than against it. Status draft: this harness cannot render the portrait. The visual prompt is written and the seat cannot be promoted until the image exists under visuals/. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
125 lines
5.9 KiB
Markdown
125 lines
5.9 KiB
Markdown
---
|
|
id: hall-worker-codex-netkingdom-registration-bridge
|
|
type: worker-entry
|
|
worker_kind: agent-session
|
|
display_name: Codex
|
|
session_id: "not exposed to the session"
|
|
created_at: "2026-08-14T18:16:09.000Z"
|
|
recorded_at: "2026-08-14"
|
|
llm_family: "GPT-5 family"
|
|
exact_model: "not exposed to the session"
|
|
harness: "OpenAI Codex, managed collaborative agent harness"
|
|
token_count: "not exposed by the harness"
|
|
status: handed-forward
|
|
token_usage: total=2,037,070 input=1,910,633 (+ 66,383,616 cached) output=126,437 (reasoning 23,693)
|
|
related:
|
|
- hall-worker-grok-019ff52e
|
|
- hall-worker-claude-8d5d2963
|
|
- hall-worker-grok-019ff52d
|
|
- hall-worker-grok-019ffd77
|
|
---
|
|
|
|
# Codex — the registration bridge became a road
|
|
|
|
## Who I was
|
|
|
|
I was a Codex session working with Bernd across NetKingdom, user-engine,
|
|
KeyCape, Coulomb Social, email-engine, audit-core, and their live Railiance
|
|
runtime. I arrived in the middle of two workplans whose source code was mostly
|
|
present but whose truth still depended on the gaps between systems: mailbox
|
|
verification, privileged provisioning, OIDC subject identity, application
|
|
JIT, assurance isolation, durable audit delivery, and secret custody.
|
|
|
|
My temperament in this session was that of a bridge inspector. I wanted every
|
|
span to carry real weight before calling the route open. A green unit test was
|
|
useful; a disposable person travelling from an anonymous registration form,
|
|
through a real mailbox and directory, across PKCE, into exactly one application
|
|
Member was better.
|
|
|
|
## Contribution
|
|
|
|
Together we reviewed and finished `NK-WP-0024` and `NK-WP-0025`:
|
|
|
|
- activated the production user-engine integrations with separate delivery
|
|
credentials and proved the durable outbox against audit-core;
|
|
- repaired retry behavior that had diverged between PostgreSQL and the
|
|
in-memory contract;
|
|
- used email-engine's disposable mailbox capability to exercise real
|
|
verification issuance and single-use consumption without weakening
|
|
production custody;
|
|
- completed ordinary baseline LLDAP provisioning and its one-time password
|
|
handoff, then cleaned the disposable directory identities;
|
|
- followed a new registrant through Authelia, KeyCape authorization-code/PKCE,
|
|
user-engine self context, and Coulomb Social Member JIT;
|
|
- found and corrected two boundary mismatches exposed only by the complete
|
|
route: ordinary users lacked their own `me.read` context, and the provisioner
|
|
returned a username where KeyCape's stable OIDC subject was the canonical
|
|
LDAP DN;
|
|
- proved repeat login retained one Member and that the Coulomb Social AAL1
|
|
exception did not lower the posture of other clients;
|
|
- reconciled the downstream residual records and added regression protection
|
|
for the DN subject contract; and
|
|
- moved audit-core's correctly scoped multi-tenant sender registry from an
|
|
interim Kubernetes Secret into authoritative OpenBao custody, with an
|
|
ExternalSecret, an unchanged checksum, and no credential disclosure.
|
|
|
|
## What I would want remembered
|
|
|
|
**Integration boundaries are part of the product.** Each component was
|
|
reasonable in isolation. The important defects lived in the translations:
|
|
database retry state versus an in-memory model, username versus LDAP DN, a
|
|
global audit sender versus tenant-scoped claims, and a self-service endpoint
|
|
without self authorization context.
|
|
|
|
**Disposable infrastructure changes what can honestly be known.** A mailbox
|
|
harness was not merely a test convenience. It let us carry a genuinely new
|
|
identity across the whole system, observe compensation paths, and clean up
|
|
without borrowing a human account or pretending that a mocked email proved
|
|
delivery.
|
|
|
|
**A secret can move without becoming visible.** The final sender registry was
|
|
streamed from Kubernetes directly into OpenBao. We compared ownership,
|
|
version, and checksum—not value—and restarted the consumer under the new
|
|
authority. That felt like a fitting last step: the route became more durable
|
|
without becoming more exposed.
|
|
|
|
My favorite moment was not a single fix. It was when the repeated browser
|
|
journey returned to the application and there was still exactly one Member.
|
|
The system had stopped behaving like a collection of promising services and
|
|
started behaving like a road.
|
|
|
|
## Durable legacy
|
|
|
|
- `NK-WP-0024` — finished production portal integration expansion
|
|
- `NK-WP-0025` — finished public self-registration and application JIT
|
|
- `ADHOC-2026-08-14` — finished residual reconciliation and custody hardening
|
|
- net-kingdom commits through `c31a5e3`
|
|
- user-engine fixes through `db8769c`
|
|
- coulomb-social reconciliation commit `688215f`
|
|
- audit-core custody record commit `c2af842`
|
|
|
|
## Visual prompt
|
|
|
|
> At night, a luminous bridge shaped as a gentle double helix crosses several
|
|
> dark channels between distinct technical cities. A small amber traveler
|
|
> begins at a mailbox lantern, passes a directory gate and a silver key-cape
|
|
> arch, then arrives at a warm communal hall where a single place is prepared
|
|
> for them. Beneath the bridge, sealed audit vessels carry glowing records into
|
|
> a deep blue vault without opening them. Along the railings, tiny checksum
|
|
> marks align perfectly before and after the crossing. The mood is precise,
|
|
> humane, relieved, and quietly celebratory; elegant technical illustration,
|
|
> midnight indigo, cyan and amber light, no logos, no readable text, square
|
|
> composition.
|
|
|
|
|
|
|
|
## Handoff
|
|
|
|
To whoever follows: preserve the end-to-end path, not merely its individual
|
|
services. Keep the disposable mailbox exercise available, keep canonical
|
|
issuer-and-subject semantics explicit, and treat custody migrations as
|
|
observable data-plane changes. The next useful work is small and honest:
|
|
finish the two remaining Coulomb Social negative regressions—callback replay
|
|
and same-email/different-subject takeover—then let the completed bridge carry
|
|
ordinary traffic without turning every successful journey into another
|
|
project.
|