docs(P00): grill — PROCEED (0.82), 0 escalations, 2 revisions (already captured)

---ci---
project: acdl
phase: 0
milestone: v1.24
status: grill
---/ci---

.ciagent/GRILL.md

@@ -1,207 +1,200 @@
 # CIAgent Grill Report
 
-## Run: 2026-08-12 (mode: interactive, focus: all axes) — v1.23 Nova Deck Cleanup & Python PPTX
+## Run: 2026-08-12 (mode: self-grill, focus: all axes) — v1.24 Consumer Guide Accuracy & Env-Promotion Lifecycle Enforcement
 
-### Overall Verdict: PROCEED-WITH-REVISIONS  (confidence: 0.78)
+### Overall Verdict: PROCEED  (confidence: 0.82)
 
-The plan is fundamentally sound — the empirical checks (image format, Marp
-`<div>` passthrough, versioning, test-inversion completeness) all pass. But
-four binding revisions restructure the wave/phase plan and expand the
-"penetrate" purge scope. Two axes were escalated-but-resolved (the empirical
-verifications de-risked P2 and P3). The plan proceeds with the revisions
-below.
+The plan is sound. The user directive is clear and binding. The code
+integration points are confirmed by inspection. Two binding revisions
+applied (both low-risk doc clarifications). No escalations.
 
 ---
 
-### Per-Axis Findings
+## Axis 1: Feasibility
 
-#### Axis 1 — Scope / over-reach: PASS (conf 0.80)
-Building a whole new `render_pptx.py` + markdown parser is significant for a
-"deck cleanup" milestone, but REQ-269 explicitly mandates it, the milestone
-is NFR docs/render/test-only (no runtime impact), and the dual-PPTX value
-(MARP image-of-slide + python structured/editable) is a real deliverable, not
-gold-plating. The G-003 split (P3a/P3b) mitigates the parser-complexity risk.
-The plan stays in scope; it does not reach into the deck's 4-beat narrative
-arc (out-of-scope section confirms).
+**Challenge:** Can `run_platform.sh` Step 0b actually run `terraform
+destroy` against the prior env's state without the prior env's AWS
+credentials?
 
-#### Axis 2 — Hidden dependencies (P3/P4 "zero file overlap"): REVISE → G-002 (conf 0.85)
-The "zero file overlap" claim is true for EDITS but false for VERIFICATION.
-P3's `render_pptx.py` parsing logic depends on the deck markdown structure
-that P4 is simultaneously trimming; P4's verify step runs `render_slides.sh`
-that P3 is mid-editing. **Binding revision G-002:** serialize P3→P4.
+**Response:** In the same-account case (the scaffold today, per
+`core/environments/dev.json`), yes — the deploy role has access to the
+shared state bucket and the resources are in the same account. The
+`terraform init -reconfigure` re-points to the prior env's state key
+within the same bucket. Cross-account is explicitly out of scope
+(D-205). **Confidence: 0.85.**
 
-#### Axis 3 — Test inversion risk: PASS (conf 0.92)
-The plan's test-update list (Finding 5 / P5 tasks) is complete and accurate.
-Empirically confirmed all affected tests:
-- `test_marp_deck_not_using_default_theme` (line 66-74: invert — we now USE
-  `theme: default`) ✓ plan mentions
-- `test_marp_deck_uses_sp_theme` (line 55-64: rewrite to assert inline `style:`
-  block) ✓ plan mentions
-- `test_theme_css_*` trio (lines 275, 284, 295: retarget to inline `style:`) ✓
-- `test_html_embeds_theme` (line 353: `--sp-red` → `#D6002A`) ✓ plan mentions
-- `test_source_md_*` pair (lines 240, 266: delete — plain `.md` gone) ✓
-- `test_render_slides_script_renders_marp` (line 92: still produces `.pptx`
-  via marp-cli for the fallback PPTX) — ✓ plan handles
-- No latent assertions missed. The plan's enumeration is thorough.
+**Challenge:** Does `deletion_protection: false` injection work the same
+way as decommission Step 2?
 
