Spec: AMS hosted control-plane architecture (core-package-plus-wrapper pattern)

[JSONbored]

Problem

AMS Cloud Readiness is a currently-empty milestone with no agreed shape for how a future hosted AMS should relate to the existing self-host packages. Without a written architecture spec, individual issues (storage, auth, fleet ops) risk being designed independently and re-entangling tenant/control-plane logic back into packages/gittensory-miner — repeating the mistake ORB's own Cloud Readiness epic (#4778 and its sub-issues, e.g. #4793/#4797/#4885) is now paying down for the single-machine-to-hosted transition on the ORB side.

Area

AMS / Cloud architecture

Proposal

Write and get sign-off on an architecture spec that fixes the pattern for every subsequent AMS Cloud Readiness issue: packages/gittensory-engine/src/miner/* and packages/gittensory-miner's core logic stay unmodified and reusable as-is; all tenant/auth/billing/fleet/secrets concerns live in a new, separate control-plane service that calls into the core packages through the same injected-driver interfaces already used for spawn/agent invocation (no new coupling introduced between core logic and hosting concerns). The spec must explicitly name, file-by-file, which existing modules are "reusable core" (untouched by hosting concerns) versus "single-machine glue to be replaced" (e.g. anything that currently assumes one process, one operator, one filesystem).

Deliverables

• Written architecture spec (markdown, reviewed) naming the reuse boundary file-by-file across packages/gittensory-engine/src/miner/* and packages/gittensory-miner
• A decision on where the control-plane service lives (new package vs. new app) and its relationship to packages/gittensory-engine and packages/gittensory-miner
• An explicit non-goals list, carried forward into every subsequent issue opened under this milestone

Resources

• packages/gittensory-engine/src/miner/*
• packages/gittensory-miner/lib/*
• ORB Cloud Readiness epic Epic: ORB Cloud Readiness #4877 (for Phase A/B framing precedent)
• ORB's tenancy sub-issues Per-tenant execution sandboxing #4793 (per-tenant execution sandboxing), Cross-tenant data-isolation audit #4797 (cross-tenant data-isolation audit), Redesign the global agent-controls table for per-tenant scoping #4885 (per-tenant agent-controls redesign) as the pattern this spec must mirror on the AMS side

Boundaries

• Design-only. This issue must NOT modify packages/gittensory-engine/src/miner/* or packages/gittensory-miner code, and must NOT stand up any control-plane service or infrastructure — it produces a document, not a deployment.
• Must NOT make a storage, auth, or fleet-ops implementation decision itself; it only fixes the pattern those follow-up issues must conform to.
• Once merged, this spec supersedes any ad-hoc scoping already implied in the storage/auth/audit issues in this milestone — if a later issue's proposal conflicts with the reuse boundary this spec sets, the spec wins and the later issue gets amended.
• Multi-tenant architecture design is maintainer-only: it sets precedent every other issue in this milestone depends on, matching the same bar ORB's own tenancy-boundary issues (Per-tenant execution sandboxing #4793/Cross-tenant data-isolation audit #4797/Redesign the global agent-controls table for per-tenant scoping #4885) were held to.

[linear-code]

JSO-3741