Problem
#8202 builds the mechanism that delivers a bootstrap credential into a running hosted tenant container so it can pull its own custodied secrets (e.g. a Neon database connection string) from the broker -- but scopes its actual container-side wiring to OrbTenantContainer only. AmsTenantContainer needs the equivalent wiring, and it is a materially different lift, not just a second call site for the same code.
OrbTenantContainer runs the unmodified self-host image (worker.ts's own comment: "runs the SAME root Dockerfile self-host image unmodified"), whose src/server.ts boot sequence already imports and wires up src/orb/broker-client.ts gated purely on an env var being present -- #8202's ORB half is close to free specifically because of this. packages/loopover-miner (AMS's image) has zero references to broker-client/enrollment-secret exchange anywhere today (confirmed by repo-wide grep while researching #8202) -- AMS needs genuinely new code, not reuse.
Area
packages/loopover-miner/lib/hosted-entry.ts (AMS's hosted dispatch point -- currently forwards to runDiscover/runManagePoll/runAttempt, reused in-process self-host commands, per its own header comment) and wherever AMS's own credential resolution lives today (packages/loopover-miner/lib/github-token-resolution.ts handles a human's own interactive OAuth token -- a different flow for a different actor, per src/orb/broker.ts's own header comment distinguishing it from the headless-container broker path).
Proposal
Not prescribing the exact call site -- needs a look at hosted-entry.ts's actual boot/dispatch flow first. Shape, established by #8202: AMS's container reads LOOPOVER_TENANT_SECRET_TOKEN (delivered via stub.start({envVars}) at the container's cold boot, product-agnostic -- the same env var name ORB reads) and exchanges it via fetchBrokeredStoredSecret (#8202, src/orb/broker-client.ts) against POST /v1/orb/token for whatever the broker has custodied (today: a tenant_db_credential; ORB_SECRET_TYPE_AMS_GITHUB_TOKEN already exists in src/orb/broker.ts for a future GitHub-token pull too, mechanically identical to ORB's own GitHub-token mint flow).
Deliverables
Resources
Boundaries
maintainer-only -- split out of #8202 deliberately (2026-07-23) because AMS's container-side lift is real new code, not plumbing reuse, and bundling it would have made #8202 a much larger, slower-to-review PR for no benefit to either half. Blocked by #8202.
Problem
#8202 builds the mechanism that delivers a bootstrap credential into a running hosted tenant container so it can pull its own custodied secrets (e.g. a Neon database connection string) from the broker -- but scopes its actual container-side wiring to
OrbTenantContaineronly.AmsTenantContainerneeds the equivalent wiring, and it is a materially different lift, not just a second call site for the same code.OrbTenantContainerruns the unmodified self-host image (worker.ts's own comment: "runs the SAME root Dockerfile self-host image unmodified"), whosesrc/server.tsboot sequence already imports and wires upsrc/orb/broker-client.tsgated purely on an env var being present -- #8202's ORB half is close to free specifically because of this.packages/loopover-miner(AMS's image) has zero references tobroker-client/enrollment-secret exchange anywhere today (confirmed by repo-wide grep while researching #8202) -- AMS needs genuinely new code, not reuse.Area
packages/loopover-miner/lib/hosted-entry.ts(AMS's hosted dispatch point -- currently forwards torunDiscover/runManagePoll/runAttempt, reused in-process self-host commands, per its own header comment) and wherever AMS's own credential resolution lives today (packages/loopover-miner/lib/github-token-resolution.tshandles a human's own interactive OAuth token -- a different flow for a different actor, persrc/orb/broker.ts's own header comment distinguishing it from the headless-container broker path).Proposal
Not prescribing the exact call site -- needs a look at
hosted-entry.ts's actual boot/dispatch flow first. Shape, established by #8202: AMS's container readsLOOPOVER_TENANT_SECRET_TOKEN(delivered viastub.start({envVars})at the container's cold boot, product-agnostic -- the same env var name ORB reads) and exchanges it viafetchBrokeredStoredSecret(#8202,src/orb/broker-client.ts) againstPOST /v1/orb/tokenfor whatever the broker has custodied (today: atenant_db_credential;ORB_SECRET_TYPE_AMS_GITHUB_TOKENalready exists insrc/orb/broker.tsfor a future GitHub-token pull too, mechanically identical to ORB's own GitHub-token mint flow).Deliverables
fetchBrokeredStoredSecretexchange Deliver secrets/env vars into a running hosted tenant container (OrbTenantContainer/AmsTenantContainer) #8202 ships -- no new broker-exchange code, just a new callercontrol-plane/'s own orchestration (already true after Deliver secrets/env vars into a running hosted tenant container (OrbTenantContainer/AmsTenantContainer) #8202 -- this issue is purely the AMS-side consumer)Resources
fetchBrokeredStoredSecret+ ORB's own wiring -- read that PR first)packages/loopover-miner/lib/hosted-entry.tssrc/orb/broker-client.ts(fetchBrokeredStoredSecret,isOrbBrokerMode)src/orb/broker.ts(ORB_SECRET_TYPE_AMS_GITHUB_TOKEN-- the likely second secret type this ends up pulling)Boundaries
maintainer-only -- split out of #8202 deliberately (2026-07-23) because AMS's container-side lift is real new code, not plumbing reuse, and bundling it would have made #8202 a much larger, slower-to-review PR for no benefit to either half. Blocked by #8202.