9 requirements implemented across presentation decks and project docs: 1. DX closing slide: added 'Infrastructure as a utility, not a craft' bullet to convey the full vision (infrastructure consumed, not maintained; platform compounds value over time). 2. PW Problem slide: 'moving a merged change' → 'promoting a change'. 3. PW Problem slide: added 'Red tape' and 'Scalability without increasing headcount' bullets (4 frictions, not 2). 4. PW Roadmap slide: redesigned with side-by-side HTML table layout (Testing | Planned), 16px font, no overflow. 5. PW deck: added new slide 'What This Platform Is — and Isn't' after North Star (sovereign boundary, infrastructure as utility, 4 anti-goals). PW deck now 16 slides (was 15). 6. Maturity nomenclature: 'Available today'/'shipped' → 'Testing' across both decks + source markdown. New .testing badge (blue/teal #DBEAFE). Roadmap title: 'Testing vs. Planned'. The platform has 0 consumer adoption — 'shipped' was inaccurate. 7. Global: 'substrate' → 'engine' across entire project (88 matches, 30+ files including .ciagent/, docs/, modules/, adapters/, schemas/, code). 8. Presentation files only: 'forge' → 'VCS' / 'version control system' (6 occurrences in 4 files). 'forge' retained in all technical docs and code as the industry-standard term. 9. New .agentic badge (purple/violet #EDE9FE) appended to agentic features in both decks: confidence signal, autonomous dev, pattern recognition, dynamic module creation, citizen developer surface, auto-promotion. Also: Change Request ID format changed from 'CR-2026-001' to 'CHG0678912' across presentation files, consumer guide, and test fixtures. HTML re-rendered. PPTX rendered for release upload. ---ci--- phase: 48 milestone: v1.9 status: complete requirements: covered: [] partial: [] ---/ci---
4.1 KiB
Pipeline
The platform runs two pipelines, both defined by declarative contracts that are the single source of truth for the workflow files.
CI pipeline
The CI pipeline runs on every push and pull request to main. It is defined
by pipelines/ci.yaml,
validated against
schemas/pipeline.schema.json.
Both platform-runner workflow files implement the same contract and are
byte-identical:
.github/workflows/ci.yml— GitHub Actions (production)
Three stages run in sequence:
- lint —
py_compileacross the platform's Python files. - test —
pytestacross the offline test suite. - check-only —
run_platform.sh --check-only(offline, no AWS).
scripts/run_ci.sh mirrors the CI pipeline locally so the pipeline is fully
reproducible from the shell:
bash scripts/run_ci.sh # run all 3 stages
bash scripts/run_ci.sh --quiet # suppress per-stage banners
Deployment pipeline
The deployment pipeline runs when a consumer submits a contract. It is
defined by pipelines/deploy.yaml,
validated against
schemas/deploy-pipeline.schema.json.
It is exposed to consumer repos as a reusable workflow:
.github/workflows/deploy.yml— GitHub Actions (production)
A consumer repo invokes the reusable workflow via a versioned tag
(floating MAJOR + MINOR, e.g. acdl/.github/workflows/deploy.yml@v1.6).
The workflow checks out the consumer repo, then checks out the ACDL platform
repo into the runner workspace, and runs scripts/run_platform.sh against
the consumer's contract. The consumer never clones the platform repo or
invokes its scripts locally. See the Consumer Guide
for the end-to-end happy path.
Deployment stages
flowchart TD
S1["validate-contract<br/>schema check"] --> S2
S2["resolve-stack<br/>contract -> Target Stack"] --> S3
S3["security checks<br/>(adapter)"] --> S4
S4["infrastructure plan<br/>(adapter compiles the stack)"] --> S5
S5["policy checks<br/>(adapter -> PolicyCheckResult)"] --> S6
S6["confidence<br/>score + band"] --> S7
S7["evidence event<br/>to the audit outbox"] --> S8
S8["infrastructure apply<br/>(dev only)"]
- validate-contract — validates the contract YAML against the contract schema. Fails fast on missing fields, unknown modules, or wrong types.
- resolve-stack — the contract resolver resolves the contract to a Target Stack instance (loads the module's pattern, expands its children, wires the contract inputs, emits a stack JSON instance).
- security checks (adapter) — security checks run on the resolved stack before any infrastructure is planned.
- infrastructure plan (adapter) — the engine adapter compiles the stack to an infrastructure plan.
- policy checks (adapter) — policy checks run on the plan. Results are
normalized to
PolicyCheckResultrecords (severity, rule ID, pass/fail). - confidence — the confidence signal computes a score from 6 inputs
(policy, validation, freshness, source, history, NFRs). For
dev, the threshold is ≥ 0.50. If the band ispass, the pipeline proceeds. - evidence event — a hash-chained evidence event is written to the audit outbox.
- infrastructure apply (dev only) — the infrastructure plan is applied, creating the resources. An evidence event for the apply is recorded.
Higher environments hold for human attestation (see Environments).
Output streaming
scripts/run_platform.sh streams output by default so the user can see what
the platform is doing:
--check-only: streams the emitted infrastructure file content.--plan-onlyand full mode: streams the infrastructure plan output.- Full mode: prints policy-check results with severity, rule ID, and pass/fail status.
A --quiet flag suppresses streaming (output to log files only).