acdl/.ciagent/archive/CLARIFY-v1.30.md

CLARIFY — v1.30 Single-shot Leadership Deck

Autonomy: full. Auto-resolution with assumption logging per config.autonomy.level: "full". No human escalation unless confidence < 0.60. The user confirmed the 4 framing decisions (milestone numbering, render pipeline path, stale intake assumption override, smoke test PPTX gate) in the pre-run planning conversation. This file records the formal D-IDs and the spec §7 open-question resolutions.

---

Method

The clarify stage identifies ambiguities in the v1.30 specification (REQ-372 v1.0, locked 2026-08-20) and resolves them at full autonomy. The spec is the user-provided "REQ-372 — Nova Leadership Presentation Deck." Each ambiguity gets a decision ID (D-241+, continuing from v1.29's D-232..D-240), a resolution, a confidence score, and a rationale.

---

Prior-conversation resolutions (already locked, restated for the record)

These were resolved by the user in the pre-run planning conversation that spawned v1.30. They are load-bearing for v1.30 execution.

Q-M1 — The cover note/spec say "v1.29.x" but the checkpoint says v1.29 is complete and active_milestone is v1.30. What is the milestone number?

Resolution: The milestone is v1.30. The cover note's "v1.29.x" is the tag line (per run.md branch strategy, tags run on the previous minor's patch line: milestone v1.30 → tags v1.29.1, v1.29.2, v1.29.3). The milestone branch is milestone/v1.30-leadership-deck. v1.29 is complete (merged to main 9dc5669, tag v1.28.6). Confidence: 1.0 (user-confirmed — "Milestone v1.30, tags v1.29.x"). Decision: n/a (milestone identity, not a D-ID).

Q-M2 — The cover note says scripts/render_pptx.py docs/presentations/nova-leadership-deck.md but render_pptx.py expects {deck}-marp.md naming. How to resolve?

Resolution: Author the source as docs/presentations/nova-leadership-deck-marp.md to fit the existing -marp.md pipeline convention. Narrowly extend render_pptx.py to accept an explicit source .md path + --output filename, and to render a right-aligned footer textbox on every slide (python-pptx does not read the Marp footer: directive). The output is nova-leadership-deck.pptx per spec REQ-372.2. Formalized as D-242. Confidence: 1.0 (user-confirmed — "Author source as nova-leadership-deck-marp.md, extend render_pptx.py"). Decision: D-242.

Q-M3 — The post-v1.29 STATE.md intake (assumption 3) says the leadership deck "is a compression, not a rewrite" of the 23-slide citizen-developer deck. The cover note + spec explicitly forbid compression. How to handle?

Resolution: Override the stale intake assumption. The leadership deck is a discrete, hand-authored artifact — NOT a compression. The existing citizen-developer deck (nova-autonomous-cloud-delivery-marp.md) remains untouched. The spec §2.2 + cover note forbid compression/mirroring; the Slide Content Map is hand-authored content, not derived. Update STATE.md intake assumption 3 to reflect the discrete-artifact decision. Formalized as D-241. Confidence: 1.0 (user-confirmed — "Override with spec's discrete-artifact decision"). Decision: D-241.

Q-M4 — The smoke test (REQ-372.8f) must assert PPTX file existence. Given the render environment limitations, should the PPTX-existence check be a hard fail or a conditional skip?

Resolution: Hard fail if .pptx absent. The deck must be rendered before ship. The render environment is resolved (python-pptx installed via user-site pip install --user --break-system-packages; no Chromium needed since python-pptx is the render path, not Marp CLI). If the environment cannot render, that is a ship blocker to resolve — not a reason to weaken the gate. Confidence: 1.0 (user-confirmed — "Hard fail if .pptx absent"). Decision: n/a (gate severity, not a D-ID — recorded in PLAN.md).

---

Open questions from the spec's §7 (auto-resolved at full autonomy)

Q1 — Specific meeting date inside August 2026

Spec context: The presentation is in August 2026, but no specific day is named. Slide 7 references "Infrastructure & Operations leadership" without naming a day.

Resolution: Anchor to month-only (August 2026). No specific day in the deck text. November 2026 is the runway anchor (~90 days from August 2026). Confidence: 0.95. Impact if wrong: Very low — the meeting is what it is; the deck text doesn't depend on a specific day. Decision: D-243 (date anchor discipline: month-only).

Q2 — Explicit non-compression of the existing citizen-developer deck

Spec context: The two decks (leadership + citizen-developer) remain discrete artifacts. The existing 23-slide nova-autonomous-cloud-delivery-marp.md is not compressed or modified.

Resolution: Document the discrete-artifact constraint in REQ-372.9 (related-artifacts header comment) + D-241 (this file) + D-241 record in PROJECT.md at ship (REQ-372.11). Leave the existing citizen-developer deck untouched. The cover note's hard scope rules ("Do not modify nova-autonomous-cloud-delivery-marp.md") are binding. Confidence: 1.0. Impact if wrong: None for this milestone. Decision: D-241 (restated — the discrete-artifact decision is the same as Q-M3's override).

