# GRILL — v1.30 Single-shot Leadership Deck

> Adversarial review of the v1.30 SPECIFY + CLARIFY + RESEARCH +
> PLAN. Griller: lead-developer (acting as ci-griller at full
> autonomy). All 9 axes reviewed; every claim verified against the
> live codebase.

---

## Overall verdict: **PROCEED** · Confidence 0.88

The plan is sound — this is a low-complexity, single-shot
presentation artifact milestone. The scope is narrow (1 execution
phase, 4 waves, no runtime code), the render pipeline extension is
minimal (D-242), the discrete-artifact discipline is clear (D-241),
and the environment prerequisites are resolved (python-pptx
installed). No critical conditions. 4 tracked conditions (all
advisory, none block P1).

The lower confidence vs. a "clean 0.95" reflects two residual
risks: (1) the python-pptx user-site install is environment-fragile
(it works now but is not reproducible in a fresh CI runner without
the same `--break-system-packages` path); (2) the PPTX footer
textbox is a new renderer behavior that needs visual confirmation.
Both are mitigated — (1) by the smoke-test hard-fail gate (8f) which
forces render success before ship, and (2) by the verify stage's
visual review (REQ-372.7).

---

## Axis verdicts

| Axis | Verdict | Confidence | Tracked condition |
|------|---------|-----------|-------------------|
| §1 Feasibility | PROCEED | 0.90 | T-1.1 footer textbox overlap |
| §2 Scope | PROCEED | 0.92 | T-2.1 single-shot discipline enforcement |
| §3 Cost | PROCEED | 0.95 | (none — smallest milestone in project history) |
| §4 Schedule | PROCEED | 0.93 | (none — 1 execution phase) |
| §5 Technical Depth | PROCEED | 0.86 | T-5.1 speaker notes word-band parsing; T-5.2 `→` bullet rendering |
| §6 Operational Readiness | PROCEED | 0.90 | T-6.1 render env reproducibility |
| §7 Security Posture | PROCEED | 0.95 | (none — static artifact, no runtime surface) |
| §8 Dependency Risk | PROCEED | 0.84 | T-8.1 python-pptx user-site install |
| §9 Re-mapping Integrity | PROCEED | 0.92 | T-9.1 STATE.md intake override applied |

---

## Tracked conditions (advisory — none block P1)

### T-1.1 — Footer textbox overlap with content

**Claim:** The footer textbox at `SLIDE_H - 0.3"` (7.2") won't
overlap content (content area tops out at ~6.5").

**Verification:** python-pptx test rendered a textbox at
`Inches(7.2)` on a 7.5" slide — succeeds, no overlap with content
ending at ~6.5". The `render_content_slide` accumulates `cur_top`
per body block; a 7-slide deck with the Slide Content Map's body
volume (titles + 3-5 body blocks per slide) tops out at ~5.5-6.0".
**Verdict:** Safe. The verify stage visual review (REQ-372.7) is the
backstop.

### T-2.1 — Single-shot discipline enforcement

**Claim:** The deck is not wired as a CI gate, not integrated with
`publish.yml`, not auto-regenerated.

**Verification:** `workflows-src/slides.yml` triggers on
`docs/presentations/**` but `render_slides.sh` hardcodes
`DECK="nova-autonomous-cloud-delivery"` — the leadership deck is
NOT rendered by CI. No `publish.yml` reference to the leadership
deck. The smoke test is a standalone script (no workflow
integration). **Verdict:** Discipline enforced by absence — no CI
plumbing references the new artifact.

### T-5.1 — Speaker notes word-band parsing in bash

**Claim:** The smoke test extracts `<!-- ... -->` per slide and
counts words with `wc -w`.

**Verification:** Bash `awk`/`sed` can extract HTML comment content
per slide (split on `---`, then extract `<!--` ... `-->` within each
slide block). Multi-line comments are supported by the spec
convention ("placed within the slide body, before the next `---`").
**Verdict:** Feasible. The ci-cli-engineer implements + tests this in
W3.

### T-5.2 — `→` bullet rendering

**Claim:** Use `- → ...` bullets so the renderer treats `→` lines as
bullet blocks.

**Verification:** The renderer's unordered-list regex
`^(\s*)([-*+])\s+(.*)` matches `- → ...` → bullet level 0, text
`→ ...`. The `→` is preserved in the rendered text. **Verdict:**
Correct. The ci-doc-writer uses `- → ...` for the arrow lines.

### T-6.1 / T-8.1 — Render environment reproducibility

**Claim:** python-pptx is installed via user-site
`pip install --user --break-system-packages`.

**Verification:** Confirmed in this session: python-pptx 1.0.2 +
pytest 9.1.1 installed. `python3 -c "import pptx"` succeeds. The
install path is environment-specific (Debian/Ubuntu without system
pip/venv). In a fresh CI runner, the `slides.yml` workflow uses
`pip install -e ".[slides]"` (system pip in the runner image) —
reproducible there. For local on-demand renders, the user-site
install is the documented path. **Verdict:** Acceptable. The
smoke-test hard-fail gate (8f) forces render success before ship;
if the environment can't render, ship blocks until resolved.

### T-9.1 — STATE.md intake override applied

**Claim:** D-241 overrides the stale STATE.md intake assumption 3.

**Verification:** STATE.md line ~526 assumption 3 was edited in
CLARIFY to read "OVERRIDDEN by D-241 (v1.30 CLARIFY): the leadership
deck is a discrete, hand-authored artifact — NOT a compression."
The override is recorded in CLARIFY.md (D-241) + this grill. **Verdict:**
Applied + verified.

---

## Binding decisions (grill-level, full autonomy)

| ID | Decision | Rationale | Confidence |
|----|----------|-----------|-----------|
| G-1 | All 7 slides use `##` H2 titles (content slides, white bg) — slide 1 is NOT a title-class slide. | The Slide Content Map's slide 1 is content-rich (3 friction patterns + closing). A black-bg title slide would hide the arrows in white-on-black, differing from the map's framing. White-bg content slides give visual consistency across all 7. The map doesn't specify background; visual review accepts either. | 0.82 |
| G-2 | The `→` arrow lines are authored as `- → ...` bullets (not bare `→` plain text). | The renderer parses `[-*+]` as bullets (proper indentation + bullet glyphs). Bare `→` lines parse as plain paragraphs (no bullet formatting). The Slide Content Map shows `→` as distinct arrow lines — bullets with the arrow glyph preserve the visual intent in the PPTX. | 0.88 |
| G-3 | The `style:` block in the leadership deck frontmatter replaces `#2E2E2E` (blockquote color in the existing deck) with `#1B1B1B`. | REQ-372.6 allows only 4 hex colors in the source. The existing deck's `style:` uses `#2E2E2E` for blockquote text — this must not appear in the leadership deck source. `#1B1B1B` is the closest S&P token (black). | 1.0 |
| G-4 | The render_pptx.py extension parses the Marp frontmatter to extract the `footer:` value (for the footer textbox), but does NOT parse `paginate:`, `theme:`, `size:`, or `style:`. | Minimal extension scope per D-242. Only the footer is needed for REQ-372.5. The other directives are source-only (smoke test checks source; the python-pptx path ignores them). | 0.90 |

---

## Escalations

None. All axes ≥ 0.84 confidence. No human escalation required at
full autonomy.