Epic: AMS Cloud Readiness

[JSONbored]

Context

A dedicated research pass (external: how Sentry, GitLab, Grafana, PostHog, Supabase, n8n, Cal.com, Ghost, Plausible, Mattermost, and Discourse each split self-host from cloud/SaaS; internal: what ORB's own Cloud Readiness epic (#4877) already concluded, and what AMS's current package boundary already buys) informs this milestone's scope and shape.

Recommended pattern

Adopt "identical core package + thin, additive control-plane wrapper" — the Supabase/Ghost/Sentry shape — for both ORB and AMS, not GitLab/n8n/Plausible's in-repo license-gated-flags model, and not Cal.com's April-2026 divergence into a private fork (which the research found had already caused core-system drift within 3 months). Concretely: packages/gittensory-engine/src/miner/* + packages/gittensory-miner stay a single, unmodified core that self-host and any future hosted AMS both consume identically. Every cloud-only concern — tenant provisioning, auth/identity, billing, fleet ops, secrets-at-scale — lives in a separate, additive layer that calls into that core through injected interfaces (the same shape driver-factory.ts and worktree-allocator.ts already use), never inline inside the CLI-glue files. Where a genuinely paid, trust-sensitive feature ever needs gating, prefer Mattermost's structural three-tier model (open core / source-visible-inert middle / closed private-peer-repo compiled in via build tag) over a bare runtime license flag — GitLab's own rule is explicit: a SaaS-only feature check must never appear in the self-host build.

AMS's head start: unlike ORB (whose Cloud Readiness Phase A is literally retrofitting a core-package boundary that grew inline for years — the same costly retrofit GitLab paid at 55-engineer/600+-MR/~1.5M-line scale), AMS was built as a separate package from day one. This milestone should skip straight to the Phase-B-equivalent work ORB's #26 already enumerates (multi-tenancy/isolation, fleet/ops, scaling/capacity, secrets-at-scale, incident/SLA), scoped to AMS's own already-real gaps — including one confirmed, already-shipped bug: packages/gittensory-miner/lib/governor-kill-switch.js resolves its kill-switch from a bare env var with no tenant key, the same class of bug ORB's own #4885-#4893 sweep is fixing for itself.

Scope summary

• Moved in from Rent-a-Loop (6): Design a client/server split for AMS #4938 (client/server split), Add tenant-scoping columns to all local ledger schemas #4939 (tenant-scoping columns), Replace the local-file database abstraction with a shared datastore for hosted use #4940 (shared datastore), Design an auth/identity layer for AMS #4941 (auth/identity layer), Re-evaluate the local concurrency model for a shared-service context #4942 (concurrency model), Decide the fate of the unimplemented hosted discovery-plane #4943 (hosted discovery-plane decision) — these are generic hosted-AMS infrastructure questions, not specific to Rent-a-Loop's own product/threat-model, so they belong here rather than in a business-launch milestone (mirrors how ORB Cloud Readiness sits in its own milestone, separate from any product-specific backlog).
• Architecture & research (4): Spec: AMS hosted control-plane architecture (core-package-plus-wrapper pattern) #5215 (control-plane architecture spec), Research spike: storage-abstraction candidates to replace AMS's node:sqlite local-store #5216 (storage-abstraction research spike), Research spike: auth/identity provider comparison for hosted AMS #5217 (auth/identity provider research spike), Spec: client-surface strategy for hosted AMS (web dashboard vs. mobile/desktop apps vs. CLI-only) #5229 (client-surface strategy — web/mobile/desktop/CLI).
• Tenant-isolation audits (2): Audit: enumerate AMS's global-singleton state with tenant-leak risk #5218 (global-singleton state sweep, starting from the confirmed governor-kill-switch gap), Audit: privacy pass on AMS telemetry/export surfaces for cross-tenant leakage #5219 (telemetry/export privacy pass).
• Fleet/ops design (3): Design: provisioning API/CLI to stand up a new hosted AMS tenant instance #5220 (provisioning API/CLI), Design: fleet rollout/versioning mechanism for many hosted AMS instances #5221 (fleet rollout/versioning), Design: tenant/instance concept for AMS's fleet deployment assets (docker-compose/k8s/Terraform) #5222 (tenant/instance concept for the Wave 4 fleet assets).
• Scaling & capacity (2): Design: per-tenant scheduling and queue-fairness model for hosted AMS #5223 (per-tenant scheduling/fairness model), Execution: load-testing harness and published capacity numbers for AMS's iterate-loop under concurrent load #5224 (load-testing harness + published capacity numbers).
• Secrets at scale (1): Design: centralized secrets custody for AI-provider keys and DB credentials across hosted AMS tenants #5225 (centralized AI-provider-key and DB-credential custody).
• Incident/SLA readiness (2): Design: fleet-wide health aggregation and status-page concept for hosted AMS #5226 (fleet health aggregation/status page), Draft: SLA and incident-response commitment for hosted AMS #5227 (SLA/incident-response commitment draft).
• Baseline documentation (1): Document: current-state single-machine concurrency assumptions across AMS's core modules #5228 (single-machine concurrency-assumption inventory, informing Re-evaluate the local concurrency model for a shared-service context #4942).

How to use this issue

This is deliberately a small, direction-setting batch for a future milestone, not a contributor-throughput sprint — most items are maintainer-only architecture/design decisions by design (mirrors ORB Cloud Readiness's own ~100%-maintainer-only posture), with a handful of research-spike/audit/documentation items already open to contributors. Sequencing: #5215 (the control-plane spec) and #5228 (the concurrency baseline) are the two items everything else benefits from existing first, though nothing strictly blocks starting other items in parallel. Do not start any client-app (mobile/desktop) build against #5229 until that spec issue actually closes with a decision.

Scope clarification: billing & onboarding (added 2026-07-12)

Unlike ORB Cloud Readiness (#26), this milestone deliberately has no billing/quota/plan-model or signup/onboarding-flow issues of its own. AMS already has a specific, named hosted product — "Rent-a-Loop" (milestone #24 / epic #4778) — whose own Billing/onboarding/legal group (#4802 self-serve signup & App-install flow, #4803 payment integration, #4804 pricing/rate card, #4805 Terms of Service) already covers this for AMS specifically. ORB has no equivalent product-specific milestone, so its own billing/onboarding work lives inside Cloud Readiness instead. If a future hosted-AMS offering beyond Rent-a-Loop ever needs its own separate billing model, file it here explicitly rather than assuming this gap is an oversight.

[linear-code]

JSO-3756