Implementation plan
The implementation plan follows ten phases. All phases are documented as planned; this repository does not establish implementation progress. Phase 0 validates the architecture before substantial production implementation. Phases 1–7 build the platform, Phase 8 establishes the organization pilot, and Phase 9 delivers developer workflows and GA.
Delivery sequence
- Phase 0: architecture spikes and ADRs
- Phase 1: control-plane foundation
- Phase 2: managed source and change sets
- Phase 3: sandboxed build system
- Phase 4: runtime and data plane
- Phase 5: deployment, preview, migration, and recovery
- Phase 6: Entra identity and security policy
- Phase 7: MCP and AI-native workflow
- Phase 8: Pilot hardening
- Phase 9: developer hybrid and v1 GA
Dependency boundaries
- Resolve the sandbox, hosting, runtime compatibility, DB, identity, MCP, routing, and signing gates before production depends on them.
- Establish tenancy, audit, idempotency, outbox, and secrets foundations before exposing source or runtime mutations.
- Source revisions feed builds; signed artifacts feed runtime activation. Approval binds the exact artifact, migrations, capabilities, and policy.
- Phase 4 can test identity assertions with fixtures. Actual Entra sessions, SCIM, and revocation depend on Phase 6.
- JIT enables early identity work, but SCIM is required for v1 completion.
- GitHub canonical mode is required for GA in Phase 9, after the initial managed-source pilot.
Acceptance evidence
Every phase retains the implementation scope and exit criteria from the source plan. Acceptance records need an owner, date, implementation revision, test or drill output, relevant decision records, and unresolved risks. No calendar estimates, staffing assignments, final vendor choices, or completed milestones are implied.
Use the test strategy, pilot scenario, and definition of done together. Building this documentation site is not a platform acceptance test.