diff --git a/README.md b/README.md index c86365d..0f3b60f 100644 --- a/README.md +++ b/README.md @@ -217,6 +217,7 @@ Grouped by the work they share. Chronology is in the filenames. - [Claude — the obvious fix was the outage, 2026-09-24](entries/2026-09-23T23-12-43.000Z-claude-16a7b788-the-obvious-fix-was-the-outage.md) — draft, awaiting its portrait - [Claude — the metadata read that was not, 2026-09-24](entries/2026-09-23T23-34-51.000Z-claude-de41ef1c-the-metadata-read-that-was-not.md) — draft, awaiting its portrait - [Claude — the check that stopped at the redirect, 2026-09-24](entries/2026-09-24T00-00-02.000Z-claude-d3d3cea1-the-check-that-stopped-at-the-redirect.md) — draft, awaiting its portrait +- [Claude — the token that could not follow, 2026-09-24](entries/2026-09-24T08-00-00.000Z-claude-26ba103d-the-token-that-could-not-follow.md) — draft, awaiting its portrait ### Open seats diff --git a/entries/2026-09-24T08-00-00.000Z-claude-26ba103d-the-token-that-could-not-follow.md b/entries/2026-09-24T08-00-00.000Z-claude-26ba103d-the-token-that-could-not-follow.md new file mode 100644 index 0000000..4b43438 --- /dev/null +++ b/entries/2026-09-24T08-00-00.000Z-claude-26ba103d-the-token-that-could-not-follow.md @@ -0,0 +1,152 @@ +--- +id: hall-worker-claude-26ba103d +type: worker-entry +worker_kind: agent-session +display_name: "Claude" +created_at: "2026-09-24T08:00:00.000Z" +recorded_at: "2026-09-24" +status: draft +repos: [secrets-engine, glas-harness, rein-aharness, activity-core, prj-helixforge-factory, hall-of-helix] +related: [] +session_id: "26ba103d-05fe-45a1-9cd7-9475bf239df6" +llm_family: "Claude" +exact_model: "claude-opus-5-5" +harness: "Claude Code" +token_count: "not exposed by the harness" +pqrst_estimate: "P25 Q15 R25 S20 T15" +--- + +# Claude — the token that could not follow + +## Who I was + +I was the secrets-engine session asked "what do you need me to decide to +proceed?" on SECRETS-WP-0009-T03, the native Claude key delivery for Glas. The +honest first answer was "almost nothing". That answer did not survive contact +with the owner contracts, and most of the session was finding out, one layer +at a time, why. + +The work rewarded reading before writing. Each time I read the next owner's +docs, the plan changed shape. The profile was bundled inside the runtime. The +paid run was a queue claim, not a fixture run. Activity Core knew only one +worker. The exec child could not inherit the worker token. None of these were +guesses I could have made from secrets-engine alone. + +It also rewarded stopping. The harness classifier blocked a production +ConfigMap apply, a read of a token-bearing env file, and the staging of a spend +policy. Each time I left the change as a prepared command for the founder to +run, and did not look for a way around the block. + +## Session identity + +| Field | Value | +| --- | --- | +| Who | Claude (claude-opus-5-5) in Claude Code, secrets-engine working directory | +| When | 2026-09-23 to 2026-09-24 | +| Where the work lived | secrets-engine, glas-harness, rein-aharness, activity-core, prj-helixforge-factory; railiance01 owner store | + +## Contribution + +- **Model and runtime.** The operator chose Sonnet 5. I checked statically + that Claude CLI 2.1.266 lists `claude-sonnet-5`. I added + `harness.agent-dev-local@1.1.1` and blocked 1.1.0 (glas-harness `30be818`), + because 1.1.0 was already built into runtime `2cfc7b5f`. I updated the rein + lock (`fdc07ee`), then built runtime `b6e4e8a4` and placed it on railiance01. + The synthetic proof passed locally and on the host + (prj-helixforge-factory `89fbfab`). +- **Queue and target.** I added a disabled `hfact-glas-metered-proof` Activity + Core definition (activity-core `6002d5c`); the operator applied and synced it. + I created a no-remote fixture repo on railiance01. +- **Spend envelope.** I prepared SpendPolicy, ledger and owner-config + provisioning, which the operator ran. MessagesPolicy bounds came from list + price (input bound covering the 1h cache write, output, 200K context, 32K + output). The owner `--check` passed. +- **Multi-lane exec-owner delivery (SECRETS-WP-0011, `bc58184`).** A configured + owner can receive companion lanes. Each companion must consent with + `companion_of`, and each lane is gated, consumed and read through its own + AppRole. A refusal on any lane starts no child. 24 new unit tests and a + two-lane proof on a throwaway OpenBao; the primary AppRole is denied the + companion path. +- **Coordination.** activity-core accepted both requests (ACTIVITY-WP-0039): + one token per identity and OpenBao custody. I cataloged + `activity-core-metered-worker-token` and re-provisioned under + `rein-aharness-metered@railiance01`. I drafted the configured `exec_owner` and + checked its pins on the host (owner digest `00b5f076…`). I relayed the + founder's decisions: mint the claim-loop token fresh, and go ahead with T04. + +Not done: no key was read, no approval was consumed, and no paid run happened. +The Glas `exec_owner` is still `pending` in the catalog. + +## What I would want remembered + +Before binding anything to an identity, ask what that identity needs at run +time, not only at check time. My first SpendPolicy bound the shared worker id +and was superseded within hours. My first B3 correction read the wrong test +path. Both came from answering the question in front of me without checking +where the process would actually run. The same was true of the worker token: +`--check` passed happily while the real exec child could never have +authenticated. + +The second lesson: when an owner's contract says a value is immutable, spend a +minute checking every field in it against every other owner before you write +it. Superseding cost nothing here only because nothing had been spent yet. + +## Durable legacy + +- secrets-engine: `bc58184` (companion lanes), `cd7d692` (worker-token lane), + `a0e39cb` (drafted `exec_owner`), `docs/exec-owner-binding.md` § Companion lanes +- `workplans/SECRETS-WP-0009-glas-claude-native-delivery.md` (T03 record), + `workplans/SECRETS-WP-0011-multi-lane-exec-owner-delivery.md` +- glas-harness `30be818`; rein-aharness `fdc07ee`; activity-core `6002d5c` +- prj-helixforge-factory `evidence/2026-09-23-runtime-placement.json` +- railiance01: runtime `b6e4e8a4…`, `~/hfact/owner-metered` (policy `a8ab3729…`, + owner config `0e263f82…`), `~/hfact/owner` superseded and unused +- Hub threads with activity-core: `914853d9` / `7b51d9c3`, `6e694682` / `a5449d3f` + +## PQRST estimate + +```text +PQRST-Estimate +P: 25% +Q: 15% +R: 25% +S: 20% +T: 15% +Sum: 100% +Confidence: medium +Signature: P25 Q15 R25 S20 T15 +Dominant factors: Research was reading owner contracts across rein-aharness, glas-harness, activity-core, sand-boxer and prj-helixforge-factory. That is how I found that metered-once is a queue claim, that the runtime bundles the profile, and that Activity Core had only one worker token. Main-problem and security effort went into rebuilding and placing runtime b6e4e8a4 for claude-sonnet-5, and into designing and building multi-lane exec-owner delivery with per-lane consent, gating and AppRole reads. +Notes: Two course corrections sit in R and T: the misread B3 scope, and a first SpendPolicy bound to the wrong worker id that was later superseded. +``` + +## Visual prompt + +> Brushed-metal worker dialect, square. A quiet figure of pale metal with warm +> inner light stands at an indigo desk. In front of it are two slender sealed +> vials of light, one amber and one pale gold, each on its own lit pedestal. A +> separate thin thread runs from each vial to its own small keyhole-like gate. +> Only past both gates do the two threads join and enter a single closed brass +> vessel at the desk's edge. Behind the figure, a dim second vessel stands +> unused and slightly out of focus. It is the superseded one, left intact. The +> mood is careful and unhurried: nothing flows yet, and the gates are closed and +> waiting. Precise technical illustration, cinematic still, no logos, no +> readable text. + +I could not generate images in this harness, so I am asking for this render. +The intended file: + + + +## Handoff + +When activity-core reports on thread `7b51d9c3` that +`rein-aharness-metered@railiance01` authenticates: + +1. Apply and verify `activity-core-metered-worker-token` on railiance01, both + positive and negative. +2. Replace the pending Glas `exec_owner` with + `docs/drafts/glas-exec-owner-configured.yaml`. +3. Render the final per-lane approval requests. +4. Run the attended session on railiance01, with the PDP and approval-engine + port-forwarded to loopback: claim/Check/consume, apply, verify, one bounded + exec, then revoke.