Jon Chery
d830357230
---ci--- project: acdl phase: 21 milestone: v1.6 status: execute ---/ci--- Restructure docs/ into a Jekyll-style GitHub Pages site: - docs/_config.yml (Pages config + nav, excludes internal/) - docs/index.md (landing: platform + consumer model, Features, Roadmap) - docs/modules/index.md (catalog: primitives + modules, normalized terms) - docs/contracts/index.md (schema, fields, sample, multi-contract) - docs/pipeline/index.md (CI + deploy pipeline, stages mermaid, streaming) - docs/pipeline/versioning.md (module + deploy-pipeline versioning) - docs/environments/index.md (platform-managed envs + onboarding, REQ-61) - docs/consumer-guide.md (renamed from CONSUMER_GUIDE.md; GitHub-only, no .gitea, forge->platform runners, L2->modules, composition->pattern, updated mermaid with security-checks + infrastructure-apply) - docs/architecture.md (consolidated from architecture.md + architecture-v1.0.md, current-architecture only, normalized terms: primitives/modules, platform runners, no L1/L2/forge/gitea in prose) - Removed docs/architecture-v1.0.md (consolidated) + docs/CONSUMER_GUIDE.md (renamed). No .ciagent/ or .gitea/ references in docs/. Consumer-facing terminology normalized (L2->modules, L1->primitives, composition->pattern, forge-> platform runners).
2.6 KiB
Environments
A consumer does not provide an AWS account, a VPC, a subnet, an S3 state bucket, or a runner key. The platform manages environments.
What an environment is
A named environment is a platform-owned bundle of:
- An AWS account (or a scoped partition of one).
- A network (VPC + subnets).
- A state backend (an S3 bucket + DynamoDB lock table for infrastructure state).
- An IAM role surfaced to the consumer via attribute-based authorization (ABAC), scoped to the consumer's repository identity and resource tags.
A consumer selects an environment by name in their contract:
environment: dev
The platform resolves the name to the underlying account/network/state/role at run time. The consumer never sees the raw credentials.
First-run onboarding
When a consumer pipeline runs for the first time and no environment is defined for the consumer's repo, the platform detects this and emits a user-friendly onboarding prompt instead of failing opaquely. The prompt tells the consumer:
- That no environment is bound to their repo yet.
- What the platform will provision on their behalf (account/network/state/ role).
- The expected turnaround for the platform team to grant the environment.
- How to request an environment (contact the platform team).
The pipeline then exits without attempting a deployment. Once the platform team binds an environment to the repo, the next pipeline run proceeds normally.
Autonomy by environment
| Environment | Autonomy | Gate |
|---|---|---|
| dev | Full autonomy | Confidence ≥ 0.50 |
| qa | Held for attestation | QA attestation + confidence ≥ 0.75 |
| prod | Held for attestation | SRE attestation + confidence ≥ 0.90 |
| dr | Held for attestation | SRE attestation + confidence ≥ 0.95 + dr-drill |
dev is the only autonomous environment. Higher environments require human
attestation (a platform-runner deployment approval) and a higher confidence
threshold. Staging does not exist.
Onboarding scaffold (current state)
The platform repo ships a minimal onboarding scaffold:
core/environments/— environment definitions (a sampledev.json).core/environment_check.py— checks whether an environment is defined for a given contract's repo + environment name; prints the friendly onboarding prompt when none is defined.scripts/run_platform.shcalls the check before contract validation.
The scaffold is minimal: the actual provisioning of a new environment is a platform-team action today. Self-service environment provisioning is on the roadmap.