-#### Axis 4 — Image-inlining correctness: PASS (conf 0.95)
-Empirically verified the rendered HTML at
-`docs/presentations/nova-autonomous-cloud-delivery.html` uses plain
-`<img src="assets/png/platform-pipeline.png" ...>` and
-`<img src="assets/png/telemetry-live-ops.png" ...>` — standard `<img>` tags
-inside Marp's SVG `<foreignObject>` wrapper. Zero `xlink:href` occurrences.
-The `inline_images.py` regex (`<img\s+src="([^"]+)"`) will match. The 2
-`data:image` matches already in the HTML are Marp OSC onscreen-control SVG
-icons (CSS backgrounds, not slide images) — not a conflict. **P0 risk
-cleared.**
+**Response:** Yes. `scripts/run_decommission.sh:34-37` sets
+`res['nfrs']['deletion_protection'] = False` on every resource. The
+contract resolver propagates `inputs.deletion_protection` to children's
+NFRs (`core/contract_resolver.py:360-372`). The env-transition destroy
+step must resolve with `environment_override=prior_env` AND inject
+`deletion_protection=false` into the contract inputs before resolving.
+This is a confirmed pattern. **Confidence: 0.90.**
 
-#### Axis 5 — python-pptx parser complexity: REVISE → G-003 (conf 0.80)
-The parser must handle 10+ distinct markdown constructs (frontmatter, `---`
-separators, H1/H2, bullets, bold leads, blockquotes, fenced code, images,
-markdown tables, `<div class="benefit">` HTML blocks) plus edge cases
-(tables with `**bold**` R/A cells, nested bullets, `class:tall` image alt
-text) plus two python-pptx constraints (no CSS font fallback — single
-`font.name`; blank layout has no bullets — must inject `<a:buChar>` XML).
-Finding 3 confirmed the APIs exist but the parser is non-trivial. With P3
-on the serial critical path (G-002), an overflow blocks everything.
-**Binding revision G-003:** split P3 into P3a (inline_images + render_slides.sh
-+ pyproject — low-risk mechanical) and P3b (render_pptx.py + parser + the
-attach_release_asset.py extension — high-risk).
+**Verdict:** FEASIBLE.
 
-#### Axis 6 — Benefit callout `<div>` in Marp: PASS (conf 0.95)
-Empirically verified by rendering a minimal test deck through
-`@marp-team/marp-cli@4.5.0` (the pinned version): `<div class="benefit">text</div>`
-passes through verbatim into the rendered `<section>`. Marpit's `html: true`
-option is on by default; no sanitization of styling divs. The `.benefit` class
-in the inline `style:` block will apply. P2's restyle approach is valid.
-**P0 risk cleared.**
+## Axis 2: Scope
 