Q3 — Assumption: existing scripts/render_pptx.py accepts S&P theme directives and Marp speaker notes without modification

Spec context: The render pipeline is existing; the spec assumes it works for the new deck. If a theme limitation forces a renderer change, scope narrowly and update render_pptx.py separately as a non-REQ-372 task.

Resolution (confirmed by research): The existing render_pptx.py has two gaps for REQ-372: (a) it expects a {deck} arg and reads {deck}-marp.md / writes {deck}-python.pptx — it does not accept an explicit source path or custom output filename; (b) it does not read the Marp footer: directive (it skips HTML comments at lines 366-379 and never adds a footer textbox). Speaker notes (HTML comments) are skipped entirely — acceptable for REQ-372.4 (smoke test checks source word counts, not PPTX-embedded notes). The narrow extension per D-242 addresses (a) and (b). No other renderer change is needed. The extension is a prerequisite, scoped separately from REQ-372 per spec §3.3 Edge 2. Confidence: 0.92. Impact if wrong: Small follow-up; doesn't change milestone scope. Decision: D-242 (restated).

Q4 — Assumption: the 18-month runway shape (α–δ) is acceptable as drafted to I&O leadership

Spec context: Slides 6 + 7 rehearse both architecture-load and political-cover framings. The worked-example granularity was confirmed by the PO.

Resolution: Accept the α–δ shape as drafted. Slides 6 + 7 are the only slide-by-slide revisions that might be needed if leadership pushes back; everything else is locked. No spec change required unless the architectural claim set shifts (spec §3.3 Edge 3). Confidence: 0.85. Impact if wrong: Slide 6 and slide 7 are the only revisions; everything else is locked. Decision: n/a (acceptance, not a D-ID — the shape is in the locked Slide Content Map).

---

Decisions (locked, full autonomy — load-bearing for v1.30)

D-241 — Leadership deck is discrete, hand-authored, NOT a compression

Q-M3 / Q2. The leadership deck is a discrete, hand-authored artifact — NOT a compression of the existing 23-slide citizen-developer pitch (nova-autonomous-cloud-delivery-marp.md). This overrides the post-v1.29 STATE.md intake assumption 3 ("is a compression, not a rewrite"). The existing citizen-developer deck remains untouched. The spec §2.2 + cover note forbid compression/mirroring; the Slide Content Map is hand-authored content, not derived. Recorded in PROJECT.md at ship (REQ-372.11). Confidence: 1.0.

D-242 — Narrow render_pptx.py extension (path arg + custom output + footer textbox)

