acdl/docs/presentations/the-developer-experience.md

# The Developer Experience

> **Subtitle:** Agentic Cloud Delivery Platform
> **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
> **Length:** ~16 minutes · 11 main + Appendix TOC + 7 appendix = 19 slides
> **Purpose:** Sell the developer experience and the citizen developer experience to tech leadership — velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort.
> **Maturity framing:** "Testing" = works internally, dev pilot-ready. "Planned" = on the roadmap. "Agentic" = involves AI agents or autonomous decision-making.
> **Re-verification (2026-07-29):** Every "Testing" claim in this deck was re-verified in v1.10 Phase 54 (D-093) and again in v1.11 via the pipeline-driven lifecycle tests (P59–P62). The headline E2E (contract → resolver → adapter → terraform init/validate/plan) passes against the live AWS account; the local emulating tier (Phase 53) runs the full E2E with no cloud credentials. **22/22 auto-verifiable capabilities Verified** (CAP-013 fixed in v1.12 P67 — the adapter's multi-resource L1 dedup defect is closed). The v1.11 lifecycle pipeline ran apply→modify→destroy against live AWS and was then torn down to zero-cost (D-096). See `.ciagent/CAPABILITY_INVENTORY.md` and `.ciagent/PRE_MORTEM.md`.

---

## Slide 1 — Title

The consumer surface is intentionally tiny. The platform's surface is large and opinionated.

> **Speaker notes:** Brief introduction — this deck covers *who uses the platform and how fast/safe they ship*, not the internal mechanics (that's the companion deck). Set the frame: velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort.

---

## Slide 2 — Two consumer paths, one safety envelope

The platform serves **two kinds of consumer** through two coordinated paths — but both converge on the **same contract, the same policy envelope, and the same evidence stream.**

```mermaid
flowchart LR
    subgraph UP ["Upstream — anything"]
        direction TB
        A["Technical dev\n(app code + contract)"]
        B["Citizen dev\n(intent → AI agent\n→ contract)"]
    end
    subgraph ACDL ["ACDL — infrastructure only"]
        C["Same contract\nSame pipeline\nSame safety"]
        D["Provision\nAWS resources"]
        E["Evidence\nhash-chained"]
    end
    subgraph DOWN ["Downstream"]
        F["AWS resources\nrunning"]
        G["Consumer pipeline\ndeploys image"]
    end
    A --> C
    B --> C
    C --> D
    C --> E
    D --> F
    F --> G
```

- **Technical developer** — owns app code + a contract + a thin CI definition.
- **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope.
- **Upstream is anything** — IDE, agentic SDLC, or vibe coding. ACDL doesn't care how the contract was produced.
- **ACDL is infrastructure only** — it provisions and governs AWS resources. Application deployment is upstream.

> **Speaker notes:** This is the thesis of the deck. The two surfaces are *parallel*, not a progression — a citizen developer doesn't "graduate" to the developer surface. Both produce a contract; both get the same treatment. The scope boundary matters: anything upstream of the contract is out of ACDL's concern. The leadership takeaway: we expand who can ship safely without lowering the bar.

---

## Slide 3 — The platform at a glance

One picture of the whole platform — what you touch, what the platform owns, and where the safety lives. The rest of this deck zooms into the developer-facing pieces.

```mermaid
flowchart TD
    subgraph UP ["Consumer surfaces — upstream"]
        direction LR
        U1["Technical dev\napp code + contract"]
        U2["Citizen dev\nintent → AI agent → contract"]
    end

    subgraph ACDL ["ACDL — infrastructure only"]
        direction TB
        CS["Contract schema\n(validate + fail-fast)"]
        subgraph PIPE ["Central pipeline — fixed stages, every deployment"]
            direction LR
            P1["Validate"] --> P2["Resolve\ntarget stack"] --> P3["Security\nchecks"] --> P4["Infra plan"] --> P5["Policy\nchecks"] --> P6["Confidence\nsignal"] --> P7["Evidence\nevent"] --> P8["Infra apply"]
        end
        CAT["Module catalog\nprimitives + modules\n(security-reviewed)"]
        ADAPT["Engine adapter\n(stateless → Terraform)"]
        ENV["Platform-managed\nenvironments\naccount · VPC · state · IAM"]
        HITL["HITL gates\nqa · prod · dr"]
        EVID["Evidence stream\nhash-chained outbox\n(RPO = 0)"]
        CS --> PIPE
        CAT --> P2
        ADAPT --> P4
        ADAPT --> P8
        ENV --> P8
        P6 --> HITL
        HITL --> P8
        P7 --> EVID
    end

    subgraph DOWN ["Downstream"]
        direction LR
        D1["AWS resources\nrunning\n(tagged, encrypted)"]
        D2["Consumer pipeline\ndeploys image"]
    end

    U1 --> CS
    U2 --> CS
    P8 --> D1
    D1 --> D2
```

- **You own the left edge** — app code and a contract. That is the entire consumer surface.
- **The platform owns everything in the middle** — the pipeline, the catalog, the adapter, the environments, the gates, the evidence.
- **Two surfaces, one pipeline, one evidence stream** — a senior engineer and a citizen developer converge on the same safety envelope.
- **The bar rises automatically** — the confidence signal and HITL gates scale with the target environment, not with a ticket.

> **Speaker notes:** This is the one-slide map. For a developer-experience audience, frame it from the left edge: "this is what you touch, this is what the platform owns for you." The leadership beat: the convergence — two surfaces, one pipeline, one evidence stream — is the design point that lets us expand who can ship safely without lowering the bar. Don't walk every node; point to the contract boundary and say "the rest of this deck zooms into the developer-facing pieces."

---

## Slide 4 — Three things. The entire consumer surface.

Three things. That is the entire consumer-side surface.

```yaml
id: msvc
name: microservice
environment: dev
infrastructure:
  microservice:
    version: "1.0.0"
    inputs:
      cpu: 256
      memory: 512
      desired_count: 2
      port: 8080
```

1. **App code** — the consumer's service, at the top level of the repo
2. **A contract** — a single YAML file: id, name, environment, infrastructure
3. **A one-line CI definition** — a thin `uses:` wrapper pointing at a versioned platform workflow

The developer does **not**: write infrastructure modules, clone the platform repo, hold cloud credentials, or maintain a state backend.

> **Speaker notes:** Hold this slide. The audience should sit with how small the consumer surface is. Every item in the "does not" list is a category of toil the platform removes. The contract is the API — deliberately tiny so that it can be reviewed, validated, and audited. For the Head of DevOps: this is the lever for throughput — the bottleneck moves off the platform team's ticket queue.

---

## Slide 5 — See what the platform does, in real time

Developers see **what the platform is doing**, in real time.

- **Streamed output by default** — the plan, policy-check results, and each check record flow to stdout.
- **PR comments after every successful pipeline stage** — a developer always knows where they stand.
- **Clear, explainable halt reasons** — a policy violation, an insufficient confidence signal, or a missing attestation. **Never an opaque debugging exercise.**
- **Connection strings posted as PR comments** — human-readable, no hunting. Runtime secrets go to encrypted Parameter Store (KMS-encrypted, namespaced), never to logs.
- **Errors become GitHub issues, automatically** — a failed deploy opens an issue on the platform repo.

> **Speaker notes:** This directly answers "but developers hate platforms that hide what they're doing." The platform is opinionated about *what* runs, not *opaque* about *that* it runs. The PR-comment-after-each-stage pattern is a small thing that compounds into trust. The "errors become issues" point is a DX win that also helps the platform team — every consumer failure is a tracked, queryable artifact, not a lost log line.

---

## Slide 6 — Pick from pre-built, security-reviewed blocks

Developers pick from **pre-built, security-reviewed building blocks.**

```mermaid
flowchart LR
    subgraph PRIM ["Primitives"]
        direction TB
        P1["S3"]
        P2["VPC"]
        P3["ECS"]
        P4["IAM"]
        P5["ALB"]
        P6["ECR"]
        P7["CloudFront"]
        P8["WAF"]
        P9["RDS"]
    end
    subgraph MOD ["Modules — composed patterns"]
        direction TB
        M1["Static site\nCDN + WAF + S3"]
        M2["Microservice\nVPC + ECS + ALB + ECR"]
    end
    PRIM --> MOD
```

- **Primitives** — single-purpose resources (S3, VPC, ECS, IAM, ALB, ECR, CloudFront, WAF, RDS), each with documented inputs/outputs and versioning.
- **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + ALB + ECR).
- **Validated examples per module** — `simple.yaml` + `complex.yaml`, validated against the contract schema in CI. Examples cannot drift from the schema silently.
- **Auto-promotion of patterns** — auto-promoted to the catalog after 3 observed usages. <span class="badge planned">Planned</span>
- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in. <span class="badge planned">Planned</span>

> **Speaker notes:** The catalog is what makes "declare intent" practical — you can only declare a module that exists. For leadership: the catalog is the leverage. One well-reviewed module serves every consumer; a fix to the module serves every consumer on the next run. This is the compounding asset.

---

## Slide 7 — The bar rises automatically with sensitivity

The contract is environment-agnostic. The platform raises the bar automatically.

```mermaid
flowchart LR
    DEV["dev<br/>autonomous"] -->|raise the bar| QA["qa<br/>QA attests"]
    QA -->|raise the bar| PROD["prod<br/>SRE attests"]
    PROD -->|raise the bar| DR["dr<br/>SRE attests + DR drill"]
```

| Environment | What the platform adds | Maturity |
|---|---|---|
| dev | Confidence ≥ 0.50, fully autonomous | — |
| qa | QA human attestation + confidence ≥ 0.75 | <span class="badge planned">Planned</span> |
| prod | SRE human attestation + confidence ≥ 0.90 | <span class="badge planned">Planned</span> |
| dr | SRE human attestation + confidence ≥ 0.95 + DR drill reference | <span class="badge planned">Planned</span> |

- **No staging environment** — the design deliberately removes the "staging is basically prod but not really" anti-pattern.
- **Separation of duties is enforced** — the QA approver cannot be the prod approver.
- **Timeout discipline** — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit.

> **Speaker notes:** Promotion is a workflow choice, not a contract mutation — this matters because it means a promotion can be reviewed as a *diff in the workflow*, not as a rewritten contract. The DX win: the contract stays stable across environments; the safety win: the platform raises the threshold and attestation bar automatically based on the target environment. The consumer can't bypass the gates — they pick *which* environment to target, and the platform applies the right bar. Be honest about maturity: dev is tested and pilot-ready; qa/prod/dr wiring is planned.

---

## Slide 8 — Tearing down is as gated as deploying

Tearing down a stack is **as deliberate as deploying one.**

```mermaid
flowchart LR
    A["Validate CR\n(CMDB)"]
    B["Disable\nprevent_destroy"]
    C["SRE\napprove"]
    D["Zero counts\n+ destroy"]
    E["SRE\napprove"]
    F["Key enters\ngrace window"]
    A --> B --> C --> D --> E --> F
```

```yaml
uses: acdl/.github/workflows/deploy.yml@v1.12
with:
  contract: .acdl/contract.yml
  mode: decommission
  changeRequestId: "CHG0678912"
```

A 2-step pipeline with **two SRE human-attestation gates**:

1. **Validate the change request** — the platform queries the CMDB and asserts the CR is `approved` and matches the consumer repo. No CR, no decommission.
2. **Disable deletion protection** → **SRE approves** → **Zero all counts + destroy** → **a second SRE approves.**

The per-stack encryption key enters a **grace window** (default 30 days) so encrypted data remains recoverable.

> **Speaker notes:** The counter-argument to "deletion protection makes cleanup impossible" is this slide. Decommission is a first-class, gated, two-approval flow — not a lock with no key, and not an ungated `terraform destroy`. For the Head of Infrastructure: the CMDB validation means decommission is auditable, not just possible.

---

## Slide 9 — You control when you absorb improvements

Consumers control **when** they absorb platform improvements.

```mermaid
flowchart LR
    subgraph FLOAT ["@v1.12 — floating MAJOR+MINOR"]
        direction LR
        F1["v1.12.0"]
        F2["v1.12.1"]
        F3["v1.12.2"]
        F1 --> F2 --> F3
    end
    subgraph PIN ["@v1.12.2 — pinned exact"]
        direction LR
        P1["v1.12.2"]
        P2["v1.12.2"]
        P3["v1.12.2"]
        P1 --> P2 --> P3
    end
    subgraph MAJ ["@v1 — float MAJOR only"]
        direction LR
        M1["v1.12.0"]
        M2["v1.13.0"]
        M3["v1.14.0"]
        M1 --> M2 --> M3
    end
```

- **Floating MAJOR + MINOR tags** (e.g. `@v1.12`) — automatically receive patch updates within the line.
- **Semantic versioning with a clear contract:** interface → MAJOR, behavior → MINOR, lifecycle → PATCH.
- **Pin to an exact version** for maximum stability, or float on MAJOR only (`@v1`) to absorb new features on your own cadence.
- **Unversioned references (`@main`, bare) are discouraged** — the versioned tag is the only immutability lever.
- **Automated release job** computes the next semver on merge to main, creates the tag, and updates the floating tags.

> **Speaker notes:** This is the "no surprise upgrades" story. Leadership hears two things: (1) consumers aren't forced to chase the platform, (2) the platform isn't forced to support N forks of every workflow. The versioning discipline is what makes both true.

---

## Slide 10 — Fails gracefully, not opaquely

First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully.

When no environment is bound, the platform emits a **user-friendly onboarding prompt** instead of failing opaquely. The prompt tells the consumer:

1. That no environment is bound to their repo yet.
2. What the platform will provision on their behalf (account, network, state, role).
3. The expected turnaround for the platform team to grant the environment.
4. How to request an environment.

The pipeline then **exits without attempting a deployment** — no partial state, no confusing errors.

<span class="badge planned">Citizen developer onboarding path: planned</span>

> **Speaker notes:** This looks like a small thing; it's actually a cultural one. The platform's posture is "help me get started," not "you should have known." For the Head of DevOps: this is what drives adoption. Platforms that fail opaquely on first run get routed around.

---

## Slide 11 — The desired outcomes

- **Velocity without sacrificing safety.** Speed is in the ergonomics; safety is in the gates the consumer cannot bypass.
- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation.
- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event.
- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
- **The bottleneck moves off the platform team's ticket queue.** A merged change progresses through lower environments without a platform engineer joining a thread.
- **Infrastructure as a utility, not a craft.** Teams consume infrastructure, they don't maintain it.
- **A path to the citizen developer.** The same safety envelope serves a senior engineer and a non-technical consumer.

> **Speaker notes:** Close on the strategic frame. The platform is not "a CI/CD tool" — it is the organizational lever for shipping safely at the pace the business demands, with the security and audit posture the regulators require. Invite questions; the companion deck ("How the Platform Works") covers the internal mechanics in more depth.

---

## Appendix — Contents

For deep dives — these slides cover details omitted from the main 10.

1. **A1 — The Citizen Developer Experience** (full)
2. **A2 — No Platform Code, No Cloning** (detail)
3. **A3 — Local Reproducibility** (detail)
4. **A4 — The Road to the North Star** (phased roadmap)
5. **A5 — Glossary**
6. **A6 — Operating Model & Cost** (real AWS spend + pre-mortem)
7. **A7 — Verified by Construction** (the v1.11 architecture)

> **Speaker notes:** These are backup slides for Q&A. Use them when the audience asks for the detail behind a main-slide claim. Don't walk through them in the main talk unless time permits.

---

## A1 — The Citizen Developer Experience

A non-technical consumer ships a production deployment **by declaring intent** — without authoring a workflow, a configuration file, or an infrastructure module. Think of this as **vibe coding on a laptop** — the consumer describes what they want; an AI agent turns that into a contract that the platform treats identically to a senior engineer's.

- The consumer opens an issue describing what they need (e.g. "a web API for the pricing service").
- An AI agent maps the intent to a contract referencing a module from the **reviewed skill catalog.**
- The contract enters the **same pipeline** and must clear the **same confidence gate** before promotion.

**Guardrails that make this safe:**

- Skills are **versioned, signed, and reviewed for sensitive data before release** (Infra & Ops owns the review — it is the mandatory release gate).
- Agents are **stateless** — all state lives in the platform. The platform does not run the skill blindly; it trusts and **always verifies** on the platform side.
- The agent's trace and submission confidence are captured in the contract (`profile: agentic`), so a reviewer can see *how* the contract was produced.
- **Initial skill catalog:** web API, worker, scheduled job, static asset, basic observability bootstrap.

<span class="badge planned">Skill catalog + real agent runtime: planned</span>

> **Speaker notes:** Be honest about maturity: the *mechanism* (agent → contract → same pipeline) is designed and the stub was proven in the v1.0 demo; the full skill catalog and real agent runtime are planned. The "vibe coding on a laptop" framing is intentional — it meets the citizen developer where they already are, but every submission still passes the same safety envelope. The design point matters to leadership now: we are building for a world where more of the org can ship safely, not where more of the org has to become a platform engineer.

---

## A2 — No Platform Code, No Cloning

Consumers `uses:` a **versioned** central workflow. The platform fetches itself at run time. The consumer **never touches platform internals.**

```mermaid
flowchart LR
    A["Consumer repo<br/>app + contract + 'uses:'"] -->|triggers on push to main| B["Platform runner"]
    B -->|checks out the consumer repo| A
    B -->|checks out the ACDL platform repo<br/>into the workspace| C["Platform code<br/>(modules, adapters, schemas)"]
    C --> B
    B -->|runs the pipeline against<br/>the consumer's contract| D["Consumer's resources in AWS"]
```

- The consumer's CI definition is a thin wrapper — one `uses:` line pointing at a versioned tag.
- The runner checks out the consumer repo, then checks out the platform repo into the workspace.
- The platform installs its own runtime dependencies. The consumer installs nothing.
- The consumer **never clones the platform repo, never invokes platform scripts locally** (optional `--check-only` validation is available but not required for the happy path).
- When the platform ships a fix, every consumer on a floating MAJOR.MINOR tag gets it on their next run — no per-repo upgrade project.

> **Speaker notes:** The Head of Cloud cares about this: there is no "platform code in every consumer repo" problem. The version-pinned `uses:` line is the *only* coupling, and it's a coupling that updates itself within the line.

---

## A3 — Local Reproducibility

The entire CI pipeline runs **from the shell**, not just in CI.

- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence.
- `scripts/run_platform.sh --check-only` runs the platform **offline** — no AWS, no policy engine, no outbox required. Validates a contract end-to-end before pushing.
- `--plan-only` runs through the infrastructure plan without applying.
- The CI and deploy pipelines are defined by **declarative contracts** (YAML instances validated against JSON Schemas) — a single source of truth that both workflows implement.

> **Speaker notes:** This is the "no surprises before you push" story. A consumer can validate their contract offline, run the plan offline, and only push when they're confident. The same declarative contract drives both the local tooling and CI — there's no "works on my machine, fails in CI" gap.

---

## A4 — The Road to the North Star

*Proposed phasing — not formally planned.*

```mermaid
flowchart LR
    P1["Phase 1<br/>Core platform<br/>(22/22 Verified)"] --> P2["Phase 2<br/>Safe promotion<br/>qa/prod/dr wiring"]
    P2 --> P3["Phase 3<br/>Agentic surface<br/>(skill catalog + agents)"]
    P3 --> P4["Phase 4<br/>North star<br/>citizen developer GA"]
```

> **Speaker notes:** This is a proposed phasing, not a formally committed plan — call that out explicitly. Phase 1 is what's tested and Verified today (22/22 capabilities, torn down to zero-cost). Phase 2 is the next milestone (qa/prod/dr wiring). Phase 3 introduces the agentic surface. Phase 4 is the north star: citizen developer GA on the same safety envelope. Use this only when an audience member asks "how do you get from here to there."

---

## A5 — Glossary

| Term | Meaning |
|---|---|
| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
| **CMDB** | Configuration Management Database — validates change requests for decommission |
| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |

> **Speaker notes:** Keep this slide in your back pocket for the audience member who asks "what does ABAC actually mean?" Don't read it aloud.

---

## A6 — Operating Model & Cost

ACDL runs at **zero cloud cost** for day-to-day development. The v1.0→v1.10 AWS spend was measured directly via Cost Explorer (`COST.md`, 2026-07-28):

| Metric | Value |
|--------|-------|
| Total spend (8 days) | **$0.001883** |
| Daily average | $0.000235 |
| Projected monthly | ~$0.007 |
| Peak day | 2026-07-27 ($0.000867 — v1.10 regression + verify run) |

- **Local emulators are the primary tier** — the full pipeline runs in-process, no AWS credentials, no Checkov, no DynamoDB.
- **Live-AWS verification is milestone-scoped, then torn down.** The v1.11 lifecycle pipeline ran apply→modify→destroy for every module, then tore down to zero-cost steady state (D-096 — teardown mandatory before milestone COMPLETE). The lifecycle pipeline now **defaults to plan-only** on every PR (fast, no AWS mutation, no cost); a CI variable (`ACDL_LIFECYCLE_MODE=full`) overrides to the real apply→destroy for milestone verification (REQ-134, v1.12).
- **Cost drivers** are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). No running infrastructure between milestones.

**Pre-mortem (`PRE_MORTEM.md`):** the project's failure modes were pre-mortemed before the leadership pitch. The v1.10 decay incident (diff-scoped VERIFY missed 7 adapter defects — decks advertised capability that wasn't reproducible) is the root pattern: *a claim outruns the verification that backs it.* Four forward failure modes + structural mitigations (regression-tested IAM baseline, mandatory teardown, verified-only deck claims, honest scope).

> **Speaker notes:** The headline for the Head of Cloud / Finance: less than one cent over 8 days of active development; zero BAU cloud spend; the lifecycle pipeline defaults to plan-only so the PR-time cost is zero. The pre-mortem is the credibility slide — we already asked "how does this fail?" and the mitigations are structural.

---

## A7 — Verified by Construction (the v1.11 architecture)

v1.11 rebuilt the platform on two architectural pillars that make "Verified" a structural property, not a claim:

- **The stateless adapter (918 → ~80 lines).** The Terraform adapter was a 918-line monolith with 3 constant tables and 39 type-specific branches. It is now a ~80-line **stateless assembler**: it owns no module content. Each L1 module ships a real `terraform/` module dir owning its resource shape, nested blocks, and defaults. A new module is a new terraform dir, not a code change. *(The v1.12 P67 fix closed a dedup defect for multi-resource L1s — ecs-service, alb; CAP-013 now Verified.)*
- **Pipeline-driven lifecycle testing.** A `modules-lifecycle` pipeline matrix-runs each L1 and L2 module's contracts through apply→modify→destroy against live AWS. **The "test" = the pipeline cell going green.** Defaults to **plan-only** on every PR (fast, no AWS mutation, no cost); `ACDL_LIFECYCLE_MODE=full` runs the real apply→destroy for milestone verification (REQ-134, v1.12). The regression gate (D-091) re-runs all 22 capabilities at milestone completion — 22/22 Verified as of v1.12.

> **Speaker notes:** This is the deep-dive slide for the Head of Engineering / Architecture. The two pillars answer "how do you keep the decks honest?" The adapter is simple enough to reason about (a stateless assembler); the lifecycle pipeline is the automated verification that backs every "Testing" claim. The v1.10 lesson is the negative space: a 918-line adapter with type-specific branches decayed silently. The ~80-line stateless adapter + the milestone regression gate are the structural fix. The plan-only default (v1.12) means verification runs on every PR at zero cost, with the full apply→destroy gated behind a CI variable override.