secrets-engine/workplans/SECRETS-WP-0011-multi-lane-exec-owner-delivery.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	related_workplans	state_hub_workstream_id
SECRETS-WP-0011	workplan	Multi-lane exec-owner delivery	infotech	secrets-engine	finished	implementation	claude-code	netkingdom	2026-09-23	2026-09-27	SECRETS-WP-0009 HFACT-WP-0001	ecb0643d-bad7-5d63-b340-e77ab9579b0a

Demand: SECRETS-WP-0009-T03. A configured exec_owner child today receives only the catalog's fixed non-secret environment plus one delivered field (exec_delivery.py:233). The Glas metered owner (rein-aharness metered-once) also needs the Activity Core worker token to claim its queue row. Operator decision 2026-09-23: generalize secrets-engine delivery rather than add a rein-side token-file reader.

Operator decisions 2026-09-23: one decision chain per lane (no flex-auth package change), and the worker-token lane uses ordinary lane approval, not human control, since it only lets a worker claim jobs.

Scope: one exec may deliver fields from more than one cataloged lane into one catalog-bound owner. The primary lane stays the one named by --catalog; the others are companions declared on the primary's exec_owner.

Invariants carried over unchanged:

• Every delivered value comes from a cataloged lane through that lane's own AppRole, in memory only, with self-revoking sessions and redaction.
• Each lane's read is its own protected action. No lane's approval, decision or consume covers another lane.
• The binding stays exact. Companion lanes, fields and env names are part of the exec_owner digest, and the command is refused if any differ.
• Fail closed as a set. If any lane is unapproved, missing, denied or fails, no child is started and no value is kept.

Define the companion contract

id: SECRETS-WP-0011-T01
status: done
priority: high
state_hub_task_id: "820514c9-f54d-530e-a45c-9a04486831c2"

Extend exec_owner with companions: [{catalog, field, env}]. Validate at catalog load: each companion is an existing kv lane with the same stage, a declared field, an env name that doesn't collide with the fixed environment or another delivery, and exec-env in its delivery modes. Companions are refused on pending owners. Document the contract in docs/ and the SCOPE exec-time delivery section.

Gate and fetch each lane separately

id: SECRETS-WP-0011-T02
status: done
priority: high
state_hub_task_id: "33d0fc37-5f23-53a6-9456-f8bd1cc984f9"

Run the existing approval-claim / CheckRequest / consume chain once per lane, with each lane's own action and resource, before any value is fetched. Then fetch every value, re-check the binding digest, and spawn once with all values injected and redacted. Evidence records each lane's decision reference and session cleanup. Any failure starts no child and reports which lane refused.

Tests and throwaway OpenBao proof

id: SECRETS-WP-0011-T03
status: done
priority: high
state_hub_task_id: "52a0ff40-81d6-589a-b05f-3e5f55f81a81"

Unit tests: validation, digest coverage, collision, stage mismatch, partial approval, one lane denied after another is fetched, redaction of every value, cleanup of every session. Integration: two KV lanes delivered to one owner on a throwaway OpenBao dev server.

Catalog the Activity Core worker token lane

id: SECRETS-WP-0011-T04
status: done
priority: high
state_hub_task_id: "cf465065-de7a-5d9c-bc80-fee16ffef70d"

Completed 2026-09-27: custody handoff received, companion cataloged and wired into the configured Glas owner after fresh backend-free host verification. Native activation remains in existing SECRETS-WP-0009-T03, as detailed below.

Request activity-core to move the worker token into OpenBao custody, synced to actcore-runtime-secret by their existing openbao-activity-core store. Then catalog a read lane for the metered owner and add it as the Glas lane's companion. This coordinates with activity-core's multi-worker request (hub message 914853d9): a dedicated metered worker token would use the same lane shape.

Implementation return — 2026-09-23

T01–T03 done. exec_owner.companions and delivery_config.companion_of are validated at catalog load. resolve_companions runs before any gate, and cmd_exec gates each lane separately (its own evidence, stance, approval and consume) before opening the backend. exec_with_secret reads each lane through its own AppRole, starts no child if any lane fails, re-checks the binding, and redacts every value. Suite: 465 passed. Integration on a throwaway OpenBao: 2 passed (two lanes to one owner; the primary AppRole is denied the companion path). Contract: docs/exec-owner-binding.md § Companion lanes. T04 waits on activity-core (hub message 6e694682).