Q-M2 / Q3. The existing scripts/render_pptx.py is narrowly extended to: (a) accept an explicit source .md path + --output filename (honouring the cover note's invocation pattern), and (b) render a right-aligned footer textbox on every slide with the exact string Nova Platform - Infrastructure & Operations (python-pptx does not read the Marp footer: directive; REQ-372.5 requires the footer on every rendered slide). The source is authored as nova-leadership-deck-marp.md to fit the existing -marp.md pipeline convention; the output is nova-leadership-deck.pptx per spec REQ-372.2. This extension is a non-REQ-372 prerequisite per spec §3.3 Edge 2 ("scope narrowly and update render_pptx.py separately"). No other renderer change (speaker notes are not embedded in the PPTX — acceptable; smoke test checks source word counts). Confidence: 0.92.

D-243 — Date anchor discipline: month-only (August 2026 present, November 2026 runway)

Q1. August 2026 is a month-only presentation anchor (no specific day). November 2026 is the runway anchor (~90 days from August 2026). Slide 7 references "Infrastructure & Operations leadership" without naming a specific day. No spec change required unless the architectural claim set shifts (spec §3.3 Edge 3). Confidence: 0.95.

---

STATE.md intake assumption override

The post-v1.29 STATE.md intake (line ~526, Agent Assumptions, item 3) states: "The 23-slide existing deck is the source material — the ≤7-slide leadership deck is a compression, not a rewrite."

Override (D-241): This assumption is replaced. The leadership deck is a discrete, hand-authored artifact — NOT a compression. The existing citizen-developer deck remains untouched. The override is recorded in this CLARIFY.md (D-241) and will be reflected in STATE.md at the v1.30 ship wave (CAP-042 row + intake assumption correction).

---

Polish-phase decisions (D-244, D-245, D-246 — full autonomy)

The first draft (v1.29.3) passed all 12 REQs but the rendered PPTX has 7 polish issues (vertical imbalance, text clipping, double bullet markers, no visual variety, near-invisible footer, slide-6 red wall, blockquote grey). The user requested: (1) polish all 7 issues, (2) add a "What works now" emphasis to slide 7, (3) generate mermaid diagrams for every slide. These decisions record the deviations from prior binding decisions.

D-244 — Slide 1 becomes a black-background cover (overrides grill G-1)

Polish issue #4. Grill G-1 locked "all 7 slides as white content slides." The user approved making slide 1 a black-background cover (strong opener for a live leadership presentation) while keeping slides 2-7 as white content slides. The on-slide body text from the Slide Content Map is preserved verbatim — only the visual treatment (background + text color) changes. REQ-372.7's "deviation requires CLARIFY" clause applies to content deviations; this is a presentation polish, not a content change. The source change: slide 1's ## The friction... → # The friction... (H1) + <!-- _class: title --> directive, which triggers render_title_slide (black bg, red top bar, white text). Confidence: 1.0 (user-confirmed).

D-245 — Slide 7 "What works now" content addition (deviation from Slide Content Map)

User request. A new "What works now" block is added to slide 7's on-slide body, before the existing "What we ask" block. This is a content deviation — the Slide Content Map specifies slide 7 as: What we ask / Why now / What comes back + closer. The new block emphasizes what's proven today (L1/L2 stack deployment works, live apply to the sandbox/dev AWS account, confidence 0.800) and the next-steps arc (ingest greenfield pilot projects → promote from sandbox to production → integrate with the SPGE constitutional library → serve as the infrastructure layer).

Factual grounding (verified in RESEARCH):

• 13 L1 primitives + 2 L2 modules in modules/registry.json (all at 1.0.0): alb, cloudfront, dynamodb, ecr, ecs-cluster, ecs-service, iam-role, kms-key, rds, s3, uptime, vpc, waf + microservice, static- assets.
• CAP-031: live terraform apply against AWS account 581513795199 (the dev environment, mode: full, dev-only per D-209), producing real ARNs (ALB, ECS, DynamoDB, S3, KMS) at confidence 0.800. This is a live AWS apply, NOT "tested locally" and NOT a "sandbox" account (the codebase has no sandbox account; the pilot-readiness policy D-208 blocks placeholder accounts).

"sandbox" colloquial term note: The user explicitly chose to keep "sandbox" as a colloquial term for the dev AWS account after I flagged that the codebase fact is "dev account 581513795199, live apply." The slide uses "sandbox" (colloquial); the speaker notes carry the precise facts (dev account, live apply, confidence 0.800).

"SPGE constitutional library" unverified-in-repo note: "SPGE" and "constitutional library" appear nowhere in the codebase (0 matches across all .md/.py/.json/.yml). The user confirmed it is an external system the audience recognizes. The slide includes it as a named next-step integration target, not as a current capability. The speaker notes do not assert it exists in the codebase.

The Slide Content Map in PROJECT.md is updated to reflect the new slide 7 structure. Confidence: 0.90.

D-246 — Mermaid diagrams on all 7 slides

User request. Each of the 7 slides gets a leader-friendly, non-technical mermaid diagram covering its core concept. Different mermaid shapes per slide for visual variety.

Render path (verified): The local mmdc (mermaid-cli) is blocked by missing Chromium shared libraries (10+ system libs absent, no root). Resolution: 24 Debian bookworm .deb packages fetched from the Debian mirror, .so files extracted to /home/opencode/tmp/so2/, LD_LIBRARY_PATH set to include them. Chromium (puppeteer cache at /home/opencode/.cache/puppeteer/chrome/.../chrome) launches with the vendored libs; mmdc renders with the S&P theme (sp-theme.json)

• 2x scale + transparent background. Verified: test diagram renders to a valid PNG with all 4 S&P colors present. The .mmd source files
• rendered PNGs are committed for reproducibility; a future environment with system Chromium can re-render via the existing scripts/render_slides.sh mermaid step.

Theme: Inline %%{init: {...}}%% directive in each .mmd with S&P theme variables (primaryColor:#1B1B1B, primaryBorderColor: #D6002A, primaryTextColor:#fff, secondaryColor:#fff, tertiaryColor:#F0F0F0, lineColor:#1B1B1B) — only the 4 S&P tokens. Transparent background. No component names, no technical jargon — concepts only (leader-friendly).

Diagram-type-per-slide mapping:

1. flowchart LR — 3 frictions → Nova absorbs them
2. flowchart TB — Central IT golden image → Nova one layer up
3. flowchart LR with subgraphs — two principles → everything inherits
4. flowchart LR (3 columns) — Live · Attested · Stays human
5. flowchart LR (two halves) — In Nova's lane / Outside Nova's lane
6. timeline — the 18-month shape (α→β→γ→δ)
7. flowchart LR — what works now → next steps arc

The Slide Content Map in PROJECT.md is updated to include a "Diagram" field per slide. Confidence: 0.88.

---

Requirements impact

No requirements are added, removed, or re-scoped by D-241–D-243. D-244–D-246 are polish-phase decisions that record deviations from prior binding decisions (G-1) and the Slide Content Map (slide 7). The spec is locked (v1.0, 2026-08-20); no spec text changes. The Slide Content Map in PROJECT.md is updated to reflect D-245 (slide 7 structure) and D-246 (diagram field per slide).