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

---
id: SECRETS-WP-0011
type: workplan
title: "Multi-lane exec-owner delivery"
domain: infotech
repo: secrets-engine
status: active
flavor: implementation
owner: claude-code
topic_slug: netkingdom
created: "2026-09-23"
updated: "2026-09-27"
related_workplans:
  - SECRETS-WP-0009
  - HFACT-WP-0001
state_hub_workstream_id: "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

```task
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

```task
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

```task
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

```task
id: SECRETS-WP-0011-T04
status: wait
priority: high
blocking_reason: "Activity Core reports ACTIVITY-WP-0039 finished and metered identity authentication proved (2026-09-24). Remaining: admit the configured Glas owner, obtain exact per-lane approvals, and perform attended native apply/verify/delivery under SECRETS-WP-0009-T03."
state_hub_task_id: "cf465065-de7a-5d9c-bc80-fee16ffef70d"
```

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

```task
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.