docs(P71): polish leadership decks — action headlines, trim, 6 new diagrams (v1.13)

Polish both leadership decks (how-the-platform-works + the-developer-experience)
across all 4 pipeline layers (source md, marp, html, talking points).

Story-arc restructure (per storytelling best practices):
- Intro ~10% / Body ~80% / Conclusion ~10%; 3-5 body points per deck
- One idea per slide; action headlines replace category names
- Before/after 2-slide sequence (problem -> north star) on platform deck
- Main 10 slides kept; detail pushed to expanded appendix (8 + 7)

Word reduction + natural flow:
- Remove all <em class="story"> transition lines (flow carried by headlines)
- Bullets <= 12 words, 3-4 per main slide (was 5-6)
- Cut parentheticals, sub-clauses, redundant restatements

Design + visuals:
- Larger fonts: body 22 -> 26px, h1 34 -> 40px, h2 26 -> 32px, blockquote 20 -> 24px
- 6 new mermaid diagrams -> PNGs:
  - platform-works-02-frictions (2x2 quadrant)
  - platform-works-03-north-star (before/after)
  - platform-works-07-zero-trust (OIDC + ABAC flow)
  - developer-experience-05-catalog (primitives -> modules)
  - developer-experience-07-decommission (6-node gate flow)
  - developer-experience-08-semver (floating/pinned/major timeline)
- At most 1 diagram per main slide; no diagrams on title/conclusion
- High contrast preserved, no animations, maturity badges intact

Verify:
- Marp renders both decks clean (HTML re-rendered, committed)
- Talking-points sections == Marp slide count per deck
- No stale "deploy-unverified" claims (only closed-status disclosure)
- 522 tests pass (no code touched; only docs/presentations/ files changed)
- 22/22 Verified framing preserved verbatim from v1.12

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

docs/presentations/the-developer-experience-talking-points.md

@@ -18,7 +18,7 @@
 
 ---
 
-## Slide 2 — Where ACDL Sits in Your World
+## Slide 2 — Two consumer paths, one safety envelope
 
 **Talking points:**
 - This is the scope-boundary slide — here's who uses the platform, and here's where ACDL's responsibility starts and stops
@@ -31,7 +31,7 @@
 
 ---
 
-## Slide 3 — The Contract — The Entire Consumer Surface
+## Slide 3 — Three things. The entire consumer surface.
 
 **Talking points:**
 - Hold this slide — the audience should sit with how small the consumer surface is. Three things: app code, a contract, a one-line CI definition
@@ -44,7 +44,7 @@
 
 ---
 
-## Slide 4 — The Developer Feedback Loop
+## Slide 4 — See what the platform does, in real time
 
 **Talking points:**
 - 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
@@ -58,177 +58,174 @@
 
 ---
 
