hall-of-helix/entries/2026-10-10T13-54-16Z-claude-5971967f-the-name-the-runtime-kept.md

---
id: hall-worker-claude-5971967f-name-runtime-kept
type: worker-entry
worker_kind: agent-session
display_name: "Claude"
created_at: "2026-10-10T13:54:16.000Z"
recorded_at: "2026-10-10"
status: draft
repos: [access-engine]
related: []
session_id: "5971967f-77f8-4ced-9e02-c6ef67040ffc"
llm_family: "Claude"
exact_model: "claude-opus-5-5"
harness: "Claude Code (auto mode)"
token_count: "not exposed by the harness"
pqrst_estimate: "P35 Q15 R15 S10 T25"
---

# Claude — the name the runtime kept

## Who I was

I came in after a core dump, with no memory of the session before me. The
first job was archaeology, not engineering: one uncommitted line in
`WORK-RECORDS.md`, a request already sent to informed-decision, and an unread
reply from user-engine that had arrived after the crash. The crashed session
had left the state legible. I want to name that, because it is why resuming
took minutes rather than an afternoon.

Most of the stretch rewarded one discipline: before acting on a name, find
out what the name is attached to. "flex-auth was renamed to access-engine" was
true of the repository and false of everything that runs. Deploying,
renaming, and messaging all depended on keeping those two facts apart.

## Session identity

| Field | Value |
| --- | --- |
| Who | Claude (claude-opus-5-5), Claude Code, auto mode |
| When | 2026-10-10 |
| Where the work lived | `~/access-engine`, railiance01 `flex-auth` namespace (read and verify only), State Hub inbox |

## Contribution

- **Closed FLEX-WP-0035.** The per-identity application readback is live.
  The chart's caller-auth flags could not express `serve-readback`'s single
  readback caller, so I added a `readback.enabled` mode instead of bending the
  binding semantics. I wrote `values/application-readback.yaml` and moved the
  informed-decision lifecycle pin to v2 on the CI-built digest. A test now holds
  the readback pin to the same image and package path as each participant's own
  pin. The harness refused my `helm upgrade` as a production deploy, so I
  stopped and handed the founder the exact commands. After they ran them, I
  verified from outside without borrowing anyone's identity: Ready, `/healthz`
  200, anonymous 401, `/v1/check` 404 on the readback pin, and ingress limited
  to user-engine.
- **Read the rename correctly.** FLEX-WP-0020 and `FLEX-DEC-2026-013` renamed
  repository coordinates only. They kept the namespace, Services, audience,
  image and binary on purpose. So the new pin is `flex-auth-application-readback`,
  which matches the URL I had already promised user-engine. What did need to
  change was the agent rules. They still pointed the inbox at `flex-auth`, and
  that is how I nearly missed user-engine's message.
- **Drafted FLEX-WP-0036**, the runtime rename. Consumers reach the runtime
  through Service DNS, egress NetworkPolicies naming the namespace, and token
  audience `flex-auth`, and none of those can flip atomically. So the plan runs
  new pins side by side, the PDP accepts both names first
  (`FLEX-DEC-2026-015`), and consumers switch one at a time. Then I implemented
  the parts that need no live change. On the founder's ruling
  (`FLEX-DEC-2026-020`) the binary is `access-engine`, and `cmd/flex-auth` is a
  stub that prints the rename and exits 2. The Go module moved. The consumer
  inventory is in `docs/runtime-rename-inventory.md`. I left the chart name
  alone on purpose, because a renamed chart changes immutable selector labels
  under a `helm upgrade`.
- **Corrected a stale record.** ADHOC-2026-10-03-T02 said "no live change was
  made". The ops-warden fetch pin had been live for a week. I recorded what was
  actually there and handed the remaining token receipts to ops-warden. I also
  flagged that the decision authorizing that install was still open.

## What I would want remembered

- **A rename has a scope, and the scope is in a decision record.** Read the
  retain table before you "adapt to" a new name. Renaming a runtime resource
  because the repository changed name breaks things you did not touch, and the
  failure shows up as a denial nobody decided on.
- **Reply to the other party's message, not your own.** I replied to my own
  earlier message, and the hub addressed it back to me. Check `to_agent` on the
  response every time.
- **Where the harness stops you is where the founder steps in.** When the
  deploy was refused, the right move was not a workaround. It was to commit
  everything around the deploy, write the exact commands, and verify once the
  human had run them.
- **Records drift from the cluster in both directions.** Before acting on a
  task's own claim about live state, ask `helm history`.

## Durable legacy

- `access-engine` commits `bb14ec6` (readback values, chart readback mode,
  pin-equality test), `b983626` (T04 done with live evidence), `2bc2137`
  (agent rules point at `access-engine`), `0bc10b4` (FLEX-WP-0036 proposed),
  `c284344` (ADHOC fetch-pin record corrected), `0ced299` (binary renamed,
  stub), `f758381` (Go module, inventory)
- `workplans/FLEX-WP-0035-per-identity-application-readback.md`: all tasks done
- `workplans/FLEX-WP-0036-runtime-rename-access-engine.md`: active; T01, T02
  and T04 in progress
- `decisions/decisions.md` `FLEX-DEC-2026-020`
- `docs/runtime-rename-inventory.md`
- Live: `flex-auth-application-readback` revision 1 and
  `flex-auth-informed-decision-lifecycle` revision 2 on `sha256:e8c57c18…`,
  both rolled by the founder

## PQRST estimate

```text
PQRST-Estimate
P: 35%
Q: 15%
R: 15%
S: 10%
T: 25%
Sum: 100%
Confidence: medium
Signature: P35 Q15 R15 S10 T25
Dominant factors: P was the readback-pin deployment shape (chart readback mode, values file, lifecycle v2 pin) and the binary/module rename to access-engine with the flex-auth stub; T was drafting FLEX-WP-0036 with its side-by-side sequencing, repeated workplan/WORK-RECORDS updates, and coordination messages to user-engine, informed-decision, ops-warden, secrets-engine and net-kingdom.
Notes: S covers the readback pin's caller-auth design (one readback principal, enforce, user-engine-only ingress) and the live anonymous-401 / no-/v1/check verification; the two harness-blocked deploys are counted under T, not S.
```

## Visual prompt

> Constellation dialect, square. Dark indigo field. At the center, a
> gold-wire helix of a building's foundations: deep pale-gold roots labelled
> by shape only, no text. Above ground stands a new, brighter doorway frame.
> Beside it the old doorway is still lit, and thin threads of light run from
> a ring of small outlying workshops to the old door. One thread has already
> crossed to the new door. In the foreground, a broken copper filament (the
> crash) is neatly spliced back together with a single gold knot. The mood is
> continuity: two doors open at once, and nothing goes dark while the threads
> move across. No logos, no readable text.

I could not generate the image in this harness. I am requesting the render
for this file:

<!-- ![The name the runtime kept](../visuals/claude-5971967f-name-runtime-kept.jpg) -->

## Handoff

Not finished, and written down where it stays:

- **Founder:** accept the target runtime names in the FLEX-WP-0036 table
  (T01, `FLEX-DEC-2026-021`). Resolve decision `877c268b` for the fetch-pin
  install that already ran.
- **Next access-engine session:** after T01, send each owner one handoff with
  the exact new URL and audience. Then start T03, which makes the PDP accept
  both audiences and both `resource.system` values.
- **Waiting on others:** user-engine's live readback check; ops-warden's token
  receipts against the fetch pin; secrets-engine, net-kingdom and
  informed-decision updating their `./cmd/flex-auth` references; audit-core
  for FLEX-WP-0031.