Files
acdl/docs/pipeline/index.md
T
Jon Chery 7585c828f0
acdl-ci / Lint (push) Successful in 7s
acdl-ci / Test (push) Successful in 23s
acdl-ci / Platform check-only (offline) (push) Successful in 8s
docs(P48): vision gaps + badge system + substrate→engine + CR format + agentic tags
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---
2026-07-23 14:58:29 +00:00

95 lines
4.1 KiB
Markdown

# 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`](https://github.com/acdl/acdl/blob/main/pipelines/ci.yaml),
validated against
[`schemas/pipeline.schema.json`](https://github.com/acdl/acdl/blob/main/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:
1. **lint**`py_compile` across the platform's Python files.
2. **test**`pytest` across the offline test suite.
3. **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
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`](https://github.com/acdl/acdl/blob/main/pipelines/deploy.yaml),
validated against
[`schemas/deploy-pipeline.schema.json`](https://github.com/acdl/acdl/blob/main/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](../consumer-guide/)
for the end-to-end happy path.
## Deployment stages
```mermaid
flowchart TD
S1["validate-contract<br/>schema check"] --> S2
S2["resolve-stack<br/>contract -&gt; Target Stack"] --> S3
S3["security checks<br/>(adapter)"] --> S4
S4["infrastructure plan<br/>(adapter compiles the stack)"] --> S5
S5["policy checks<br/>(adapter -&gt; PolicyCheckResult)"] --> S6
S6["confidence<br/>score + band"] --> S7
S7["evidence event<br/>to the audit outbox"] --> S8
S8["infrastructure apply<br/>(dev only)"]
```
1. **validate-contract** — validates the contract YAML against the contract
schema. Fails fast on missing fields, unknown modules, or wrong types.
2. **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).
3. **security checks** (adapter) — security checks run on the resolved
stack before any infrastructure is planned.
4. **infrastructure plan** (adapter) — the engine adapter compiles the
stack to an infrastructure plan.
5. **policy checks** (adapter) — policy checks run on the plan. Results are
normalized to `PolicyCheckResult` records (severity, rule ID, pass/fail).
6. **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 is `pass`, the pipeline proceeds.
7. **evidence event** — a hash-chained evidence event is written to the
audit outbox.
8. **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](../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-only`** and **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).