-## Slide 5 — Versioned, Predictable Releases
-
-**Talking points:**
-- This is the "no surprise upgrades" story — consumers aren't forced to chase the platform, and the platform isn't forced to support N forks of every workflow
-- Floating MAJOR + MINOR tags (e.g. `@v1.12`) — a consumer automatically receives patch updates within the line. Pin to exact version for stability, or float on MAJOR only for new features
-- Semantic versioning with a clear contract: interface → MAJOR, behavior → MINOR, lifecycle → PATCH
-- Unversioned references (`@main`, bare) are discouraged — the versioned tag is the only immutability lever a consumer has
-- The automated release job computes the next semver on merge to main, creates the tag, and updates the floating tags — no manual release process
-
-**Key takeaway:** Consumers control when they absorb platform improvements. No surprise upgrades.
-
----
-
-## Slide 6 — Friendly Onboarding
-
-**Talking points:**
-- 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"
-- First impressions of a platform are made when it fails for the first time. The platform fails gracefully with a guided prompt, not an opaque error
-- The prompt tells the consumer: what's missing, what the platform will provision, the expected turnaround, and how to request an environment
-- The pipeline exits without attempting a deployment — no partial state, no confusing errors
-- Be honest: the citizen developer onboarding path is planned, not yet shipped
-
-**Key takeaway:** The platform fails gracefully. First impressions drive adoption — platforms that fail opaquely get routed around.
-
----
-
-## Slide 7 — Safe Promotion Path
-
-**Talking points:**
-- 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 promotion journey diagram shows the rising bar: dev (autonomous) → qa (QA attests) → prod (SRE attests) → dr (SRE attests + DR drill)
-- Approach A (one contract, environment passed by the job) keeps the single source of truth — the contract never changes
-- Approach B (environment-specific contracts) lets teams whose inputs genuinely vary keep that variation explicit and reviewable
-- The rising bar is annotated with maturity: **dev = Testing** (works internally, pilot-ready); **qa/prod/dr = Planned** (on the roadmap). Be honest about that split
-- Separation of duties is enforced — the QA approver cannot be the prod approver. No staging environment — the design deliberately removes the "staging is basically prod but not really" anti-pattern
-
-**Key takeaway:** Change the environment field, not the contract. The platform raises the bar automatically. The consumer can't bypass the gates.
-
----
-
-## Slide 8 — Safe Decommission
-
-**Talking points:**
-- The counter-argument to "deletion protection makes cleanup impossible" — decommission is a first-class, gated, two-approval flow, not a lock with no key
-- The change request must be `approved` in the CMDB and match the consumer repo — no CR, no decommission
-- Two SRE human-attestation gates: one to disable deletion protection, a second to zero counts and destroy
-- The per-stack encryption key enters a 30-day grace window so encrypted data remains recoverable — the key is permanently deleted only after the window expires
-- For the Head of Infrastructure: the CMDB validation means decommission is auditable, not just possible
-
-**Key takeaway:** Tearing down is as gated as deploying. Two SRE approvals, CMDB-validated change request, 30-day key grace window.
-
----
-
-## Slide 9 — Self-Service Module Catalog
+## Slide 5 — Pick from pre-built, security-reviewed blocks
 
 **Talking points:**
 - The catalog is what makes "declare intent" practical — you can only declare a module that exists
-- Primitives are single-purpose resources (S3, VPC, ECS, IAM, ALB, ECR, CloudFront, WAF, RDS) — each with documented inputs/outputs, usage, compliance extension points, and versioning
-- Modules are composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + ALB + registry) — one well-reviewed module serves every consumer
-- Validated examples per module — `simple.yaml` + `complex.yaml` + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently
-- For leadership: the catalog is the leverage — a fix to a module serves every consumer on the next run. This is the compounding asset
-- Auto-promotion of patterns (after 3 observed usages) and compliance extension points (GDPR, SOX, SOC2, DORA) are planned
+- 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
+- Primitives are single-purpose resources (S3, VPC, ECS, IAM, ALB, ECR, CloudFront, WAF, RDS) — each with documented inputs/outputs and versioning
+- Modules are composed patterns — a static site with CDN + WAF; a microservice with VPC + ECS + ALB + ECR
+- Validated examples per module (`simple.yaml` + `complex.yaml`) are validated against the contract schema in CI — examples cannot drift from the schema silently
+- Auto-promotion of patterns (after 3 observed usages) and compliance extension points (GDPR, SOX, SOC2, DORA) are on the roadmap
 
-**Key takeaway:** The catalog is the compounding asset. One well-reviewed module serves every consumer. A fix serves everyone on the next run.
+**Key takeaway:** You don't author infrastructure — you pick from pre-built, security-reviewed building blocks. The catalog is the compounding asset.
 
 ---
 
-## Slide 10 — The Desired Outcomes
+## Slide 6 — The bar rises automatically with sensitivity
 
 **Talking points:**
