Design: per-tenant pause semantics for hosted AMS (orchestration-layer vs in-app kill-switch)

[JSONbored]

Problem

packages/loopover-miner/docs/global-singleton-tenant-audit.md (for the now-closed #5218) flags LOOPOVER_MINER_KILL_SWITCH (packages/loopover-engine/src/governor/kill-switch.ts) as a single process-env boolean with no per-tenant key — one tenant's flag would halt every tenant sharing a process. That finding assumed a shared-process hosting model.

Under the now-decided per-tenant-container model, this may already be structurally resolved a different way: since each tenant is a separate container, "pause tenant X" could simply mean the control-plane stops waking/routing to that container — no in-app flag needed at all. But that's not obviously equivalent to today's kill-switch, which can halt a cycle already in progress, not just prevent a future wake. This issue exists to make that call explicitly rather than assume either answer.

Area

packages/loopover-engine/src/governor/kill-switch.ts, and whatever the shared control-plane's (#7173) provisioning/orchestration layer ends up being.

Proposal

Decide: does orchestration-layer pause (stop scheduling/routing to a container) fully replace the in-app kill-switch for the hosted path, or is there a real gap (e.g. stopping a cycle already mid-flight, or an operator-facing "pause my own instance" self-service action that shouldn't require going through the central control-plane)? If a gap exists, design the per-tenant version of the in-app switch; if not, document why orchestration-layer pause is sufficient and this doesn't need new in-app code.

Deliverables

• Written decision with reasoning
• If new in-app code is needed: the per-tenant kill-switch design
• If not: this issue closes with the reasoning recorded, no code required

Boundaries

• Trust/safety-relevant — maintainer-owned, matching the bar the audit doc itself set (mirrors ORB's equivalent kill-switch scoping, Redesign the global agent-controls table for per-tenant scoping #4885's original concern before it was resolved by architecture).

Links & Resources

• Design: shared hosting control-plane for ORB + AMS SaaS (provisioning, secrets, billing, health) #7173 (parent — shared hosting control-plane)
• packages/loopover-miner/docs/global-singleton-tenant-audit.md
• packages/loopover-engine/src/governor/kill-switch.ts

[linear-code]

JSO-4936

[JSONbored]

Decision: orchestration-layer pause is sufficient for the initial hosted launch — no new in-app kill-switch code needed.

Reasoning: #7182 (AMS's cron-based wake scheduling) already deliberately runs bounded, single cycles — wake, run one discover/attempt/poll cycle, sleep — not the continuous self-scheduling `loop` daemon. That bounds the real gap orchestration-layer pause has (it can't halt a cycle already in flight) to the duration of one cycle, not an indefinite window. Stopping future scheduling at the control-plane is enough to actually stop a paused tenant within one cycle's worth of time.

If incident response ever needs a faster hard-stop than "finish the current bounded cycle," that's a real, separate future need — but it's not required for launch, and building it now would be speculative. Revisit if that need actually materializes.