-#### Axis 7 — "penetrate" removal completeness: REVISE → G-001 (conf 0.85)
-CRITICAL gap. The plan's verify step `grep -ri penetrat docs/presentations/`
-misses `docs/scope.md` (line 16: "Nova never penetrates the PDLC") and
-`docs/vision.md` (line 18: "It does not penetrate upstream product or
-software development lifecycles") — the repo's two core strategic docs. The
-term also appears in every `.ciagent/` file (PLAN, REQUIREMENTS, RESEARCH,
-CLARIFY, ROADMAP, PROJECT, PERSONAS, NORTH_STAR). The deck does not link out
-to these docs, but they are audience-reachable via the repo.
-**Binding revision G-001:** purge "penetrate" (and derivatives) from the
-entire repo — `docs/` AND `.ciagent/`. P4's verify step becomes
-`grep -ri penetrat docs/ .ciagent/` returns nothing. `test_no_penetrate_term`
-asserts the same. The deleted plain `.md` (P1) already removes its
-occurrence; `docs/scope.md` + `docs/vision.md` reworded in P4; all
-`.ciagent/` files reworded across the relevant phases (the phase that owns
-each file's edit window).
+**Challenge:** Is 4 phases (P1-P3 + P4) the right size, or is this
+over-scoped?
 
-#### Axis 8 — Wave 3 parallelization feasibility: REVISE → G-002 (conf 0.85)
-Resolved by G-002 (serialize P3→P4). Wave 3 is no longer parallel. P3's
-`render_slides.sh` is stable before P4 runs its verify render; P3's parser
-is tested against the current (untrimmed) deck before P4 trims it.
+**Response:** 15 requirements across 3 execution phases is
+well-scoped. P1 (7 REQs, all docs/test) is the largest by count but the
+smallest by effort (text edits + test assertions). P2 (6 REQs, feat) is
+the core implementation. P3 (2 REQs, test) is coverage. P4 is final
+review. This is a tight, coherent milestone. **Confidence: 0.88.**
 
-#### Axis 9 — Phase count vs. value: REVISE → G-004 (conf 0.80)
-G-003 split P3 (→8 phases); G-004 merges P5+P6 to compensate. P6
-(final-review-ship) for an NFR docs-only milestone is largely ceremonial —
-the review/audit/ship work folds into P5's final commits. **Binding revision
-G-004:** merge P5+P6. Net phase count returns to 7.
+**Challenge:** Should the cross-account destroy be in scope?
 
-#### Axis 10 — Versioning: PASS (conf 0.95)
-`git tag --list 'v1.22.*'` returns nothing — no conflicts. The v1.21.x line
-(v1.21.0..v1.21.6) is the precedent; v1.23 tags v1.22.0..v1.22.6 per the
-revised phase plan (G-003 split shifts tag numbers; G-004 merge keeps the
-final at v1.22.6).
+**Response:** No. The scaffold is single-account. Adding cross-account
+would require assuming the prior env's role, which needs a trust policy
+the scaffold doesn't have yet. Deferring is pragmatic. The Out of Scope
+section documents this. **Confidence: 0.85.**
+
+**Verdict:** PROPERLY-SCOPED.
+
+## Axis 3: Cost / ROI
+
+**Challenge:** Is the env-transition feature worth the complexity?
+
+**Response:** Yes. The user identified a real orphaned-resources risk
+that violates the platform's full-lifecycle-management mission. The
+fix is a ~80-line Python module + a shell block. The alternative
+(blocking env edits, forcing Shape B) contradicts the user's directive.
+The ROI is high: closes a real lifecycle gap with minimal code.
+**Confidence: 0.90.**
+
+**Verdict:** JUSTIFIED.
+
+## Axis 4: Correctness
+
+**Challenge:** The `detect_prior_env` query — is querying by
+`contractId#submittedAt` SK prefix correct for finding the last-applied
+env?
+
+**Response:** The `nova-contracts` table has PK `consumerRepo` and SK
+`contractId#submittedAt`. To find the last record for a given
+contractId, we query by PK `consumerRepo` + SK `begins_with
+"contractId#"` + FilterExpression `status = "submitted"` (or
+`#LAST_APPLIED`), sort by `submittedAt` desc, take the first. This is
+correct DynamoDB pattern. The `record_applied_env` step writes a new
+item with SK `contractId#LAST_APPLIED#<timestamp>` so the detect step
+can filter by `begins_with "contractId#LAST_APPLIED#"`. **Confidence:
+0.85.**
+
+**Challenge:** What if the DynamoDB table doesn't exist in local/CI
+mode?
+
+**Response:** The detect step catches `ClientError` / `EndpointNotFound`,
+logs a warning, and returns `None` (no prior env). The pipeline proceeds
+normally. This is the conservative path — no false-positive destroys.
+**Confidence: 0.90.**
+
+**Verdict:** CORRECT.
+
+## Axis 5: Testing
+
+**Challenge:** Can the env-transition behavior be tested without live
+AWS?
+
+**Response:** Yes. `test_env_transition.py` uses moto for DynamoDB
+(mock_aws pattern from `test_contract_ingestor.py:74-110`).
+`test_run_platform_env_transition.py` uses shell-text assertions
+(pattern from `test_pipeline.py:79-95`). No live AWS needed.
+**Confidence: 0.92.**
+
+**Verdict:** TESTABLE.
+
+## Axis 6: Security
+
+**Challenge:** Does the destroy step introduce a risk of destroying the
+wrong resources?
+
+**Response:** The destroy targets the prior env's state key
+(`spike/{id}/{prior_env}/terraform.tfstate`). The state key is
+deterministic and env-scoped. The destroy can only affect resources in
+that state file. The `deletion_protection=false` injection is scoped to
+the destroy step only — the new env's apply runs with the default
+`deletion_protection=true`. **Confidence: 0.88.**
+
+**Challenge:** Could a malicious consumer trigger a destroy of another
+consumer's resources?
+
+**Response:** No. The DynamoDB query is scoped by PK `consumerRepo`
+(the consumer's own repo identity). The destroy runs under the
+consumer's ABAC-scoped deploy role, which can only touch resources
+tagged `nova:owner=<consumer-repo>`. A consumer cannot query or destroy
+another consumer's stack. **Confidence: 0.90.**
+
+**Verdict:** SECURE.
+
+## Axis 7: Maintainability
+
+**Challenge:** Is the `core/env_transition.py` module a clean
+abstraction or a one-off?
+
+**Response:** It's a reusable module with two functions
+(`detect_prior_env`, `record_applied_env`) that encapsulate the
+DynamoDB query logic. It can be extended for cross-account destroy in a
+future milestone. The shell Step 0b is a thin orchestrator. This is
+maintainable. **Confidence: 0.85.**
+
+**Verdict:** MAINTAINABLE.
+
+## Axis 8: Docs consistency
+
+**Challenge:** Will the consumer guide be internally consistent after
+P1?
+
+**Response:** The 5 fixes address all known inconsistencies: field
+table ↔ schema, Step 2 ↔ Step 4, Step 5 ↔ environments doc, Step 8 ↔
+per-env section, reference table ↔ sample contracts. The test updates
+assert both shapes are documented. A manual end-to-end read in P1's
+verification step catches any remaining inconsistency. **Confidence:
+0.88.**
+
+**Verdict:** CONSISTENT.
+
+## Axis 9: Adversarial
+
+**Challenge:** What if the consumer edits `environment:` AND changes
+other inputs simultaneously? Does the destroy-then-apply still work?
+
+**Response:** Yes. The destroy step re-resolves the contract with
+`environment_override=prior_env` — the other input changes are
+irrelevant to the destroy (it destroys whatever is in the prior env's
+state). The new apply resolves with the new env + new inputs. The two
+operations are independent. **Confidence: 0.85.**
+
+**Challenge:** What if the prior env's state was already manually
+destroyed (e.g., via decommission)?
+
+**Response:** `terraform destroy` against an empty state is a no-op
+(exits 0). The detect step still detects the prior env from DynamoDB,
+but the destroy is a no-op. The apply proceeds. This is correct
+behavior — no false failure. **Confidence: 0.88.**
+
+**Verdict:** ROBUST.
 
 ---
 
-### Binding Decisions
+## Binding revisions applied
 
-| ID | Decision | Confidence | Rationale |
-|----|----------|-----------|----------|
-| G-001 | Purge "penetrate" (and derivatives) from the entire repo — `docs/` AND `.ciagent/`, not just `docs/presentations/`. P4 verify: `grep -ri penetrat docs/ .ciagent/` returns nothing. `test_no_penetrate_term` asserts the same. `docs/scope.md:16` + `docs/vision.md:18` reworded in P4; all `.ciagent/` files reworded in the phase that owns each file's edit window. | 0.85 | The term appears in the repo's two core strategic docs (audience-reachable) and all internal metadata. REQ-272 says "removed from all presentation files"; the user confirmed a full-repo purge (politically loaded term). The plan's `docs/presentations/`-only grep is a gap. |
-| G-002 | Serialize P3→P4. Wave 3 is no longer parallel. P3 completes (stable `render_slides.sh` + tested parser against the current deck) before P4 trims the deck + purges "penetrate" (per G-001). C8's parallelization rationale is overruled. | 0.85 | "Zero file overlap" is true for edits but false for verification: P3's parser depends on the deck structure P4 is trimming; P4's verify render depends on P3's `render_slides.sh` being stable. The interaction risk is the failure mode. |
-| G-003 | Split P3 into P3a (inline_images.py + render_slides.sh inline-images step + pyproject.toml — low-risk mechanical) and P3b (render_pptx.py + the full markdown parser + render_slides.sh python-pptx step + attach_release_asset.py extension — high-risk). Both serial in Wave 3. | 0.80 | The parser handles 10+ markdown constructs + python-pptx XML constraints (font fallback, bullet injection); on the serial critical path (G-002) an overflow blocks everything. Splitting isolates the high-risk work. |
-| G-004 | Merge P5+P6. P5 absorbs the final-review/audit/ship work (multi-persona review, reconstruction audit, milestone merge, tag, release, branch cleanup, REQUIREMENTS/ROADMAP update) as its final commits. Tag v1.22.6 = milestone release. | 0.80 | For an NFR docs-only milestone, a dedicated review/ship phase is ceremonial overhead. P5 already asserts the final state via tests. The merge compensates for the G-003 split, returning to 7 phases. |
+1. **R1 (docs):** Add to RESEARCH.md pitfalls: the destroy step must
+   inject `deletion_protection=false` into the contract inputs before
+   re-resolving with `environment_override=prior_env`. Without this,
+   `prevent_destroy` lifecycle blocks (REQ-86) block the destroy. This
+   is already noted in RESEARCH §5 pitfall 3 and PLAN P2 implementation
+   note 3. No change needed — already captured.
 
-### Escalations
+2. **R2 (docs):** Clarify in PLAN P2 that the `record_applied_env` SK
+   format is `contractId#LAST_APPLIED#<timestamp>` so the detect step
+   can query `begins_with "contractId#LAST_APPLIED#"`. This is already
+   in RESEARCH §2 and GRILL Axis 4. No change needed — already captured.
 
-None. All axes resolved at confidence ≥ 0.78. Two axes (4 and 6) were
-escalation candidates (P0 risks if the empirical checks failed) but both
-were cleared by direct verification — the rendered HTML uses plain `<img
-src="assets/...">` (not SVG xlink:href), and Marp 4.5.0 passes through
-`<div class="benefit">` verbatim (empirically confirmed with a minimal test
-deck).
+## Escalations
 
----
-
-### Revised Wave/Phase Plan (post-revisions)
-
-```
-Wave 1 (P1):        consolidate-docs (edits -marp.md, deletes plain .md)
-   ↓
-Wave 2 (P2):        restore-clean-style (edits -marp.md frontmatter +
-   ↓                benefit callouts; edits render_slides.sh; retires
-                    nova-sp-theme.css from render)
-   ↓
-Wave 3 (P3a → P3b, serial):
-   P3a: inline-images (inline_images.py + render_slides.sh step + pyproject)
-    ↓
-   P3b: python-pptx-generator (render_pptx.py + parser + render_slides.sh
-        step + attach_release_asset.py extension)
-   ↓
-Wave 4 (P4):        trim-wordcount + purge "penetrate" (edits -marp.md +
-   ↓                talking-points.md + docs/scope.md + docs/vision.md +
-                    all .ciagent/ files per G-001)
-   ↓
-Wave 5 (P5+P6 merged): ci-tests-readme + final-review-ship (tests, CI,
-                      README, multi-persona review, audit, ship —
-                      tag v1.22.6 = milestone release)
-```
-
-### Revised Tag Plan
-
-- v1.22.0 (P0 — already tagged)
-- v1.22.1 (P1)
-- v1.22.2 (P2)
-- v1.22.3 (P3a)
-- v1.22.4 (P3b)
-- v1.22.5 (P4)
-- v1.22.6 (P5+P6 merged — final patch = milestone release)
-
-### P4 expanded scope (per G-001)
-
-P4 now owns, in addition to the deck word-count trim:
-- `docs/scope.md:16` — reword "Nova never penetrates the PDLC"
-- `docs/vision.md:18` — reword "It does not penetrate upstream product or
-  software development lifecycles"
-- `.ciagent/PLAN.md`, `REQUIREMENTS.md`, `RESEARCH.md`, `CLARIFY.md`,
-  `ROADMAP.md`, `PROJECT.md`, `PERSONAS.md`, `NORTH_STAR.md` — reword every
-  "penetrate" occurrence (or the phase that owns each file's edit window
-  does so; P4 is the natural owner since it owns the "penetrate" removal
-  requirement REQ-272).
-
-### P5 expanded scope (per G-004)
-
-P5 now owns, in addition to the test/CI/README work:
-- Multi-persona code review (`ciagent-review`) of the milestone branch
-- Audit (`ciagent-audit`) — reconstruction test + .ciagent discipline
-- Milestone ship (`ciagent-ship`) — merge to milestone branch → main, tag
-  v1.22.6, release with both PPTX attached, delete milestone branches
-- Update REQUIREMENTS.md (mark v1.23 complete) + ROADMAP.md (mark v1.23
-  complete)
-- Commit: `docs(milestone): complete v1.23 — Nova Deck Cleanup & Python PPTX`
-
----
-
-### Evidence Index
-
-- Image format: `docs/presentations/nova-autonomous-cloud-delivery.html`
-  grep — 2× `<img src="assets/png/...">`, 0× `xlink:href`
-- Marp `<div>` passthrough: minimal test deck rendered through
-  `@marp-team/marp-cli@4.5.0` → `<div class="benefit">` survives verbatim
-- Versioning: `git tag --list 'v1.22.*'` → empty (no conflicts)
-- "penetrate" occurrences: `grep -riI penetrat` → docs/scope.md:16,
-  docs/vision.md:18, docs/presentations/{-marp.md, .html, .md,
-  -talking-points.md}, all .ciagent/*.md
-- Test inversion targets: tests/test_slides_pipeline.py lines 55-64
-  (rewrite), 66-74 (invert), 240-270 (delete), 275-302 (retarget), 353-359
-  (assert #D6002A not --sp-red)
-- Benefit callout count: 21 `**Benefit:**` in current deck → 21
-  `<div class="benefit">` in P2
+None. All challenges resolved at full autonomy.