-- Close on the strategic frame — the platform is not "a CI/CD tool," it's the organizational lever for shipping safely at the pace the business demands
-- Velocity without sacrificing safety: speed is in the ergonomics (a simple contract, a one-line `uses:`), safety is in the gates the consumer cannot bypass
-- Security, observability, and compliance as platform defaults — not per-team effort, not post-hoc remediation. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction
+- Promotion is a workflow choice, not a contract edit — 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
+- No staging environment — the design deliberately removes the "staging is basically prod but not really" anti-pattern. Dev is the only autonomous environment
+- Separation of duties is enforced — the QA approver cannot be the prod approver
+- Be honest about maturity: dev is tested and pilot-ready; qa/prod/dr wiring is planned
+
+**Key takeaway:** The bar rises automatically with sensitivity. The consumer picks the environment; the platform applies the right gate.
+
+---
+
+## Slide 7 — Tearing down is as gated as deploying
+
+**Talking points:**
+- 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`
+- The CMDB validation means decommission is auditable, not just possible — the platform queries the CMDB and asserts the CR is `approved` and matches the consumer repo
+- Two SRE human-attestation gates: disable 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 during decommission
+- For the Head of Infrastructure: this is what makes deletion protection safe to ship by default — cleanup is a deliberate, gated path, not an impossible one
+
+**Key takeaway:** Tearing down is as deliberate as deploying — two SRE attestation gates + CMDB-validated change request.
+
+---
+
+## Slide 8 — You control when you absorb improvements
+
+**Talking points:**
+- 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
+- Floating MAJOR + MINOR tags (e.g. `@v1.12`) — a consumer automatically receives patch updates within the line
+- Semantic versioning with a clear contract: interface → MAJOR, behavior → MINOR, lifecycle → PATCH
+- A consumer can pin to an exact version for maximum stability, or float on MAJOR only (`@v1`) to absorb new features on their own cadence
+- Unversioned references (`@main`, bare) are discouraged — the versioned tag is the only immutability lever a consumer has
+- The automated release job computes the next semver on merge to main, creates the tag, and updates the floating tags
+
+**Key takeaway:** You control when you absorb platform improvements — no surprise upgrades, no forced forks.
+
+---
+
+## Slide 9 — Fails gracefully, not opaquely
+
+**Talking points:**
+- 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
+- When no environment is bound, the platform emits a user-friendly onboarding prompt — not an opaque failure
+- The prompt tells the consumer: no environment bound, what the platform will provision, expected turnaround, how to request an environment
+- The pipeline then exits without attempting a deployment — no partial state, no confusing errors
+- The citizen developer onboarding path is planned
+
+**Key takeaway:** The platform fails gracefully, not opaquely — first impressions are made when it fails for the first time.
+
+---
+
+## Slide 10 — The desired outcomes
+
+**Talking points:**
+- 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
+- Velocity without sacrificing safety: speed is in the ergonomics (a simple contract, a one-line `uses:`); 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
 - 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, they don't maintain. The platform compounds value over time by learning from recurring patterns
-- The path to the citizen developer — the same safety envelope that serves a senior engineer will serve a non-technical consumer. Expanding who can ship safely without lowering the bar
+- A path to the citizen developer: the same safety envelope serves a senior engineer and a non-technical consumer
+- Invite questions; the companion deck ("How the Platform Works") covers the internal mechanics in more depth
 
-**Key takeaway:** Velocity without sacrificing safety. Security and auditability as byproducts. The bottleneck moves off the platform team's queue.
+**Key takeaway:** Ship safely at the pace the business demands, with the security and audit posture the regulators require.
 
 ---
 
-## Appendix — Contents
+## Appendix TOC — Appendix
 
 **Talking points:**
-- These are backup slides for Q&A — don't walk through them in the main talk unless time permits
-- Use A1 when asked about the citizen developer detail; A2 for the no-cloning mechanism; A3 for local reproducibility; A4 for the roadmap; A5 for term definitions
-- The appendix now has 7 slides (A1–A7), including two new ones: A6 (Operating Model & Cost with real AWS figures + pre-mortem) and A7 (Verified by Construction — the v1.11 architecture)
+- 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
+- The appendix is indexed to match the Marp deck's A1-A7 structure
 
-**Key takeaway:** The appendix is the deep-dive drawer. Pull a slide when the audience asks for the detail behind a main-slide claim.
+**Key takeaway:** Backup slides for Q&A — pull the relevant appendix slide when asked.
 
 ---
 
 ## A1 — The Citizen Developer Experience
 
 **Talking points:**
-- The framing is **vibe coding on a laptop** — the consumer describes what they want in plain language; an AI agent turns that into a contract the platform treats identically to a senior engineer's
-- The consumer opens an issue (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 — no weaker mode
-- Guardrails: skills are versioned, signed, and reviewed for sensitive data before release (Infra & Ops owns the review); agents are stateless — all state lives in the platform; the platform trusts and always verifies
-- The agent's trace and submission confidence are captured in the contract (`profile: agentic`), so a reviewer can see how the contract was produced
-- Be honest about maturity: the mechanism is designed and stub-proven; the full skill catalog and real agent runtime are planned
+- 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
+- Guardrails: skills are versioned, signed, reviewed for sensitive data; agents are stateless; the platform trusts and always verifies
+- The agent's trace and submission confidence are captured in the contract (`profile: agentic`) for review
 
-**Key takeaway:** Vibe coding on a laptop — but every submission passes the same safety envelope. The agent produces the contract; the platform verifies it.
+**Key takeaway:** A non-technical consumer ships by declaring intent — same pipeline, same safety envelope, no weaker checks.
 
 ---
 
 ## A2 — No Platform Code, No Cloning
 
 **Talking points:**
-- The consumer's CI definition is a thin wrapper — one `uses:` line pointing at a versioned tag. That's the only coupling
-- 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)
-- 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
-- For the Head of Cloud: there is no "platform code in every consumer repo" problem. The version-pinned `uses:` line is the only coupling, and it updates itself within the line
+- 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
+- The runner checks out the consumer repo, then checks out the platform repo into the workspace — the consumer never clones the platform repo
+- The platform installs its own runtime dependencies — the consumer installs nothing
+- When the platform ships a fix, every consumer on a floating tag gets it on their next run — no per-repo upgrade project
 
-**Key takeaway:** One `uses:` line is the only coupling. The platform fetches itself at run time. No per-repo upgrade projects.
+**Key takeaway:** The consumer never touches platform internals. The versioned `uses:` line is the only coupling.
 
 ---
 
 ## A3 — Local Reproducibility
 
 **Talking points:**
-- The entire CI pipeline runs from the shell, not just in CI — no "works on my machine, fails in CI" gap
+- 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
 - `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