activity-core return — 2026-09-23

Accepted under ACTIVITY-WP-0039 (hub 053ef7c6). activity-core b4a7a84 adds ACTIVITY_CORE_WORKERS: one token per identity, no shared token, no fallback. The dedicated identity is rein-aharness-metered@railiance01, with its token at platform/workloads/activity-core/ops-run-workers/rein-aharness-metered-railiance01 (field token), seeded fresh. Not deployed yet.

Cataloged as activity-core-metered-worker-token (prod, standard risk, companion_of: [glas-claude-agent-dev-anthropic], ordinary decision approval). Not applied. Suite: 467 passed.

Founder go-ahead for ACTIVITY-WP-0039-T04 (ExternalSecret, multi-identity rollout, claim-loop restart) relayed 2026-09-24 on activity-core thread 7b51d9c3. Store policy was done 2026-09-23T18:06Z (CCR-2026-0029/0030).

Enforce companion-only delivery at both entry points

id: SECRETS-WP-0011-T05
status: done
priority: high
state_hub_task_id: "11090cb5-6d56-51da-a372-78ce5749241c"

Review on 2026-09-27 found that companion_of consent was checked when resolving companions, but a caller could select that lane directly as the primary exec lane with an arbitrary child. The delivery helper also accepted a supplied companion list without comparing it with the pinned owner declaration.

Refuse standalone companion delivery before approval/backend/read. Require the helper's supplied lane/field/environment list to match the owner declaration, and recheck companion consent and stage before any value is read. Preserve ordinary lanes and the configured multi-lane child. Regression tests cover both entry points, omissions, additions, substituted lane/field/environment, revoked consent and stage mismatch.

Validation: 476 tests passed, including disposable OpenBao integration tests; layer conformance and git diff --check passed. No production credential was requested or delivered.

Activity Core handoff reviewed — 2026-09-27

Owner messages a2eae5f8-60cf-499b-8f52-dd04ac407924 and bfef619d-53e0-4b4c-8b92-ef092450e4a1 report ACTIVITY-WP-0039 finished at activity-core 54ab1e4. The founder-run check on 2026-09-24 returned HTTP 200 for the metered identity on a no-match label, and HTTP 403 when that token claimed the loop identity. The existing loop continued to claim with its own fresh token. This is the owner's reported evidence, not a new live check here.

The former token seeding/store-policy/identity-rollout blocker is resolved. T04 remains wait for native lane activation with SECRETS-WP-0009-T03: current owner admission/pins, exact per-lane approvals and attended apply/verify/exec. The draft binds rein-aharness-metered@railiance01 and hfact-metered, matching the handoff. No production policy, role, catalog binding or credential changed.

Catalog task and workplan completed — 2026-09-27

T04's stated work is custody coordination, the worker-token catalog entry and adding that entry as the Glas owner's companion. All three are now complete. Activity Core's 2026-09-24 handoff supplies the custody/identity return. The configured binding is now in catalog/glas-claude-agent-dev-anthropic.yaml, including the worker identity/label and a private spend-policy file pin.

A fresh backend-free check on railiance01 verified the installed owner with metered-once --check --no-hub (dispatch disabled), and this checkout's exact path/ownership/mode/hash checks passed for the executable, owner configuration, spend policy and private working directory. Receipt: docs/evidence/2026-09-27-companion-catalog-readiness.json. The owner digest is 46ab4f3fab1c5996ee61c96061b90518d625ffb3fa0966c9bbf7550f422b884b.

The previous wait reason conflated catalog completion with native activation. That activation was already owned by SECRETS-WP-0009-T03 and stays there: exact per-lane action approvals, scoped attended apply, positive/negative verification, actual bounded delivery and session revocation. No new task is needed. This workplan's completion claims the configured multi-lane contract, its tests and catalog wiring, not production delivery. No credential was requested or read, no queue row was claimed, and no provider request was made.