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
SECRETS-WP-0011	workplan	Multi-lane exec-owner delivery	infotech	secrets-engine	proposed	implementation	claude-code	netkingdom	2026-09-23	2026-09-23	SECRETS-WP-0009 HFACT-WP-0001

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.

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: todo
priority: high

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: todo
priority: high

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: todo
priority: high

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: wait
priority: high
blocking_reason: "Needs activity-core owner assent to source ACTIVITY_CORE_WORKER_TOKEN from OpenBao (ESO) instead of a hand-generated Kubernetes Secret."

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.