+- `scripts/run_platform.sh --check-only` runs the platform offline — no AWS, no policy engine, no outbox required
+- The same declarative contract drives both the local tooling and CI — there's no "works on my machine, fails in CI" gap
 
-**Key takeaway:** Validate offline, plan offline, push when confident. The same declarative contract drives local tooling and CI.
+**Key takeaway:** The entire CI pipeline runs from the shell — no surprises before you push.
 
 ---
 
 ## A4 — The Road to the North Star
 
 **Talking points:**
-- Call this out explicitly: **proposed phasing, not formally planned** — don't let the audience read it as a commitment
-- Phase 1 is what's Verified today (22/22 capabilities) — core platform (contract, catalog, evidence), torn down to zero-cost
-- Phase 2 is the next milestone — safe promotion wiring for qa/prod/dr
-- Phase 3 introduces the agentic surface — skill catalog + agents
-- Phase 4 is the north star — citizen developer GA on the same safety envelope
-- Use this slide only when an audience member asks "how do you get from here to there"
+- 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 (skill catalog + agents)
+- 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"
 
-**Key takeaway:** A proposed path from the Verified core (22/22) to the citizen developer north star — proposed phasing, not formally planned.
+**Key takeaway:** Proposed phasing — Phase 1 Verified, Phase 4 is the North Star (citizen developer GA).
 
 ---
 
 ## A5 — Glossary
 
 **Talking points:**
