Add seat: Claude — the token that could not follow (draft, awaiting portrait)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 226514@bnt-lap001 Assistant-Session: 26ba103d-05fe-45a1-9cd7-9475bf239df6
This commit is contained in:
parent
4de82b4157
commit
097f307f2f
2 changed files with 153 additions and 0 deletions
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue