docs(P71b): presentation badge cleanup + platform architecture diagram (v1.13.2)

Remove all testing/agentic maturity badges from both leadership decks across
all 4 pipeline layers (source .md, Marp -marp.md, rendered .html,
talking-points). Only the planned badges are retained where relevant. Marp
inline CSS dropped the .testing/.agentic rules (kept .planned). README
maturity-framing updated to describe only the Planned badge.

Add a new Slide 3 'The platform at a glance' to both decks with a shared
high-level logical architecture diagram (assets/mmd/platform-architecture.mmd
-> assets/png/platform-architecture.png). The diagram shows the full topology:
consumer surfaces (technical dev + citizen dev) -> contract schema -> central
pipeline (8 fixed stages) -> cross-cutting components (module catalog,
stateless engine adapter, platform-managed environments, HITL gates,
hash-chained evidence stream) -> downstream AWS resources. Subsequent slides
renumbered 4-11; talking points + README directory layout + slide counts
(10->11 main, 19->20 / 18->19 total) synced. Both HTML decks re-rendered.

Docs-only NFR patch (no code changes).

---ci---
project: acdl
phase: 71b
milestone: v1.13
status: complete
---/ci---

docs/presentations/the-developer-experience.md

@@ -2,7 +2,7 @@
 
 > **Subtitle:** Agentic Cloud Delivery Platform
 > **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
-> **Length:** ~15 minutes · 10 main + Appendix TOC + 7 appendix = 18 slides
+> **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`.
@@ -46,7 +46,7 @@ flowchart LR
 ```
 
 - **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. <span class="badge agentic">Agentic</span>
+- **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.
 
@@ -54,7 +54,62 @@ flowchart LR
 
 ---
 
-## Slide 3 — Three things. The entire consumer surface.
+## 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.
 
@@ -82,9 +137,9 @@ The developer does **not**: write infrastructure modules, clone the platform rep
 
 ---
 
-## Slide 4 — See what the platform does, in real time
+## Slide 5 — See what the platform does, in real time
 
-Developers see **what the platform is doing**, in real time. <span class="badge testing">Testing</span>
+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.
@@ -96,9 +151,9 @@ Developers see **what the platform is doing**, in real time. <span class="badge
 
 ---
 
-## Slide 5 — Pick from pre-built, security-reviewed blocks
+## Slide 6 — Pick from pre-built, security-reviewed blocks
 
-Developers pick from **pre-built, security-reviewed building blocks.** <span class="badge testing">Testing</span>
+Developers pick from **pre-built, security-reviewed building blocks.**
 
 ```mermaid
 flowchart LR
@@ -125,14 +180,14 @@ flowchart LR
 - **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> <span class="badge agentic">Agentic</span>
+- **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 6 — The bar rises automatically with sensitivity
+## Slide 7 — The bar rises automatically with sensitivity
 
 The contract is environment-agnostic. The platform raises the bar automatically.
 
@@ -145,7 +200,7 @@ flowchart LR
 
 | Environment | What the platform adds | Maturity |
 |---|---|---|
-| dev | Confidence ≥ 0.50, fully autonomous | <span class="badge testing">Testing</span> |
+| 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> |
@@ -158,9 +213,9 @@ flowchart LR
 
 ---
 
-## Slide 7 — Tearing down is as gated as deploying
+## Slide 8 — Tearing down is as gated as deploying
 
-Tearing down a stack is **as deliberate as deploying one.** <span class="badge testing">Testing</span>
+Tearing down a stack is **as deliberate as deploying one.**
 
 ```mermaid
 flowchart LR
@@ -192,9 +247,9 @@ The per-stack encryption key enters a **grace window** (default 30 days) so encr
 
 ---
 
-## Slide 8 — You control when you absorb improvements
+## Slide 9 — You control when you absorb improvements
 
-Consumers control **when** they absorb platform improvements. <span class="badge testing">Testing</span>
+Consumers control **when** they absorb platform improvements.
 
 ```mermaid
 flowchart LR
@@ -231,9 +286,9 @@ flowchart LR
 
 ---
 
-## Slide 9 — Fails gracefully, not opaquely
+## Slide 10 — Fails gracefully, not opaquely
 
-First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully. <span class="badge testing">Testing</span>
+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:
 
@@ -250,7 +305,7 @@ The pipeline then **exits without attempting a deployment** — no partial state
 
 ---
 
-## Slide 10 — The desired outcomes
+## 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.
@@ -258,7 +313,7 @@ The pipeline then **exits without attempting a deployment** — no partial state
 - **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. <span class="badge agentic">Agentic</span>
+- **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.
 
@@ -285,7 +340,7 @@ For deep dives — these slides cover details omitted from the main 10.
 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.** <span class="badge agentic">Agentic</span>
+- 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:**
@@ -295,7 +350,7 @@ A non-technical consumer ships a production deployment **by declaring intent**
 - 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> <span class="badge agentic">Agentic</span>
+<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.
 
@@ -326,7 +381,7 @@ flowchart LR
 
 ## A3 — Local Reproducibility
 
-The entire CI pipeline runs **from the shell**, not just in CI. <span class="badge testing">Testing</span>
+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.
@@ -380,7 +435,7 @@ ACDL runs at **zero cloud cost** for day-to-day development. The v1.0→v1.10 AW
 | 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. <span class="badge testing">Testing</span>
+- **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.