docs: define SaaS capacity controls

.scratch/saas-production-readiness/map.md

@@ -5,18 +5,25 @@ Label: wayfinder:map
 ## Destination
 
 The repository can be deployed from a clean checkout as the initial production
-multi-tenant Curriculum Project Hub, operated safely on the ADR-0018/0020/0021
-single-host Linux topology, with repeatable release evidence, rollback and
-recovery procedures, and no known critical security or data-integrity gaps.
+multi-tenant Curriculum Project Hub: platform staff manage Organizations; every
+Organization authenticates through and operates its own customer-owned Feishu
+app/bot, and selects either an Organization-managed BYOK provider connection or
+a distinct platform-managed provider connection; Organization owners/admins
+manage their own members, projects and settings. The ADR-0018/0020/0021
+single-host Linux topology is operated with repeatable release evidence,
+rollback and recovery, and no known critical security or data-integrity gaps.
 
 ## Notes
 
 - `spec/` remains the semantic source of truth; implementation drift must be
   surfaced rather than silently resolved.
 - The initial product boundary follows the accepted ADRs: Organization is the
-  tenant root, customer onboarding may be manual, and full billing, limits,
-  tenant suspension, and self-service platform administration remain deferred
-  unless a readiness investigation proves they are required for safe operation.
+  tenant root and customer onboarding may be manual. Full billing, tenant
+  suspension, and self-service platform administration remain deferred;
+  ADR-0022's safety limits and workload brakes are required for production.
+- Manual guided setup may provision each Organization's customer-owned Feishu
+  app during the pilot; one process-global Feishu/OAuth credential shared by
+  unrelated Organizations is not an acceptable destination state.
 - Use the `diagnosing-bugs` loop for every reproduced defect. Prefer explicit
   failures and observable critical paths over fallback behavior.
 - Work on `saas-production-readiness`; make small conventional commits after
@@ -32,6 +39,7 @@ recovery procedures, and no known critical security or data-integrity gaps.
 - [Audit tenant, authentication, and request security boundaries](issues/02-audit-tenant-auth-security.md) — retain the working org-admin/application authorization core, but production is blocked on agent/MCP isolation, execution-time object binding, org-scoped encrypted credentials, tenant status, browser sessions, and clean dependency audits.
 - [Audit run lifecycle and data integrity under failure](issues/03-audit-run-lifecycle-integrity.md) — retain the database-enforced project-lock uniqueness and normal happy path, but replace receipt-before-success, process-local queues, independent run/session/lock effects, silent delivery/audit loss, and partial startup reset with durable, recoverable state machines; explicitly decide failed-run workspace semantics.
 - [Define production observability and incident recovery](issues/04-define-observability-recovery.md) — keep the existing Fastify/Prisma/systemd signal fragments, but production requires dependency-aware readiness, typed and correlated errors, durable-work telemetry, an explicit SLO/retention/alerting control plane, and recovery runbooks proven by fault drills.
+- [Define initial abuse and capacity controls](issues/05-define-abuse-capacity-controls.md) — require layered fail-closed limits, durable Organization-fair admission, explicit backpressure, bounded files/storage/runs, soft usage alerts, and audited emergency workload brakes; calibrate numerical ceilings under production-like load.
 
 ## Fog