intrnl.cloud
Reference

Decision register

Locked architecture and the evidence required to close open implementation gates.

Status conventions

Locked means the source plan establishes the design. Open gate means a selection or contract needs validation. Proposed default is an initial pilot value. Future is outside the current delivery scope. These states do not indicate implemented functionality.

Locked baseline

The architectural decisions establish a central SaaS control plane with separate runtimes; dedicated pilot infrastructure; disposable sandboxed builds; workerd inside an OS/VM sandbox; scoped remote MCP; intrnl-brokered identity; one canonical source; Nuxt first; per-environment SQLite; and governance based on capabilities and risk. Separate registrable runtime and control-plane domains are also mandatory.

Open implementation gates

  • Sandbox RuntimeClass: compare Kata/Firecracker with gVisor, including KVM availability, isolation, startup, build performance, memory, network enforcement, upgrades, and cost. Record the chosen class and fallback.
  • Infrastructure and region: identify vendor, region, data residency requirements, KVM support, availability design, storage, and operational ownership. No vendor or region is selected here.
  • Nuxt/workerd compatibility: publish the supported template, pinned toolchain, API subset, package exclusions, and benchmark results.
  • Database contract: fix result/error shapes, parameter types, batch atomicity, transaction semantics, limits, WAL, concurrent writes, backups, and multiple runtime replica behavior.
  • KV contract: document consistency, limits, TTLs, listing, namespace isolation, and recovery expectations independently from Cloudflare KV.
  • Entra identity: validate issuer/subject mapping, app roles, assigned groups, group overage, JIT, session revocation, and redirects. SCIM remains a required v1 follow-on.
  • MCP compatibility: prove approved client/account combinations, OAuth transport and discovery, scope denial, human/client attribution, expiration, and revocation. Specify how approved workspace or account membership is established; client branding alone is insufficient evidence.
  • Source adapter: validate managed repository creation, changes, protected merges, complete export, backup/restore, and optional developer access.
  • Domain and TLS: choose the separate runtime apex and certificate automation, and validate preview naming, origin protection, and trusted client IPs.
  • Artifacts and signing: define manifest encoding, digests, signing-service boundary, key custody, rotation, verification before execution, and activation.
  • Quotas, retention, and capacity: benchmark actual Nuxt workloads and accept final request, build, storage, preview, and retention settings. Keep the proposed defaults distinct from guarantees.
  • Commercial prices: set amounts and packaging separately from the locked economic model. No prices are promised here.

ADR record

Each accepted gate needs a stable ADR ID, status, owner, date, context, alternatives, validation evidence, decision, consequences, fallback, and review trigger. Link it from the relevant phase and contract page. Do not mark an open selection accepted based solely on a preferred candidate in the plan.

Acceptance gates after Phase 0

The pilot hardening phase requires security review, resolved critical/high penetration-test findings, restore evidence, pilot organization sign-off, and rehearsed operational procedures. The GA phase requires GitHub canonical mode and portable developer handoff.