feat: add deployable alpha silo

2026-07-11 00:25:45 +08:00
parent 44557da499
commit 9e954790dc
57 changed files with 2792 additions and 400 deletions
@@ -0,0 +1,57 @@
+# ADR 0025: Alpha Uses Managed Single-Organization Silos
+
+## Status
+
+Accepted for the supervised alpha.
+
+## Context
+
+The shared SaaS control plane, durable cross-Organization admission scheduler,
+and customer administration SPA are not complete. Real customer data must not
+depend on partially migrated application-level tenant filtering merely to start
+the supervised alpha.
+
+## Decision
+
+Each alpha Organization runs as a separately named Silo deployment. A Silo has
+one Hub systemd unit and service identity, one logical PostgreSQL database and
+database role, one workspace root, one environment/session secret, one local
+master-key keyring, one Feishu Application Connection, and Organization-local
+Provider Connections. The process is pinned by `HUB_SILO_ORGANIZATION_ID` and
+refuses startup unless its database contains exactly that one active
+Organization.
+
+Application releases remain shared and versioned; customer state does not live
+inside a release directory. Host-console bootstrap, upgrade, backup, restore,
+and KEK rotation always name a Silo instance explicitly. The alpha exposes no
+platform administration surface. Operators provision and support Silos through
+the controlled host console and retain an external change record.
+
+The process-local trigger queue is not an accepted-work queue in the Silo
+alpha. A busy project or instance rejects new work explicitly. Each instance
+has checked-in application limits and explicit systemd CPU, memory, and process
+ceilings. Workspace filesystem quotas are a host provisioning prerequisite.
+
+This topology changes deployment, not the semantic tenant root:
+`Organization` remains the tenant root and every authorization, secret, audit,
+Project, Team, and Run remains Organization-scoped. A later pooled or bridge
+adapter may host multiple Organizations only after ADR-0022's durable admission
+and platform control requirements are implemented.
+
+## Consequences
+
+- Cross-Organization data access is prevented by database credentials and
+  process/filesystem identity in addition to application authorization.
+- Provisioning, migrations, backups, health, and upgrades are repeated per
+  Silo and therefore must be automated before tenant count grows materially.
+- Cross-Organization fairness is not applicable inside one Silo; host cgroup
+  ceilings prevent one Silo from exhausting the machine.
+- Database/workspace backups and the keyring/environment recovery copy are
+  produced to distinct protected destinations and must pass a restore drill.
+
+## Deferred
+
+- Shared platform identity and administration from ADR-0023.
+- Pooled durable fair scheduling from ADR-0022.
+- Customer org administration SPA and self-service onboarding.
+- Docker or Kubernetes as an alternative deployment adapter.