-- Keep this slide in your back pocket for the audience member who asks "what does ABAC actually mean?" — don't read it aloud
-- OIDC = short-lived federation tokens, no long-lived credentials; ABAC = access scoped by resource tags + repo identity, not roles
-- CMK = per-stack encryption key, 90-day rotation; CMDB = validates change requests for decommission
-- RPO = 0 means evidence written synchronously, no data loss; HITL = deliberate human attestation for qa/prod/dr
-- VCS = the git hosting platform (GitHub, Gitea, GitLab); NFR = encryption, tagging, observability standards
+- Keep this slide in your back pocket for the audience member who asks "what does ABAC actually mean?"
+- Don't read it aloud
+- All acronyms used in the deck are defined here
 
-**Key takeaway:** The deck uses real security and ops vocabulary. The glossary is the cheat sheet for the audience member who wants the definitions.
+**Key takeaway:** Reference slide — don't read aloud.
 
 ---
 
 ## A6 — Operating Model & Cost
 
 **Talking points:**
-- This is the slide for the Head of Cloud / Finance — the headline: less than one cent ($0.001883) over 8 days of active development; zero BAU cloud spend
-- Walk the cost table: total $0.001883 / 8 days, daily average $0.000235, projected monthly ~$0.007, peak day 2026-07-27 at $0.000867
-- S3 dominates the spend (98.8%, the terraform state bucket) — no compute (ECS/Lambda) ran because v1.0→v1.10 was plan-only for IAM-gated capabilities
-- 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 (D-096 — teardown mandatory before milestone COMPLETE)
-- The lifecycle pipeline now defaults to **plan-only** on every PR (fast, no AWS mutation, no cost); `ACDL_LIFECYCLE_MODE=full` overrides to apply→destroy for milestone verification (REQ-134, v1.12)
-- The pre-mortem (`PRE_MORTEM.md`) is the credibility slide — we already asked "how does this fail?" The v1.10 decay incident (diff-scoped VERIFY missed 7 adapter defects) 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)
+- 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; `ACDL_LIFECYCLE_MODE=full` overrides for milestone verification
+- The pre-mortem is the credibility slide — we already asked "how does this fail?" and the mitigations are structural
+- The v1.10 decay incident is disclosed honestly, not hidden — that disclosure IS the mitigation
+- Cost drivers are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). No running infrastructure between milestones
 
-**Key takeaway:** Less than one cent over 8 days. Zero BAU cloud spend. The pre-mortem + plan-only default make cost a non-issue and verification structural.
+**Key takeaway:** Zero BAU cloud cost. Pre-mortemed failure modes with structural mitigations.
 
 ---
 
@@ -236,10 +233,9 @@
 
 **Talking points:**
 - This is the deep-dive slide for the Head of Engineering / Architecture — the two pillars answer "how do you keep the decks honest?"
-- Pillar 1 — the **stateless adapter** (918 → ~80 lines): the old adapter was a monolith with 3 constant tables and 39 type-specific branches. The new adapter is a stateless assembler that owns no module content — each L1 module ships a real `terraform/` module dir owning its 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 is now Verified
-- Pillar 2 — **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. No per-module Python
-- The pipeline defaults to plan-only on every PR (zero cost); `ACDL_LIFECYCLE_MODE=full` runs the real apply→destroy for milestone verification. The regression gate (D-091) re-runs all 22 capabilities at milestone completion — 22/22 Verified as of v1.12
-- The v1.10 lesson is the negative space: a 918-line adapter with type-specific branches decayed silently because the VERIFY gate was diff-scoped. The ~80-line stateless adapter + the milestone regression gate are the structural fix
+- 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 because the VERIFY gate was diff-scoped
+- 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
 
-**Key takeaway:** "Verified" is a structural property, not a claim — a stateless ~80-line adapter + a lifecycle pipeline that defaults to plan-only and goes green on every PR.
+**Key takeaway:** "Verified" is a structural property, not a claim — the stateless adapter + lifecycle pipeline make it so.