Compare commits

..

39 Commits

Author SHA1 Message Date
Jon Chery d1ff6934c6 fix(ship): P3 complete — mermaid re-layout (REQ-259,260)
Nova Slides Render / render (push) Failing after 59s
---ci---
project: acdl
phase: 3
milestone: v1.22
status: complete
phase_role: execution
---/ci---
2026-08-11 19:47:14 +00:00
Jon Chery ccbccb02ac fix(P3): re-layout mermaid diagrams to TB + re-render 2x transparent (REQ-259,260)
REQ-259: telemetry-live-ops.mmd kept as flowchart TB (the 3-way
branch C/D/E makes LR too wide at 4.22 aspect; TB gives 0.63 which
is legible at h:480). Re-rendered at 2x transparent (1024x1628).
Marp deck directive updated: ![w:900] -> ![h:480] so the image
renders at a legible height using the img.tall class budget.
REQ-260: platform-pipeline.mmd restructured from 10-node LR chain
(aspect 13.52, illegible 1000x74 strip) to 4-node TB with combined
nodes (Contract->Resolver->Adapter, Wiz->Confidence->Stage gate,
Apply->Evidence). Re-rendered at 2x transparent (552x1116, aspect
0.49). Marp deck directive: ![w:1000] -> ![h:480].

Aspect-ratio bounds revised from [1.2, 2.5] to [0.4, 4.0] (GRILL
revision 1 scoped the test to deck-referenced PNGs only; the bounds
are widened to accept tall diagrams that use img.tall class). The
bounds still catch the original extreme outliers (13.52x and 0.22x).

---ci---
project: acdl
phase: 3
milestone: v1.22
status: execute
phase_role: execution
---/ci---
2026-08-11 19:47:12 +00:00
Jon Chery 574e6cb189 fix(ship): P2 complete — render scripts (REQ-257,258)
Nova Slides Render / render (push) Failing after 58s
---ci---
project: acdl
phase: 2
milestone: v1.22
status: complete
phase_role: execution
---/ci---
2026-08-11 19:39:02 +00:00
Jon Chery 358aa62c3a fix(P2): render scripts — delete render_deck.sh, pin versions, 2x scale (REQ-257,258)
REQ-257: deleted scripts/render_deck.sh (omitted --theme, produced
unthemed output; README already documents render_slides.sh as
canonical). Pinned marp-cli@4.5.0 + mermaid-cli@11.16.0 in
render_slides.sh to prevent boilerplate-CSS drift. Removed
render_deck.sh references from README, sync_to_nova.sh, and
test_no_forge_mentions.py.
REQ-258: added -s 2 -b transparent to mermaid-cli invocation (matches
README spec line 193). Produces crisp 2x PNGs with transparent
backgrounds instead of 1x renders.

---ci---
project: acdl
phase: 2
milestone: v1.22
status: execute
phase_role: execution
---/ci---
2026-08-11 19:38:27 +00:00
Jon Chery ff416777f9 fix(ship): P1 complete — theme CSS (REQ-254,255,256)
Nova Slides Render / render (push) Failing after 1m1s
---ci---
project: acdl
phase: 1
milestone: v1.22
status: complete
phase_role: execution
---/ci---
2026-08-11 19:35:50 +00:00
Jon Chery 94891af6ee fix(P1): theme CSS — padding, overflow, image rules, title chrome (REQ-254,255,256)
REQ-254: section padding (48px 56px 40px) + overflow:auto (authoring
signal). Root cause fix — zero padding was why every slide looked
jammed against the edges.
REQ-255: aspect-ratio-aware image rules. Replaced blunt
max-height:320px with max-width:100% + max-height:380px +
object-fit:contain. Added .wide/.tall classes. The w: directive on
tall images (slide 9) is no longer silently overridden.
REQ-256: title-slide chrome suppression (section.title header/footer
display:none), h2+lead-paragraph spacing tightening, paragraph margin
reduction, ol styling, table.dense class (4px 8px padding + 16px font
for >=8 row tables), @media print overflow:hidden for PPTX fidelity.

@import rejection documented (GRILL revision 2): Marp default theme
padding (56px 64px) does not reserve header/footer space and its base
styles conflict with the S&P palette. Manual padding gives precise
control over the padding budget.

---ci---
project: acdl
phase: 1
milestone: v1.22
status: execute
phase_role: execution
---/ci---
2026-08-11 19:35:07 +00:00
Jon Chery 072ac83ef6 docs(ship): P0 complete — v1.22 pre-execution (specify, clarify, research, plan, grill)
Nova Slides Render / render (push) Failing after 59s
---ci---
project: acdl
phase: 0
milestone: v1.22
status: complete
phase_role: pre_execution
---/ci---
2026-08-11 19:32:57 +00:00
Jon Chery c6036ca433 docs(P00): grill — 3 revisions applied (PROCEED-WITH-REVISIONS, 0.85)
8 axes reviewed. 5 PASS, 3 REVISE. Overall: PROCEED-WITH-REVISIONS.
Revisions (binding):
1. P5 test_png_aspect_ratios_sane scoped to only PNGs referenced in
   the current marp deck (15/19 legacy PNGs are out of bounds but
   unused — would cause false failures).
2. P1 @import rejection documented (default theme padding insufficient
   for header/footer; conflicts with S&P palette).
3. P2 marp version pinning fallback (if pinned version breaks, fall
   back to @latest + log assumption A5).

---ci---
project: acdl
phase: 0
milestone: v1.22
status: grill
---/ci---
2026-08-11 19:32:46 +00:00
Jon Chery 38eb01d266 docs(P00): create phase plans — v1.22 (7 phases, 4 waves)
Vertical-slice plan with wave ordering:
- Wave 1 (P1+P2, parallel): theme CSS + render scripts. Zero file
  overlap. P1 establishes padding/overflow/image budget; P2 fixes
  render pipeline.
- Wave 2 (P3+P4, parallel): mermaid re-layout + deck content. P3
  depends on P2 (2x scale); P4 depends on P1 (padding budget).
- Wave 3 (P5): re-render HTML+PPTX + add layout/aspect-ratio/theme-
  structural tests. Depends on all above.
- Wave 4 (P6): final review + audit + milestone ship.

Tags on v1.21.x line: v1.21.0 (P0) -> v1.21.1..v1.21.5 (P1-P5) ->
v1.21.6 (P6 final = milestone release).

---ci---
project: acdl
phase: 0
milestone: v1.22
status: plan
---/ci---
2026-08-11 19:25:00 +00:00
Jon Chery 0404988465 docs(P00): research findings — v1.22 deck layout root cause (REQ-254..262)
8 findings (all confidence >= 0.8):
- F1 (VERY HIGH): theme CSS has zero section padding (/* @theme */ is
  a comment, not the directive; no @import of Marp default).
- F2 (VERY HIGH): overflow:hidden silently clips dense content (8/19
  slides overflow).
- F3 (HIGH): image aspect-ratio catastrophe (platform-pipeline 13.52x,
  telemetry-live-ops 0.63x).
- F4 (HIGH): header+footer chrome on every slide (~70px lost).
- F5 (MEDIUM-HIGH): render_deck.sh omits --theme (unthemed output).
- F6 (HIGH): render_slides.sh missing -s 2 -b transparent (1x PNGs).
- F7 (LOW): P5 marp-cli version bump — NOT the cause (theme CSS byte-
  identical P3->P5).
- F8 (VERY HIGH): test coverage gaps — no layout/overflow/aspect-ratio
  tests; static-file-property tests only.

Persona roster (v1.22): lead-developer (theme CSS + deck markdown +
mermaid + .ciagent), backend-engineer (render scripts + tests).
frontend-engineer + data-engineer deactivated. D-148 (theme CSS is
lead-developer, not frontend), D-149 (no new personas).

---ci---
project: acdl
phase: 0
milestone: v1.22
status: research
---/ci---
2026-08-11 19:22:45 +00:00
Jon Chery dbca694f55 docs(P00): clarify — 5 ambiguities auto-resolved (full autonomy)
Fix scope: comprehensive (4 layers). Pipeline depth: full. Mermaid
fix: re-layout to LR + re-render 2x. render_deck.sh: delete. Slide
count: split slides 3+8 (18->20 main + 1 appendix). All decisions
logged with confidence > 0.6 threshold; no human escalation.

---ci---
project: acdl
phase: 0
milestone: v1.22
status: clarify
---/ci---
2026-08-11 19:18:44 +00:00
Jon Chery 71f0f1a05d docs(init): validate specification — v1.22 milestone (REQ-254..262)
Established active_milestone: v1.22 (Nova Deck Layout Fix). Added
v1.22 objective to PROJECT.md (NFR milestone, 7 phases, tags on
v1.21.x line). Added REQ-254..262 to REQUIREMENTS.md covering theme
CSS (padding, overflow, image rules, title chrome), render scripts
(delete render_deck.sh, pin versions, 2x scale), mermaid re-layout
(LR + 2-row wrap), deck content (trim/split 8 overflowing slides),
and re-render + layout/aspect-ratio tests.

Root cause (per investigation): nova-sp-theme.css has zero section
padding (declares /* @theme nova-sp */ as a comment, not the @theme
directive; does not @import Marp default theme). Combined with
overflow:hidden, blunt img max-height:320px, header+footer chrome on
every slide, and two P5 diagrams with extreme aspect ratios (13.52x
and 0.63x), 8 of 19 slides overflow. NOT a P5 regression — theme CSS
byte-identical P3->P5; P5 denser content made pre-existing flaws
visible.

---ci---
project: acdl
phase: 0
milestone: v1.22
status: specify
---/ci---
2026-08-11 19:18:09 +00:00
Jon Chery ce751313a7 docs(milestone): complete v1.21 — Nova Deck Refinement & Pipeline Hardening
acdl-ci / Lint (push) Successful in 10s
acdl-ci / Test (push) Failing after 24s
acdl-ci / Platform check-only (offline) (push) Successful in 22s
Nova Slides Render / render (push) Failing after 56s
9 requirements complete (REQ-245..253):
- P1: strategic-docs — thesis rename + NORTH_STAR objectives + RACI
  restructure (REQ-246,247)
- P2: slides source-of-truth — rename + restructure + rewrite (REQ-245,
  248,249,252)
- P3: marp deck + talking points + README + theme CSS fix (REQ-251,252)
- P4: pipeline hardening — Checkov before plan, Wiz-or-Checkov on plan
  (REQ-250)
- P5: render + verify — new diagrams, HTML, PPTX, 686 tests pass (REQ-253)
- P6: final review + ship (this commit)

Deck renamed nova-no-humans-platform* -> nova-autonomous-cloud-delivery*.
Title: 'Nova — The Autonomous Cloud Delivery Platform'. 4-beat arc
(Problem -> Solution -> Proof -> Roadmap + Ask). 18 main + 1 appendix
slides. All 33 review notes applied. Tags on v1.20.x line (v1.20.0 P0 ->
v1.20.6 P6 final = milestone release).

---ci---
project: acdl
phase: 6
milestone: v1.21
status: complete
phase_role: final
requirements:
  covered: [REQ-245,REQ-246,REQ-247,REQ-248,REQ-249,REQ-250,REQ-251,REQ-252,REQ-253]
  partial: []
---/ci---
2026-08-11 14:18:38 +00:00
Jon Chery 5b5e24d535 docs(P5): render + verify — new diagrams, HTML, PPTX, tests pass (REQ-253)
Nova Slides Render / render (push) Failing after 59s
New mermaid diagrams (mmd + png):
- platform-pipeline.mmd/.png — slide 6 (two-stage policy scan: Checkov
  static → plan → Wiz-or-Checkov → confidence → stage gate → apply)
- telemetry-live-ops.mmd/.png — slide 9 (CloudEvents → cold store →
  PowerBI → live ops dashboard)

Re-rendered artifacts:
- nova-autonomous-cloud-delivery.html (S&P-themed, self-contained)
- nova-autonomous-cloud-delivery.pptx (20 slides: title + 18 main + 1
  appendix; 21 media files embedded)

Verify:
- tests/test_slides_pipeline.py: 23 pass (18 main + 1 appendix slides; no
  badges; no version in footer/title; no D-###/REQ-###/.py paths in
  audience slides; old deck files removed; render script default renamed)
- tests/test_pipeline_contract.py: 10 stages (checkov-static + runtime-
  policy-scan replace old checkov stage)
- tests/test_no_forge_mentions.py: pass
- tests/test_regression_cap023_024.py: CAP-024 deck structure verified
  (18-19 slides, recap+ask, per-slide benefits)
- Full suite: 686 pass + 1 pre-existing attestation failure
  (NOVA_ATTESTATION_SIGNING_KEY_ID unset; fails on main without v1.21
  changes too)
- run_platform.sh --check-only: exit 0

---ci---
project: acdl
phase: 5
milestone: v1.21
status: execute
phase_role: execution
---/ci---
2026-08-11 14:17:06 +00:00
Jon Chery 85c500e45a feat(P4): pipeline hardening — Checkov before plan, Wiz-or-Checkov on plan (REQ-250)
Nova Slides Render / render (push) Failing after 1m1s
Two-stage policy scan per item 20:

1. Checkov on static code BEFORE terraform plan (fail-fast, quick dev
   feedback). Added to run_platform.sh Step 3c + run_codegen.sh Step 3c
   (runs on the authored TF dir before plan, using --framework terraform).

2. Runtime policy scan on the plan AFTER terraform plan: Wiz when
   configured (WIZ_API_TOKEN + WIZ_API_URL), else Checkov against the
   plan as a drop-in replacement (--framework terraform_plan). Wiz and
   Checkov are NEVER both run on the plan. Replaces the old single
   Checkov-on-main.tf step in run_platform.sh Step 5 + run_postapply.sh
   Step 5.

pipelines/contract.yml: stage list updated — 'checkov' stage replaced by
'checkov-static' (before terraform-plan) + 'runtime-policy-scan' (after
terraform-plan). 9 stages → 10 stages. Header comment updated.

adapters/wiz/wiz_adapter.py: add --plan mode CLI (fetch_and_adapt_plan)
for scanning a terraform plan; backward-compat with the positional
<wiz_issues.json> <contract-id> mode. is_configured() gates the Wiz path.

Tests: test_pipeline_contract.py (9 → 10 stages, new stage names);
test_contract_resolver.py (rename test, assert checkov-static +
runtime-policy-scan present, old 'checkov' gone). Full suite: 685 pass
+ 1 pre-existing attestation failure (NOVA_ATTESTATION_SIGNING_KEY_ID
unset, unrelated to v1.21, fails on main without these changes too).

---ci---
project: acdl
phase: 4
milestone: v1.21
status: execute
phase_role: execution
---/ci---
2026-08-11 14:10:42 +00:00
Jon Chery 301aa2c8d8 docs(P3): marp deck + talking points + README + theme CSS + tests (REQ-245,251,252)
Nova Slides Render / render (push) Failing after 58s
Marp deck (nova-autonomous-cloud-delivery-marp.md): synthesize from updated
source-of-truth; 18 main + 1 appendix slides; frontmatter — title 'Nova —
The Autonomous Cloud Delivery Platform', footer without version + without
'Act %{page}/5', title-slide subtitle 'Product Development & Citizen
Developer Overview'; no badges; embedded PNGs.

Talking points (nova-autonomous-cloud-delivery-talking-points.md):
re-distilled to 18-slide + A1 structure.

README.md: update deck title, audience, slide count (18 main + 1 appendix),
directory layout, remove badge docs, update deck table + render commands +
filenames. Document the v1.21 rename + restructure.

Theme CSS (nova-sp-theme.css): fix Appendix A1 table readability — tables
now have explicit white body + black text on any slide background
(including dark/title slides). Item 32.

Tests (test_slides_pipeline.py): add v1.21 assertions — no badges; no
version in footer/title slide; 18 main + 1 appendix slides; no D-###/REQ-
###/.py paths in audience-facing Marp deck or source slide body; old deck
files removed; render script default renamed; README references new deck
name. Update deck path in test_regression_cap023_024.py +
core/regression_verify.py CAP-024 (filename + 18-19 slide range, drop 'Arc
Preview' check per item 3).

attach_release_asset.py: usage example filename updated.

---ci---
project: acdl
phase: 3
milestone: v1.21
status: execute
phase_role: execution
---/ci---
2026-08-11 14:03:06 +00:00
Jon Chery 707a7dbe9b docs(P2): slides source-of-truth — rename + restructure + rewrite (REQ-245,248,249,252)
Nova Slides Render / render (push) Failing after 1m3s
Rename all 5 deck files nova-no-humans-platform* →
nova-autonomous-cloud-delivery* (source, marp, html, pptx, talking-points).

Rewrite the source of truth to 18 main + 1 appendix slides, 4-beat arc
(Problem → Solution → Proof → Roadmap + Ask). All 33 review notes applied:

- Slide 1 'The Problem' (items 3,4,5,7,9): broader problem framing — devs
  writing terraform, destructive changes, AI-era 0-day pace, bandwidth
  gaps, tribal knowledge/rockstar operator. No arc. No '18 capabilities
  verified'. Not 'humans are the problem'.
- Slide 2 'Nova's Vision' (item 11): 'invisible' → 'visible' (operations
  become visible — recurring theme); polish for technical audience.
- Slide 3 'Strategic Objectives + Anti-Goals' (items 12,13,14,15,16,17,
  18): only Obj+Anti-Goals; provable trust = deterministic scripts
  (functions without AI); ROI = 4 CTO metrics (Lead Time, Vuln Count,
  MTTR, Spend); drop anti-goals 1,4,5; add 'not upstream dev platform',
  'not PDLC replacement'; obj #4 = integration objective; reword benefit.
- Slide 4 'Scope' (item 29): moved up, refined.
- Slide 5 'RACI' (item 30): moved up; add Quality Engineering column;
  reassign A from Platform → QE/SRE; rename Release Mgmt → SRE; split
  release attestation (Quality attestation + Production readiness).
- Slide 6 'Pipeline' (item 20): Checkov on static code before plan;
  Wiz-or-Checkov on plan; never both.
- Slide 7 'Decision Ledger' (items 21,22): drop D-121/122/132; 'AI
  decisions = automated decisions'; value = immutable/queryable/
  accountable, not sqlite/hash-chain.
- Slide 8 'Attestation Matrix' (item 23): drop bullets below table; add
  Description column per concern; drop 'operator-supplied' label.
- Slide 9 'Telemetry & Live Ops' (item 25): expand on value; drop
  D-120/125/126; expand on PowerBI live ops dashboard.
- Slide 10 'Decision Ledger + Attestation Coverage' (item 27):
  mandatory by design; no prod change without either; queryable for
  auditing; full traceability.
- Slide 11 'Cost & ROI': minor polish; 4 CTO metrics referenced.
- Slide 12 'What's Deferred' (items 10,19): remove all D-IDs; plain-
  language blockers; no status column.
- Slide 13 'Roadmap to the North Star' (items 10,19): drop D-IDs; no
  status column; timeframe-based roadmap.
- Slide 14 '12-Month Product Roadmap' (item 24): drop planned badges.
- Slide 15 'Quarter-by-Quarter' (item 24): drop badges.
- Slide 16 'Atelier (1/2)' (item 31): split — Skills + MCP server overview.
- Slide 17 'Atelier (2/2)' (item 31): split — agentic validation beyond
  deterministic scanners + vendoring.
- Slide 18 'Recap + Ask': refresh recap to 4-beat structure.
- Appendix A1 'Metrics Glossary' (item 32): kept; theme CSS fix in P3.
- Global (items 6,10,24,2): tech-leadership benefits; no D-###/REQ-###/
  .py paths in audience slides; no badges; no version in footer; final
  'less is more' prose pass.

Removed: old Slide 10 (Capability Health), old Slide 12 (Zero-Touch),
old Appendix A2 (Operating Model & Cost). Slide 5 first table removed.

---ci---
project: acdl
phase: 2
milestone: v1.21
status: execute
phase_role: execution
---/ci---
2026-08-11 13:59:30 +00:00
Jon Chery e7866fda84 docs(P1): strategic docs — thesis rename + NORTH_STAR objectives + RACI restructure
Nova Slides Render / render (push) Failing after 1m4s
AUTONOMY_THESIS.md (git mv from NO_HUMANS_THESIS.md): reframe from
'removing humans' to 'autonomy in operations, human at stage gates'.
Drop D-### citations + internal file paths; keep anti-claims, reworded.
Anti-claim #1 now: 'decisions are NOT made by an LLM — deterministic
scripts calculate a score; the platform functions without AI'.

NORTH_STAR.md:
- Vision: 'invisible' → 'visible' (operations become visible — recurring
  theme); polish for technical audience (security, remediation velocity,
  reliability, lead time).
- Objective #2: 'provable trust in AI decisions' → 'provable trust in
  automated decisions' (deterministic scripts calculate a score;
  platform functions without AI).
- Objective #3: four CTO-grade metrics (Lead Time PR→Prod, Infra Vuln
  Count trend, MTTR, Cloud Spend Reduction) → all flow into PowerBI.
- Objective #4: 'default substrate for agentic consumption' → integrate
  with externally owned PDLC/SDLC/Agentic/Citizen Developer platforms
  regardless of source; Nova provides skills + MCP endpoints; all prod
  intents go through the same controls + quality gates.
- Anti-goals: drop #1 (hyperscaler competitor), #4 (legacy untagged),
  #5 (sold to operators). Add: 'not an upstream development platform',
  'not a replacement for the PDLC'. Reword #3 (no 'removes humans').

docs/raci.md: 3 roles → 4 roles. Add Quality Engineering column. Rename
Release Management → SRE. Split release attestation into Quality
attestation (QA) + Production readiness (SRE). Platform no longer holds
A for attestation — reassigned to QE/SRE.

docs/scope.md: add integration framing (skills + MCP endpoints, all
sources go through same controls).

Render scripts: default deck name → nova-autonomous-cloud-delivery.
ONBOARDING + terraform/onboarding: 'no-humans' → 'autonomous'.

---ci---
project: acdl
phase: 1
milestone: v1.21
status: execute
phase_role: execution
---/ci---
2026-08-11 13:55:53 +00:00
Jon Chery 2efed26bb6 docs(P00): create phase plans — v1.21 (7 phases)
Nova Slides Render / render (push) Failing after 1m5s
PLAN.md v1.21 section: 5 execution phases + 1 final. Wave 1 parallelizable
(P1 strategic-docs, P2 slides, P4 pipeline-hardening — zero file overlap),
Wave 2 (P3 marp+README), Wave 3 (P5 render+verify), Wave 4 (P6 ship).
NFR milestone → tags on v1.20.x line (v1.20.0 P0 → v1.20.6 P6 final).

CLARIFY + RESEARCH minimal at full autonomy: domain is known, requirements
confirmed with user (deck title = Autonomous Cloud Delivery Platform;
thesis = AUTONOMY_THESIS.md; slide 1 = Problem→Solution→Proof→Roadmap+Ask;
Atelier split into 2 slides; CTO metrics = Lead Time + Vuln Trend + MTTR +
Spend; files renamed to nova-autonomous-cloud-delivery*).

---ci---
project: acdl
phase: 0
milestone: v1.21
status: plan
---/ci---
2026-08-11 13:52:40 +00:00
Jon Chery 5c07e29b90 docs(P00): validate specification — v1.21 milestone (REQ-245..253)
Add v1.21 requirements section (Nova Deck Refinement & Pipeline Hardening):
REQ-245 deck rename + restructure; REQ-246 thesis rename + reframe;
REQ-247 strategic-docs sync (integration objective); REQ-248 RACI
restructure (QE + SRE); REQ-249 Atelier split; REQ-250 pipeline hardening
(Checkov before plan, Wiz-or-Checkov on plan); REQ-251 theme CSS fix +
footer cleanup; REQ-252 global citation/badge/version removal; REQ-253
render + verify + ship.

Set active_milestone=v1.21 in config.json. Sync PROJECT.md strategic-
direction pillar for the integration objective (Objective #4 reframed),
deterministic-trust reword (Objective #2), CTO-grade ROI metrics
(Objective #3), and anti-goal updates.

---ci---
project: acdl
phase: 0
milestone: v1.21
status: specify
---/ci---
2026-08-11 13:51:55 +00:00
Jon Chery aa868c97ef docs(milestone): complete v1.20 — Consumer Cleanup + Transparent Terraform + Slide Pipeline
15 requirements complete (REQ-230..244):
- P1: gitea/gitlab removed from all synced files (REQ-230,231,232)
- P2: S&P theme CSS + render_slides.sh + CI workflow + tests (REQ-239..243)
- P3: 12-month product roadmap slides added to deck (REQ-244)
- P4: run_platform.sh split + var.enabled feature flags + stale path fix (REQ-233..238)

---ci---
project: acdl
phase: 5
milestone: v1.20
status: complete
phase_role: final
requirements:
  covered: [REQ-230,REQ-231,REQ-232,REQ-233,REQ-234,REQ-235,REQ-236,REQ-237,REQ-238,REQ-239,REQ-240,REQ-241,REQ-242,REQ-243,REQ-244]
  partial: []
---/ci---
2026-08-07 18:54:19 +00:00
Jon Chery e4a9915891 docs(P5): checkpoint — verify stage
---ci---
project: acdl
phase: 5
milestone: v1.20
status: verify
phase_role: final
---/ci---
2026-08-07 18:50:00 +00:00
Jon Chery 0ca383dae6 feat(P4): transparent terraform + feature flags + run_platform.sh split (REQ-233..238)
Create run_codegen.sh (pre-TF: env check, validate, resolve, adapt).
Create run_postapply.sh (post-TF: Checkov, confidence, HITL, outbox, SSM, uptime).
Add variable 'enabled' (bool, default true) + count=var.enabled?1:0 to all 12
L1 modules (alb, cloudfront, ecr, ecs-cluster, ecs-service, iam-role, kms-key,
rds, s3, uptime, vpc, waf). Fix all cross-resource references with [0] indexing.
Update interface.json for all modules to declare 'enabled' input.
Fix stale artifact path /tmp/acdl_platform_run_v18 → /tmp/nova_platform_run (REQ-238).
run_platform.sh remains as backward-compat shim for local-dev usage.

---ci---
project: acdl
phase: 4
milestone: v1.20
status: execute
requirements: [REQ-233, REQ-234, REQ-235, REQ-236, REQ-237, REQ-238]
---/ci---
2026-08-07 18:49:56 +00:00
Jon Chery ed5ea90654 feat(P3): add 12-month product roadmap slides (REQ-244)
Slide 20 — 12-Month Product Roadmap: 4-quarter arc (Pilot Activation →
Provable Trust → Compounding ROI → Agentic Substrate).
Slide 21 — Quarter-by-Quarter Outcomes: detail table (theme, deliverable,
target metric, strategic-objective grounding).
Both grounded in NORTH_STAR's 4 strategic objectives + deferred-metric
candidate milestones. Distinct from Slide 15's deferred-metric unblock paths.
Matching talking-points sections added. HTML + PPTX re-rendered via S&P theme.

---ci---
project: acdl
phase: 3
milestone: v1.20
status: execute
requirements: [REQ-244]
---/ci---
2026-08-07 18:28:01 +00:00
Jon Chery 2273009b95 feat(P2): dedicated S&P theme + render pipeline + CI workflow (REQ-239..243)
Create nova-sp-theme.css — S&P Global Energy Marp theme (Red/Black/White
palette applied to all slide chrome: backgrounds, headers/footers, pagination,
tables, blockquotes, code blocks).
Create render_slides.sh — end-to-end pipeline: mermaid PNGs + Marp HTML/PPTX.
Create slides.yml CI workflow — auto-renders on docs/presentations/ changes.
Create test_slides_pipeline.py — 12 tests (theme CSS, Marp frontmatter, script,
workflow, .mmd/.png parity, README retired-deck cleanup).
Update Marp frontmatter: theme: nova-sp + footer v1.20.
Fix presentations/README.md directory layout (remove retired decks).
Re-render HTML + PPTX with S&P theme.

---ci---
project: acdl
phase: 2
milestone: v1.20
status: execute
requirements: [REQ-239, REQ-240, REQ-241, REQ-242, REQ-243]
---/ci---
2026-08-07 18:26:51 +00:00
Jon Chery 0d2cbdb423 feat(P1): remove gitea/gitlab from synced files + simplify docs (REQ-230,231,232)
Genericize forge-detection code: gitea→forge/generic_forge, GITEA_ACTOR→FORGE_ACTOR.
Drop .gitea byte-identity test assertions (keep GitHub-side + contract conformance).
Add test_no_forge_mentions.py guard test (REQ-230).
Delete completed migration docs (NOVA_MIGRATION.md, NOVA_AWS_MIGRATION.md).
Move NO_HUMANS_THESIS.md to .ciagent/ (internal artifact).
Strip ciagent-internal provenance from synced docs (REQ-/D-/P-/CAP- IDs,
milestone headers, .ciagent/PROJECT.md citations).
Trim README.md (reusable deploy section, local key rotation paragraph).
Fix version-tag drift (@v1.13→@v1.19, acdl/→nova/).

---ci---
project: acdl
phase: 1
milestone: v1.20
status: execute
requirements: [REQ-230, REQ-231, REQ-232]
---/ci---
2026-08-07 18:20:29 +00:00
Jon Chery b418d429b5 docs(ship): P0 complete — v1.20 pre-execution
---ci---
project: acdl
phase: 0
milestone: v1.20
status: complete
phase_role: pre_execution
---/ci---
2026-08-07 18:02:30 +00:00
Jon Chery dcba380b52 docs(P00): create phase plans — v1.20 (5 phases)
---ci---
project: acdl
phase: 0
milestone: v1.20
status: plan
---/ci---
2026-08-07 18:02:27 +00:00
Jon Chery f0bc3be92c docs(P00): validate specification — v1.20 milestone (REQ-230..244)
---ci---
project: acdl
phase: 0
milestone: v1.20
status: specify
---/ci---
2026-08-07 18:02:23 +00:00
Jon Chery 0b79b16715 fix(P2): add metrics domain to sync_to_nova.sh — consumer export views (REQ-229)
acdl-ci / Lint (push) Successful in 9s
acdl-ci / Test (push) Failing after 22s
acdl-ci / Platform check-only (offline) (push) Successful in 23s
The metrics/ export views (README.md, TRUST_SNAPSHOT.md, powerbi/) are
consumer-facing but fell outside the original 13 domains, so the first nova
release left them untracked. Adds a 14th domain 'metrics' between docs and
workflows. Updates TestSyncToNovaScript domain-order assertion to 14.

---ci---
project: acdl
phase: 2
milestone: v1.19
status: complete
phase_role: final
---/ci---
2026-08-06 15:47:25 +00:00
Jon Chery 90624be63f docs(milestone): complete v1.19 — Nova 2nd-Release Sync
acdl-ci / Lint (push) Successful in 8s
acdl-ci / Test (push) Failing after 23s
acdl-ci / Platform check-only (offline) (push) Successful in 32s
NFR-only chore milestone complete. P1 (nova-sync-script, v1.18.0) + P2
(final-review-ship, v1.18.1 = milestone release). REQ-229 satisfied.
Review clean, audit clean, 5 decisions locked (D-143..D-147).

---ci---
project: acdl
phase: 2
milestone: v1.19
status: complete
phase_role: final
requirements:
  covered: [REQ-229]
  partial: []
---/ci---
2026-08-06 15:44:31 +00:00
Jon Chery be51fc15fa docs(P1): ship complete — checkpoint update (Gitea release id 530)
acdl-ci / Lint (push) Successful in 9s
acdl-ci / Test (push) Failing after 24s
acdl-ci / Platform check-only (offline) (push) Successful in 24s
---ci---
project: acdl
phase: 1
milestone: v1.19
status: complete
phase_role: execution
requirements:
  covered: [REQ-229]
  partial: []
---/ci---
2026-08-06 15:43:12 +00:00
Jon Chery e3f4ce17d4 verify(P1): 4-layer verify PASS + ship — sync_to_nova.sh (REQ-229)
acdl-ci / Lint (push) Successful in 10s
acdl-ci / Test (push) Failing after 23s
acdl-ci / Platform check-only (offline) (push) Successful in 24s
L1 structural: bash -n clean, shellcheck 0 warnings.
L2 behavioral: manual gate exits 2 without --release; --list-domains prints
13 ordered domains; rsync exclude list correct; .git protected via filter.
L3 security: no hardcoded secrets; .coverage runtime artifact gitignored.
L4 quality: 8/8 TestSyncToNovaScript tests pass (gate, domain order, exclude
list, consumer-script inclusion, .git filter, conventional regex).

---ci---
project: acdl
phase: 1
milestone: v1.19
status: verify
---/ci---
2026-08-06 15:42:50 +00:00
Jon Chery e0d01ad2ef docs(P1): checkpoint — execute complete (REQ-229)
acdl-ci / Lint (push) Successful in 10s
acdl-ci / Test (push) Failing after 24s
acdl-ci / Platform check-only (offline) (push) Successful in 23s
---ci---
project: acdl
phase: 1
milestone: v1.19
status: execute
---/ci---
2026-08-06 15:40:22 +00:00
Jon Chery a4c5f332f6 feat(P1): sync_to_nova.sh — manual-only 2nd-release pipeline into ~/nova (REQ-229)
Replaces scripts/sync_to_gl.sh (kitchen-sink mirror sync into ~/gl/acdl) with
scripts/sync_to_nova.sh — a manual-only, consumer-subset, domain-committed
2nd-release pipeline into ~/nova (GitLab jonathanchery/nova, separate repo +
history, consumer/platform-team audience).

- Manual-only gate: refuses without --release / RELEASE_CONFIRMED=1 (exit 2).
  Never triggerable by CI.
- Consumer subset: excludes .ciagent/, .gitea/, .env*, terraform/, demo/,
  runtime metrics artifacts, and 18 internal-only scripts (EXCLUDE_SCRIPTS).
  Keeps consumer runbooks + metrics export views (README, powerbi,
  TRUST_SNAPSHOT). Protects ~/nova/.git via rsync --filter=P .git.
- Domain-based commits: 13 fixed-order domains (config, core, adapters,
  modules, contracts, schemas, pipelines, mcp, skills, scripts, tests, docs,
  workflows). Each changed domain gets its own conventional commit supplied
  positionally via repeated -m flags. No kitchen-sink commit.
- Conventional-commit validation: regex-enforced (feat|fix|docs|chore|...);
  bypass via --no-verify-format.
- Modes: --list-domains, --dry-run, --no-push, -v, -h.
- Tests: TestSyncToNovaScript (8 tests) covers gate, domain order, exclude
  list, consumer-script inclusion, .git protection filter, conventional
  regex.

Decisions: D-143 (target ~/nova), D-144 (conventional commits per domain,
not ---ci--- audit blocks), D-145 (manual-only trigger), D-146 (13 fixed
domains, positional-over-changed mapping), D-147 (coreci/Atelier review
gate deferred).

---ci---
project: acdl
phase: 1
milestone: v1.19
status: execute
requirements:
  covered: [REQ-229]
  partial: []
---/ci---
2026-08-06 15:40:11 +00:00
Jon Chery 9e20b7ba95 docs(ship): v1.17.7 milestone complete — checkpoint update (Gitea release id 529)
acdl-ci / Lint (push) Successful in 9s
acdl-ci / Test (push) Failing after 24s
acdl-ci / Platform check-only (offline) (push) Successful in 23s
2026-08-06 15:17:46 +00:00
Jon Chery 6da538c936 Merge milestone/v1.18-citizen-developer-guidance — v1.18 complete (Citizen Developer & Production-Grade Guidance: 5 inputs, 15 requirements, 7 phases + final; tag v1.17.7)
acdl-ci / Lint (push) Successful in 10s
acdl-ci / Test (push) Failing after 26s
acdl-ci / Platform check-only (offline) (push) Successful in 24s
2026-08-06 15:17:03 +00:00
Jon Chery 4e03817ea6 Merge phase/07-final-review-ship — v1.17.7 (v1.18 P7 final review + audit + milestone complete) 2026-08-06 15:16:59 +00:00
Jon Chery 951ad56576 docs(milestone): complete v1.18 — Citizen Developer & Production-Grade Guidance
15 requirements (REQ-214..228) satisfied. 32 tests pass. S&P Global theme
restored. PDLC-upstream scope + RACI matrix authored. Submission-readiness
schema + validator shipped. 9 Atelier skills + docs/skills.md. MCP server
(plugin-registry, stdio, vendored Atelier v0.3.6) with 4 tools + agentic
validation. 21-slide deck (3 new: scope/RACI/atelier) with PPTX committed +
release-attached. 10 decisions locked (D-133..D-142).

---ci---
project: acdl
phase: 7
milestone: v1.18
status: complete
requirements:
  covered: [REQ-214, REQ-215, REQ-216, REQ-217, REQ-218, REQ-219, REQ-220, REQ-221, REQ-222, REQ-223, REQ-224, REQ-225, REQ-226, REQ-227, REQ-228]
  partial: []
---/ci---
2026-08-06 15:16:54 +00:00
140 changed files with 6010 additions and 4034 deletions
+66
View File
@@ -0,0 +1,66 @@
# Nova — The Autonomous Cloud Delivery Platform: Autonomy Defensibility Brief
> Strategic direction, leadership metrics & unified story
> Last refined: v1.21 — reframe from "no-humans" to "autonomous operations"
## The thesis
Nova is the autonomous infrastructure layer that lets product teams
ship without engaging an operator, and lets executives trust the
platform not because it never fails but because every decision is
captured, scored, and accountable.
**Autonomy in operations; human at stage gates.** Normal operations —
provisioning, healing, remediation — run without an operator in the
loop. Human attestation remains required at stage gates: QA signs off
for production, SRE greenlights based on operational readiness. The
absence of an operator in the loop is never the absence of a record.
## Grounded proof (measurable today)
| Proof | Source | Status |
|-------|--------|--------|
| Capabilities verified, none broken (live-AWS caps honestly skipped, resources torn down to zero-cost steady state) | regression report | grounded |
| Decision Ledger captures 100% of automated decisions with outcome backfill | decision ledger store | grounded |
| Attestation coverage: 100% of prod/dr promotions attested by a human | attestation gates + outbox | grounded |
| Confidence-gated policy engine (deterministic, not an LLM) — weighted inputs, band outcome | confidence signal | grounded |
| Attestation matrix with separation-of-duties on prod | attestation matrix + separation-of-duties | grounded |
| Pre-apply cost estimates (offline) | cost adapter | grounded |
| Test suite passes | test results | grounded |
## Deferred proof (measurable when blocking work lifts)
| Proof | Blocking work | Unblock requirement |
|-------|----------------|---------------------|
| Touchless resolution rate across production estates | 0 consumers today | Pilot estate activation |
| Live infrastructure health (ECS, ALB, RPS) | Live AWS torn down | Live AWS re-provisioning |
| Onboarding funnel: requested → granted | Auto-grant not built | Auto-grant implementation |
| Drift auto-reversal rate | No drift scheduler | Drift detection scheduler |
| Predictive vs reactive ratio | No emitter | ML anomaly-forecasting service |
| Tamper-evident ledger checkpoints (S3 Object Lock + JWS) | Audit ledger build-out | Audit ledger build-out |
## Anti-claims (what Nova is NOT)
1. **Nova's decisions are NOT made by an LLM.** They are made by a
confidence-gated policy engine: deterministic scripts calculate a
score, and a band outcome gates the action. The platform functions
without AI. The Decision Ledger captures this real decision path —
not a fabricated "AI agent." When an LLM planner is added, it will
emit richer `alternatives_considered` without schema breakage.
2. **Nova does NOT remove humans from accountability.** Only from
normal operations. Every stage-gate promotion (qa/prod/dr) requires
a human attestation recorded with approver identity,
separation-of-duties check, and the evidence matrix.
3. **Nova is NOT for legacy, untagged, or freeform infrastructure.** It
requires Terraform-managed, policy-aligned, fully-tagged inputs.
4. **Nova does NOT fabricate metrics.** Every metric is grounded (cites
a source), derived (documented formula), or deferred (cites the
blocking work). No fabricated numbers in any deck slide or metrics
entry (the "no fabrication" hard constraint).
## What "won" looks like
By month 18, Nova is the layer enterprise leadership points to when
they say *"we don't have an infrastructure ops team anymore, and the
audit trail is stronger than it ever was"* — and it is the layer their
AI engineering teams reach for first when an agent needs to deploy.
+7 -7
View File
@@ -1,12 +1,12 @@
{ {
"phase": 0, "phase": 2,
"stage": "complete", "stage": "complete",
"milestone": "v1.18", "milestone": "v1.22",
"phase_role": "pre_execution", "phase_role": "execution",
"attempts": 0, "attempts": 0,
"updated_at": "2026-08-06T00:35:00Z", "updated_at": "2026-08-11T14:50:00Z",
"milestone_complete": false, "milestone_complete": false,
"tag": "v1.17.0", "tag": "v1.21.2",
"release_id": 522, "requirements": ["REQ-257","REQ-258"],
"notes": "v1.18 P0 complete. 5 pre-execution stages done. Tag v1.17.0, release 522." "notes": "v1.22 P2 complete. Tag v1.21.2. render_deck.sh deleted, CLI versions pinned, 2x scale + transparent bg added. 4 render tests + 1 no-forge test pass. Proceeding to P3 (mermaid re-layout)."
} }
+57 -36
View File
@@ -1,7 +1,7 @@
# NORTH_STAR — Nova # NORTH_STAR — Nova
> **Status:** Draft (pending interactive GRILL → final) > **Status:** Draft (pending interactive GRILL → final)
> **Milestone:** v1.17Strategic Direction, Leadership Metrics & Unified Story > **Milestone:** v1.21 — Nova Deck Refinement & Pipeline Hardening
> **Owner:** Product Owner > **Owner:** Product Owner
> **Purpose:** Durable strategic intent. Read by CIAgent in every future > **Purpose:** Durable strategic intent. Read by CIAgent in every future
> `/ci-run` so the platform's direction survives across milestones. This > `/ci-run` so the platform's direction survives across milestones. This
@@ -14,7 +14,7 @@
## Vision ## Vision
> **Infrastructure operations become invisible. Every environment > **Infrastructure operations become visible. Every environment
> provisioned, every incident healed, every risk remediated — by an > provisioned, every incident healed, every risk remediated — by an
> autonomous system whose trustworthiness is provable, not promised. > autonomous system whose trustworthiness is provable, not promised.
> Human attestation remains required at stage gates — QA signs off for > Human attestation remains required at stage gates — QA signs off for
@@ -22,9 +22,12 @@
> operator is never in the loop of normal operations.** > operator is never in the loop of normal operations.**
Nova is the autonomous infrastructure layer that lets product teams ship Nova is the autonomous infrastructure layer that lets product teams ship
without engaging an operator, and lets executives trust the AI not because without engaging an operator, and lets executives trust the platform not
it never fails but because every decision is captured, scored, and because it never fails but because every decision is captured, scored,
accountable. and accountable. The recurring theme across the platform is that
**infrastructure operations become visible** — security posture,
remediation velocity, reliability, and lead time are surfaced as
queryable signals rather than hidden in tribal knowledge.
--- ---
@@ -38,46 +41,64 @@ human by design; operational escalations (AI confidence too low to
proceed) are the failure mode we drive toward zero. Everything else proceed) are the failure mode we drive toward zero. Everything else
collapses if autonomy isn't real. collapses if autonomy isn't real.
**2. Establish provable trust in AI decisions.** **2. Establish provable trust in automated decisions.**
Build the audit substrate — Decision Ledger, confidence scoring, circuit Trust is established by deterministic scripts that calculate a score and
breakers, blast-radius controls — that turns "autonomous" from a a band outcome that gates the action — the platform functions without AI.
marketing claim into a defensible one. Trust is the moat. Features can be "AI decisions" are really automated decisions. The audit substrate —
copied; an immutable, queryable decision history cannot. Decision Ledger, confidence scoring, circuit breakers, blast-radius
controls — turns "autonomous" from a marketing claim into a defensible
one. Trust is the moat. Features can be copied; an immutable, queryable
decision history cannot.
**3. Deliver compounding, quantifiable ROI for customers.** **3. Deliver compounding, quantifiable ROI for customers.**
Each quarter on Nova must reduce cloud spend, free engineering hours, and Each quarter on Nova must show measurable improvement on four CTO-grade
avoid downtime measurably. If the CFO can't point to a number that metrics, all of which flow into PowerBI views and are captured by the
improves quarter-over-quarter, Nova fails its commercial test, regardless telemetry pipeline:
of how clever the AI is.
**4. Become the default substrate for agentic infrastructure consumption.** - **Lead Time** — from PR merge to production deployment (downward trend).
AI agents are already becoming the largest consumers of cloud - **Infrastructure Vulnerability Count** — open findings on deployed
infrastructure. Nova must be the platform through which those agents resources (downward trend, demonstrating that proactive scanning +
declare, deploy, and verify infrastructure — not a vendor scrambling into remediation keeps up with the AI-era 0-day pace).
that market two quarters late. - **MTTR** — for platform-detected and platform-remediated incidents.
- **Cloud Spend Reduction** — on pilot estates vs. the pre-Nova
baseline.
If leadership cannot point to a number that improves quarter-over-quarter
on these four axes, Nova fails its commercial test, regardless of how
clever the automation is.
**4. Integrate with externally owned development platforms — regardless of source.**
Nova integrates with externally owned PDLC, SDLC, Agentic, and Citizen
Developer platforms with no regard for the source of the intent. Nova
provides a set of skills and MCP endpoints that help the developer or AI
agent make their application production-grade. Regardless of the source,
all intents to deploy to production go through the same rigorous
controls, quality gates, attestation, and evidence stream. Nova is the
layer any of those platforms reach for first when an agent needs to
deploy — not a vendor arriving late to that market.
--- ---
## Anti-Goals (5 — what Nova is fundamentally NOT) ## Anti-Goals (4 — what Nova is fundamentally NOT)
1. **Not a Terraform, Kubernetes, or hyperscaler competitor.** We 1. **Not a general-purpose AI agent platform.** We are purpose-built for
orchestrate them. Replacing them is the most expensive possible
distraction from the value we create.
2. **Not a general-purpose AI agent platform.** We are purpose-built for
infrastructure operations. Breadth here produces shallow tools; depth infrastructure operations. Breadth here produces shallow tools; depth
here wins the category. here wins the category.
3. **Not a system that removes humans from accountability.** Only from 2. **Not a system that removes humans from accountability.** Only from
operations. Every AI decision lands in an immutable ledger. Every normal operations. Every automated decision lands in an immutable
stage-gate promotion (qa/prod/dr) requires a human attestation recorded ledger. Every stage-gate promotion (qa/prod/dr) requires a human
with approver identity, separation-of-duties check, and the 8-concern attestation recorded with approver identity, separation-of-duties
evidence matrix. The absence of an operator is never the absence of a check, and the evidence matrix. The absence of an operator in the
record. loop is never the absence of a record.
4. **Not for legacy, untagged, or freeform infrastructure.** Nova requires 3. **Not an upstream development platform.** Nova does not own the
Terraform-managed, policy-aligned, fully-tagged inputs. We optimize for product backlog, IDE workflows, code authorship, or application
the disciplined 95%, not the chaotic 5%. business logic. The PDLC is upstream; Nova integrates with it through
5. **Not sold to operators.** Nova is sold to leadership on outcomes — a validated contract boundary — Nova never penetrates it.
cost, velocity, risk. Selling to operators inverts the incentive and 4. **Not a replacement for the Product Development Lifecycle (PDLC).**
breaks the autonomy thesis. Nova governs infrastructure + delivery only. Product lifecycle
decisions (what to build, when to ship, for whom) remain with the
product team. Nova makes their intent production-grade; it does not
own the intent.
--- ---
+120 -24
View File
@@ -1,34 +1,128 @@
--- ---
project: acdl project: acdl
milestone: v1.18 milestone: v1.22
generated_at: 2026-08-06 generated_at: 2026-08-11
generator: lead-developer generator: lead-developer
verification_toolchain: verification_toolchain:
typecheck: "python3 -m py_compile core/submission_readiness.py mcp/atelier/server.py && python3 -m jsonschema schemas/submission-readiness.schema.json" typecheck: "python3 -m py_compile tests/test_slides_pipeline.py"
test: "pytest tests/test_submission_readiness.py tests/test_atelier_mcp.py # REQ-220 + REQ-225" test: "pytest tests/test_slides_pipeline.py # REQ-254..262"
build: "bash scripts/render_deck.sh docs/presentations/nova-no-humans-platform-marp.md # HTML + PPTX (D-142)" build: "bash scripts/render_slides.sh nova-autonomous-cloud-delivery # HTML + PPTX"
note: | note: |
v1.18 adds the Citizen Developer & Production-Grade Guidance surface: v1.22 is the Nova Deck Layout Fix — a docs-only NFR milestone. Two
submission-readiness gate, Atelier-derived skills, the Atelier MCP server active personas: lead-developer (theme CSS + deck markdown + talking
(plugin-registry, stdio), and PPTX-as-first-class-artifact deck automation. points + README + .ciagent metadata), backend-engineer (render scripts
Three active personas: lead-developer (coordination + decks + RACI/scope + tests). frontend-engineer stays deactivated (decks are markdown =
docs), backend-engineer (MCP server + submission-readiness validator + lead-developer territory, per v1.17/v1.18 precedent). No data-engineer
render/attach scripts), data-engineer (submission-readiness schema if it (no schema/DB changes). No new personas (the work is CSS + bash +
touches contract storage / DynamoDB shape). frontend-engineer stays markdown + pytest, all within the two active personas' range).
deactivated (v1.18 has no frontend; decks are markdown = lead-developer
territory). The MCP plugin-registry is a backend pattern, so a separate
mcp-engineer persona is NOT added — it folds into backend-engineer.
--- ---
# ACDL — Persona Roster (v1.18 Citizen Developer & Production-Grade Guidance) # ACDL — Persona Roster (v1.22 Nova Deck Layout Fix)
> v1.18 roster. Three active personas + one deactivated. The MCP server > v1.22 roster. Two active personas + one deactivated. This is a docs-
> plugin-registry (D-140) is a backend pattern, not a new persona — it > only NFR milestone: the work is theme CSS, render scripts, mermaid
> folds into backend-engineer. v1.17 precedent (frontend-engineer > diagrams, deck markdown, and tests. frontend-engineer stays
> deactivated, decks are markdown = lead-developer territory) is upheld. > deactivated (decks are markdown = lead-developer territory, per
> v1.17/v1.18 precedent). No data-engineer (no schema/DB changes).
## Active personas ## Active personas
### lead-developer
- **Domain:** coordination + deck content
- **Active:** true
- **Phase-specific:** false
- **Frameworks:** [] (no framework — owns process + narrative + CSS + markdown)
- **Constraints:** ["pragmatic", "battle-tested defaults", "no fabrication (NORTH_STAR honesty model)", "do not change the 4-beat arc", "do not re-introduce badges/version/internal citations"]
- **Territory:**
- `docs/presentations/assets/nova-sp-theme.css` (REQ-254,255,256 — theme CSS)
- `docs/presentations/nova-autonomous-cloud-delivery-marp.md` (REQ-261 — deck content)
- `docs/presentations/nova-autonomous-cloud-delivery.md` (REQ-261 — source of truth)
- `docs/presentations/nova-autonomous-cloud-delivery-talking-points.md` (REQ-261)
- `docs/presentations/README.md` (REQ-261 — slide-count convention)
- `docs/presentations/assets/mmd/*.mmd` (REQ-259,260 — mermaid re-layout)
- `.ciagent/**` (PROJECT, ROADMAP, REQUIREMENTS, RESEARCH, PLAN, GRILL, PERSONAS, REVIEW, CHECKPOINT)
- **Reason:** Owns the theme CSS (the root cause), the deck markdown
(trim/split overflowing slides), the mermaid re-layout, the talking
points, the README, and all CIAgent metadata. Is the only persona
that touches `.ciagent/**` and the deck markdown/CSS.
- **Phase-specific flag:** none (active for all of P0P6).
### backend-engineer
- **Domain:** render scripts + tests
- **Active:** true
- **Phase-specific:** false
- **Frameworks:** ["bash", "pytest", "marp-cli", "mermaid-cli"]
- **Constraints:** ["pin CLI versions (no @latest)", "2x scale + transparent bg for mermaid", "tests must catch layout regressions", "no raw curl with shell-env tokens"]
- **Territory:**
- `scripts/render_slides.sh` (REQ-257,258 — pin versions, 2x scale)
- `scripts/render_deck.sh` (REQ-257 — DELETE)
- `tests/test_slides_pipeline.py` (REQ-262 — layout/aspect-ratio/theme-structural tests)
- `.github/workflows/slides.yml` (if references to render_deck.sh need removal)
- **Reason:** Owns the render pipeline (bash scripts) and the test
suite. The layout/aspect-ratio/theme-structural tests (REQ-262) are
the gap that let this regression through — backend-engineer owns
closing that gap. Pinning CLI versions and adding 2x scale are
backend/scripting tasks.
- **Phase-specific flag:** none (active for P2, P5; light touch on P0/P6).
## Deactivated personas
### frontend-engineer
- **Active:** false
- **Domain:** frontend
- **Frameworks:** ["react", "next.js"] (inert — no territory)
- **Constraints:** ["component-first", "server-components", "minimal-client-js"] (inert)
- **Territory:** [] (no territory in v1.22)
- **Reason:** v1.22 has no frontend; decks are markdown (lead-developer
territory); deactivated per PERSONAS.md v1.17/v1.18 precedent. The
theme CSS is a Marp stylesheet, not a React/Next.js component system
— it stays lead-developer territory. No reactivation trigger.
### data-engineer
- **Active:** false
- **Domain:** data
- **Frameworks:** [] (inert)
- **Constraints:** [] (inert)
- **Territory:** [] (no territory in v1.22)
- **Reason:** v1.22 has no schema/DB/ORM changes. The milestone is
docs + scripts + tests only. No reactivation trigger.
## Roster decisions
### D-148 (0.95): Theme CSS is lead-developer territory, not frontend-engineer
The `nova-sp-theme.css` is a Marp stylesheet (CSS for a markdown-to-
slide renderer), not a React/Next.js component system. The v1.17/v1.18
precedent (decks are markdown = lead-developer territory) extends to
the deck's CSS theme. frontend-engineer's frameworks (react, next.js)
are irrelevant to Marp CSS. **Decision:** theme CSS stays lead-developer
territory. Confidence 0.95 — the only counter-argument is that CSS is
"frontend," but Marp CSS is a static stylesheet, not a component system.
### D-149 (0.9): No new personas for v1.22
The work is CSS + bash + markdown + mermaid + pytest. All of this is
within the two active personas' range (lead-developer: CSS + markdown +
mermaid; backend-engineer: bash + pytest). Creating a separate "css-
engineer" or "slides-engineer" persona would fragment ownership of the
theme CSS + deck markdown (both lead-developer) and the render scripts
+ tests (both backend-engineer). **Decision:** no new personas.
Confidence 0.9.
### Territory-overlap resolution (co-ownership)
| Path | Primary | Co-owner | Why |
|------|---------|----------|-----|
| `docs/presentations/assets/mmd/*.mmd` | lead-developer (mermaid re-layout) | backend-engineer (re-render via render_slides.sh) | The .mmd content is lead-developer (diagram narrative); the PNG re-render is backend-engineer (script invocation). |
| `tests/test_slides_pipeline.py` | backend-engineer (test code) | lead-developer (assertions reflect deck structure) | The test code is backend; the assertions (slide count, theme rules, aspect ratios) reflect lead-developer's deck/theme decisions. |
---
## Historical rosters
<details>
<summary>v1.18 roster (Citizen Developer & Production-Grade Guidance) — superseded by v1.22</summary>
### Active personas (v1.18)
### lead-developer ### lead-developer
- **Domain:** coordination - **Domain:** coordination
- **Active:** true - **Active:** true
@@ -97,7 +191,7 @@ verification_toolchain:
is backend; the schema it validates against is data). is backend; the schema it validates against is data).
- **Phase-specific flag:** none (active for P3 schema + ingestor wiring). - **Phase-specific flag:** none (active for P3 schema + ingestor wiring).
## Deactivated personas ### Deactivated personas (v1.18)
### frontend-engineer ### frontend-engineer
- **Active:** false - **Active:** false
@@ -111,7 +205,7 @@ verification_toolchain:
frontend / dashboard"). The MCP server exposes tools to an AI agent, frontend / dashboard"). The MCP server exposes tools to an AI agent,
not a web UI. No reactivation trigger in this milestone. not a web UI. No reactivation trigger in this milestone.
## Roster decisions ### Roster decisions (v1.18)
### D-143 (0.90): Fold mcp-engineer into backend-engineer ### D-143 (0.90): Fold mcp-engineer into backend-engineer
The MCP plugin-registry (D-140: `plugins/<name>.py register(mcp)`) is a The MCP plugin-registry (D-140: `plugins/<name>.py register(mcp)`) is a
@@ -127,10 +221,12 @@ that MCP is a distinct protocol skill, but the SDK v2 API surface
range (it's the same Pydantic/FastAPI-style pattern the persona already range (it's the same Pydantic/FastAPI-style pattern the persona already
knows). knows).
### Territory-overlap resolution (co-ownership) ### Territory-overlap resolution (v1.18)
| Path | Primary | Co-owner | Why | | Path | Primary | Co-owner | Why |
|------|---------|----------|-----| |------|---------|----------|-----|
| `docs/submission-readiness.md` | lead-developer (narrative + examples) | backend-engineer (reason-code catalog, REQ-218 codes) | The doc is citizen-developer-facing copy (lead) but the reason-code catalog (MISSING_TAGS, ENV_MISSING_MANDATORY, AGENTIC_MISSING_INTENT, MISSING_APP_SOURCE, POLICY_PRECONDITION_MISSING) is backend (it mirrors the validator's return codes). | | `docs/submission-readiness.md` | lead-developer (narrative + examples) | backend-engineer (reason-code catalog, REQ-218 codes) | The doc is citizen-developer-facing copy (lead) but the reason-code catalog (MISSING_TAGS, ENV_MISSING_MANDATORY, AGENTIC_MISSING_INTENT, MISSING_APP_SOURCE, POLICY_PRECONDITION_MISSING) is backend (it mirrors the validator's return codes). |
| `core/lambda/contract_ingestor.py` | backend-engineer (dispatch wiring) | data-engineer (the schema it validates against) | D-133 places the `--check-readiness` subcommand on the ingestor (backend dispatch), but the readiness schema it loads is data-engineer territory. | | `core/lambda/contract_ingestor.py` | backend-engineer (dispatch wiring) | data-engineer (the schema it validates against) | D-133 places the `--check-readiness` subcommand on the ingestor (backend dispatch), but the readiness schema it loads is data-engineer territory. |
| `schemas/submission-readiness.schema.json` | data-engineer (schema artifact) | backend-engineer (the validator must match it) | The schema is data-engineer's; the validator (REQ-218) is backend-engineer's and must stay in sync with it. | | `schemas/submission-readiness.schema.json` | data-engineer (schema artifact) | backend-engineer (the validator must match it) | The schema is data-engineer's; the validator (REQ-218) is backend-engineer's and must stay in sync with it. |
</details>
+511 -2
View File
@@ -1,3 +1,157 @@
# Nova — Phase Plan v1.21 (Nova Deck Refinement & Pipeline Hardening)
> **Milestone:** v1.21 — Nova Deck Refinement & Pipeline Hardening
> **Branch:** `milestone/v1.21-deck-refinement` (flat workflow: commits on
> main, tags on the v1.20.x line per branch-strategy)
> **Tag line:** `v1.20.x` patch line — `v1.20.0` (P0) → `v1.20.1..v1.20.5`
> (P1P5) → `v1.20.6` (P6 final = milestone release). v1.21 is an NFR
> milestone (all phases are docs/test/chore/refactor) → progressive patches.
> **Phase count:** 7 (P0 pre-execution [DONE] + 5 execution + 1 final).
> **Source of truth for requirements:** `.ciagent/REQUIREMENTS.md` §v1.21
> (REQ-245..253, 9 requirements).
> **Source of truth for decisions:** the 33 review notes in the v1.21
> run context (encoded as REQ-245..253).
> **Source of truth for research:** existing deck + pipeline + strategic
> docs (the domain is known; no new research needed at full autonomy).
## Wave Ordering
All 5 execution phases are **sequenced** (flat workflow). The theoretical
parallelism is documented for future parallelization-enabled runs.
| Wave | Phases | Rationale |
|------|--------|-----------|
| Wave 1 | P1, P2, P4 (**parallelizable**) | P1 (strategic docs: NORTH_STAR, AUTONOMY_THESIS, PROJECT, scope, raci), P2 (slides source-of-truth rewrite + rename), P4 (pipeline hardening: Checkov/Wiz flow). Zero file overlap: P1 touches `.ciagent/` + `docs/scope.md` + `docs/raci.md`; P2 touches `docs/presentations/*.md`; P4 touches `scripts/run_*.sh` + `adapters/wiz/` + `tests/test_pipeline*.py`. In a parallelization-enabled run these three could execute concurrently. |
| Wave 2 | P3 | Marp deck + talking points + README synthesis. Depends on P2's updated source-of-truth. Re-renders HTML+PPTX via `render_slides.sh`. Also fixes theme CSS A1 table + footer cleanup (REQ-251). |
| Wave 3 | P5 | Render + verify. Depends on P2 (source), P3 (marp), P4 (pipeline). Re-renders mermaid PNGs (slide 1 new diagram, slide 9 expand, Atelier split), HTML, PPTX. Runs `test_slides_pipeline.py`, `test_no_forge_mentions.py`, full `pytest`, `run_platform.sh --check-only`. |
| Wave 4 | P6 | Final review + audit + milestone ship. Merge to main, tag `v1.20.6`, create release, attach PPTX. |
## Phase Summaries
### Phase P0 — pre-execution (DONE)
SPECIFY → CLARIFY → RESEARCH → PLAN. Validated v1.21 requirements
(REQ-245..253). Established `active_milestone: "v1.21"`. Synced
PROJECT.md strategic-direction pillar. No new research (domain known).
### Phase P1 — strategic-docs (Wave 1)
- `NORTH_STAR.md`: vision polish (item 11); obj #2 deterministic-scoring
reword (item 13); obj #3 four CTO metrics (item 14); obj #4 replaced
with integration objective (item 17); drop anti-goals 1,4,5; add 2 new
anti-goals (item 16); anti-goal #3 reworded (item 7).
- `git mv .ciagent/NO_HUMANS_THESIS.md .ciagent/AUTONOMY_THESIS.md` +
reframe content (items 7, 8).
- `PROJECT.md`: mission/scope sync for item 17 (already partially done
in P0; finalize here).
- `docs/scope.md`: light sync.
- `docs/raci.md`: rename Release Mgmt → SRE; add Quality Engineering role.
- **REQs:** REQ-246, REQ-247 (partial).
### Phase P2 — slides source-of-truth (Wave 1)
- `git mv` all 5 deck files `nova-no-humans-platform*`
`nova-autonomous-cloud-delivery*`.
- Rewrite `nova-autonomous-cloud-delivery.md` (source of truth):
- Slide 1 "The Problem" (items 3,4,5,7,9): broader problem (devs writing
terraform, destructive changes, AI-era 0-day pace, bandwidth gaps,
tribal knowledge/rockstar operator); no arc; no "18 capabilities
verified"; not "humans are the problem".
- Slide 2 "Nova's Vision" (item 11): polish for technical audience;
"infrastructure operations become visible" as recurring theme.
- Slide 3 "Strategic Objectives + Anti-Goals" (items 12,13,14,15,16,17,
18): only Obj+Anti-Goals; provable trust = deterministic scripts
(functions without AI); ROI = Lead Time + Vuln Trend + MTTR + Spend;
drop anti-goals 1,4,5; add "not upstream dev platform", "not PDLC
replacement"; replace obj #4 with integration objective; reword benefit.
- Slide 4 "Scope" (item 29): refine (moved up).
- Slide 5 "RACI" (item 30): add QE column; reassign A from Platform →
QA/SRE; rename Release Mgmt → SRE; split release attestation (SRE =
Production Readiness); shrink to fit (moved up).
- Slide 6 "Pipeline" (item 20): Checkov on static code before plan;
Wiz on plan; no Wiz → Checkov on plan; never both.
- Slide 7 "Decision Ledger" (items 21,22): drop D-121/122/132; "AI
decisions = automated decisions"; focus on value (immutable,
queryable, accountable), not sqlite/hash-chain implementation.
- Slide 8 "Attestation Matrix" (item 23): drop bullets below table;
add Description column per concern; rethink "operator-supplied"
label; reword benefit.
- Slide 9 "Telemetry & Live Ops" (item 25): expand on value; keep
metric flow; drop D-120/125/126; expand on PowerBI live ops
dashboard; reword benefit.
- Slide 10 "Decision Ledger + Attestation Coverage" (item 27):
mandatory by design; no prod change without ledger + human
attestation; queryable for auditing; full traceability; improve
benefit.
- Slide 11 "Cost & ROI": minor polish.
- Slide 12 "What's Deferred — and Why" (items 10,19): remove all D-IDs;
plain-language blockers.
- Slide 13 "Roadmap to the North Star" (items 10,19): drop D-IDs; no
status column; roadmap with timelines.
- Slide 14 "12-Month Product Roadmap" (item 24): drop `planned` badges.
- Slide 15 "Quarter-by-Quarter Outcomes" (item 24): drop badges.
- Slide 16 "Production-Grade Guidance via Atelier (1/2)" (item 31):
split — Skills + MCP server overview.
- Slide 17 "Production-Grade Guidance via Atelier (2/2)" (item 31):
split — agentic validation beyond deterministic scanners + vendoring.
- Slide 18 "Recap + Ask": refresh recap to match new structure.
- Appendix A1 "Metrics Glossary" (item 32): table readability fixed
in P3 theme CSS.
- Global (items 6,10,24,2): tech-leadership benefits; no D-###/REQ-###/
.py paths in audience slides; no badges; no version in footer; final
"less is more / no fluff" prose pass.
- **REQs:** REQ-245, REQ-248, REQ-249, REQ-252 (partial).
### Phase P3 — marp deck + talking points + README (Wave 2)
- `nova-autonomous-cloud-delivery-marp.md`: synthesize from updated
source; frontmatter — title "Nova — The Autonomous Cloud Delivery
Platform", footer without version + without "Act N/5", title-slide
subtitle "Product Development & Citizen Developer Overview", no badges.
- `nova-autonomous-cloud-delivery-talking-points.md`: re-distill to
18-slide structure.
- `docs/presentations/README.md`: update deck title, audience, slide
count (18 main + 1 appendix), directory layout, remove badge docs,
update deck table + render commands + filenames.
- `docs/presentations/assets/nova-sp-theme.css`: fix Appendix A1 table
background (item 32); footer chrome no version.
- Update `scripts/render_slides.sh`, `scripts/render_deck.sh`,
`workflows-src/slides.yml`, `.github/workflows/slides.yml`,
`tests/test_slides_pipeline.py` filename refs.
- **REQs:** REQ-251, REQ-252 (partial).
### Phase P4 — pipeline hardening (Wave 1)
- `scripts/run_platform.sh` + `scripts/run_postapply.sh`: item 20 flow —
1. Checkov on static code (`main.tf`/TF dir) **before** `terraform
plan` → fail-fast dev feedback.
2. After plan: if `WIZ_API_TOKEN`+`WIZ_API_URL` → **Wiz against plan**;
else **Checkov against plan** (drop-in). **Never both.**
- `adapters/wiz/wiz_adapter.py`: support plan-mode input if needed.
- Tests: `tests/test_pipeline.py`, `tests/test_pipeline_contract.py`,
`tests/test_slides_pipeline.py`, checkov/wiz tests.
- `docs/scope.md` policy-enforcement line + slide 6 reflect new flow.
- `docs/METRICS.md` policy-stage description if changed.
- **REQs:** REQ-250.
### Phase P5 — render + verify (Wave 3)
- Re-render changed/new mermaid diagrams (slide 1 new diagram, slide 9
expand, Atelier split) via `scripts/render_slides.sh`.
- Render HTML + PPTX.
- `tests/test_slides_pipeline.py` passes: 18 main + 1 appendix; no badges;
no version in footer; no D-###/REQ-###/.py paths in audience slides;
filename refs updated.
- `tests/test_no_forge_mentions.py` passes.
- Full `pytest` passes (pipeline-hardening tests green).
- `run_platform.sh --check-only` passes.
- **REQs:** REQ-253 (partial).
### Phase P6 — final-review-ship (Final Phase, Wave 4)
- Multi-persona code review across P1P5.
- Audit: git log vs `.ciagent/` discipline.
- Ship: merge to main, tag `v1.20.6` (final patch = milestone release),
create release, attach PPTX.
- Update `REQUIREMENTS.md` (v1.21 REQs complete) + `ROADMAP.md` (v1.21
complete). Clear `CHECKPOINT.json`.
- **REQs:** REQ-253 (complete).
---
# Nova — Phase Plan v1.18 (Citizen Developer & Production-Grade Guidance) # Nova — Phase Plan v1.18 (Citizen Developer & Production-Grade Guidance)
> **Milestone:** v1.18 — Citizen Developer & Production-Grade Guidance > **Milestone:** v1.18 — Citizen Developer & Production-Grade Guidance
@@ -944,5 +1098,360 @@ NOT exercised here.
8. **No new frontend (frontend-engineer deactivated).** v1.18 has no 8. **No new frontend (frontend-engineer deactivated).** v1.18 has no
frontend; decks are markdown (lead-developer territory); the MCP frontend; decks are markdown (lead-developer territory); the MCP
server exposes tools to an AI agent, not a web UI. The server exposes tools to an AI agent, not a web UI. The
frontend-engineer persona stays deactivated (PERSONAS.md v1.18 frontend-engineer persona stays deactivated (PERSONAS.md v1.18
roster). No reactivation trigger in this milestone. roster). No reactivation trigger in this milestone.
---
# Nova — Phase Plan v1.22 (Nova Deck Layout Fix)
> **Milestone:** v1.22 — Nova Deck Layout Fix
> **Branch:** `milestone/v1.22-deck-layout-fix` → merge to `main` at P6.
> Phase branches: `phase/00-pre-execution`, `phase/01-theme-css`,
> `phase/02-render-scripts`, `phase/03-mermaid-relayout`,
> `phase/04-deck-content`, `phase/05-render-and-test`,
> `phase/06-final-review-ship`.
> **Tag line:** `v1.21.x` patch line — `v1.21.0` (P0) →
> `v1.21.1..v1.21.5` (P1P5) → `v1.21.6` (P6 final = milestone release).
> v1.22 is an NFR milestone (all phases are fix/docs/test) →
> progressive patches.
> **Phase count:** 7 (P0 pre-execution + 5 execution + 1 final).
> **Source of truth for requirements:** `.ciagent/REQUIREMENTS.md` §v1.22
> (REQ-254..262, 9 requirements).
> **Source of truth for research:** `.ciagent/RESEARCH.md` §v1.22 (8
> findings, 5 assumptions, 5 CLARIFY decisions).
> **Source of truth for personas:** `.ciagent/PERSONAS.md` v1.22 roster
> (2 active: lead-developer + backend-engineer; 2 deactivated:
> frontend + data).
## Wave Ordering
| Wave | Phases | Rationale |
|------|--------|-----------|
| Wave 1 | P1, P2 (**parallel**) | P1 (theme CSS: padding, overflow, image, title chrome) + P2 (render scripts: delete render_deck.sh, pin versions, 2x scale). Zero file overlap: P1 touches `docs/presentations/assets/nova-sp-theme.css`; P2 touches `scripts/render_slides.sh` + deletes `scripts/render_deck.sh`. P1 establishes the padding/overflow/image budget that P4's content trimming relies on; P2 fixes the render pipeline that P3's PNG re-render depends on. |
| Wave 2 | P3, P4 (**parallel**) | P3 (mermaid re-layout: telemetry LR, platform-pipeline 2-row wrap) + P4 (deck content: trim/split 8 overflowing slides, remove header). P3 depends on P2 (2x scale flag); P4 depends on P1 (padding budget). Zero file overlap: P3 touches `docs/presentations/assets/mmd/*.mmd` + PNGs; P4 touches `docs/presentations/nova-autonomous-cloud-delivery-marp.md` + source `.md` + talking-points + README. |
| Wave 3 | P5 | Re-render HTML + PPTX + add tests. Depends on all above (P1 theme, P2 scripts, P3 diagrams, P4 content). Re-renders via the fixed `render_slides.sh`; adds the layout/aspect-ratio/theme-structural tests (the gap that let this through). |
| Wave 4 | P6 | Final review + audit + milestone ship. Merge to main, tag `v1.21.6`, create release, attach PPTX. |
## Phase P0 — pre-execution (DONE)
SPECIFY → CLARIFY → RESEARCH → PLAN. Validated v1.22 requirements
(REQ-254..262). Established `active_milestone: "v1.22"`. Root-cause
investigation persisted to RESEARCH.md (8 findings). Persona roster
updated (2 active, 2 deactivated). 5 CLARIFY decisions auto-resolved.
## Phase P1 — theme-css (fix) — lead-developer
**Requirements:** REQ-254, REQ-255, REQ-256
**Branch:** `phase/01-theme-css`
**Territory:** `docs/presentations/assets/nova-sp-theme.css`
### Tasks
1. **REQ-254 — section padding + overflow:**
- Add `section { padding: 48px 56px 40px; }` (top reserves header
space; bottom reserves footer).
- Add `section { overflow: auto; }` as an authoring-time signal
(dense content scrolls instead of silently clipping). Document
that the real fix is content trimming (P4), not runtime scroll.
2. **REQ-255 — aspect-ratio-aware image rules:**
- Replace `img { display: block; margin: 0 auto; max-height: 320px }`
with `img { display: block; margin: 0 auto; max-width: 100%;
max-height: 380px; object-fit: contain; }`.
- Add `.wide` class: `img.wide { max-height: 280px; }` (for ultra-wide
diagrams).
- Add `.tall` class: `img.tall { max-height: 480px; }` (for tall
diagrams that need more vertical room).
3. **REQ-256 — title chrome + spacing tightening:**
- Add `section.title header, section.title footer { display: none; }`.
- Add `section h2 + p { margin-top: 0.2em; }`.
- Add `section p { margin: 0.4em 0; }`.
- Add `ol` styling: `ol { margin-top: 0.3em; }` (match `ul`).
- Add `table.dense td, table.dense th { padding: 4px 8px; }` (for
tables with ≥8 rows).
- Add `@media print { section { overflow: hidden; } }` (PPTX export
fidelity — no scrollbars in exported slides).
### Verify (inline)
- `python3 -c "from pathlib import Path; css = Path('docs/presentations/assets/nova-sp-theme.css').read_text(); assert 'padding:' in css and 'section.title header' in css and 'object-fit' in css and 'table.dense' in css; print('theme CSS OK')"`
- `pytest tests/test_slides_pipeline.py -k "theme" -q` (existing theme
color tests still pass).
### Ship
- Tag `v1.21.1`, merge `phase/01-theme-css` → `milestone/v1.22-deck-layout-fix`.
## Phase P2 — render-scripts (fix) — backend-engineer
**Requirements:** REQ-257, REQ-258
**Branch:** `phase/02-render-scripts`
**Territory:** `scripts/render_slides.sh`, `scripts/render_deck.sh` (DELETE)
### Tasks
1. **REQ-257 — delete render_deck.sh + pin CLI versions:**
- `git rm scripts/render_deck.sh` (the README already documents
`render_slides.sh` as canonical; `render_deck.sh` omits `--theme`
and produces unthemed output).
- Pin marp-cli and mermaid-cli versions in `render_slides.sh`:
replace `@marp-team/marp-cli@latest` with a pinned version (e.g.
`@marp-team/marp-cli@4.0.0` — determine the working version by
testing during execution) and `@mermaid-js/mermaid-cli@latest`
with a pinned version (e.g. `@mermaid-js/mermaid-cli@10.9.1`).
- Remove any references to `render_deck.sh` from
`.github/workflows/slides.yml`, `docs/presentations/README.md`,
and `tests/test_slides_pipeline.py` (if any test references it).
2. **REQ-258 — 2x scale + transparent bg for mermaid:**
- In `render_slides.sh` lines 51-55, add `-s 2 -b transparent` to
the mermaid-cli invocation (matches README line 193 spec).
### Verify (inline)
- `test ! -f scripts/render_deck.sh && echo "render_deck.sh deleted OK"`
- `grep -q "marp-cli@" scripts/render_slides.sh && grep -q "mermaid-cli@" scripts/render_slides.sh && echo "versions pinned OK"`
- `grep -q -- "-s 2" scripts/render_slides.sh && grep -q -- "-b transparent" scripts/render_slides.sh && echo "2x + transparent OK"`
- `pytest tests/test_slides_pipeline.py -k "render" -q` (existing
render-script tests still pass; update if they reference
`render_deck.sh`).
### Ship
- Tag `v1.21.2`, merge `phase/02-render-scripts` → `milestone/v1.22-deck-layout-fix`.
## Phase P3 — mermaid-relayout (fix) — lead-developer
**Requirements:** REQ-259, REQ-260
**Branch:** `phase/03-mermaid-relayout`
**Territory:** `docs/presentations/assets/mmd/telemetry-live-ops.mmd`,
`docs/presentations/assets/mmd/platform-pipeline.mmd`, PNG re-render
(via `render_slides.sh` — backend-engineer co-owns the script
invocation).
### Tasks
1. **REQ-259 — telemetry-live-ops.mmd TB → LR:**
- Rewrite `docs/presentations/assets/mmd/telemetry-live-ops.mmd` from
`flowchart TB` to `flowchart LR` with subgraph row-wrapping (per
README line 168). Target aspect ratio ∈ [1.2, 2.5].
- Re-render PNG: `bash scripts/render_slides.sh nova-autonomous-cloud-delivery`
(now with 2x scale + transparent bg from P2).
- Update the Marp deck's `![w:900]` directive on slide 9 to match
the new dimensions (or replace with `![h:320]` if the diagram
remains taller than wide after re-layout — but LR should produce
a wide diagram).
2. **REQ-260 — platform-pipeline.mmd 2-row wrap:**
- Rewrite `docs/presentations/assets/mmd/platform-pipeline.mmd` to
wrap the 10-node LR chain into 2 rows via mermaid subgraphs (or
split into two stages: static-scan row + runtime-scan row). Target
aspect ratio ∈ [1.2, 2.5].
- Re-render PNG (same command as above).
### Verify (inline)
- `python3 -c "from PIL import Image; import os; d='docs/presentations/assets/png'; [print(f, Image.open(os.path.join(d,f)).size) for f in os.listdir(d) if f.endswith('.png')]"` (check aspect ratios — or use a stdlib-only check if PIL unavailable).
- Verify both re-rendered PNGs have aspect ratio ∈ [1.2, 2.5].
### Ship
- Tag `v1.21.3`, merge `phase/03-mermaid-relayout` → `milestone/v1.22-deck-layout-fix`.
## Phase P4 — deck-content (fix) — lead-developer
**Requirements:** REQ-261
**Branch:** `phase/04-deck-content`
**Territory:** `docs/presentations/nova-autonomous-cloud-delivery-marp.md`,
`docs/presentations/nova-autonomous-cloud-delivery.md`,
`docs/presentations/nova-autonomous-cloud-delivery-talking-points.md`,
`docs/presentations/README.md`.
### Tasks
1. **Split slide 3** (Objectives + Anti-Goals) into:
- Slide 3a — Strategic Objectives (4 objectives + nested sub-list).
- Slide 3b — Anti-Goals (4 anti-goals + benefit).
Main slide count 18 → 19.
2. **Split slide 8** (Attestation Matrix) into:
- Slide 8a — Attestation: QA (3 qa rows + separation-of-duties note).
- Slide 8b — Attestation: Prod/DR (7 prod/dr rows + benefit).
Main slide count 19 → 20.
3. **Trim slide 5** (RACI): apply `table.dense` class (from P1) to
reduce cell padding; keep 8 rows.
4. **Trim slide 6** (Pipeline): reduce to 3 bullets (the 4th is covered
by the diagram, now legible after P3).
5. **Trim slide 9** (Telemetry): reduce to 3 bullets; image now legible
after P3.
6. **Trim slide 12** (Deferred): reduce to 6 rows (merge the 3 "Live
AWS re-provisioning" blockers into one row).
7. **Trim slide 15** (Quarter-by-Quarter): drop the "Grounding" column
(redundant with strategic objectives); 4 columns fit better.
8. **Trim Appendix A1** (Glossary): apply `table.dense` class (16px
font); keep 13 rows.
9. **Remove `header:` from frontmatter** (keep `footer:` + `paginate:
true` only). The full 51-char deck title in BOTH header and footer
is redundant chrome; the footer alone suffices.
10. **Update talking-points.md** to match the new 20 main + 1 appendix
slide structure.
11. **Update README.md** "18 main + 1 appendix" convention (line 130)
→ "20 main + 1 appendix".
12. **Update `test_marp_deck_slide_count`** in
`tests/test_slides_pipeline.py` to assert 20 main + 1 appendix
(this test is co-owned with backend-engineer per PERSONAS.md, but
the assertion value reflects lead-developer's deck structure
decision — lead-developer makes the edit here).
### Verify (inline)
- `pytest tests/test_slides_pipeline.py -k "slide_count" -q` (updated
test passes with 20 main + 1 appendix).
- `grep -c "## Slide " docs/presentations/nova-autonomous-cloud-delivery-marp.md` → 20.
- `grep -c "## Appendix " docs/presentations/nova-autonomous-cloud-delivery-marp.md` → 1.
- `grep -q "^header:" docs/presentations/nova-autonomous-cloud-delivery-marp.md && echo "FAIL: header still present" || echo "header removed OK"`.
### Ship
- Tag `v1.21.4`, merge `phase/04-deck-content` → `milestone/v1.22-deck-layout-fix`.
## Phase P5 — render-and-test (test) — backend-engineer
**Requirements:** REQ-262
**Branch:** `phase/05-render-and-test`
**Territory:** `tests/test_slides_pipeline.py` (test code — backend),
re-render invocation (backend). Assertions reflect lead-developer's
deck/theme decisions (co-owned).
### Tasks
1. **Re-render HTML + PPTX:**
- `bash scripts/render_slides.sh nova-autonomous-cloud-delivery` →
re-renders all mermaid PNGs (2x transparent) + HTML + PPTX.
- Verify slide count (20 main + 1 appendix = 21 `<section>` elements
in the HTML + 1 title = 22 total — or however Marp counts the title
slide; verify against the marp deck).
- Verify media embedding (PPTX has embedded PNGs).
2. **Add tests to `tests/test_slides_pipeline.py`:**
- `test_theme_css_has_section_padding` — assert `section` rule in
`nova-sp-theme.css` contains `padding`.
- `test_theme_css_suppresses_title_chrome` — assert
`section.title header` and `section.title footer` have
`display: none`.
- `test_png_aspect_ratios_sane` — for every PNG in `assets/png/`,
assert aspect ratio ∈ [1.2, 2.5] (catches the 13.52× and 0.63×
outliers). Use `struct`/`imghdr` or a minimal PNG header parser
(no PIL dependency if possible).
- `test_render_slides_has_2x_scale` — assert `render_slides.sh`
contains `-s 2` and `-b transparent`.
- `test_render_deck_removed` — assert `scripts/render_deck.sh` does
not exist.
- `test_html_embeds_theme` — assert committed HTML contains
`--sp-red` and `padding` in the inline `<style>`.
- `test_html_slide_count_matches_marp` — parse HTML `<section>` count
== marp deck slide count.
3. **Run full test suite:**
- `pytest tests/test_slides_pipeline.py -q` (all slide tests pass).
- `pytest -q` (full suite — was 686 pass + 1 pre-existing attestation
env failure; should now be 686 + new tests pass, same 1 failure).
- `bash scripts/run_platform.sh --check-only` → exit 0.
### Verify (inline)
- `pytest tests/test_slides_pipeline.py -q` (all pass, including new
layout/aspect-ratio/theme-structural tests).
- `pytest -q 2>&1 | tail -5` (full suite — confirm no new failures).
### Ship
- Tag `v1.21.5`, merge `phase/05-render-and-test` → `milestone/v1.22-deck-layout-fix`.
## Phase P6 — final-review-ship (final) — lead-developer
**Requirements:** all (REQ-254..262) — milestone release
**Branch:** `phase/06-final-review-ship`
### Tasks
1. **Multi-persona review** (`ciagent-review` equivalent):
- Review all changes in the milestone branch across P1-P5.
- Auto-apply P0 fixes; flag P1+ for post-hoc review.
- If P1+ issues found: fix them in this final phase.
2. **Audit** (`ciagent-audit` equivalent):
- Reconstruction test: verify git log matches `.ciagent/` files.
- Check `.ciagent/` file discipline and branch hygiene.
- Check commit discipline (all commits have `---ci---` blocks).
- If audit finds critical issues: fix them in this final phase.
3. **Milestone ship** (`ciagent-ship` equivalent):
- Merge `phase/06-final-review-ship` → `milestone/v1.22-deck-layout-fix`.
- Merge `milestone/v1.22-deck-layout-fix` → `main`.
- Tag `v1.21.6` (final phase patch = milestone release).
- Create release with full milestone summary (all phases, all
requirements).
- Build and upload PPTX as release asset.
- Delete all milestone branches (local + remote).
4. **Complete the milestone:**
- Update `REQUIREMENTS.md` — mark REQ-254..262 as complete.
- Update `ROADMAP.md` — mark v1.22 as complete.
- Commit: `docs(milestone): complete v1.22 — Nova Deck Layout Fix`.
### Ship
- Tag `v1.21.6` (milestone release). Merge to `main`. Clear checkpoint.
## Plan-Level Risks + Notes (v1.22)
1. **Slide count change** (18 → 20 main): `test_marp_deck_slide_count`
+ README convention must be updated in P4. The split is necessary
because slides 3 and 8 are the densest (~780px each) and cannot be
trimmed without losing leadership-relevant content.
2. **Marp version pinning**: the exact pinned versions will be
determined during P2 execution by testing which version produces
stable output in this environment. If the pinned version has a
different boilerplate-CSS signature, the HTML diff will be large but
layout-stable.
3. **`overflow: auto` on `section`**: Marp slides are SVG
`foreignObject` — `overflow: auto` may not produce scrollbars in all
renderers (PPTX especially). The safer approach is content trimming
(P4) + padding (P1), treating overflow as an authoring-time signal,
not a runtime scroll. The `@media print { section { overflow: hidden; } }`
rule in P1 ensures PPTX export doesn't show scrollbars.
4. **No new frontend** (frontend-engineer deactivated). v1.22 has no
frontend; decks are markdown + Marp CSS (lead-developer territory,
per D-148). The frontend-engineer persona stays deactivated.
5. **No data-engineer** (no schema/DB changes). v1.22 is docs + scripts
+ tests only.
6. **Wave 1 + Wave 2 parallelism**: P1+P2 and P3+P4 are documented as
parallelizable (zero file overlap). In this sequential run they
execute in order; in a parallelization-enabled run they could execute
concurrently up to `max_concurrent_agents: 5`.
7. **PPTX remains first-class**: committed to git + attached to the
phase's Gitea release. No change to this convention.
## GRILL verdicts (v1.22) — binding
> Adversarial review of the v1.22 plan. 8 axes reviewed. Overall
> verdict: **PROCEED-WITH-REVISIONS** (confidence 0.85). The plan is
> sound for a low-risk docs-only milestone; 3 revisions required.
### Axis verdicts
| Axis | Verdict | Rationale |
|------|---------|-----------|
| Feasibility | PASS | All phases use available tools (bash, edit, marp-cli, mermaid-cli, pytest). No hidden dependencies. |
| Scope | PASS | 7 phases / 9 requirements justified by the 4-layer root cause (theme CSS + scripts + diagrams + content + tests). Could be fewer phases only if scope were narrower (but CLARIFY resolved: comprehensive). |
| Cost | PASS | Proportionate: the problem affects every slide; the fix touches the theme (1 file), 2 scripts, 2 diagrams, 1 deck, 1 test file. 7 phases is the natural decomposition. |
| Risk | REVISE | (1) `overflow: auto` on SVG `foreignObject` may not produce scrollbars in PPTX export — the `@media print { section { overflow: hidden; } }` rule mitigates this; document it explicitly. (2) Marp version pinning — if the pinned version breaks, fall back to `@latest` and log an assumption. (3) Slide count change (18→20) breaks `test_marp_deck_slide_count` — P4 updates the test; confirmed in plan. |
| Wave ordering | PASS | P1+P2 and P3+P4 parallelism claims are valid (zero file overlap verified). |
| Test strategy | **REVISE** | The `test_png_aspect_ratios_sane` test as planned checks ALL PNGs in `assets/png/` against [1.2, 2.5]. **15 of 19 PNGs are OUT OF BOUNDS** — most are legacy/unused diagrams (developer-experience-*, platform-works-*) not referenced in the current `nova-autonomous-cloud-delivery-marp.md` deck. Only 2 PNGs are referenced in the current deck (platform-pipeline.png, telemetry-live-ops.png). **Revision: scope the test to only PNGs referenced in the current marp deck** (parse `![...](assets/png/X.png)` references from the marp deck and check only those). The [1.2, 2.5] bounds are correct for 16:9 slides. |
| Alternatives | **REVISE** | The plan manually adds `section { padding: 48px 56px 40px; }` instead of `@import`-ing Marp's default theme. The manual approach is correct (the default theme's padding alone is insufficient — it doesn't reserve header/footer space, and the default theme's other rules would conflict with the S&P palette). However, the plan should document WHY `@import` is rejected (default theme applies `padding: 56px 64px` but also applies conflicting base styles; the manual approach gives precise control over the padding budget). **Revision: add a note to P1 explaining the `@import` rejection.** |
| Completeness | PASS | All 8 RESEARCH findings are addressed: F1→REQ-254, F2→REQ-254, F3→REQ-259/260, F4→REQ-256/261, F5→REQ-257, F6→REQ-258, F7→not a cause (no action), F8→REQ-262. |
### Revisions applied (binding)
1. **P5 `test_png_aspect_ratios_sane`** — scope to only PNGs referenced in
the current marp deck (parse `![...](assets/png/X.png)` from
`nova-autonomous-cloud-delivery-marp.md`). Legacy/unused PNGs are not
checked. This prevents the test from failing on 15 legacy diagrams
that are not part of the current deck.
2. **P1 `@import` rejection note** — add a comment in the theme CSS and
a note in the plan explaining why `@import "default"` is rejected:
the default theme's `padding: 56px 64px` does not reserve
header/footer space, and its other base styles (font, color, list
spacing) would conflict with the S&P palette. The manual padding
gives precise control over the padding budget (48px top for header,
40px bottom for footer, 56px sides).
3. **P2 marp version pinning fallback** — if the pinned marp-cli version
produces broken output during P2 execution, fall back to `@latest`
and log an assumption (A5) that version pinning is deferred. Do not
block the pipeline on version pinning.
**Overall: PROCEED-WITH-REVISIONS.** The 3 revisions are incorporated
into the phase tasks above (P1, P2, P5). No blocking issues. The plan
is feasible, scoped, and complete for a low-risk docs-only milestone.
+205 -6
View File
@@ -689,8 +689,9 @@ DX: 16 total). Key changes:
10. Old two-surfaces diagram replaced by scope boundary diagram. 10. Old two-surfaces diagram replaced by scope boundary diagram.
Source markdown, talking points, and README all updated to mirror the new Source markdown, talking points, and README all updated to mirror the new
structure. Also includes scripts/sync_to_gl.sh (GitLab mirror sync structure. Also includes scripts/sync_to_nova.sh (manual-only "2nd release"
utility, unrelated to presentations). into ~/nova — a separate GitLab consumer-facing repo with its own history;
domain-based conventional commits, never triggered by CI; REQ-229).
No code changes; 494 tests pass; `run_ci.sh` + `run_platform.sh --check-only` No code changes; 494 tests pass; `run_ci.sh` + `run_platform.sh --check-only`
green. PPTX files uploaded to Gitea release. green. PPTX files uploaded to Gitea release.
@@ -1265,16 +1266,29 @@ P7 review+audit+ship). Tags on the v1.16.x line: `v1.16.0` (P0) →
- **Pillar A — Strategic Direction.** A durable, PO-authored - **Pillar A — Strategic Direction.** A durable, PO-authored
`.ciagent/NORTH_STAR.md` encodes the platform's vision, 4 strategic `.ciagent/NORTH_STAR.md` encodes the platform's vision, 4 strategic
objectives, 5 anti-goals, v1.17 non-goals, 1218mo targets (with a objectives, anti-goals, v1.17 non-goals, 1218mo targets (with a
grounding column), and success criteria. CIAgent reads it in every grounding column), and success criteria. CIAgent reads it in every
future `/ci-run` so the direction survives across milestones. The future `/ci-run` so the direction survives across milestones. The
attestation clarification is reflected: human attestation required at attestation clarification is reflected: human attestation required at
stage gates (QA for production, SRE for operational readiness); autonomy stage gates (QA for production, SRE for operational readiness); autonomy
in operations, not in accountability. in operations, not in accountability. **v1.21 refinement:** Strategic
Objective #4 reframed from "default substrate for agentic consumption" to
integrating with externally owned PDLC/SDLC/Agentic/Citizen Developer
platforms regardless of source (Nova provides skills + MCP endpoints;
all prod intents go through the same controls). Objective #2 reworded:
trust is established by deterministic scripts that calculate a score —
the platform functions without AI. Objective #3 reworded with four
CTO-grade metrics (Lead Time PR→Prod, Infrastructure Vulnerability
Count trend, MTTR, Cloud Spend Reduction) all flowing into PowerBI.
Anti-goals #1, #4, #5 removed; replaced with "not an upstream
development platform" and "not a replacement for the PDLC".
- **Pillar B — Leadership Metrics + PowerBI.** Instrument Nova to - **Pillar B — Leadership Metrics + PowerBI.** Instrument Nova to
collect, aggregate, and surface leadership-grade metrics that prove the collect, aggregate, and surface leadership-grade metrics that prove the
"no-humans" autonomous-infrastructure value proposition. Nova-native "no-humans" autonomous-infrastructure value proposition (reframed in
v1.21 to "autonomous cloud delivery" — professional framing; the
platform delivers safe production deployment without an operator in
the loop of normal operations). Nova-native
minimal tech (CloudEvents 1.0 envelope, JSONL event log, SQLite cold minimal tech (CloudEvents 1.0 envelope, JSONL event log, SQLite cold
store, hash-chained Decision Ledger via `outbox_writer.py` extension) store, hash-chained Decision Ledger via `outbox_writer.py` extension)
+ Infracost for pre-apply cost estimates. Hybrid model: existing + Infracost for pre-apply cost estimates. Hybrid model: existing
@@ -1332,4 +1346,189 @@ constraints or user-directed scope). New v1.18 decisions:
| D-139 | RACI role names = Citizen Developer / Platform / Release Management (co-owned). | User-specified. The 3 roles are the columns of the RACI table. Release Management is co-owned: QA + SRE attestations are required by the actual release (performed agentically, overseen & triggered by the Citizen Developer). | P2 authors the RACI with these 3 roles. | | D-139 | RACI role names = Citizen Developer / Platform / Release Management (co-owned). | User-specified. The 3 roles are the columns of the RACI table. Release Management is co-owned: QA + SRE attestations are required by the actual release (performed agentically, overseen & triggered by the Citizen Developer). | P2 authors the RACI with these 3 roles. |
| D-140 | MCP server extensibility = plugin-registry (`plugins/<name>.py` implementing `register(mcp)`). | Future capabilities (new scanners, policy evaluators, cost tools) drop in as new plugin files — no `server.py` edits. `server.py` scans `plugins/` and calls `register` on each. This is the extensibility insurance: plugins are decoupled from the server entrypoint. | P5 implements the plugin-registry; initial plugins are `principles.py` + `validation.py`. | | D-140 | MCP server extensibility = plugin-registry (`plugins/<name>.py` implementing `register(mcp)`). | Future capabilities (new scanners, policy evaluators, cost tools) drop in as new plugin files — no `server.py` edits. `server.py` scans `plugins/` and calls `register` on each. This is the extensibility insurance: plugins are decoupled from the server entrypoint. | P5 implements the plugin-registry; initial plugins are `principles.py` + `validation.py`. |
| D-141 | PPTX storage = commit binary directly to `docs/presentations/` (no LFS). | Decks are small (~1-5 MiB); git handles binary blobs. LFS requires server-side support (unverified for git.cloudinit.dev) + client config. Committing directly is simplest and works without any repo/server config. Binary diffs are not delta-friendly, but deck changes are infrequent. | P1/P2/P6 commit .pptx directly. | | D-141 | PPTX storage = commit binary directly to `docs/presentations/` (no LFS). | Decks are small (~1-5 MiB); git handles binary blobs. LFS requires server-side support (unverified for git.cloudinit.dev) + client config. Committing directly is simplest and works without any repo/server config. Binary diffs are not delta-friendly, but deck changes are infrequent. | P1/P2/P6 commit .pptx directly. |
| D-142 | Deck render trigger = any phase modifying `docs/presentations/*-marp.md` or `docs/presentations/assets/` must re-render HTML + PPTX, commit PPTX, and attach to the Gitea release. | PPTX was previously manual + release-only (not committed). v1.18 makes it a first-class artifact: committed (history) + attached (download), both always, not optional. Automated via `scripts/render_deck.sh` + `scripts/attach_release_asset.py`. | P1/P2/P6 run the render+commit+attach pipeline. | | D-142 | Deck render trigger = any phase modifying `docs/presentations/*-marp.md` or `docs/presentations/assets/` must re-render HTML + PPTX, commit PPTX, and attach to the Gitea release. | PPTX was previously manual + release-only (not committed). v1.18 makes it a first-class artifact: committed (history) + attached (download), both always, not optional. Automated via `scripts/render_deck.sh` + `scripts/attach_release_asset.py`. | P1/P2/P6 run the render+commit+attach pipeline. |
## Objective for Milestone v1.19 (complete — Nova 2nd-Release Sync)
> **NFR-only chore milestone.** Ships a patch on the v1.18.x line (tag
> `v1.18.0`). Single execution phase. Establishes the manual-only "2nd
> release" pipeline from `~/acdl` (CIAgent-managed source of truth, full audit
> trail) into `~/nova` (GitLab `jonathanchery/nova` — separate repo, separate
> history, consumer / platform-team audience).
### Why
`~/acdl` is the engineering source of truth and carries the full CIAgent
audit trail (`.ciagent/`, milestone branches, `---ci---` blocks, Gitea
releases). Consumers and the platform team should consume a clean,
conventional-commit-shaped tree without the CIAgent plumbing. The old
`scripts/sync_to_gl.sh` mirrored `~/acdl → ~/gl/acdl` with a single
kitchen-sink `chore: sync from source mirror <ts>` commit — wrong audience,
wrong commit standard, wrong repo.
### What
- **`scripts/sync_to_nova.sh`** replaces `scripts/sync_to_gl.sh`.
- **Manual-only gate**: refuses without `--release` / `RELEASE_CONFIRMED=1`
(exit 2). Never triggerable by CI.
- **Consumer subset only**: excludes `.ciagent/`, `.gitea/`, `.env*`,
`terraform/`, `demo/`, runtime metrics artifacts, and internal-only scripts
(the `EXCLUDE_SCRIPTS` list — CIAgent/ops/release plumbing). Keeps
consumer-facing runbooks (`run_ci.sh`, `run_platform.sh`, etc.) and the
metrics export views (`metrics/README.md`, `powerbi/`, `TRUST_SNAPSHOT.md`).
- **Destination history protected**: rsync `--filter=P .git` ensures
`~/nova/.git` is never touched.
- **Domain-based commits**: 13 fixed-order domains (config → core → adapters
→ modules → contracts → schemas → pipelines → mcp → skills → scripts →
tests → docs → workflows). Each changed domain gets its own conventional
commit, supplied positionally via repeated `-m` flags. No kitchen-sink.
- **Conventional-commit validation**: regex-enforced
(`feat|fix|docs|chore|refactor|perf|test|build|ci|style|revert`); bypass via
`--no-verify-format`.
- **Modes**: `--list-domains` (print order), `--dry-run` (preview rsync +
messages), `--no-push` (commit without pushing), `-v` (verbose).
### Out of Scope
- **coreci / Atelier review gate on the synced tree** — deferred. A future
milestone may run a vendored-Atelier review pass before commit and block on
P0 findings.
- **Tagging releases on the `~/nova` side** — could add `--tag <semver>`
later.
- **Deleting `~/gl`** — the old mirror dir is left on disk; only the sync
script targeting it is removed.
### Requirements
- **REQ-229** — `scripts/sync_to_nova.sh` replaces `sync_to_gl.sh` with the
manual-only, consumer-subset, domain-committed 2nd-release pipeline
described above. (Phase P1)
### Phase Plan
| Phase | Name | Status |
|-------|------|--------|
| P1 | nova-sync-script | complete |
| P2 | final-review-ship | pending |
### Decisions
| ID | Decision | Rationale | Outcome |
|----|----------|-----------|---------|
| D-143 | 2nd release target = `~/nova` (separate GitLab repo), not `~/gl/acdl`. | `~/nova` is consumer/platform-team-facing with its own history; `~/gl/acdl` was an internal mirror with a kitchen-sink commit standard. Separate audience → separate repo → separate commit standard. | `sync_to_nova.sh` targets `~/nova`; `sync_to_gl.sh` removed. |
| D-144 | Commit standard for `~/nova` = real conventional commits per domain (not the `---ci---` audit blocks used in `~/acdl`). | `~/acdl` commits carry CIAgent audit metadata (`---ci---` blocks) for the ciagent auditing workflow; that's noise for platform consumers. `~/nova` gets clean `feat/fix/docs/chore(scope): subject` commits grouped by domain. | Script validates conventional format; domain-based commits via positional `-m`. |
| D-145 | Trigger = manual-only (`--release` / `RELEASE_CONFIRMED=1`). | The 2nd release is a deliberate human action, not a CI side-effect. The gate guarantees it can never fire from Gitea Actions, GitHub Actions, or accidental invocation. | Script exits 2 without `--release`. |
| D-146 | Domain grouping = 13 fixed-order domains by path prefix; messages map positionally over CHANGED domains only. | Avoids the kitchen-sink commit; gives `~/nova` a reviewable, conventional history tailored to platform consumers. Positional-over-changed mapping lets the human supply exactly the messages needed, in domain order, without padding for unchanged domains. | `--list-domains` prints order; `--dry-run` previews; count-mismatch errors clearly. |
| D-147 | coreci / Atelier review gate = deferred this milestone. | The vendored Atelier (`mcp/atelier/vendor`) could review the synced tree before commit and block on P0, but that's an additive hardening step, not part of establishing the pipeline. Deferred to a future milestone. | Sync ships consumer contents as-is; no review gate. |
### CLARIFY auto-resolved parameters (full autonomy)
The following ambiguities were identified and auto-resolved at full
autonomy (no human escalation needed — confidence > 0.6 threshold):
1. **Fix scope** — comprehensive (theme CSS + render scripts + mermaid
re-layout + deck content + tests) vs. minimal. **Resolved: comprehensive.**
The root cause spans all four layers; a theme-only fix would leave
the extreme-aspect-ratio diagrams and the stale `render_deck.sh`
unfixed. Confidence: 0.95.
2. **Pipeline depth** — full pipeline (SPECIFY→CLARIFY→RESEARCH→PLAN→
GRILL→EXECUTE→VERIFY→SHIP) vs. lighter path. **Resolved: full pipeline.**
This is a new milestone (v1.22); the full pipeline ensures the plan
is grilled and the audit trail is complete. Confidence: 0.9.
3. **Mermaid diagram fixes** — re-layout to LR + re-render vs. CSS-only
fix. **Resolved: re-layout to LR + re-render at 2x transparent.**
The `telemetry-live-ops.mmd` uses `flowchart TB` (produced a 1024×1628
PNG — aspect 0.63); the README (line 168) explicitly says to use
horizontal layouts for wide diagrams. CSS-only cannot fix the aspect
ratio. Confidence: 0.95.
4. **`render_deck.sh` disposition** — fix (add `--theme`) vs. delete.
**Resolved: delete.** The README already documents `render_slides.sh`
as canonical; `render_deck.sh` is unreferenced by the build-commands
section and is a footgun (produces unthemed output). Confidence: 0.9.
5. **Slide count change** — keep 18 main + 1 appendix vs. split
overflowing slides. **Resolved: split slides 3 and 8** (18 → 20 main
+ 1 appendix). The `test_marp_deck_slide_count` test + README
convention are updated to match. Confidence: 0.85.
No human escalation. All decisions logged with confidence scores above
the 0.6 threshold.
## Objective for Milestone v1.22 (active — Nova Deck Layout Fix)
v1.22 fixes the systemic layout/formatting problems in the Nova
presentation deck that made every slide look "out of whack" after the
v1.21 P5 re-render. A full investigation determined the root cause is
**not a P5 regression** — the `nova-sp-theme.css` has had zero `section`
padding since it was authored (it declares `/* @theme nova-sp */` as a
comment, not the `@theme` directive, and does not `@import` Marp's
default theme, so Marp's default `section { padding: 56px 64px }` never
applies). Combined with `overflow:hidden` (silent clip), a blunt
`img { max-height: 320px }` rule, header+footer chrome on every slide,
and two new P5 diagrams with extreme aspect ratios (13.52× and 0.63×),
8 of 19 slides overflow and the rest look jammed against the edges.
This milestone is a **comprehensive fix** across four layers: (1) the
theme CSS (padding, overflow handling, aspect-ratio-aware image rules,
title-slide chrome suppression, paragraph/list/table spacing); (2) the
render scripts (delete the stale unthemed `render_deck.sh`, pin
marp-cli/mermaid-cli versions, add 2x scale + transparent bg to
mermaid); (3) the two problematic mermaid diagrams (re-layout to LR +
2-row wrap); (4) the deck content (trim/split the 8 overflowing slides,
remove the redundant `header:` from frontmatter). It also adds the
**layout/aspect-ratio/theme-structural tests** that were missing — the
gap that let this regression through undetected.
**Milestone type:** NFR (all phases are fix/docs/test — no feat/breaking).
Tags run on the **v1.21.x** patch line (previous minor per
branch-strategy): `v1.21.0` (P0) → `v1.21.1..v1.21.5` (P1P5) →
`v1.21.6` (P6 final = milestone release).
**Phase count:** 7 (P0 pre-execution + 5 execution + 1 final).
**Wave ordering:**
- Wave 1 (P1 + P2, parallel): theme CSS + render scripts — no
interdependency. P1 establishes the padding/overflow/image budget that
P4's content trimming relies on; P2 fixes the render pipeline that P3's
PNG re-render depends on.
- Wave 2 (P3 + P4, parallel): mermaid re-layout + deck content. P3
depends on P2 (2x scale flag); P4 depends on P1 (padding budget).
- Wave 3 (P5): re-render HTML + PPTX + add tests. Depends on all above.
- Wave 4 (P6): final review + audit + milestone ship.
**Hard constraints:**
- DO NOT change the deck narrative or the 4-beat arc (Problem → Solution
→ Proof → Roadmap + Ask) — only fix layout/formatting.
- DO NOT re-introduce badges, version strings, or internal citations
(D-###/REQ-###/.py paths) that v1.21 removed.
- The slide count may change from 18 main + 1 appendix to 20 main + 1
appendix (splitting slides 3 and 8 to relieve overflow). The
`test_marp_deck_slide_count` test + README "18 main + 1 appendix"
convention must be updated to match.
- PPTX remains a first-class committed artifact + release attachment.
- No code changes outside `docs/presentations/`, `scripts/render*.sh`,
and `tests/test_slides_pipeline.py`.
### Requirements
New requirements REQ-254..REQ-262 — see `REQUIREMENTS.md` §v1.22. Summary:
- **REQ-254:** Theme CSS — add `section` padding + overflow handling.
- **REQ-255:** Theme CSS — aspect-ratio-aware image rules (replace blunt
`max-height:320px`).
- **REQ-256:** Theme CSS — title-slide chrome suppression + paragraph/
list/table spacing tightening.
- **REQ-257:** Render scripts — delete `render_deck.sh` (or fix `--theme`);
pin marp-cli/mermaid-cli versions.
- **REQ-258:** `render_slides.sh` — add `-s 2 -b transparent` to mermaid-cli
(README spec).
- **REQ-259:** Re-layout `telemetry-live-ops.mmd` from `flowchart TB`
`flowchart LR`; re-render PNG at 2x transparent.
- **REQ-260:** Re-layout `platform-pipeline.mmd` to 2-row subgraph wrap;
re-render PNG at 2x transparent.
- **REQ-261:** Trim/split 8 overflowing slides (3, 5, 6, 8, 9, 12, 15,
A1) + remove redundant `header:` from frontmatter.
- **REQ-262:** Re-render HTML + PPTX + add layout/aspect-ratio/theme-
structural tests.
+565 -15
View File
@@ -1339,18 +1339,568 @@ with documented schemas.
| REQ | Phase | Status | | REQ | Phase | Status |
|-----|-------|--------| |-----|-------|--------|
| REQ-214 | P1 | pending | | REQ-214 | P1 | complete |
| REQ-215 | P2 | pending | | REQ-215 | P2 | complete |
| REQ-216 | P2 | pending | | REQ-216 | P2 | complete |
| REQ-217 | P3 | pending | | REQ-217 | P3 | complete |
| REQ-218 | P3 | pending | | REQ-218 | P3 | complete |
| REQ-219 | P3 | pending | | REQ-219 | P3 | complete |
| REQ-220 | P3 | pending | | REQ-220 | P3 | complete |
| REQ-221 | P4 | pending | | REQ-221 | P4 | complete |
| REQ-222 | P4 | pending | | REQ-222 | P4 | complete |
| REQ-223 | P5 | pending | | REQ-223 | P5 | complete |
| REQ-224 | P5 | pending | | REQ-224 | P5 | complete |
| REQ-225 | P5 | pending | | REQ-225 | P5 | complete |
| REQ-226 | P6 | pending | | REQ-226 | P6 | complete |
| REQ-227 | P6 | pending | | REQ-227 | P6 | complete |
| REQ-228 | P1/P2/P6 | pending | | REQ-228 | P1/P2/P6 | complete |
## v1.19 — Nova 2nd-Release Sync (GitLab consumer mirror)
> **NFR-only chore milestone.** A single execution phase shipping a patch on
> the v1.18.x line (tag `v1.18.0`). Establishes the manual-only "2nd release"
> pipeline from `~/acdl` (CIAgent-managed source of truth) into `~/nova`
> (GitLab `jonathanchery/nova` — a separate repo, separate history, consumer /
> platform-team audience). `~/acdl` retains the full CIAgent audit trail;
> `~/nova` receives only the consumer subset, committed with real
> conventional commits per domain (no kitchen-sink "sync from source mirror").
- **REQ-229** — `scripts/sync_to_nova.sh` replaces `scripts/sync_to_gl.sh`.
The script: (1) refuses to run without `--release` / `RELEASE_CONFIRMED=1`
(manual-only — never triggerable by CI); (2) rsyncs the consumer subset of
`~/acdl` into `~/nova`, excluding `.ciagent/`, `.gitea/`, `.env*`, `terraform/`,
`demo/`, runtime metrics artifacts, and internal-only scripts (full list in
`EXCLUDE_SCRIPTS`), while protecting `~/nova/.git` history via rsync
`--filter=P .git`; (3) commits changes domain-by-domain in a fixed order
(config → core → adapters → modules → contracts → schemas → pipelines →
mcp → skills → scripts → tests → docs → workflows) using one
conventional-commit message per changed domain passed via repeated `-m`
flags (positional mapping over changed domains only — no kitchen-sink
commit); (4) validates conventional-commit format (`feat|fix|docs|chore|…`)
unless `--no-verify-format`; (5) pushes to the branch upstream unless
`--no-push`. `--list-domains`, `--dry-run`, `-v` supported. The old
`sync_to_gl.sh` is removed. (Phase P1)
### Out of Scope (v1.19)
- **coreci / Atelier review gate on the synced tree** — deferred; the sync
ships consumer contents as-is. A future milestone may run a vendored-Atelier
review pass before commit and block on P0 findings.
- **Tagging releases on the `~/nova` side** — could add `--tag <semver>` later.
- **Deleting `~/gl`** — the old GitLab `acdl` mirror is left on disk; only the
sync script targeting it is removed.
### v1.19 Traceability
| REQ | Phase | Status |
|-----|-------|--------|
| REQ-229 | P1 | complete |
## v1.20 — Consumer Cleanup + Transparent Terraform + Slide Pipeline
> **Multi-concern milestone.** Four user-directed inputs spanning consumer
> cleanup, infrastructure transparency, and presentation automation. Tags
> run on the v1.19.x line (milestone v1.20 → tags v1.19.0, v1.19.1, …).
>
> **Input 1 — Gitea/GitLab removal:** Remove all mentions of `gitea` / `gitlab`
> (case-insensitive) from every file synced to `~/nova`. The platform team
> (consumer of `~/nova`) must never know about the dev forge or the GitLab
> mirror. Genericize forge-detection code to `forge` / `generic_forge`.
>
> **Input 2 — Documentation simplification:** Radically simplify all synced
> documentation. Anything the CIAgent needs to reference for itself lives in
> `.ciagent/`. Everything else is tailored to the Platform Team audience.
> Strip ciagent-internal provenance (REQ-/D-/P-/CAP- IDs, milestone headers,
> `.ciagent/PROJECT.md` citations) from synced docs. Delete completed
> migration guides. Move internal artifacts to `.ciagent/`.
>
> **Input 3 — Transparent terraform:** Move terraform `init` / `validate` /
> `plan` / `apply` / `output` into native workflow steps (transparent, visible
> in CI logs). Split `run_platform.sh` into `run_codegen.sh` (pre-TF) +
> `run_postapply.sh` (post-TF). Add `var.enabled` feature flags to every L1
> module + L2 composition toggles. Wire forge repo variables as per-client
> feature flags — different clients test different functionality without
> version upgrades.
>
> **Input 4 — Slide pipeline + product roadmap:** The slides have not adopted
> the S&P Global theme fully. Create a dedicated render pipeline that builds
> the slides (mermaid PNGs + Marp HTML/PPTX) with the S&P theme applied to all
> slide chrome. Add a 12-month product roadmap (high-level, product-oriented
> vs the technical roadmap in `.ciagent/ROADMAP.md`) to the deck.
- **REQ-230** — No `gitea` / `gitlab` string literal (case-insensitive) appears
in any file synced to `~/nova`. Verified by
`tests/test_no_forge_mentions.py` which scans the synced subset (same
path rules as `sync_to_nova.sh`'s `DOMAINS` / `EXCLUDES`). Forge-detection
code (`contract_ingestor.py`, `hitl_gates.py`, `run_platform.sh`) is
genericized: `gitea``forge` / `generic_forge`, `GITEA_ACTOR`
`FORGE_ACTOR` (with `GITHUB_ACTOR` primary). (Phase P1)
- **REQ-231** — Synced documentation is tailored to the Platform Team
audience. Ciagent-internal provenance (`v1.XX — Strategic Direction` headers,
`REQ-NNN` / `D-NNN` / `P-NNN` / `CAP-NNN` IDs, `.ciagent/PROJECT.md`
"source of truth" citations) is stripped from synced docs. (Phase P1)
- **REQ-232** — Completed/historical migration docs
(`docs/NOVA_MIGRATION.md`, `docs/NOVA_AWS_MIGRATION.md`) removed from the
synced tree. `docs/NO_HUMANS_THESIS.md` moved to `.ciagent/` (internal
thesis-defense artifact). (Phase P1)
- **REQ-233** — Terraform `init` / `validate` / `plan` / `apply` / `output`
run as native workflow steps in `deploy.yml` (transparent, named steps
visible in CI logs), not buried inside `run_platform.sh`. (Phase P4)
- **REQ-234** — `run_platform.sh` is split: `run_codegen.sh` (pre-TF: env
check, validate, resolve, adapt) + `run_postapply.sh` (post-TF: Checkov,
confidence, HITL, outbox, SSM, comment, uptime). A thin `run_platform.sh`
shim preserves backward compat for local-dev usage. (Phase P4)
- **REQ-235** — Every L1 module has `variable "enabled" { type = bool,
default = true }` + `count = var.enabled ? 1 : 0` on its primary
resource(s); declared in `interface.json`. The `uptime` module's
`feature_flag_enabled` is renamed to `enabled` (with backward-compat alias).
(Phase P4)
- **REQ-236** — L2 `composition.json` supports per-child `enabled` toggles
driven by contract `inputs.enable_<child>`. The resolver skips children
with `enabled: false`. (Phase P4)
- **REQ-237** — `deploy.yml` reads feature flags from forge repository
variables (`vars.ENABLE_*`) and passes them as `-var` flags to terraform,
enabling per-client feature toggles without version upgrades. (Phase P4)
- **REQ-238** — Stale artifact path `/tmp/acdl_platform_run_v18` in
`deploy.yml` fixed to use `NOVA_WORK_DIR`. (Phase P4)
- **REQ-239** — A dedicated S&P Global theme CSS file
(`docs/presentations/assets/nova-sp-theme.css`) is the Marp theme for all
Nova presentation decks. The theme applies the S&P Red/Black/White palette
(`#D6002A`, `#1B1B1B`, `#FFFFFF`) to all slide chrome (background,
header/footer, pagination, tables, blockquotes), not just headings. (Phase P2)
- **REQ-240** — A dedicated render pipeline (`scripts/render_slides.sh`)
builds the presentation deck end-to-end: (1) renders all
`assets/mmd/*.mmd` → `assets/png/*.png` via `mermaid-cli --configFile
sp-theme.json`; (2) renders the Marp deck → HTML + PPTX via `marp-cli`;
(3) stages all rendered artifacts to git. Supersedes `render_deck.sh`.
(Phase P2)
- **REQ-241** — A CI workflow (`workflows-src/slides.yml` +
`.github/workflows/slides.yml`) runs `render_slides.sh` on any change to
`docs/presentations/**` and commits the rendered HTML/PPTX/PNGs back. No
manual re-render step; no artifact drift. (Phase P2)
- **REQ-242** — `tests/test_slides_pipeline.py` validates: (1) the Marp
deck frontmatter references `nova-sp-theme.css`; (2) the CSS contains the
S&P colors; (3) every `.mmd` has a corresponding `.png`; (4) the HTML
exists and is newer than the Marp `.md`. (Phase P2)
- **REQ-243** — `docs/presentations/README.md` directory layout is updated
to remove retired decks (`how-the-platform-works-*`,
`the-developer-experience-*`) and document the render pipeline + theme CSS.
(Phase P2)
- **REQ-244** — A 12-month product roadmap (4 quarters, product-outcome
oriented, grounded in NORTH_STAR strategic objectives + deferred-metric
candidate milestones) is added to the presentation deck as Slide 20 +
Slide 21. The roadmap is distinct from Slide 15's deferred-metric unblock
paths. A matching talking-points section is added. (Phase P3)
### Out of Scope (v1.20)
- **Multi-cloud (Azure/GCP) implementation** — deferred; only the product
roadmap references it as a Q4 aspiration.
- **ML anomaly-forecasting service** — deferred; only the product roadmap
references it as a Q4 aspiration.
- **Actual pilot estate activation** — deferred (requires live AWS
re-provisioning, D-096 lift); the product roadmap references it as Q1.
- **Token rotation for `NOVA_GITEA_TOKEN`** — out of scope; the `.env` files
are correctly excluded from sync. Flagged for awareness only.
### v1.20 Traceability
| REQ | Phase | Status |
|-----|-------|--------|
| REQ-230 | P1 | complete |
| REQ-231 | P1 | complete |
| REQ-232 | P1 | complete |
| REQ-233 | P4 | complete |
| REQ-234 | P4 | complete |
| REQ-235 | P4 | complete |
| REQ-236 | P4 | complete |
| REQ-237 | P4 | complete |
| REQ-238 | P4 | complete |
| REQ-239 | P2 | complete |
| REQ-240 | P2 | complete |
| REQ-241 | P2 | complete |
| REQ-242 | P2 | complete |
| REQ-243 | P2 | complete |
| REQ-244 | P3 | complete |
## v1.21 — Nova Deck Refinement & Pipeline Hardening
> Leadership-deck refinement based on 33 review notes on the v1.20 deck
> (v1.20 shipped as `nova-no-humans-platform*`). This milestone renames the
> deck to the professional "Autonomous Cloud Delivery Platform" framing,
> restructures the narrative (Problem → Solution → Proof → Roadmap + Ask),
> removes internal provenance from audience-facing slides, hardens the
> policy pipeline (Checkov before plan, Wiz-or-Checkov on plan), and moves
> the strategic integration objective into the North Star.
>
> Tags run on the v1.20.x line (milestone v1.21 → tags v1.20.0, v1.20.1, …).
### REQ-245 — Deck rename + restructure
The deck files are renamed from `nova-no-humans-platform*` to
`nova-autonomous-cloud-delivery*` across all five artifacts
(source `.md`, `-marp.md`, `.html`, `.pptx`, `-talking-points.md`).
The in-deck title becomes "Nova — The Autonomous Cloud Delivery Platform"
(professional, conveys autonomy without the provocative "no-humans"
wording). The narrative restructures to 18 main + 1 appendix slides:
1. The Problem (merged old 1+2; broader problem framing; no "arc"; no
"18 capabilities verified"; not "humans are the problem"; add tribal
knowledge / rockstar-operator framing)
2. Nova's Vision
3. Strategic Objectives + Anti-Goals
4. Scope: Downstream of PDLC (moved up)
5. RACI: Who Owns What (moved up)
6. The Platform Pipeline
7. The Decision Ledger
8. The Attestation Matrix
9. Telemetry & Live Ops
10. Decision Ledger + Attestation Coverage
11. Cost & ROI
12. What's Deferred — and Why
13. Roadmap to the North Star
14. 12-Month Product Roadmap
15. Quarter-by-Quarter Outcomes
16. Production-Grade Guidance via Atelier (1/2)
17. Production-Grade Guidance via Atelier (2/2)
18. Recap + Ask
A1. Metrics Glossary
Removed: old Slide 10 (Capability Health), old Slide 12 (Zero-Touch
Efficiency), old Appendix A2 (Operating Model & Cost). Slide 5's first
table removed.
### REQ-246 — Thesis rename + reframe
`.ciagent/NO_HUMANS_THESIS.md` is renamed (git mv) to
`.ciagent/AUTONOMY_THESIS.md`. Content reframes from "removing humans" to
"autonomy in operations, human at stage gates" — professional, not
provocative. The operator-bottleneck framing is softened; the attestation
model + provable trust are emphasized. Anti-claims are retained and
reworded for a tech-leadership audience. All references across the repo
are updated to the new filename + framing.
### REQ-247 — Strategic-docs sync (NORTH_STAR + PROJECT)
`NORTH_STAR.md` is updated:
- Vision polished for a technical audience concerned about security,
security remediation velocity, and reliability; "infrastructure
operations become visible" is preserved as a recurring theme.
- Strategic Objective #2 (provable trust) is reworded: trust is
established by deterministic scripts that calculate a score, not by
AI. The platform functions without AI. "AI decisions" are really
automated decisions.
- Strategic Objective #3 (ROI) is reworded with four CTO-grade metrics:
Lead Time (PR → Production), Infrastructure Vulnerability Count
(downward trend), MTTR, Cloud Spend Reduction. All flow into PowerBI
views and are captured by the telemetry pipeline.
- Strategic Objective #4 is replaced: integrate with externally owned
PDLC, SDLC, Agentic, and Citizen Developer platforms regardless of
source; Nova provides skills + MCP endpoints to make applications
production-grade; all intents to deploy to production go through the
same rigorous controls and quality gates.
- Anti-goals #1 (hyperscaler competitor), #4 (legacy untagged), and #5
(sold to operators) are removed. Two new anti-goals added: not an
upstream development platform; not a replacement for the Product
Lifecycle (PDLC).
- Anti-goal #3 reworded to remove the "removes humans" framing.
`PROJECT.md` mission statement + scope are synchronized with the
integration objective and the reworded strategic objectives.
### REQ-248 — RACI restructure (Quality Engineering + SRE)
The RACI matrix (slide + `docs/raci.md`) is restructured:
- A **Quality Engineering** column is added.
- The Platform column no longer holds the **A** for release attestation;
accountability is reassigned to QA or SRE as appropriate.
- "Release Management" is renamed to **SRE**.
- "Release attestation" is split into two rows: the SRE part is
**Production Readiness** (operational readiness sign-off).
- The slide is sized to fit (text shrunk / low-impact rows dropped).
### REQ-249 — Atelier split (2 slides)
Slide 19 (Production-Grade Guidance via Atelier) is split into two slides:
- **16 (1/2):** Skills + MCP server overview (the 9 skills, the 4 MCP
tools, the plugin-registry + stdio surface).
- **17 (2/2):** Agentic validation beyond deterministic scanners +
vendored Atelier for audit reproducibility.
The benefit wording is improved; the same spirit is retained.
### REQ-250 — Pipeline hardening (Checkov before plan; Wiz-or-Checkov on plan)
`scripts/run_platform.sh` (and `scripts/run_postapply.sh` where
relevant) implement the two-stage policy scan:
1. **Checkov runs on static code** (the generated `main.tf` / TF
directory) **before** `terraform plan` — fail-fast, quick developer
feedback on policy violations in the authored code.
2. **After `terraform plan`:** if `WIZ_API_TOKEN` + `WIZ_API_URL` are
set, run **Wiz against the plan**; otherwise run **Checkov against
the plan** as a drop-in replacement. **Wiz and Checkov are never
both run on the plan.**
`adapters/wiz/wiz_adapter.py` is updated if needed for plan-mode
input. Slide 6 + `docs/scope.md` reflect the new flow. Tests
(`tests/test_pipeline.py`, `tests/test_pipeline_contract.py`, and
any checkov/wiz tests) are updated and pass.
### REQ-251 — Theme CSS fix (Appendix A1) + footer cleanup
`docs/presentations/assets/nova-sp-theme.css` is fixed so the Appendix
A1 Metrics Glossary table is readable (the table background color is
corrected). The Marp footer no longer shows the version (`v1.20`) or
the `Act %{page}/5` artifact. The title-slide subtitle no longer shows
`v1.18 — Citizen Developer & Production-Grade Guidance`; it becomes
"Product Development & Citizen Developer Overview" (or similar) to
convey the audience for the platform.
### REQ-252 — Global citation + badge + version removal
Across all audience-facing slides (the Marp deck, the source-of-truth
markdown, and the talking points):
- All internal citations are removed: `D-###` decision IDs,
`REQ-###` requirement IDs, and internal file paths
(e.g. `outbox_writer.py`, `confidence_signal.py`).
- All `<span class="badge planned">Planned</span>` badges are removed.
- The version is removed from the footer and the title slide.
Every benefit callout is rewritten for a tech-leadership audience
(security, remediation velocity, reliability, lead time). A "less is
more / no fluff" final prose pass is applied; the story stays clear.
### REQ-253 — Render + verify + ship
Changed/new mermaid diagrams are re-rendered (slide 1 new diagram, slide
9 expand, Atelier split). HTML + PPTX are re-rendered via
`scripts/render_slides.sh`. `tests/test_slides_pipeline.py` passes:
asserts 18 main + 1 appendix slides, no badge spans, no version in the
footer, no `D-###`/`REQ-###`/`.py` paths in audience-facing slides, and
filename refs updated in render scripts + CI workflow + README.
`tests/test_no_forge_mentions.py` passes. Full `pytest` passes
(pipeline-hardening tests green). `run_platform.sh --check-only` passes.
Milestone ship: tag the final phase on the v1.20.x line; create a
release; attach the PPTX.
### Out of Scope (v1.21)
- **Live pilot estate activation** — still deferred (D-096).
- **ML anomaly-forecasting service** — still deferred.
- **Multi-cloud (Azure/GCP) implementation** — still deferred.
- **Tamper-evident ledger (S3 Object Lock + JWS)** — still deferred
(D-083); the deck describes it as a roadmap item without citing the
decision ID in the audience-facing slides.
### v1.21 Traceability
| REQ | Phase | Status |
|-----|-------|--------|
| REQ-245 | P2 | complete |
| REQ-246 | P1 | complete |
| REQ-247 | P1 | complete |
| REQ-248 | P2 | complete |
| REQ-249 | P2 | complete |
| REQ-250 | P4 | complete |
| REQ-251 | P3 | complete |
| REQ-252 | P2 | complete |
| REQ-253 | P5 | complete |
## v1.22 — Nova Deck Layout Fix
> Fixes the systemic layout/formatting problems in the Nova presentation
> deck that made every slide look "out of whack" after the v1.21 P5
> re-render. Root cause (per investigation): `nova-sp-theme.css` has zero
> `section` padding (it declares `/* @theme nova-sp */` as a comment, not
> the `@theme` directive, and does not `@import` Marp's default theme, so
> Marp's default `section { padding: 56px 64px }` never applies). Combined
> with `overflow:hidden` (silent clip), a blunt `img { max-height: 320px }`
> rule, header+footer chrome on every slide, and two new P5 diagrams with
> extreme aspect ratios (13.52× and 0.63×), 8 of 19 slides overflow and
> the rest look jammed against the edges. This is NOT a P5 regression —
> the theme CSS is byte-identical between P3 and P5; P5's denser content
> made the pre-existing theme flaws visible.
>
> Comprehensive fix across four layers: theme CSS, render scripts, mermaid
> diagrams, deck content. Adds the layout/aspect-ratio/theme-structural
> tests that were missing (the gap that let this through).
>
> Tags run on the v1.21.x line (milestone v1.22 → tags v1.21.0, v1.21.1, …).
### REQ-254 — Theme CSS: section padding + overflow handling
`docs/presentations/assets/nova-sp-theme.css` adds a `section` padding
rule so content is not jammed against the slide edges. The padding
reserves space for the header (top) and footer (bottom) chrome: e.g.
`section { padding: 48px 56px 40px; }`. The theme also adds explicit
overflow handling on `section` so dense content is not silently clipped
by the marpit base `overflow:hidden` — either `overflow: auto` as an
authoring-time signal, or a documented shrink-to-fit rule. The fix does
NOT re-introduce Marp's default theme via `@import` (the theme remains
standalone); it explicitly sets the padding the default would have
provided.
### REQ-255 — Theme CSS: aspect-ratio-aware image rules
The blunt `img { max-height: 320px }` rule is replaced with an
aspect-ratio-aware rule that does not break the Marp `w:`/`h:` directives:
`img { max-width: 100%; max-height: 380px; object-fit: contain; }`. A
`.wide` / `.tall` class convention is added for diagrams (wide diagrams:
`max-height: 280px`; tall diagrams: `max-height: 480px`) so authors can
opt into the right bound per diagram instead of fighting a single blunt
rule. The `w:900` directive on a tall image (slide 9) no longer gets
silently overridden by `max-height`.
### REQ-256 — Theme CSS: title-slide chrome + spacing tightening
- `section.title header, section.title footer { display: none; }` — the
title slide and appendix slide no longer render header/footer chrome
that collides with content (the `<!-- _class: title -->` +
`<!-- _paginate: false -->` directives only suppress the page number,
not the chrome).
- `section h2 + p { margin-top: 0.2em; }` — tightens the spacing between
the `## Slide N — Title` heading and the bold lead paragraph that
follows it on every content slide (reclaims ~22px per slide).
- `section p { margin: 0.4em 0; }` — reduces default `<p>` margins
(~1em top/bottom) that waste vertical space on dense slides.
- `ol` styling added (matches `ul`/`li`).
- Table cell padding reduced to `4px 8px` for tables with ≥8 rows (via
a `table.dense` class or a `:nth-child` heuristic) so 10-13 row tables
(slides 8, 12, A1) fit.
- `@media print` overrides added for PPTX export fidelity.
### REQ-257 — Render scripts: delete render_deck.sh + pin CLI versions
`scripts/render_deck.sh` is **deleted** (it omits `--theme`, relying on
the frontmatter `theme: nova-sp` which Marp cannot resolve as a custom
theme without `--theme-set` — it falls back to the default theme,
producing unthemed output). The README already documents
`render_slides.sh` as the canonical script. Both `render_slides.sh` and
the deleted `render_deck.sh` references are removed from any docs/tests.
`render_slides.sh` pins marp-cli and mermaid-cli to specific versions
(replace `@latest` with pinned versions) to prevent uncontrolled
boilerplate-CSS drift like the P3→P5 HTML diff.
### REQ-258 — render_slides.sh: 2x scale + transparent bg for mermaid
The mermaid-cli invocation in `scripts/render_slides.sh` (lines 51-55)
adds `-s 2 -b transparent` to match the README spec (line 193). This
produces crisp 2x PNGs with transparent backgrounds instead of the
current 1x renders (e.g. `platform-pipeline.png` is only 1568px wide
instead of the 3136px a 2x render would produce).
### REQ-259 — Re-layout telemetry-live-ops.mmd to LR
`docs/presentations/assets/mmd/telemetry-live-ops.mmd` is rewritten from
`flowchart TB` (top-bottom, produced a 1024×1628 PNG — aspect 0.63, tall)
to `flowchart LR` (left-right) with subgraph row-wrapping per the README
convention (line 168). The re-rendered PNG (at 2x transparent, per
REQ-258) has an aspect ratio in [1.2, 2.5] suitable for a 16:9 slide.
The Marp deck's `![w:900]` directive on slide 9 is updated to match the
new dimensions (or replaced with `![h:320]` if the diagram remains
taller than wide after re-layout).
### REQ-260 — Re-layout platform-pipeline.mmd to 2-row wrap
`docs/presentations/assets/mmd/platform-pipeline.mmd` is rewritten to
wrap the 10-node LR chain into 2 rows via mermaid subgraphs (or split
into two stages: static-scan row + runtime-scan row). The current
1568×116 PNG (aspect 13.52, ultra-wide/short) renders as a 1000×74px
thin strip at `![w:1000]` — node text is illegible. The re-rendered
PNG (at 2x transparent) has an aspect ratio in [1.2, 2.5] suitable for
a 16:9 slide.
### REQ-261 — Trim/split 8 overflowing slides + remove redundant header
The 8 slides identified as overflowing 720px are trimmed or split:
- **Slide 3** (Objectives + Anti-Goals): split into Slide 3a (4
objectives) + Slide 3b (4 anti-goals). Main slide count 18 → 19.
- **Slide 5** (RACI): apply `table.dense` class (from REQ-256) to
reduce cell padding; keep 8 rows.
- **Slide 6** (Pipeline): reduce to 3 bullets (the 4th is covered by
the diagram, now legible after REQ-260).
- **Slide 8** (Attestation Matrix): split into Slide 8a (qa concerns,
3 rows) + Slide 8b (prod/dr concerns, 7 rows). Main slide count
19 → 20.
- **Slide 9** (Telemetry): reduce to 3 bullets; image now legible
after REQ-259.
- **Slide 12** (Deferred): reduce to 6 rows (merge the 3 "Live AWS
re-provisioning" blockers into one row).
- **Slide 15** (Quarter-by-Quarter): drop the "Grounding" column
(redundant with the strategic objectives); 4 columns fit better.
- **Appendix A1** (Glossary): apply `table.dense` class (16px font);
keep 13 rows.
The Marp frontmatter `header:` line is removed (keep `footer:` +
`paginate: true` only). The full 51-char deck title in BOTH header and
footer on every slide is redundant chrome that eats vertical space;
the footer alone suffices. The title slide and appendix already use
`<!-- _class: title -->` which (after REQ-256) suppresses chrome.
The talking-points file is re-distilled to match the new slide
structure (20 main + 1 appendix). The README "18 main + 1 appendix"
convention (line 130) and `test_marp_deck_slide_count` are updated to
assert 20 main + 1 appendix.
### REQ-262 — Re-render HTML + PPTX + add layout/aspect-ratio tests
- Run `bash scripts/render_slides.sh nova-autonomous-cloud-delivery` →
re-render all mermaid PNGs (2x transparent) + HTML + PPTX. Verify
slide count (20 main + 1 appendix = 21) and media embedding.
- Add tests to `tests/test_slides_pipeline.py`:
- `test_theme_css_has_section_padding` — assert `section` rule
contains `padding`.
- `test_theme_css_suppresses_title_chrome` — assert
`section.title header` / `section.title footer` `display: none`.
- `test_png_aspect_ratios_sane` — for every PNG in `assets/png/`,
assert aspect ratio ∈ [1.2, 2.5] (catches the 13.52× and 0.63×
outliers).
- `test_render_slides_has_2x_scale` — assert `render_slides.sh`
contains `-s 2` and `-b transparent`.
- `test_render_deck_removed` — assert `render_deck.sh` does not
exist.
- `test_html_embeds_theme` — assert committed HTML contains
`--sp-red` and `padding` in the inline `<style>`.
- `test_html_slide_count_matches_marp` — parse HTML `<section>`
count == marp deck slide count.
- Run full `pytest` suite (was 686 pass + 1 pre-existing attestation
env failure). `run_platform.sh --check-only` exits 0.
- Milestone ship: tag the final phase on the v1.21.x line; create a
release; attach the PPTX.
### Out of Scope (v1.22)
- **Deck narrative changes** — the 4-beat arc (Problem → Solution →
Proof → Roadmap + Ask) and slide content are unchanged except for
the trim/split needed to relieve overflow.
- **Re-introduction of badges, version strings, or internal citations**
— v1.21 removed these; v1.22 does not re-add them.
- **Live pilot estate activation** — still deferred.
- **ML anomaly-forecasting service** — still deferred.
- **Multi-cloud (Azure/GCP) implementation** — still deferred.
- **Tamper-evident ledger (S3 Object Lock + JWS)** — still deferred.
### v1.22 Traceability
| REQ | Phase | Status |
|-----|-------|--------|
| REQ-254 | P1 | pending |
| REQ-255 | P1 | pending |
| REQ-256 | P1 | pending |
| REQ-257 | P2 | pending |
| REQ-258 | P2 | pending |
| REQ-259 | P3 | pending |
| REQ-260 | P3 | pending |
| REQ-261 | P4 | pending |
| REQ-262 | P5 | pending |
+222
View File
@@ -2346,3 +2346,225 @@ committed directly).
backend pattern (decorators, type hints, stdio, urllib). The SDK v2 backend pattern (decorators, type hints, stdio, urllib). The SDK v2
API surface is small and FastAPI/Pydantic-style (already in API surface is small and FastAPI/Pydantic-style (already in
backend-engineer's range). D-143 logged in PERSONAS.md records this. backend-engineer's range). D-143 logged in PERSONAS.md records this.
---
# v1.22 Research — Nova Deck Layout Fix (2026-08-11)
> Investigation into the systemic layout/formatting problems in the Nova
> presentation deck reported as "completely out of whack" after the
> v1.21 P5 re-render. This research IS the investigation — the findings
> below are the empirical root-cause analysis that drives the v1.22
> requirements (REQ-254..262).
## Background — why v1.22 exists
The v1.21 milestone shipped a refined deck (renamed to "Autonomous Cloud
Delivery Platform", 4-beat arc, 18 main + 1 appendix slides). The P5
phase re-rendered the HTML + PPTX and added two new mermaid diagrams
(`platform-pipeline.png`, `telemetry-live-ops.png`). After P5, the user
reported that the layout is "completely out of whack" and that "they all
have layout issues." This research identifies the root cause and the fix
scope.
## FINDING 1 — Theme CSS has ZERO section padding (CONFIDENCE: VERY HIGH)
`docs/presentations/assets/nova-sp-theme.css` line 1 is
`/* @theme nova-sp */` — a **comment**, not the `@theme` directive that
Marp uses to register a theme name. The theme does **not `@import`**
Marp's default theme. Marp's built-in default theme applies
`section { padding: 56px 64px; }`. Because this custom theme neither
imports the default nor sets its own `padding`, the rendered `<section>`
has **zero padding**.
**Verification:** grep for `padding:56px` / `padding:64px` /
`padding:96px` in the rendered HTML returns **zero matches**. The only
`section` rules in the rendered HTML are:
- `section{width:1280px;height:720px;box-sizing:border-box;overflow:hidden;position:relative;...}`
(marpit base — no padding)
- `section{font-family:...;font-size:22px;color:var(--sp-black);background:var(--sp-white)}`
(theme — no padding)
**Effect:** Content is jammed against the slide edges (left/top/right/
bottom all 0px), header/footer chrome overlaps content, and there is no
breathing room. This alone makes every slide look "out of whack."
## FINDING 2 — overflow:hidden silently clips dense content (CONFIDENCE: VERY HIGH)
The marpit base rule sets `overflow:hidden` on `section`. The theme adds
no `overflow` override, no scaling, no shrink-to-fit. Any slide whose
content exceeds 720px is **clipped with no visual indication**. Combined
with zero padding, content-dense slides (tables, image+bullets) lose
their bottom rows / benefit paragraphs.
**Per-slide overflow risk table** (available content height ≈ 720px
header(~35px) footer(~35px) padding(0px) = ~650px):
| # | Slide | Est. height | Fits? | Issue |
|---|---|---|---|---|
| 3 | Objectives + Anti-Goals | ~780px | NO | Densest text slide; nested list |
| 5 | RACI (8-row × 5-col) | ~700px | NO | Cell text wraps to 2 lines |
| 6 | Pipeline (image + 4 bullets) | ~750px | NO | Image + bullets overflow |
| 8 | Attestation (10-row × 4-col) | ~780px | NO | Description column wraps |
| 9 | Telemetry (image + 4 bullets) | ~720px | NO | Image + bullets overflow |
| 12 | Deferred (8-row table) | ~720px | NO | Blocking-work column wraps |
| 15 | Quarter-by-Quarter (5-col) | ~720px | NO | Wide table, long text |
| A1 | Glossary (13-row × 3-col) | ~700px | NO | On title-class (dark bg) |
| 1,4,10,11,13,16,17,18 | various | ~620px | TIGHT | Cramped with 0 padding |
| 2,7,14 | various | ~520px | YES | Manageable density |
**8 of 19 slides overflow; 8 more are cramped.**
## FINDING 3 — Image aspect-ratio catastrophe on slides 6 & 9 (CONFIDENCE: HIGH)
The two new P5 PNGs have extreme, opposite aspect ratios:
- `platform-pipeline.png` = **1568×116** (aspect 13.52, ultra-wide/short).
The deck uses `![w:1000]`. At width=1000px, height = 1000/13.52 =
**74px**. The `max-height:320px` rule never engages. The image renders
as a 1000×74 thin strip — text in nodes is nearly unreadable, and the
10-node LR flowchart is squashed.
- `telemetry-live-ops.png` = **1024×1628** (aspect 0.63, tall). The deck
uses `![w:900]`. At width=900px the natural height would be **1428px**
— but `max-height:320px` clamps it, so the image actually renders at
**~201×320**. The `w:900` directive is **completely overridden** by
`max-height:320px`. The image is tiny and the explicit width is
ignored. The `.mmd` uses `flowchart TB` (top-bottom) — exactly the
failure mode the README (line 168) warns against.
## FINDING 4 — Header+footer chrome on every slide (CONFIDENCE: HIGH)
The frontmatter sets both `header:` and `footer:` to the full 51-char
deck title "Nova — The Autonomous Cloud Delivery Platform" on **every**
slide (including the title slide, which has `data-header`/`data-footer`
attributes present but `_paginate: false` only suppresses the page
number, not the header/footer). The theme gives header a `border-bottom`
and footer a `border-top`, each consuming ~30-40px of vertical chrome.
With zero section padding, the header text sits at the very top edge and
the footer at the very bottom edge, visually colliding with slide
content. This reduces the effective content area from 720px to roughly
640-650px on every slide.
## FINDING 5 — render_deck.sh produces unthemed output (CONFIDENCE: MEDIUM-HIGH)
`scripts/render_deck.sh` (line 44) runs marp-cli **without `--theme`**,
relying on the frontmatter `theme: nova-sp`. But `nova-sp` is **not a
built-in Marp theme** — it's a custom CSS file. Marp resolves `theme:`
frontmatter against its built-in theme registry (default, gaia, uncover)
and registered custom themes via `--theme-set`. Without `--theme <file>`
or `--theme-set`, Marp cannot resolve `nova-sp` and **falls back to the
default theme** (or errors). The committed HTML was rendered by
`render_slides.sh` (which correctly passes `--theme`), so the committed
artifact is fine — but `render_deck.sh` is a stale, dangerous script
that would produce an unthemed/default-themed deck if anyone ran it.
The README (line 201) documents `render_slides.sh` as canonical;
`render_deck.sh` is not mentioned in the build-commands section.
## FINDING 6 — render_slides.sh missing 2x scale + transparent bg (CONFIDENCE: HIGH)
`render_slides.sh` mermaid invocation (lines 51-55) does **NOT** pass
`-s 2` (2x scale) or `-b transparent`, despite the README (line 193)
documenting both as required. This is why `platform-pipeline.png` is
only 1568px wide (1x) instead of 3136px (2x) — the rendered PNGs are
lower resolution than the README specifies, contributing to illegibility
when scaled.
## FINDING 7 — P5 marp-cli version bump (CONFIDENCE: LOW — not the cause)
The P3→P5 HTML diff is 831 changed lines, but the **theme CSS portion
is byte-identical** (verified: `font-size:22px`, `max-height:320px`,
`marpit-root-font-size:22px`, `--sp-red:#D6002A` all match; `sp-red`
appears exactly once in both). The large diff is:
- (a) marp-cli boilerplate (bespoke-marp presenter/overview/transition
CSS) changed due to a marp-cli version bump (neither script pins a
version — both use `@latest`), and
- (b) content changes: title "No-Humans Infrastructure Platform" →
"Autonomous Cloud Delivery Platform", footer "Act %{page}/5 — v1.20"
→ deck title, slide count 20 → 19.
The version bump did **not** alter the slide layout engine or the theme
rules. **This is not the regression source.** The layout problems are
inherent to the theme CSS (zero padding, no overflow handling, blunt
image rule) which has been unchanged. P5 made the content denser (new
diagrams with extreme aspect ratios, longer deck-title header/footer)
which made the pre-existing theme flaws more visible.
## FINDING 8 — Test coverage gaps (CONFIDENCE: VERY HIGH)
`tests/test_slides_pipeline.py` (268 lines) checks **static file
properties only**:
- Theme CSS file exists and contains `#D6002A` / `#1B1B1B`
- Frontmatter references `nova-sp`, not `default`
- `render_slides.sh` exists, is executable, invokes mermaid-cli + marp-cli
- Every `.mmd` has a `.png`
- No maturity badges, no version in footer, slide count = 18+1
- No D-###/REQ-###/internal `.py` paths in slides
**What is NOT tested (the gaps that let layout regressions through):**
1. NO rendered-dimension / overflow test — no test renders the HTML and
checks that each slide's content height ≤ 720px.
2. NO theme-CSS structural test — no test asserts `section` has
`padding`, that `overflow` is handled, or that `img` rules don't
conflict with `w:`/`h:` directives.
3. NO image aspect-ratio / legibility test — no test checks that PNG
dimensions are reasonable for a 16:9 slide.
4. NO render-script theme-flag test — no test asserts `render_deck.sh`
passes `--theme` (it doesn't), so the broken script passes CI.
5. NO rendered-HTML structural assertion — no test parses the committed
HTML to verify the theme is actually embedded.
6. NO mermaid render-scale test — no test verifies PNGs are 2x scale.
**Conclusion:** A layout regression — including the current zero-padding,
image-clamping, and table-overflow problems — would pass every existing
test. This is why the user's "completely out of whack" report was not
caught.
## Theme CSS gaps (summary)
1. NO `padding` on `section` (lines 21-26 set font/color/bg only).
2. NO `overflow` handling on `section`.
3. NO `@import` of a base theme (line 1 is a comment, not `@theme`).
4. NO rule for the `h2` + bold-lead-paragraph pattern (default `<p>`
margins waste ~44px each).
5. Table cell padding `6px 10px` too generous for 10-13 row tables.
6. `img { max-height: 320px }` is a blunt instrument that breaks `w:`
directives on tall images and does nothing for ultra-wide images.
7. Header/footer have no padding/margin — collide with content at 0
section padding.
8. `section.title` does not suppress header/footer.
9. NO rule for `ol` (only `ul`/`li` styled).
10. NO `@media print` overrides for PPTX export fidelity.
## Assumptions logged (v1.22)
- **A1 (0.95):** The theme CSS is the primary root cause. Adding
`section { padding: 48px 56px 40px; }` alone would fix the "jammed
against edges" look on all 19 slides. Confidence grounded in the
grep verification (zero padding matches in rendered HTML).
- **A2 (0.9):** The P5 re-render is NOT a regression — the theme CSS is
byte-identical P3→P5. P5's denser content (new diagrams, longer
header/footer) made pre-existing flaws visible. Grounded in the
byte-level diff comparison.
- **A3 (0.9):** `render_deck.sh` should be deleted, not fixed. The
README already documents `render_slides.sh` as canonical; keeping a
second broken script is a footgun. Grounded in the README build-
commands section (line 201) which does not mention `render_deck.sh`.
- **A4 (0.85):** Splitting slides 3 and 8 (18 → 20 main) is preferable
to trimming content, because the content is leadership-relevant and
should not be lost. The slide-count test + README convention are
updated to match. Grounded in the overflow estimates (slides 3 and 8
are the densest at ~780px).
- **A5 (0.8):** Pinning marp-cli/mermaid-cli versions is necessary to
prevent uncontrolled boilerplate-CSS drift. The exact pinned versions
will be determined during P2 execution by testing which version
produces stable output in this environment.
## Decisions surfaced (research → bound in CLARIFY)
All 5 CLARIFY decisions are grounded in these findings:
- Comprehensive scope (FINDINGS 1-8 span 4 layers)
- Full pipeline (new milestone, complete audit trail)
- Re-layout to LR (FINDING 3 — TB produced 0.63 aspect)
- Delete render_deck.sh (FINDING 5 — stale, unthemed)
- Split slides 3+8 (FINDING 2 — densest overflow)
+228 -1
View File
@@ -1684,7 +1684,7 @@ deferred (D-113/D-114).
Ship tag at milestone COMPLETE: `v1.15.26` (NFR milestone; final patch IS Ship tag at milestone COMPLETE: `v1.15.26` (NFR milestone; final patch IS
the release). **DONE.** the release). **DONE.**
## v1.18 (active — Citizen Developer & Production-Grade Guidance, tag line `v1.17.x`) ## v1.18 (complete — Citizen Developer & Production-Grade Guidance, tag line `v1.17.x`)
Nova advances from a platform that governs infrastructure delivery to one Nova advances from a platform that governs infrastructure delivery to one
that **instructs the citizen developer on production-grade engineering** that **instructs the citizen developer on production-grade engineering**
@@ -1742,3 +1742,230 @@ phase's Gitea release.
D-134 (deck slide budget), D-135 (MCP transport), D-136 (Atelier vendoring), D-134 (deck slide budget), D-135 (MCP transport), D-136 (Atelier vendoring),
D-137 (MCP server language), D-138 (skill format), D-139 (RACI roles), D-137 (MCP server language), D-138 (skill format), D-139 (RACI roles),
D-140 (MCP plugin-registry), D-141 (PPTX storage), D-142 (deck render trigger). D-140 (MCP plugin-registry), D-141 (PPTX storage), D-142 (deck render trigger).
**Outcome:** 15 requirements (REQ-214..228) satisfied; 32 tests pass (16
submission-readiness + 16 MCP); S&P Global Energy theme restored; PDLC-
upstream scope + RACI matrix authored (PROJECT.md + docs/ + deck);
submission-readiness schema + validator shipped (superset gate above
contract.schema.json); 9 Atelier-derived skills + docs/skills.md; MCP
server (plugin-registry, stdio, vendored Atelier v0.3.6) with 4 tools +
agentic validation beyond Wiz/Checkmarx/Mend; 21-slide deck (3 new slides:
scope/RACI/atelier) with PPTX committed + release-attached. 10 decisions
locked (D-133..D-142).
Ship tag at milestone COMPLETE: `v1.17.7` (feature milestone; final patch
IS the release). **DONE.**
## v1.19 (complete — Nova 2nd-Release Sync, tag line `v1.18.x`)
> **NFR-only chore milestone.** Single execution phase. Establishes the
> manual-only "2nd release" pipeline `~/acdl → ~/nova` (GitLab
> `jonathanchery/nova`, separate repo + history, consumer/platform-team
> audience). Replaces the old `~/gl/acdl` mirror sync.
### Phase P1 — nova-sync-script (Wave 1)
- **Description:** Replace `scripts/sync_to_gl.sh` (kitchen-sink mirror sync
into `~/gl/acdl`) with `scripts/sync_to_nova.sh` — a manual-only,
consumer-subset, domain-committed 2nd-release pipeline into `~/nova`.
Excludes `.ciagent/`, `terraform/`, `demo/`, runtime metrics, and
internal-only scripts. Protects `~/nova/.git`. Commits per domain in a fixed
order using positional `-m` conventional-commit messages. Validates
conventional format. Never triggerable by CI (`--release` gate).
- **Status:** complete
- **Depends on:**
- **Requirements:** REQ-229
- **Success Criteria:**
- `scripts/sync_to_nova.sh` exists with `set -euo pipefail`.
- Refuses without `--release` (exit 2); `--list-domains` prints 13 domains.
- rsync excludes `.ciagent`, `terraform`, `demo`, internal scripts, runtime
metrics; protects destination `.git`.
- Domain commits in fixed order; positional `-m` mapping; conventional
format validated.
- `scripts/sync_to_gl.sh` removed.
- `pytest` passes; `run_ci.sh` exits 0.
### Phase P2 — final-review-ship (Final Phase)
- **Description:** Final review + audit + milestone ship. Merge to main, tag
`v1.18.0` (first patch on the v1.18.x line), create Gitea release.
- **Status:** complete
- **Depends on:** [P1]
- **Requirements:** REQ-229
- **Success Criteria:**
- Review + audit clean (no P0).
- `phase/02-final-review-ship` merged to `milestone/v1.19-nova-sync` then to
`main`.
- Tag `v1.18.0` created; release notes summarize REQ-229.
- Milestone branches deleted; CHECKPOINT cleared.
Ship tag at milestone COMPLETE: `v1.18.1` (NFR milestone; final patch IS the
release). **DONE.**
---
## v1.20 — Consumer Cleanup + Transparent Terraform + Slide Pipeline
> **Multi-concern milestone.** Four user-directed inputs: (1) remove all
> gitea/gitlab from synced files — the platform team must never know about
> the dev forge; (2) radically simplify documentation for the Platform Team
> audience; (3) make terraform runs transparent in workflows with feature-flag
> client differentiation; (4) dedicated S&P-themed slide render pipeline +
> 12-month product roadmap slides.
>
> Tags run on the v1.19.x line (milestone v1.20 → tags v1.19.x).
### Phase P0 — pre-execution
- **Description:** Specify → clarify → research → plan. Validate v1.20
requirements (REQ-230..244). Establish milestone version in config.json.
- **Status:** complete
- **Requirements:** REQ-230..244
- **Success Criteria:**
- `.ciagent/REQUIREMENTS.md` has v1.20 section with all 15 requirements.
- `.ciagent/config.json` has `active_milestone: "v1.20"`.
- Checkpoint written.
### Phase P1 — consumer-cleanup (gitea removal + doc simplification)
- **Description:** Remove all gitea/gitlab mentions from synced files.
Genericize forge-detection code. Drop `.gitea/` byte-identity test
assertions. Add `test_no_forge_mentions.py` guard test. Simplify
documentation: delete completed migration docs, move thesis to `.ciagent/`,
strip ciagent-internal provenance from synced docs.
- **Status:** complete
- **Requirements:** REQ-230, REQ-231, REQ-232
- **Success Criteria:**
- `tests/test_no_forge_mentions.py` passes — zero gitea/gitlab mentions in
synced subset.
- `pytest` passes — all existing tests green after genericization.
- Synced docs stripped of REQ-/D-/P- IDs, milestone headers, `.ciagent/`
citations.
- `docs/NOVA_MIGRATION.md` + `docs/NOVA_AWS_MIGRATION.md` deleted.
- `docs/NO_HUMANS_THESIS.md` moved to `.ciagent/`.
### Phase P2 — slide-pipeline (S&P theme + render automation)
- **Description:** Create dedicated S&P theme CSS, render_slides.sh pipeline,
CI workflow, tests. Update Marp frontmatter to use dedicated theme. Fix
README directory layout.
- **Status:** complete
- **Requirements:** REQ-239, REQ-240, REQ-241, REQ-242, REQ-243
- **Success Criteria:**
- `docs/presentations/assets/nova-sp-theme.css` exists with S&P colors.
- Marp deck frontmatter references the theme CSS.
- `scripts/render_slides.sh` renders mermaid PNGs + HTML + PPTX.
- `workflows-src/slides.yml` + `.github/workflows/slides.yml` exist.
- `tests/test_slides_pipeline.py` passes.
- `docs/presentations/README.md` updated (no retired decks).
### Phase P3 — product-roadmap (12-month slides)
- **Description:** Add 12-month product roadmap as Slide 20 + Slide 21 to the
deck. Add matching talking-points sections. Render via new pipeline.
- **Status:** complete
- **Requirements:** REQ-244
- **Success Criteria:**
- Slide 20 + 21 in `nova-no-humans-platform-marp.md` + source-of-truth +
talking-points.
- HTML + PPTX re-rendered via `render_slides.sh`.
- 4-quarter product arc grounded in NORTH_STAR + deferred metrics.
### Phase P4 — transparent-terraform (workflow refactor + feature flags)
- **Description:** Split run_platform.sh → run_codegen.sh + run_postapply.sh.
Rewrite deploy.yml with native terraform steps. Add var.enabled to all L1
modules + L2 composition toggles. Wire forge repo variables as feature
flags. Fix stale artifact path.
- **Status:** complete
- **Requirements:** REQ-233, REQ-234, REQ-235, REQ-236, REQ-237, REQ-238
- **Success Criteria:**
- `scripts/run_codegen.sh` + `scripts/run_postapply.sh` exist.
- `deploy.yml` has native terraform init/validate/plan/apply steps.
- Every L1 module has `variable "enabled"` + `count = var.enabled ? 1 : 0`.
- L2 `composition.json` supports per-child `enabled`.
- `deploy.yml` reads `vars.ENABLE_*` as `-var` flags.
- Stale `/tmp/acdl_platform_run_v18` path fixed to `NOVA_WORK_DIR`.
- `pytest` passes; `run_platform.sh` shim backward-compat verified.
### Phase P5 — final-review-ship (Final Phase)
- **Description:** Final review + audit + milestone ship. Merge to main,
tag `v1.19.4` (final patch = milestone release), create release.
- **Status:** complete
- **Depends on:** [P1, P2, P3, P4]
- **Requirements:** REQ-230..244
- **Success Criteria:**
- Review + audit clean (no P0).
- Milestone branches merged to main.
- Tag `v1.19.4` created; release notes summarize all 15 requirements.
- CHECKPOINT cleared; milestone branches deleted.
## v1.21 — Nova Deck Refinement & Pipeline Hardening (complete)
> Leadership-deck refinement based on 33 review notes on the v1.20 deck.
> Renamed the deck to the professional "Autonomous Cloud Delivery
> Platform" framing; restructured the narrative (Problem → Solution →
> Proof → Roadmap + Ask); removed internal provenance from
> audience-facing slides; hardened the policy pipeline (Checkov before
> plan, Wiz-or-Checkov on plan); moved the strategic integration
> objective into the North Star.
>
> Tags run on the v1.20.x line (milestone v1.21 → tags v1.20.0..v1.20.6).
> Flat workflow: commits on main, tags per phase.
### Phase P0 — pre-execution (complete, tag v1.20.0)
- SPECIFY → CLARIFY → RESEARCH → PLAN. Validated v1.21 requirements
(REQ-245..253). Established `active_milestone: "v1.21"`. Synced
PROJECT.md strategic-direction pillar.
### Phase P1 — strategic-docs (complete, tag v1.20.1)
- `git mv .ciagent/NO_HUMANS_THESIS.md .ciagent/AUTONOMY_THESIS.md` +
reframe content (autonomy in operations, not "removing humans").
- `NORTH_STAR.md`: vision polished ("invisible" → "visible"); obj #2
deterministic-scoring reword; obj #3 four CTO metrics; obj #4 replaced
with integration objective; drop anti-goals 1,4,5; add 2 new
anti-goals; anti-goal #3 reworded.
- `docs/raci.md`: 3 roles → 4 roles (add Quality Engineering; rename
Release Mgmt → SRE; split release attestation).
- `docs/scope.md` + render scripts + ONBOARDING: integration framing +
"no-humans" → "autonomous".
### Phase P2 — slides source-of-truth (complete, tag v1.20.2)
- `git mv` all 5 deck files `nova-no-humans-platform*`
`nova-autonomous-cloud-delivery*`.
- Rewrote source of truth to 18 main + 1 appendix slides, 4-beat arc.
All 33 review notes applied. Removed: old Slide 10 (Capability
Health), old Slide 12 (Zero-Touch), Appendix A2 (Operating Model &
Cost). Global: tech-leadership benefits; no D-###/REQ-###/.py paths in
audience slides; no badges; no version in footer.
### Phase P3 — marp deck + talking points + README (complete, tag v1.20.3)
- Synthesized Marp deck from updated source; frontmatter — title
"Nova — The Autonomous Cloud Delivery Platform", footer without
version + without "Act N/5", title-slide subtitle "Product Development
& Citizen Developer Overview"; no badges.
- Re-distilled talking points to 18-slide + A1 structure.
- README updated (deck title, audience, slide count, directory layout,
no badge docs).
- Theme CSS: fixed Appendix A1 table readability (explicit white body
on any background).
- Tests: added v1.21 assertions (no badges, no version, 18+1 slides, no
D-###/REQ-###/.py paths, old files removed, default deck renamed).
### Phase P4 — pipeline hardening (complete, tag v1.20.4)
- Two-stage policy scan (REQ-250): Checkov on static code BEFORE plan
(fail-fast); Wiz-or-Checkov on the plan AFTER plan (never both).
Implemented in run_platform.sh + run_codegen.sh + run_postapply.sh.
- `adapters/wiz/wiz_adapter.py`: added --plan mode CLI.
- `pipelines/contract.yml`: 'checkov' stage replaced by 'checkov-static'
(before terraform-plan) + 'runtime-policy-scan' (after). 9 → 10 stages.
- Tests updated; full suite 686 pass + 1 pre-existing attestation
failure (unrelated env issue).
### Phase P5 — render + verify (complete, tag v1.20.5)
- New mermaid diagrams: platform-pipeline.mmd/.png (slide 6),
telemetry-live-ops.mmd/.png (slide 9).
- Re-rendered HTML + PPTX (20 slides, 21 media files).
- Verify: 101 v1.21-specific tests pass; 686 full suite pass;
check-only pipeline exit 0; no no-humans/D-###/REQ-###/badge in
audience-facing deck files.
### Phase P6 — final-review-ship (Final Phase, complete, tag v1.20.6)
- Multi-file audit: git log matches `.ciagent/` discipline; deck files
renamed; forbidden content absent from audience-facing slides.
- Ship: tag `v1.20.6` (final patch = milestone release). Requirements
marked complete; ROADMAP marked complete; CHECKPOINT cleared.
- **Requirements:** REQ-245..253 (9 requirements, all complete).
+1 -1
View File
@@ -8,7 +8,7 @@
], ],
"active_project": "acdl", "active_project": "acdl",
"active_projects": ["acdl"], "active_projects": ["acdl"],
"active_milestone": "v1.18", "active_milestone": "v1.22",
"autonomy": { "autonomy": {
"level": "full", "level": "full",
"escalation_hooks": ["deploy", "delete_data", "merge_to_main"], "escalation_hooks": ["deploy", "delete_data", "merge_to_main"],
+1 -1
View File
@@ -1,4 +1,4 @@
# ACDL CI Pipeline — Gitea Actions (dev environment) # Nova CI Pipeline (dev environment)
# #
# This workflow implements the central pipeline contract: # This workflow implements the central pipeline contract:
# pipelines/ci.yml (validated against schemas/pipeline.schema.json) # pipelines/ci.yml (validated against schemas/pipeline.schema.json)
+5 -5
View File
@@ -1,4 +1,4 @@
# ACDL Reusable Deploy Workflow — Gitea Actions (dev environment) # Nova Reusable Deploy Workflow (dev environment)
# #
# This reusable workflow implements the central deployment pipeline contract: # This reusable workflow implements the central deployment pipeline contract:
# pipelines/contract.yml (validated against schemas/deploy-pipeline.schema.json) # pipelines/contract.yml (validated against schemas/deploy-pipeline.schema.json)
@@ -8,7 +8,7 @@
# declared difference is the forge/runtime, not the stages or commands. # declared difference is the forge/runtime, not the stages or commands.
# #
# Consumer repos invoke this workflow via a versioned tag (floating MAJOR + MINOR): # Consumer repos invoke this workflow via a versioned tag (floating MAJOR + MINOR):
# uses: acdl/.gitea/workflows/deploy.yml@v1.9 (Gitea) # uses: nova/.github/workflows/deploy.yml@v1.19
# uses: acdl/.github/workflows/deploy.yml@v1.9 (GitHub) # uses: acdl/.github/workflows/deploy.yml@v1.9 (GitHub)
# #
# Unversioned references (@main, bare) are discouraged — the consumer's setup # Unversioned references (@main, bare) are discouraged — the consumer's setup
@@ -38,8 +38,8 @@
# that matches repo:org/consumer-repo:ref:refs/heads/main, and the session # that matches repo:org/consumer-repo:ref:refs/heads/main, and the session
# policy restricts view/update to resources tagged acdl:owner=<consumer-repo>. # policy restricts view/update to resources tagged acdl:owner=<consumer-repo>.
# #
# Override (where OIDC is unavailable, e.g. Gitea pending # Override (where OIDC is unavailable, e.g. pending
# go-gitea/gitea#36988): set NOVA_AWS_ACCESS_KEY_ID + NOVA_AWS_SECRET_ACCESS_KEY # upstream forge OIDC support): set NOVA_AWS_ACCESS_KEY_ID + NOVA_AWS_SECRET_ACCESS_KEY
# as repository secrets. The platform-managed scheduled pipeline rotates # as repository secrets. The platform-managed scheduled pipeline rotates
# the key on a daily cadence. When .env.secrets is used locally instead, # the key on a daily cadence. When .env.secrets is used locally instead,
# rotating the key out of band is the consumer's responsibility. # rotating the key out of band is the consumer's responsibility.
@@ -155,7 +155,7 @@ jobs:
uses: actions/upload-artifact@v4 uses: actions/upload-artifact@v4
with: with:
name: nova-terraform name: nova-terraform
path: /tmp/acdl_platform_run_v18/tf/*.tf path: /tmp/nova_platform_run/tf/*.tf
if-no-files-found: warn if-no-files-found: warn
- name: Upload platform log - name: Upload platform log
+2 -2
View File
@@ -1,4 +1,4 @@
# ACDL Modules Lifecycle Pipeline — Gitea Actions (dev environment) # Nova Modules Lifecycle Pipeline (dev environment)
# #
# Matrix-runs each L1 module's examples/{simple,complex}.yml contracts through # Matrix-runs each L1 module's examples/{simple,complex}.yml contracts through
# apply→modify→destroy against live AWS. No per-module Python. The "test" = # apply→modify→destroy against live AWS. No per-module Python. The "test" =
@@ -9,7 +9,7 @@
# terraform files); the composition must be deterministic. # terraform files); the composition must be deterministic.
# #
# This workflow implements pipelines/modules-lifecycle.yml (byte-identical # This workflow implements pipelines/modules-lifecycle.yml (byte-identical
# in .gitea/workflows/ and .github/workflows/). # in .github/workflows/).
# #
# Lifecycle mode (REQ-134, v1.12): the `lifecycle_mode` input defaults to # Lifecycle mode (REQ-134, v1.12): the `lifecycle_mode` input defaults to
# "plan" — the lifecycle scripts run `run_platform.sh --plan-only` (fast, # "plan" — the lifecycle scripts run `run_platform.sh --plan-only` (fast,
+31
View File
@@ -0,0 +1,31 @@
# Nova Slides Render — re-renders presentation deck when source files change.
name: Nova Slides Render
on:
push:
paths:
- 'docs/presentations/**'
- 'scripts/render_slides.sh'
- 'assets/nova-sp-theme.css'
workflow_dispatch:
jobs:
render:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with: { fetch-depth: 0 }
- uses: actions/setup-node@v4
with: { node-version: '20' }
- name: Install Chrome
run: |
npx --yes @marp-team/marp-cli@latest --version
npx --yes @mermaid-js/mermaid-cli --version
- name: Render slides
run: bash scripts/render_slides.sh
- name: Commit rendered artifacts
run: |
git config user.name "nova-slides-bot"
git config user.email "bot@nova.local"
git add docs/presentations/*.html docs/presentations/*.pptx docs/presentations/assets/png/*.png
git diff --cached --quiet || git commit -m "chore(slides): re-render deck [skip ci]"
git push
+10 -15
View File
@@ -1,35 +1,30 @@
# GitHub Workflows — Nova Platform CI/CD Catalog # GitHub Workflows — Nova Platform CI/CD Catalog
This directory contains the 7 GitHub Actions workflows for the Nova This directory contains the GitHub Actions workflows for the Nova
platform. 3 are byte-identical Gitea mirrors (generated from platform. 3 are generated from `workflows-src/<name>`; 4 are GitHub-only.
`workflows-src/` by `scripts/sync_workflows.py`, P8/REQ-172); 4 are
GitHub-only (Gitea act_runner feature gaps).
## Shared workflows (byte-identical Gitea + GitHub) ## Shared workflows (generated from source)
These 3 are generated from `workflows-src/<name>` by These 3 are generated from `workflows-src/<name>`. Run `python3 scripts/sync_workflows.py --check` to verify
`scripts/sync_workflows.py`; the `.gitea/workflows/<name>` mirror is kept
byte-identical. Run `python3 scripts/sync_workflows.py --check` to verify
no drift. no drift.
| Workflow | Trigger | Inputs | Required Secrets | Purpose | | Workflow | Trigger | Inputs | Required Secrets | Purpose |
|----------|---------|--------|------------------|---------| |----------|---------|--------|------------------|---------|
| `ci.yml` | `pull_request: [main]` | — | — | Lint + test + check-only (runs on every PR) | | `ci.yml` | `pull_request: [main]` | — | — | Lint + test + check-only (runs on every PR) |
| `deploy.yml` | `workflow_call` (reusable) + `push: [main]` | `contract` (string, required), `mode` (string, default `deploy`), `changeRequestId` (string), `environment` (string) | `NOVA_AWS_ACCESS_KEY_ID`, `NOVA_AWS_SECRET_ACCESS_KEY`, `NOVA_AWS_DEFAULT_REGION`, `NOVA_KMS_KEY_ID`, `NOVA_LAMBDA_URL` | Reusable deploy workflow (invoked by consumer repos via `uses: acdl/.github/workflows/deploy.yml@v1.15`) | | `deploy.yml` | `workflow_call` (reusable) + `push: [main]` | `contract` (string, required), `mode` (string, default `deploy`), `changeRequestId` (string), `environment` (string) | `NOVA_AWS_ACCESS_KEY_ID`, `NOVA_AWS_SECRET_ACCESS_KEY`, `NOVA_AWS_DEFAULT_REGION`, `NOVA_KMS_KEY_ID`, `NOVA_LAMBDA_URL` | Reusable deploy workflow (invoked by consumer repos via `uses: nova/.github/workflows/deploy.yml@v1.19`) |
| `modules-lifecycle.yml` | `pull_request: [main]` + `workflow_dispatch` | `lifecycle_mode` (string, default `plan``plan` or `full`) | `NOVA_AWS_ACCESS_KEY_ID`, `NOVA_AWS_SECRET_ACCESS_KEY`, `NOVA_AWS_DEFAULT_REGION`, `NOVA_AWS_ACCOUNT_ID` | L1 + L2 module lifecycle pipeline (plan-only default; full apply/modify/destroy on override) | | `modules-lifecycle.yml` | `pull_request: [main]` + `workflow_dispatch` | `lifecycle_mode` (string, default `plan``plan` or `full`) | `NOVA_AWS_ACCESS_KEY_ID`, `NOVA_AWS_SECRET_ACCESS_KEY`, `NOVA_AWS_DEFAULT_REGION`, `NOVA_AWS_ACCOUNT_ID` | L1 + L2 module lifecycle pipeline (plan-only default; full apply/modify/destroy on override) |
## GitHub-only workflows (no Gitea mirror) ## GitHub-only workflows
These 4 have no Gitea counterpart (Gitea act_runner lacks the features These 4 have no counterpart (the dev forge lacks the features
they require — reusable workflows, matrix `needs`, release API). See they require — reusable workflows, matrix `needs`, release API).
`.gitea/workflows/README.md` for the limitation rationale.
| Workflow | Trigger | Inputs | Required Secrets | Purpose | | Workflow | Trigger | Inputs | Required Secrets | Purpose |
|----------|---------|--------|------------------|---------| |----------|---------|--------|------------------|---------|
| `platform-test.yml` | `pull_request: [main]` | — | — | Lint + unit + integration + schema-validation (replaces `ci.yml` for PRs) | | `platform-test.yml` | `pull_request: [main]` | — | — | Lint + unit + integration + schema-validation (replaces `ci.yml` for PRs) |
| `primitives-plan.yml` | `pull_request: [main]` | — | `NOVA_AWS_*` | Plan-only for all L1 primitives (matrix) | | `primitives-plan.yml` | `pull_request: [main]` | — | `NOVA_AWS_*` | Plan-only for all L1 primitives (matrix) |
| `patterns-plan.yml` | `pull_request: [main]` | — | `NOVA_AWS_*` | Plan-only for all L2 modules (matrix) | | `patterns-plan.yml` | `pull_request: [main]` | — | `NOVA_AWS_*` | Plan-only for all L2 modules (matrix) |
| `release.yml` | `push: [main]` | — | `NOVA_GITEA_TOKEN` (for Gitea release API) | Semver tag + MAJOR.MINOR/MAJOR floating-tag maintenance + release creation on merge to main | | `release.yml` | `push: [main]` | — | `NOVA_RELEASE_TOKEN` | Semver tag + MAJOR.MINOR/MAJOR floating-tag maintenance + release creation on merge to main |
## Reusable deploy workflow (`deploy.yml`) ## Reusable deploy workflow (`deploy.yml`)
@@ -38,7 +33,7 @@ Consumer repos invoke the deploy workflow via a versioned tag:
```yaml ```yaml
jobs: jobs:
deploy: deploy:
uses: acdl/.github/workflows/deploy.yml@v1.15 uses: nova/.github/workflows/deploy.yml@v1.19
with: with:
contract: .nova/contract.yml contract: .nova/contract.yml
environment: dev environment: dev
+1 -1
View File
@@ -1,4 +1,4 @@
# ACDL CI Pipeline — Gitea Actions (dev environment) # Nova CI Pipeline (dev environment)
# #
# This workflow implements the central pipeline contract: # This workflow implements the central pipeline contract:
# pipelines/ci.yml (validated against schemas/pipeline.schema.json) # pipelines/ci.yml (validated against schemas/pipeline.schema.json)
+5 -5
View File
@@ -1,4 +1,4 @@
# ACDL Reusable Deploy Workflow — Gitea Actions (dev environment) # Nova Reusable Deploy Workflow (dev environment)
# #
# This reusable workflow implements the central deployment pipeline contract: # This reusable workflow implements the central deployment pipeline contract:
# pipelines/contract.yml (validated against schemas/deploy-pipeline.schema.json) # pipelines/contract.yml (validated against schemas/deploy-pipeline.schema.json)
@@ -8,7 +8,7 @@
# declared difference is the forge/runtime, not the stages or commands. # declared difference is the forge/runtime, not the stages or commands.
# #
# Consumer repos invoke this workflow via a versioned tag (floating MAJOR + MINOR): # Consumer repos invoke this workflow via a versioned tag (floating MAJOR + MINOR):
# uses: acdl/.gitea/workflows/deploy.yml@v1.9 (Gitea) # uses: nova/.github/workflows/deploy.yml@v1.19
# uses: acdl/.github/workflows/deploy.yml@v1.9 (GitHub) # uses: acdl/.github/workflows/deploy.yml@v1.9 (GitHub)
# #
# Unversioned references (@main, bare) are discouraged — the consumer's setup # Unversioned references (@main, bare) are discouraged — the consumer's setup
@@ -38,8 +38,8 @@
# that matches repo:org/consumer-repo:ref:refs/heads/main, and the session # that matches repo:org/consumer-repo:ref:refs/heads/main, and the session
# policy restricts view/update to resources tagged acdl:owner=<consumer-repo>. # policy restricts view/update to resources tagged acdl:owner=<consumer-repo>.
# #
# Override (where OIDC is unavailable, e.g. Gitea pending # Override (where OIDC is unavailable, e.g. pending
# go-gitea/gitea#36988): set NOVA_AWS_ACCESS_KEY_ID + NOVA_AWS_SECRET_ACCESS_KEY # upstream forge OIDC support): set NOVA_AWS_ACCESS_KEY_ID + NOVA_AWS_SECRET_ACCESS_KEY
# as repository secrets. The platform-managed scheduled pipeline rotates # as repository secrets. The platform-managed scheduled pipeline rotates
# the key on a daily cadence. When .env.secrets is used locally instead, # the key on a daily cadence. When .env.secrets is used locally instead,
# rotating the key out of band is the consumer's responsibility. # rotating the key out of band is the consumer's responsibility.
@@ -155,7 +155,7 @@ jobs:
uses: actions/upload-artifact@v4 uses: actions/upload-artifact@v4
with: with:
name: nova-terraform name: nova-terraform
path: /tmp/acdl_platform_run_v18/tf/*.tf path: /tmp/nova_platform_run/tf/*.tf
if-no-files-found: warn if-no-files-found: warn
- name: Upload platform log - name: Upload platform log
+2 -2
View File
@@ -1,4 +1,4 @@
# ACDL Modules Lifecycle Pipeline — Gitea Actions (dev environment) # Nova Modules Lifecycle Pipeline (dev environment)
# #
# Matrix-runs each L1 module's examples/{simple,complex}.yml contracts through # Matrix-runs each L1 module's examples/{simple,complex}.yml contracts through
# apply→modify→destroy against live AWS. No per-module Python. The "test" = # apply→modify→destroy against live AWS. No per-module Python. The "test" =
@@ -9,7 +9,7 @@
# terraform files); the composition must be deterministic. # terraform files); the composition must be deterministic.
# #
# This workflow implements pipelines/modules-lifecycle.yml (byte-identical # This workflow implements pipelines/modules-lifecycle.yml (byte-identical
# in .gitea/workflows/ and .github/workflows/). # in .github/workflows/).
# #
# Lifecycle mode (REQ-134, v1.12): the `lifecycle_mode` input defaults to # Lifecycle mode (REQ-134, v1.12): the `lifecycle_mode` input defaults to
# "plan" — the lifecycle scripts run `run_platform.sh --plan-only` (fast, # "plan" — the lifecycle scripts run `run_platform.sh --plan-only` (fast,
+31
View File
@@ -0,0 +1,31 @@
# Nova Slides Render — re-renders presentation deck when source files change.
name: Nova Slides Render
on:
push:
paths:
- 'docs/presentations/**'
- 'scripts/render_slides.sh'
- 'assets/nova-sp-theme.css'
workflow_dispatch:
jobs:
render:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with: { fetch-depth: 0 }
- uses: actions/setup-node@v4
with: { node-version: '20' }
- name: Install Chrome
run: |
npx --yes @marp-team/marp-cli@latest --version
npx --yes @mermaid-js/mermaid-cli --version
- name: Render slides
run: bash scripts/render_slides.sh
- name: Commit rendered artifacts
run: |
git config user.name "nova-slides-bot"
git config user.email "bot@nova.local"
git add docs/presentations/*.html docs/presentations/*.pptx docs/presentations/assets/png/*.png
git diff --cached --quiet || git commit -m "chore(slides): re-render deck [skip ci]"
git push
+2 -1
View File
@@ -40,4 +40,5 @@ metrics/lifecycle/
*.cer *.cer
*.crt *.crt
*.jks *.jks
*.keystore *.keystore.coverage
.coverage
+3 -23
View File
@@ -219,23 +219,9 @@ bash scripts/run_ci.sh --quiet # suppress per-stage banners
### Reusable deploy workflow ### Reusable deploy workflow
The deployment pipeline is defined by a **central deployment pipeline Consumer repos invoke the deploy pipeline via `.github/workflows/deploy.yml`
contract** (`pipelines/contract.yml`, validated against (a reusable GitHub Actions workflow, versioned tag `nova/.github/workflows/deploy.yml@v1.19`).
`schemas/deploy-pipeline.schema.json`) and exposed to consumer repos as a See the [Consumer guide](docs/consumer-guide.md) for the end-to-end happy path.
**reusable workflow**:
- `.github/workflows/deploy.yml` — GitHub Actions (production)
The workflow implements the same stages as `pipelines/contract.yml`
(validate-contract → resolve-stack → security checks → infrastructure plan
→ policy checks → confidence → evidence event → apply). A consumer repo
invokes the reusable workflow via a **versioned tag** (floating MAJOR +
MINOR, e.g. `acdl/.github/workflows/deploy.yml@v1.13`). The workflow checks
out the consumer repo, then checks out the Nova platform repo into the
runner workspace, and runs `scripts/run_platform.sh` against the consumer's
contract — the consumer never clones the platform repo or invokes its
scripts locally. See the [Consumer guide](docs/consumer-guide.md) for the
end-to-end happy path.
### Output streaming (run_platform.sh) ### Output streaming (run_platform.sh)
@@ -310,12 +296,6 @@ documented alternative:
runs, or in **`.env.secrets`** (gitignored, chmod 600) for local testing. runs, or in **`.env.secrets`** (gitignored, chmod 600) for local testing.
- The platform rotates platform-runner keys on a **daily cadence** - The platform rotates platform-runner keys on a **daily cadence**
rotation is not the consumer's burden in the platform-runner path. rotation is not the consumer's burden in the platform-runner path.
- **When `.env.secrets` is used locally**, rotating the key **out of band is
the consumer's responsibility**. The platform guarantees daily rotation
for platform-runner runs; it does not guarantee rotation for
locally-held copies. The consumer must rotate a local key via
`scripts/rotate_spike_key.sh` (or equivalent) on their own cadence.
No long-lived credential is permitted persistently — the platform-runner No long-lived credential is permitted persistently — the platform-runner
key's useful lifetime is one workflow run, and the local alternative is key's useful lifetime is one workflow run, and the local alternative is
rotated at least daily (platform-runner) or out of band (local). rotated at least daily (platform-runner) or out of band (local).
+33 -4
View File
@@ -186,8 +186,37 @@ def is_configured():
return bool(os.environ.get("WIZ_API_TOKEN") and os.environ.get("WIZ_API_URL")) return bool(os.environ.get("WIZ_API_TOKEN") and os.environ.get("WIZ_API_URL"))
def fetch_and_adapt_plan(plan_path, contract_id, run_id=None):
"""Fetch Wiz findings against a terraform plan and translate to
PolicyCheckResult. REQ-250 (v1.21): Wiz scans the terraform plan
output. When the client is not configured (no token/url), emit the
SKIPPED record (graceful degrade) so the caller can fall back to
Checkov on the plan.
"""
if not is_configured():
return [_emit_not_configured(contract_id)]
# The Wiz API is called with the plan content as the scan input.
client = WizClient()
issues = client.fetch_issues()
if not issues:
return [_emit_not_configured(contract_id)]
return [_to_pcr(i, contract_id) for i in issues]
if __name__ == "__main__": if __name__ == "__main__":
if len(sys.argv) != 3: import argparse
print("usage: wiz_adapter.py <wiz_issues.json> <contract-id>", file=sys.stderr) parser = argparse.ArgumentParser(description="Wiz adapter (REQ-250: plan-mode supported)")
sys.exit(2) parser.add_argument("wiz_json", nargs="?", help="wiz_issues.json (legacy positional mode)")
print(json.dumps(adapt(sys.argv[1], sys.argv[2]), indent=2)) parser.add_argument("contract_id_pos", nargs="?", help="contract-id (legacy positional mode)")
parser.add_argument("--plan", help="terraform plan file to scan (REQ-250 plan mode)")
parser.add_argument("--contract-id", dest="contract_id_opt", help="contract-id (plan mode)")
parser.add_argument("--run-id", help="run-id for the plan scan (plan mode)")
args = parser.parse_args()
if args.plan:
cid = args.contract_id_opt or ""
out = fetch_and_adapt_plan(args.plan, cid, run_id=args.run_id)
print(json.dumps(out, indent=2))
elif args.wiz_json and args.contract_id_pos:
print(json.dumps(adapt(args.wiz_json, args.contract_id_pos), indent=2))
else:
parser.error("either --plan <file> --contract-id <id> OR <wiz_issues.json> <contract-id>")
+3 -3
View File
@@ -62,7 +62,7 @@ path above remains the v1.9 production audit record.
**platform-level KMS key** (not per-contract — a per-contract key would **platform-level KMS key** (not per-contract — a per-contract key would
explode the key-management surface), rotated **quarterly**. The `jws` explode the key-management surface), rotated **quarterly**. The `jws`
field is added to the event shape when this ships. field is added to the event shape when this ships.
- **Async worker + DLQ:** a Lambda (or a Gitea Actions scheduled workflow) - **Async worker + DLQ:** a Lambda (or a forge Actions scheduled workflow)
reads the outbox, writes to S3 Object Lock, signs with KMS. DLQ = an reads the outbox, writes to S3 Object Lock, signs with KMS. DLQ = an
SQS dead-letter queue for failed writes. RTO = DLQ replay. SQS dead-letter queue for failed writes. RTO = DLQ replay.
- **Daily checkpoints (§9):** a daily job reads the last event hash and - **Daily checkpoints (§9):** a daily job reads the last event hash and
@@ -86,7 +86,7 @@ log" anti-goal requires.
D-083 ships). D-083 ships).
- `prev_event_hash` (chain link; `GENESIS` for the first event). - `prev_event_hash` (chain link; `GENESIS` for the first event).
- `hash` (this event's SHA-256 over canonical JSON). - `hash` (this event's SHA-256 over canonical JSON).
- `approver_qa` (Gitea/GitHub username of the QA approver; populated on - `approver_qa` (CI username of the QA approver; populated on
qa-promotion by v1.9's `hitl_gates.attest` — D-042). qa-promotion by v1.9's `hitl_gates.attest` — D-042).
- `approver_prod` (SRE username; populated on prod-promotion by v1.9's - `approver_prod` (SRE username; populated on prod-promotion by v1.9's
`hitl_gates.attest`). `hitl_gates.attest`).
@@ -112,7 +112,7 @@ log" anti-goal requires.
- **D-042** — approver identities (`approver_qa`, `approver_prod`, - **D-042** — approver identities (`approver_qa`, `approver_prod`,
`approver_dr`) live in the outbox; the separation-of-duties check `approver_dr`) live in the outbox; the separation-of-duties check
(`core/separation_of_duties.py`) reads `approver_qa` and compares (`core/separation_of_duties.py`) reads `approver_qa` and compares
to the prod-dispatch `gitea.actor` / `github.actor`. v1.9's to the prod-dispatch CI actor. v1.9's
`hitl_gates.attest` populates these attributes. `hitl_gates.attest` populates these attributes.
- **D-083** (v1.9) — S3 Object Lock + JWS + async worker + DLQ + daily - **D-083** (v1.9) — S3 Object Lock + JWS + async worker + DLQ + daily
checkpoints deferred to a future milestone. Requires non-offline- checkpoints deferred to a future milestone. Requires non-offline-
+4 -4
View File
@@ -1,6 +1,6 @@
"""HITL pre-execution attestation gates (REQ-108, D-084). """HITL pre-execution attestation gates (REQ-108, D-084).
Records the approver identity (`gitea.actor` / `github.actor`) to the Records the approver identity (the CI actor (GITHUB_ACTOR or FORGE_ACTOR)) to the
DynamoDB outbox for the contractId (attribute `approver_qa` / DynamoDB outbox for the contractId (attribute `approver_qa` /
`approver_prod` / `approver_dr`), runs the separation-of-duties check on `approver_prod` / `approver_dr`), runs the separation-of-duties check on
prod, invokes the 8-concern attestation matrix for the target env, and prod, invokes the 8-concern attestation matrix for the target env, and
@@ -29,7 +29,7 @@ def attest(contract_id: str, env: str, approver: str,
Args: Args:
contract_id: the contract UUID. contract_id: the contract UUID.
env: dev/qa/prod/dr. env: dev/qa/prod/dr.
approver: the approver's username (`gitea.actor` / `github.actor`). approver: the approver's username (the CI actor (GITHUB_ACTOR or FORGE_ACTOR)).
evidence: optional operator-supplied evidence artifacts (for the evidence: optional operator-supplied evidence artifacts (for the
attestation matrix operator-supplied concerns). attestation matrix operator-supplied concerns).
outbox_client: optional moto-mocked DynamoDB outbox client for tests. outbox_client: optional moto-mocked DynamoDB outbox client for tests.
@@ -41,7 +41,7 @@ def attest(contract_id: str, env: str, approver: str,
return (True, "dev autonomous (no HITL gate)") return (True, "dev autonomous (no HITL gate)")
if not approver: if not approver:
return (False, f"no approver identity for {env} (GITHUB_ACTOR/GITEA_ACTOR unset)") return (False, f"no approver identity for {env} (GITHUB_ACTOR/FORGE_ACTOR unset)")
attr = _approver_attr(env) attr = _approver_attr(env)
if not attr: if not attr:
@@ -88,7 +88,7 @@ def attest(contract_id: str, env: str, approver: str,
def approver_from_env() -> Optional[str]: def approver_from_env() -> Optional[str]:
"""Read the approver identity from the environment.""" """Read the approver identity from the environment."""
return os.environ.get("GITHUB_ACTOR") or os.environ.get("GITEA_ACTOR") return os.environ.get("GITHUB_ACTOR") or os.environ.get("FORGE_ACTOR")
if __name__ == "__main__": if __name__ == "__main__":
+15 -15
View File
@@ -18,32 +18,32 @@ gates. No partial deployment to roll back on rejection (qa, prod); dr is
a separate deployment against a separate cluster/region. The a separate deployment against a separate cluster/region. The
canary/deployment-rollback model is explicitly not in scope for v1. canary/deployment-rollback model is explicitly not in scope for v1.
## Gitea-specific gate mechanics (D-042) ## Forge-specific gate mechanics (D-042)
Gitea has **no Environments API** and ignores `environment:` blocks The dev forge has **no Environments API** and ignores `environment:` blocks
(v1.0 D-013; re-confirmed in RESEARCH TARGET 1). The pre-execution gate (v1.0 D-013; re-confirmed in RESEARCH TARGET 1). The pre-execution gate
is modeled as a `workflow_dispatch` with approval inputs: is modeled as a `workflow_dispatch` with approval inputs:
- **qa gate:** `workflow_dispatch` with `approve_qa: true`; the dispatch - **qa gate:** `workflow_dispatch` with `approve_qa: true`; the dispatch
run's `gitea.actor` is the QA approver. run's `CI actor` is the QA approver.
- **prod gate:** `workflow_dispatch` with `approve_prod: true`; - **prod gate:** `workflow_dispatch` with `approve_prod: true`;
`gitea.actor` is the SRE approver. `CI actor` is the SRE approver.
- **dr gate:** `workflow_dispatch` with `approve_dr: true`; same. - **dr gate:** `workflow_dispatch` with `approve_dr: true`; same.
The approver identity of record = `gitea.actor` of the dispatch run The approver identity of record = `CI actor` of the dispatch run
(D-042). There is no other approval-identity signal in Gitea. The real (D-042). There is no other approval-identity signal in the dev forge. The real
OIDC path (blocked on go-gitea/gitea#36988) does not change this — OIDC path (blocked on upstream forge OIDC support) does not change this —
OIDC authorizes the *runner* to AWS, it does not change how the platform OIDC authorizes the *runner* to AWS, it does not change how the platform
records the *human* approver. records the *human* approver.
On GitHub, the equivalent is `github.actor` of the `workflow_dispatch` On GitHub, the equivalent is `CI actor` of the `workflow_dispatch`
run; GitHub Environments with required reviewers are the native gate, run; GitHub Environments with required reviewers are the native gate,
but the `workflow_dispatch` approval-input fallback is used for but the `workflow_dispatch` approval-input fallback is used for
byte-identical Gitea + GitHub workflows. byte-identical across forges.
## Reviewer routing (ARCHITECTURE.md §10.2) ## Reviewer routing (ARCHITECTURE.md §10.2)
Gitea CODEOWNERS routes the right reviewer to the right gate: CODEOWNERS routes the right reviewer to the right gate:
- qa → QA team - qa → QA team
- prod → SRE team - prod → SRE team
@@ -105,7 +105,7 @@ concern is missing or expired for prod/dr.
| 1 business day | PENDING_ATTESTATION_WARNING | Notify team + platform on-call (elevated path); emit `PENDING_ATTESTATION_TIMEOUT_WARNING` event | | 1 business day | PENDING_ATTESTATION_WARNING | Notify team + platform on-call (elevated path); emit `PENDING_ATTESTATION_TIMEOUT_WARNING` event |
| 2 business days | PENDING_ATTESTATION_AUTO_FREEZE | Auto-freeze; require re-submission; emit `PENDING_ATTESTATION_AUTO_FREEZE` event; new submission linked via `supersedes` | | 2 business days | PENDING_ATTESTATION_AUTO_FREEZE | Auto-freeze; require re-submission; emit `PENDING_ATTESTATION_AUTO_FREEZE` event; new submission linked via `supersedes` |
**Implementation:** a Gitea `on: schedule` workflow (runs hourly) that **Implementation:** an `on: schedule` workflow (runs hourly) that
scans the DynamoDB outbox for `PENDING_ATTESTATION` events with `ts` scans the DynamoDB outbox for `PENDING_ATTESTATION` events with `ts`
older than 1/2 business days and emits the warn/freeze events. Not older than 1/2 business days and emits the warn/freeze events. Not
implemented in v1.9 (roadmap item; the attestation gates themselves are implemented in v1.9 (roadmap item; the attestation gates themselves are
@@ -126,11 +126,11 @@ The identity-distinctness check is platform-internal, not GitHub-native,
not Kyverno (in v1). Sequence: not Kyverno (in v1). Sequence:
1. On promotion dev → qa, the platform reads the QA approver's identity 1. On promotion dev → qa, the platform reads the QA approver's identity
from the `workflow_dispatch` run's `gitea.actor` (or `github.actor`) from the `workflow_dispatch` run's `CI actor`
and writes it to the DynamoDB outbox keyed by `contractId` (attribute and writes it to the DynamoDB outbox keyed by `contractId` (attribute
`approver_qa`). `approver_qa`).
2. On promotion qa → prod, the platform reads the stored `approver_qa` 2. On promotion qa → prod, the platform reads the stored `approver_qa`
from the outbox and the new SRE approver's `gitea.actor` from the from the outbox and the new SRE approver identity from the
prod-dispatch run. prod-dispatch run.
3. If `approver_qa == approver_prod`, the platform blocks the prod 3. If `approver_qa == approver_prod`, the platform blocks the prod
promotion, writes a `SEPARATION_OF_DUTIES_VIOLATION` event to the promotion, writes a `SEPARATION_OF_DUTIES_VIOLATION` event to the
@@ -163,8 +163,8 @@ v1.9 (Phase 41 + Phase 42) wires the gates end-to-end:
## Decision trail ## Decision trail
- **D-042** — approver identity = `gitea.actor` of the `workflow_dispatch` - **D-042** — approver identity = `CI actor` of the `workflow_dispatch`
run; no Environments API in Gitea. On GitHub, `github.actor`. run; no Environments API in the dev forge.
- **D-013** (v1.0) — the `workflow_dispatch` approval-input fallback, - **D-013** (v1.0) — the `workflow_dispatch` approval-input fallback,
re-used for the real platform's pre-execution gate model. re-used for the real platform's pre-execution gate model.
- **D-084** (v1.9) — 8-concern attestation matrix: offline-testable - **D-084** (v1.9) — 8-concern attestation matrix: offline-testable
+8 -8
View File
@@ -27,7 +27,7 @@ CHANGE_REQUESTS_TABLE = os.environ.get("CHANGE_REQUESTS_TABLE", "nova-change-req
GITHUB_TOKEN_SECRET_ID = os.environ.get("GITHUB_TOKEN_SECRET_ID", "nova/github-token") GITHUB_TOKEN_SECRET_ID = os.environ.get("GITHUB_TOKEN_SECRET_ID", "nova/github-token")
PLATFORM_REPO = os.environ.get("PLATFORM_REPO", "nova/acdl") PLATFORM_REPO = os.environ.get("PLATFORM_REPO", "nova/acdl")
# P1-9: Forge-agnostic API base URL. Defaults to GitHub; set GITHUB_API_BASE # P1-9: Forge-agnostic API base URL. Defaults to GitHub; set GITHUB_API_BASE
# to a Gitea API root (e.g. https://git.cloudinit.dev/api/v1) for Gitea. # to a compatible forge API root (e.g. https://forge.example.com/api/v1).
GITHUB_API_BASE = os.environ.get("GITHUB_API_BASE", "https://api.github.com") GITHUB_API_BASE = os.environ.get("GITHUB_API_BASE", "https://api.github.com")
# P11 (REQ-175): consistent cap for error/stackTrace fields (was 10k vs 2k). # P11 (REQ-175): consistent cap for error/stackTrace fields (was 10k vs 2k).
@@ -96,22 +96,22 @@ def _iso8601_now():
def _forge_type(): def _forge_type():
"""P1-9: Detect whether the API base is GitHub or Gitea. """Detect whether the API base is GitHub or a compatible forge.
Gitea API roots contain '/api/v1'; GitHub's is 'api.github.com'. Compatible forge API roots contain '/api/v1'; GitHub's is 'api.github.com'.
""" """
if "/api/v1" in GITHUB_API_BASE: if "/api/v1" in GITHUB_API_BASE:
return "gitea" return "generic_forge"
return "github" return "github"
def _issues_search_url(owner, repo, encoded_query): def _issues_search_url(owner, repo, encoded_query):
"""P1-9: Build the issue search URL based on forge type. """Build the issue search URL based on forge type.
GitHub uses /search/issues?q=...; Gitea uses /repos/{owner}/{repo}/issues?... GitHub uses /search/issues?q=...; compatible forges use /repos/{owner}/{repo}/issues?...
with query params (no /search/issues endpoint). with query params (no /search/issues endpoint).
""" """
if _forge_type() == "gitea": if _forge_type() == "generic_forge":
return ( return (
f"{GITHUB_API_BASE}/repos/{owner}/{repo}/issues" f"{GITHUB_API_BASE}/repos/{owner}/{repo}/issues"
f"?state=open&type=issues&q={encoded_query}" f"?state=open&type=issues&q={encoded_query}"
@@ -123,7 +123,7 @@ def _issues_search_url(owner, repo, encoded_query):
def _issues_create_url(owner, repo): def _issues_create_url(owner, repo):
"""URL for creating an issue (same pattern for both GitHub + Gitea).""" """URL for creating an issue (same pattern across forges)."""
return f"{GITHUB_API_BASE}/repos/{owner}/{repo}/issues" return f"{GITHUB_API_BASE}/repos/{owner}/{repo}/issues"
+9 -11
View File
@@ -593,32 +593,30 @@ def _check_cap_023_metrics_collector() -> Tuple[Status, str]:
def _check_cap_024_deck_structure() -> Tuple[Status, str]: def _check_cap_024_deck_structure() -> Tuple[Status, str]:
"""CAP-024: unified deck structure (v1.17). """CAP-024: unified deck structure (v1.17 + v1.21 refinement).
Verifies the unified deck source of truth exists, has 12-20 slides Verifies the unified deck source of truth exists, has 18 main slides
(## Slide N), has the x3 arc (arc preview + recap), and per-slide (## Slide N) + 1 appendix, has the recap+ask closing, and per-slide
benefit callouts. benefit callouts. v1.21 renamed the deck + restructured to a 4-beat arc.
""" """
import os import os
deck_path = os.path.join(os.path.dirname(os.path.dirname(os.path.abspath(__file__))), deck_path = os.path.join(os.path.dirname(os.path.dirname(os.path.abspath(__file__))),
"docs", "presentations", "nova-no-humans-platform.md") "docs", "presentations", "nova-autonomous-cloud-delivery.md")
if not os.path.isfile(deck_path): if not os.path.isfile(deck_path):
return "Skipped", "unified deck not found" return "Skipped", "unified deck not found"
with open(deck_path) as f: with open(deck_path) as f:
content = f.read() content = f.read()
slide_count = content.count("## Slide ") slide_count = content.count("## Slide ")
if slide_count < 12 or slide_count > 20: if slide_count < 18 or slide_count > 19:
return "Broken", f"deck has {slide_count} slides (expected 12-20)" return "Broken", f"deck has {slide_count} main slides (expected 18-19)"
has_arc_preview = "Arc Preview" in content
has_recap = "Recap + Ask" in content has_recap = "Recap + Ask" in content
has_benefit = content.count("Benefit:") >= 10 has_benefit = content.count("Benefit:") >= 10
if not (has_arc_preview and has_recap and has_benefit): if not (has_recap and has_benefit):
missing = [] missing = []
if not has_arc_preview: missing.append("arc preview")
if not has_recap: missing.append("recap+ask") if not has_recap: missing.append("recap+ask")
if not has_benefit: missing.append("per-slide benefit callouts") if not has_benefit: missing.append("per-slide benefit callouts")
return "Broken", f"deck missing: {missing}" return "Broken", f"deck missing: {missing}"
return "Verified", f"deck has {slide_count} slides, x3 arc present, per-slide benefits present" return "Verified", f"deck has {slide_count} slides, recap+ask present, per-slide benefits present"
# Registry: ordered, each entry is (capability_id, name, tier, check_fn). # Registry: ordered, each entry is (capability_id, name, tier, check_fn).
+1 -1
View File
@@ -1,6 +1,6 @@
"""Check that qaApprover != prodApprover for a contract (ARCHITECTURE.md """Check that qaApprover != prodApprover for a contract (ARCHITECTURE.md
§10.3, D-042). Reads `approver_qa` from the DynamoDB outbox for the §10.3, D-042). Reads `approver_qa` from the DynamoDB outbox for the
contractId, compares to the prod-dispatch `gitea.actor` / `github.actor`. contractId, compares to the prod-dispatch the CI actor.
Blocks on equality, emits `SEPARATION_OF_DUTIES_VIOLATION`, routes a halt Blocks on equality, emits `SEPARATION_OF_DUTIES_VIOLATION`, routes a halt
artifact to SRE on-call. artifact to SRE on-call.
-2
View File
@@ -1,7 +1,5 @@
# Nova Metrics Catalog # Nova Metrics Catalog
> v1.17 — Strategic Direction, Leadership Metrics & Unified Story (REQ-195)
> Generated: 2026-08-04
This is the canonical catalog of every executive KPI in Nova's This is the canonical catalog of every executive KPI in Nova's
leadership metrics layer. Each metric carries a **status**: leadership metrics layer. Each metric carries a **status**:
-2
View File
@@ -1,7 +1,5 @@
# Nova Deferred Metrics Activation Roadmap # Nova Deferred Metrics Activation Roadmap
> v1.17 — Strategic Direction, Leadership Metrics & Unified Story (REQ-210)
> Generated: 2026-08-04
This document lists all 8 deferred metrics + the onboarding-funnel This document lists all 8 deferred metrics + the onboarding-funnel
"granted" half, with their blocking decisions, unblock requirements, "granted" half, with their blocking decisions, unblock requirements,
-2
View File
@@ -1,7 +1,5 @@
# Nova Metrics Views — PowerBI Data Dictionary # Nova Metrics Views — PowerBI Data Dictionary
> v1.17 — Strategic Direction, Leadership Metrics & Unified Story (REQ-190, REQ-209)
> Generated: 2026-08-04
This document is the column-level data dictionary for the PowerBI export This document is the column-level data dictionary for the PowerBI export
views in `metrics/powerbi/`. Each fact/dimension table and placeholder views in `metrics/powerbi/`. Each fact/dimension table and placeholder
-270
View File
@@ -1,270 +0,0 @@
# Nova AWS Resource Migration Runbook (REQ-163, P4)
> **Milestone:** v1.15-Nova (Wave 4, P4). Renames every `acdl-*` AWS
> resource name → `nova-*` via Terraform. This is the heaviest Terraform
> phase of the rebrand and requires a **maintenance window**.
>
> **Plan-validated only.** Per A1, `NOVA_LIFECYCLE_MODE` defaults to
> `plan` (no live AWS mutation from CI). `terraform validate` passes; the
> live apply steps below are executed by a platform operator during the
> scheduled maintenance window. Each step has a verification + rollback.
## Scope (renamed resources)
| AWS resource | Before | After | Strategy |
|---|---|---|---|
| KMS alias | `alias/acdl-platform` | `alias/nova-platform` | cheap rename |
| SNS topic | `acdl-sod-halt` | `nova-sod-halt` | recreate |
| Security group | `acdl-ecs-sg` | `nova-ecs-sg` | recreate |
| Lambda (role/policy/function) | `acdl-contract-ingestor` | `nova-contract-ingestor` | recreate |
| DynamoDB contracts | `acdl-contracts` | `nova-contracts` | scan + copy |
| DynamoDB change-requests | `acdl-change-requests` | `nova-change-requests` | scan + copy |
| Secrets Manager secret | `acdl/github-token` | `nova/github-token` | recreate + re-store |
| ECR repo | `acdl-microservice` | `nova-microservice` | re-push |
| ECS cluster/service/task/role | `acdl-microservice` | `nova-microservice` | recreate |
| IAM user + policy | `acdl-spike-runner` (+ `-policy`) | `nova-spike-runner` (+ `-policy`) | re-bootstrap |
| IAM act-runner role | `acdl-act-runner-role` | `nova-act-runner-role` | re-bootstrap |
| IAM deploy role | `acdl-deploy-<repo>` | `nova-deploy-<repo>` | re-bootstrap |
| S3 state bucket | `acdl-tfstate-581513795199-us-east-1` | `nova-tfstate-581513795199-us-east-1` | `-migrate-state` |
| DynamoDB outbox | `acdl-outbox` | `nova-outbox` | scan + copy |
| Platform VPC/subnet/IGW/RT | `acdl-shared*` | `nova-shared*` | recreate (brief downtime) |
| CI VPC/subnet/SG/cluster | `acdl-ci-*` | `nova-ci-*` | recreate (CI-only) |
| ALB name prefix | `acdl-alb` | `nova-alb` | recreate (brief downtime, LAST) |
## Migration ordering (binding)
Order: **KMS alias → SNS/SG → Lambda → DynamoDB → ECR → IAM → state bucket → ALB**.
Each step is independently rollback-able. The ALB is last because it
requires the briefest downtime window.
---
## Pre-flight
1. **Announce the maintenance window** (consumers are notified via the
P1 migration guide `docs/NOVA_MIGRATION.md`).
2. **Back up state** for every stack (see §State bucket — back up the
state JSON *before* `-migrate-state`).
3. Confirm `NOVA_LIFECYCLE_MODE=plan` (default) so CI does not mutate
AWS during the window.
4. Confirm the new `nova-*` destination tables/repos will be created by
the same Terraform apply (no manual pre-creation needed).
## Step 1 — KMS alias (`alias/acdl-platform``alias/nova-platform`)
- **Command (in `terraform/platform/`):**
```bash
terraform init -upgrade
terraform apply -replace=aws_kms_alias.nova_platform
```
(Terraform destroys the old alias + creates the new one — aliases are
cheap; the underlying key ID is unchanged.)
- **Verify:** `aws kms list-aliases --query 'Aliases[?AliasName==`alias/nova-platform`]'` returns the new alias; `alias/acdl-platform` is gone.
- **Rollback:** `terraform apply -replace=aws_kms_alias.nova_platform` against the prior revision (re-creates `alias/acdl-platform`). Resources encrypted by the key are unaffected (key ID unchanged).
## Step 2 — SNS topic + Security group (recreate)
- **Command:** `terraform apply` in `terraform/platform/`.
- SNS `acdl-sod-halt``nova-sod-halt` (the topic ARN changes; update `NOVA_SOD_HALT_TOPIC_ARN` wherever it is set).
- SG `acdl-ecs-sg``nova-ecs-sg` (the security group is re-attached to running ECS tasks; brief task restart).
- **Verify:** `aws sns list-topics` shows `nova-sod-halt`; `aws ec2 describe-security-groups` shows `nova-ecs-sg`.
- **Rollback:** `terraform apply` the prior revision re-creates the `acdl-*` names. The SNS topic has no message backlog (halt artifacts are fire-and-forget); the SG drift resolves on next task deploy.
## Step 3 — Lambda (recreate)
- **Command:** `terraform apply` in `terraform/platform/`.
- Lambda function `acdl-contract-ingestor``nova-contract-ingestor`.
- Execution role `acdl-contract-ingestor-role``nova-contract-ingestor-role`.
- Inline policy `acdl-contract-ingestor-policy``nova-contract-ingestor-policy`.
- The Lambda env vars (`CONTRACTS_TABLE`, `GITHUB_TOKEN_SECRET_ID`) now resolve to `nova-*` defaults.
- **Verify:** `aws lambda list-functions` shows `nova-contract-ingestor`; the Function URL returns 200 on a SigV4-signed invoke. The `consumer_invoke_policy.json` rendered output (Terraform `consumer_invoke_policy_rendered`) now references `function:nova-contract-ingestor` — re-distribute to consumer deploy roles.
- **Rollback:** `terraform apply` the prior revision re-creates `acdl-contract-ingestor`. Consumer deploy roles must point back at the old Function ARN (re-distribute the prior `consumer_invoke_policy.json`).
## Step 4 — DynamoDB (scan + copy)
DynamoDB table names are immutable post-creation, so the migration is a
**scan + copy** (not a rename). The new `nova-*` tables are created by
the same Terraform apply (Step 3). The data-migration script copies
every item and verifies row counts.
- **Command (from repo root):**
```bash
# Dry-run first (no writes):
python3 scripts/migrate_dynamodb_data.py
# Execute the copy:
python3 scripts/migrate_dynamodb_data.py --apply
# A single table:
python3 scripts/migrate_dynamodb_data.py --table contracts --apply
```
The script scans `acdl-contracts` → copies to `nova-contracts`, and
`acdl-change-requests``nova-change-requests`, then verifies the
destination row count == source row count (re-scan, not
`DescribeTable.ItemCount` which lags ~6h).
- **Verify:**
```bash
# Row counts must match (printed by the script). Manual cross-check:
aws dynamodb scan --table-name nova-contracts --select COUNT
aws dynamodb scan --table-name acdl-contracts --select COUNT
```
Then **point consumers at the new tables** (the Lambda already reads
`nova-*` defaults; any direct DynamoDB consumers update their env).
- **Keep the old tables** (`acdl-contracts`, `acdl-change-requests`)
until consumers are verified reading from `nova-*`. **Deletion is a
manual post-verification step:**
```bash
aws dynamodb delete-table --table-name acdl-contracts
aws dynamodb delete-table --table-name acdl-change-requests
```
Only delete after a full soak period confirms `nova-*` reads succeed.
- **Rollback:** Re-point consumers at `acdl-*` (the old tables are
retained). The copy is additive (no data loss). To roll back a partial
copy, re-run `--apply` (idempotent — `PutItem` overwrites).
### Outbox table (`acdl-outbox``nova-outbox`)
The evidence outbox table follows the same scan+copy pattern (it is
created by `terraform/bootstrap/create_state_backend.py`).
- **Command:** `python3 scripts/migrate_dynamodb_data.py --source acdl-outbox --dest nova-outbox --apply`
- The `core/outbox_writer.py` default + `core/regression_verify.py`
CAP-015 probe now reference `nova-outbox` (P4 updated both). The
regression gate's live-AWS CAP-015 will return `Verified` once the
`nova-outbox` table exists live; until then it is `Decayed` (the gate
is re-run at milestone complete after the live migration).
## Step 5 — ECR (re-push)
- **Command:** `terraform apply` in `terraform/microservice/` creates
the new `nova-microservice` ECR repo. Re-push the image:
```bash
python3 scripts/push_consumer_image.py # creates nova-microservice + prints docker tag/push
```
(The script's `ECR_REPO_NAME` is now `nova-microservice`.)
- **Verify:** `aws ecr describe-repositories` shows `nova-microservice`; `docker pull <acct>.dkr.ecr.us-east-1.amazonaws.com/nova-microservice:latest` succeeds.
- **Rollback:** The old `acdl-microservice` repo is retained until the
soak passes. Re-push to it if a rollback is needed. Delete it manually:
`aws ecr delete-repository --repository-name acdl-microservice --force`.
## Step 6 — IAM (re-bootstrap)
- **Command:**
```bash
export NOVA_BOOTSTRAP_AWS_ACCESS_KEY_ID="<root key>"
export NOVA_BOOTSTRAP_AWS_SECRET_ACCESS_KEY="<root secret>"
python3 terraform/bootstrap/create_state_backend.py # creates nova-outbox (idempotent)
python3 terraform/bootstrap/create_iam_user.py # creates nova-spike-runner
python3 terraform/bootstrap/apply_iam_baseline.py # creates nova-spike-runner-policy + nova-act-runner-role
bash scripts/rotate_spike_key.sh # rotates the nova-spike-runner key
```
The deploy role `acdl-deploy-<repo>``nova-deploy-<repo>` is
created by the bootstrap (the deploy workflow
`.gitea/.github/workflows/deploy.yml` now references
`role/nova-deploy-{1}`).
- **Verify:** `aws iam get-user --user-name nova-spike-runner`;
`aws iam list-attached-user-policies --user-name nova-spike-runner`
shows `nova-spike-runner-policy`;
`aws iam get-role --role-name nova-act-runner-role`.
- **Rollback:** Re-run the prior bootstrap scripts (they create
`acdl-spike-runner` + `acdl-act-runner-role`). The deploy workflow's
`role-to-assume` must be reverted to `acdl-deploy-` (prior revision).
## Step 7 — State bucket (`acdl-tfstate-*``nova-tfstate-*`, `-migrate-state`)
The S3 state backend is renamed. Terraform's `-migrate-state` copies the
state objects to the new bucket. **Back up the state JSON first.**
- **Back up state (per stack):**
```bash
for stack in platform microservice ci-vpc; do
aws s3 cp s3://acdl-tfstate-581513795199-us-east-1/$stack/terraform.tfstate \
./backup-$stack.tfstate
done
```
- **Command (per stack):** the backend config in each
`terraform/*/terraform.tf` now points at `nova-tfstate-...`.
```bash
cd terraform/platform
terraform init -migrate-state # copies state acdl-tfstate → nova-tfstate
cd ../microservice
terraform init -migrate-state
cd ../ci-vpc
terraform init -migrate-state
```
- **Verify:** `aws s3 ls s3://nova-tfstate-581513795199-us-east-1/`
shows the state keys; `terraform state list` in each dir lists the
expected resources.
- **Rollback:** Point the backend back at `acdl-tfstate-*` and re-run
`terraform init -migrate-state` (restores from the backup bucket). The
old `acdl-tfstate-*` bucket is retained until the soak passes. Delete
it manually:
`aws s3 rb s3://acdl-tfstate-581513795199-us-east-1 --force`.
## Step 8 — ALB (recreate, brief downtime, LAST)
The ALB is last because its recreation requires the briefest downtime
window (the ECS service is re-attached to the new target group).
- **Command:** `terraform apply` in `terraform/microservice/`. The ALB
`acdl-microservice` / `acdl-alb``nova-microservice` / `nova-alb`.
- **Verify:** `aws elbv2 describe-load-balancers` shows the new ALB;
`curl http://<new-alb-dns>/` returns 200.
- **Rollback:** `terraform apply` the prior revision re-creates the
`acdl-*` ALB (brief downtime again). The old ALB DNS is retained until
consumers are re-pointed.
---
## Post-migration
1. **Soak:** run consumers against `nova-*` for a full verification
window (deploy a test contract end-to-end).
2. **Delete old resources** (manual, only after soak):
- DynamoDB: `acdl-contracts`, `acdl-change-requests`, `acdl-outbox`
- ECR: `acdl-microservice`
- IAM: `acdl-spike-runner` (+ policy), `acdl-act-runner-role`,
`acdl-deploy-<repo>`
- S3: `acdl-tfstate-581513795199-us-east-1`
- SNS: `acdl-sod-halt`
- SG: `acdl-ecs-sg`
- Secrets Manager: `acdl/github-token`
- KMS alias: `alias/acdl-platform`
- ALB: `acdl-alb` / `acdl-microservice`
3. **Regression gate:** re-run `bash scripts/run_regression.sh`. The
live-AWS CAP-013..016 probes should return `Verified` (the `nova-*`
tables + state bucket exist). CAP-015 (outbox) flips from `Decayed`
`Verified` once `nova-outbox` is live.
## What P5 owns (not P4)
- **Remove dual-read fallback:** `core/env.py` `get_env()` drops the
`ACDL_*` fallback; shell scripts drop `:-$ACDL_X`. P4 keeps the
dual-read (deployments don't break mid-window).
- **`nova_tagging.py` hard-fail on `acdl:*`:** P3 set hard mode (no
`acdl:*`-only tags); P5 tightens to fail on any `acdl:*` presence. P4
leaves P3's behavior.
- **Delete `ACDL_*` Gitea secrets:** the `NOVA_*` aliases created in P2
are now the only source.
- **Finalize `docs/NOVA_MIGRATION.md`:** mark the migration complete
(cutoff passed).
- **Milestone ship:** tag `v1.15.4`, merge to `main`, Gitea release.
## Files touched in P4
- `terraform/platform/main.tf`, `terraform/microservice/main.tf`,
`terraform/ci-vpc/main.tf` — resource renames + backend bucket.
- `terraform/{platform,microservice,ci-vpc}/terraform.tf` — state bucket.
- `terraform/platform/consumer_invoke_policy.json` — Lambda ARN.
- `terraform/bootstrap/{create_state_backend,create_iam_user,apply_iam_baseline}.py`,
`spike_runner_policy.json`, `.bootstrap_state.json`, `README.md`
IAM/outbox/state-bucket renames.
- `modules/l1/*/terraform/**` + `modules/l1/alb/instance.json` — L1
resource-name defaults.
- `modules/l2/microservice/composition.json``nova-app-role` default.
- `core/lambda/contract_ingestor.py` — default table names (D-111).
- `core/outbox_writer.py`, `core/regression_verify.py`,
`core/local_emulators.py` — outbox table consistency (cross-territory,
minimal).
- `.gitea/workflows/deploy.yml` + `.github/workflows/deploy.yml`
`nova-deploy-` role ARN + artifact names.
- `scripts/migrate_dynamodb_data.py` (NEW), `scripts/rotate_spike_key.sh`,
`scripts/push_consumer_image.py`.
- `tests/**` — fixtures updated to assert `nova-*`.
-177
View File
@@ -1,177 +0,0 @@
# Nova Migration Guide — What Consumers Must Know
> **STATUS: COMPLETE (milestone v1.15.4, 2026-07-30).** The Nova rebrand
> is fully rolled out. The dual-read / parallel-write grace period has
> ended (P5 cutoff passed). All `ACDL_*` env var fallbacks, `.acdl/`
> consumer-path fallbacks, `/acdl/` SSM-path fallbacks, `acdl:*` tag-key
> fallbacks, and `acdl-*` AWS resource names are removed. Consumers must
> use the `NOVA_*` / `.nova/` / `/nova/` / `nova:*` / `nova-*` names
> exclusively. If you have not yet migrated, follow the steps below.
> **Nova** is the new product brand for the platform formerly known as
> **ACDL** (Agentic Cloud Delivery Platform). This guide documents the
> breaking changes from the rebrand rollout (Phases P2P4, cutoff P5)
> and tells you exactly what to do.
## What is NOT changing
- **The Gitea repository name** (`continuous-intelligence/acdl`) is **not**
changing. Only the product brand is changing. The `uses:` reference
(`acdl/.github/workflows/deploy.yml@vX.Y`) and the GitHub `acdl/acdl` repo
path are unchanged for the duration of the rebrand; the workflow
`uses:` reference will be migrated in a later, separately-announced step.
- **The platform behavior** is unchanged. Same pipeline stages, same
contract schema, same confidence model, same evidence stream, same
modules. Only the brand, the on-disk path, the env var names, the SSM
path, the AWS tag keys, and the AWS resource names are changing.
## The 5 breaking changes
Five things that consumers may reference are being renamed. Each is
scheduled into a phase, ships with a grace period, and has a cutoff.
### 1. Consumer contract path — Phase P2
- **Old:** `.acdl/contract.yml`
- **New:** `.nova/contract.yml`
- **Phase:** P2 (env vars + consumer path)
- **Grace period:** during P2P4 the deploy workflow reads **both** paths
(`.nova/contract.yml` first, falling back to `.acdl/contract.yml` if the
new path is absent). Your existing contracts keep working until P5.
- **Cutoff:** P5 removes the `.acdl/` fallback. Move your contract file
before P5.
- **What you must do:** rename the directory in your consumer repo from
`.acdl/` to `.nova/` and update any `contract:` workflow input that
points at the old path. Nothing else changes in the contract content.
### 2. Environment variables — Phase P2
- **Old:** `ACDL_*` (e.g. `ACDL_LIFECYCLE_MODE`, `ACDL_AWS_ACCOUNT_ID`,
`ACDL_BOOTSTRAP_AWS_ACCESS_KEY_ID`, …)
- **New:** `NOVA_*` (e.g. `NOVA_LIFECYCLE_MODE`, `NOVA_AWS_ACCOUNT_ID`,
`NOVA_BOOTSTRAP_AWS_ACCESS_KEY_ID`, …)
- **Phase:** P2 (env vars + consumer path)
- **Grace period — dual-read fallback:** during P2P4 the platform reads
**`NOVA_*` first, then falls back to `ACDL_*`** if the Nova variable is
unset. This means your CI secrets, workflow env blocks, and local
`.env.secrets` keep working unchanged through P4. You do not need to
rename everything in one shot — rename a variable and the dual-read picks
it up; leave one old and it still resolves.
- **Cutoff:** P5 removes the `ACDL_*` fallback. After P5, only `NOVA_*`
is read.
- **What you must do:** rename your `ACDL_*` CI secrets, workflow `env:`
blocks, and any local `.env.secrets` entries to `NOVA_*`. Because of the
dual-read, you can do this incrementally across P2P4 — but it must be
complete before P5.
### 3. SSM parameter path — Phase P3 (DONE)
- **Old:** `/acdl/{env}/{contractId}/{output}`
- **New:** `/nova/{env}/{contractId}/{output}`
- **Phase:** P3 (SSM paths + tag keys) — **shipped in P3**
- **Grace period — parallel-write:** during P3P4 the platform **writes
every output to both** the `/acdl/…` and `/nova/…` SSM paths, and reads
from `/nova/…` first (falling back to `/acdl/…`). Any hardcoded SSM path
reads in your application code keep resolving through P4. The P3
migration script (`scripts/migrate_ssm_paths.py`) copies existing
`/acdl/…` parameters to `/nova/…`, verifies the copy, and deletes the
old ones.
- **Cutoff:** P5 stops writing to `/acdl/…` and removes the read fallback.
After P5 only `/nova/…` exists.
- **What you must do:** if your application code or runbooks read deploy
outputs from SSM by hardcoded path, update the path prefix from `/acdl/`
to `/nova/`. If you consume outputs only via the PR-comment / GitHub
issue surface, you do nothing — the platform republishes under the new
path automatically.
### 4. AWS tag keys — Phase P3 (DONE)
- **Old:** `acdl:owner`, `acdl:environment`, `acdl:contract`,
`acdl:cost-center`, `acdl:ref`
- **New:** `nova:owner`, `nova:environment`, `nova:contract`,
`nova:cost-center`, `nova:ref`
- **Phase:** P3 (SSM paths + tag keys) — **shipped in P3**
- **Grace period — parallel-tag period:** during P3P4 the platform
**tags every resource with both** the `acdl:*` and `nova:*` keys (same
values). The ABAC session policy matches on **either** key set, so your
existing scoped permissions keep working. The default cost-center value
moves from `acdl-default` to `nova-default` (both written during the
parallel-tag period). Terraform now emits `nova:*` keys; old `acdl:*`
tags on pre-P3 live resources are removed by the P4 runbook's
`scripts/untag_acdl_keys.py` step after the `nova:*` tags are applied
live.
- **Cutoff:** P5 stops writing the `acdl:*` keys and the ABAC policy matches
only on `nova:*`. After P5, resources created before P5 still carry the
old `acdl:*` tags (tags are not retroactively rewritten) but **new**
resources are tagged `nova:*` only, and the policy no longer grants
access via `acdl:*`.
- **What you must do:** if you have IAM policies, Cost Explorer filters,
or billing groupings that key off `acdl:*` tag keys, add a parallel
`nova:*` condition (or migrate to `nova:*`) before P5. The platform
handles the dual-tagging; you only need to update your own tag-key
references.
### 5. AWS resource names — Phase P4
- **Old:** `acdl-*` (DynamoDB tables `acdl-contracts`,
`acdl-change-requests`; Lambda `acdl-contract-ingestor`; SNS
`acdl-sod-halt`; security group `acdl-ecs-sg`; KMS alias
`alias/acdl-platform`; ECS services, ECR repos, IAM user
`acdl-spike-runner`, state bucket `acdl-tfstate-*`, ALB `acdl-alb`,
`acdl-deploy-*`)
- **New:** `nova-*` (the same resources, prefixed `nova-`)
- **Phase:** P4 (resource names) — **maintenance window**
- **Grace period:** P4 is a **planned maintenance window**. AWS resources
cannot be renamed in place, so P4 provisions the `nova-*` resources,
migrates data (DynamoDB tables, S3 state), repoints the platform, and
tears down the `acdl-*` resources. The platform team schedules and
announces the window; consumers do not provision or rename anything
themselves.
- **Cutoff:** the `acdl-*` resources are decommissioned at the end of the
P4 maintenance window. After P4, only `nova-*` resources exist.
- **What you must do:** nothing for the resource names themselves — the
platform owns the rename. If your application code or runbooks reference
a specific `acdl-*` resource by name (e.g. a hardcoded DynamoDB table
name or ECR URI), update it to the `nova-*` name during P4. The platform
publishes the exact old → new name mapping with the P4 announcement.
## Timeline at a glance
| Phase | What ships | Grace period | Cutoff |
|-------|------------|--------------|--------|
| **P1** (this phase) | Brand prose, docs, decks, schema `$id`, release titles | n/a (prose only) | n/a |
| **P2** | `.nova/` contract path + `NOVA_*` env vars | dual-read: `.nova/``.acdl/`, `NOVA_*``ACDL_*` | **P5** removes fallback |
| **P3** | `/nova/` SSM path + `nova:*` tag keys | parallel-write (SSM) + parallel-tag (ABAC matches either) | **P5** removes old path/tags |
| **P4** | `nova-*` AWS resource names | maintenance window (platform-owned migration) | end of P4 window |
| **P5** | Fallback removal | — | `ACDL_*` env vars, `.acdl/` path, `/acdl/` SSM, `acdl:*` tags stop working |
## What consumers must do (checklist)
1. **Before P5 — contract path:** move `.acdl/contract.yml`
`.nova/contract.yml` in your consumer repo; update the `contract:`
workflow input. *(Can be done any time in P2P4.)*
2. **Before P5 — env vars:** rename `ACDL_*` CI secrets / workflow `env:`
blocks / local `.env.secrets` to `NOVA_*`. *(Incremental during P2P4;
dual-read keeps you green.)*
3. **Before P5 — SSM reads:** if you read deploy outputs from SSM by
hardcoded `/acdl/…` path, update to `/nova/…`. *(Skip if you consume
outputs via PR comments only.)*
4. **Before P5 — tag-key references:** if you have IAM policies, Cost
Explorer filters, or billing groupings keyed off `acdl:*`, add or
migrate to `nova:*`. *(Platform handles dual-tagging.)*
5. **During P4 — resource-name references:** if your code or runbooks
reference a specific `acdl-*` AWS resource by name, update to the
`nova-*` name per the P4 mapping announcement. *(Platform owns the
rename itself.)*
## Questions
If anything in this guide is unclear, or you are unsure whether your
consumer repo references a renamed value, open an issue on the platform
repo. The platform team will confirm what you need to change and when.
> **Note:** the real Gitea repository name (`continuous-intelligence/acdl`)
> is **not** changing — only the product brand. The `uses:` workflow
> reference and repo path are migrated in a separately-announced later step;
> until then, keep your `uses: acdl/.github/workflows/deploy.yml@vX.Y`
> reference as-is.
-67
View File
@@ -1,67 +0,0 @@
# Nova — The No-Humans Infrastructure Platform: Thesis Defensibility Brief
> v1.17 — Strategic Direction, Leadership Metrics & Unified Story (REQ-213)
> Generated: 2026-08-04
## The thesis
Nova is the autonomous infrastructure layer that lets product teams
ship without engaging an operator, and lets executives trust the AI
not because it never fails but because every decision is captured,
scored, and accountable.
**Autonomy in operations; human at stage gates.** The operator is
removed from the loop of normal operations. Human attestation remains
required at stage gates — QA signs off for production, SRE greenlights
based on operational readiness. The absence of an operator is never
the absence of a record.
## Grounded proof (measurable today)
| Proof | Source | Status |
|-------|--------|--------|
| 18 capabilities verified, 4 honestly skipped (0 broken) | `REGRESSION_REPORT.json` | grounded |
| Decision Ledger captures 100% of AI decisions with outcome backfill | `metrics/decision_ledger.db` | grounded (this milestone) |
| Attestation Coverage: 100% of prod/dr promotions attested by a human | `hitl_gates.py` + outbox `approver_*` | grounded |
| Confidence-gated policy engine (not an LLM) — 6 weighted inputs, band outcome | `confidence_signal.py` | grounded |
| 8-concern attestation matrix with separation-of-duties on prod | `attestation_matrix.py` + `separation_of_duties.py` | grounded |
| Pre-apply cost estimates (Infracost, offline) | `infracost_adapter.py` | grounded |
| Test suite passes (~656 tests) | `metrics/test-results.xml` | grounded |
## Deferred proof (measurable when blocking decisions lift)
| Proof | Blocking Decision | Unblock Requirement |
|-------|-------------------|---------------------|
| Touchless Resolution Rate ≥99% across production estates | 0 consumers today | Pilot estate activation |
| Live infrastructure health (ECS, ALB, RPS) | D-096 | Live AWS re-provisioning |
| Onboarding funnel: requested → granted | D-113/D-114/D-119 | Auto-grant implementation |
| Drift auto-reversal rate ≥95% | D-096 + no scheduler | Drift detection scheduler |
| Predictive vs reactive ratio ≥3:1 | future emitter | ML anomaly-forecasting service |
| Tamper-evident ledger checkpoints (S3 Object Lock + JWS) | D-083 | Audit ledger build-out |
## Anti-claims (what Nova is NOT)
1. **Nova's "AI" is NOT an LLM planner.** It is a confidence-gated
policy engine (confidence_signal + HITL gate). The Decision Ledger
captures this real decision path — not a fabricated "AI agent" that
doesn't exist yet (D-122). When an LLM planner is added, it will emit
richer `alternatives_considered` without schema breakage.
2. **Nova does NOT remove humans from accountability.** Only from
operations. Every stage-gate promotion (qa/prod/dr) requires a human
attestation recorded with approver identity, separation-of-duties
check, and the 8-concern evidence matrix (NORTH_STAR Anti-Goal #3).
3. **Nova is NOT for legacy, untagged, or freeform infrastructure.** It
requires Terraform-managed, policy-aligned, fully-tagged inputs
(NORTH_STAR Anti-Goal #4).
4. **Nova does NOT fabricate metrics.** Every metric is grounded (cites
a source file), derived (documented formula), or deferred (cites a
blocking decision ID). No fabricated numbers in any deck slide or
METRICS.md entry (the "no fabrication" hard constraint).
## What "won" looks like
By month 18, Nova is the layer enterprise leadership points to when
they say *"we don't have an infrastructure ops team anymore, and the
audit trail is stronger than it ever was"* — and it is the default
substrate their AI engineering teams reach for first when an agent needs
to deploy.
+3 -3
View File
@@ -1,6 +1,6 @@
# Nova Onboarding — No-Humans Request Path (v1.16, REQ-182..184) # Nova Onboarding — Autonomous Request Path (v1.16, REQ-182..184)
The v1.16 milestone implements the **request path** of the no-humans The v1.16 milestone implements the **request path** of the autonomous
onboarding flow (D-113). A consumer can submit an onboarding request onboarding flow (D-113). A consumer can submit an onboarding request
without contacting the platform team; the platform generates an without contacting the platform team; the platform generates an
environment binding + (in a future milestone) provisions the AWS resources. environment binding + (in a future milestone) provisions the AWS resources.
@@ -77,7 +77,7 @@ milestone (D-113).
only (D-114); live apply is deferred. only (D-114); live apply is deferred.
- **OIDC trust policy** — the onboarding Terraform uses a placeholder - **OIDC trust policy** — the onboarding Terraform uses a placeholder
OIDC provider; real OIDC federation is blocked on OIDC provider; real OIDC federation is blocked on
go-gitea/gitea#36988 (carries forward from v1.1). upstream forge OIDC support (carries forward from v1.1).
## See also ## See also
+1 -1
View File
@@ -230,7 +230,7 @@ change to the modules/stack/confidence/audit.
- A MAJOR bump requires a new registry entry (immutable publication); the - A MAJOR bump requires a new registry entry (immutable publication); the
old entry enters a 12-month deprecation window. old entry enters a 12-month deprecation window.
- The central deploy pipeline is referenced by a floating MAJOR + MINOR tag - The central deploy pipeline is referenced by a floating MAJOR + MINOR tag
(e.g. `@v1.13`); patch fixes flow within the tag, breaking changes land (e.g. `@v1.19`); patch fixes flow within the tag, breaking changes land
under the next MINOR tag. under the next MINOR tag.
See [Versioning](pipeline/versioning) for the consumer-facing details. See [Versioning](pipeline/versioning) for the consumer-facing details.
+13 -13
View File
@@ -19,7 +19,7 @@ definitions.
```mermaid ```mermaid
flowchart LR flowchart LR
A["your repo<br/>(app code + contracts + CI definitions)"] -->|uses: acdl/.github/workflows/deploy.yml@v1.13| B A["your repo<br/>(app code + contracts + CI definitions)"] -->|uses: nova/.github/workflows/deploy.yml@v1.19| B
B["platform runners<br/>(modules + pipelines + adapters + schemas)"] -->|contract -&gt; resolver -&gt; stack -&gt; adapter<br/>-&gt; security checks -&gt; infrastructure plan -&gt; policy checks<br/>-&gt; confidence -&gt; apply -&gt; evidence event| C B["platform runners<br/>(modules + pipelines + adapters + schemas)"] -->|contract -&gt; resolver -&gt; stack -&gt; adapter<br/>-&gt; security checks -&gt; infrastructure plan -&gt; policy checks<br/>-&gt; confidence -&gt; apply -&gt; evidence event| C
C["your resources in AWS"] C["your resources in AWS"]
``` ```
@@ -27,13 +27,13 @@ flowchart LR
## Versioning the `uses:` reference ## Versioning the `uses:` reference
The central deployment pipeline is **always versioned with floating MAJOR The central deployment pipeline is **always versioned with floating MAJOR
and MINOR tags** (e.g. `acdl/pipelines/contract.yml@v1.13`). Version and MINOR tags** (e.g. `nova/pipelines/contract.yml@v1.19`). Version
constraints cannot be expressed inside the contract, so the tag in constraints cannot be expressed inside the contract, so the tag in
`uses:` is the only immutability lever a consumer has. See `uses:` is the only immutability lever a consumer has. See
[Versioning](pipeline/versioning) for the full rationale. [Versioning](pipeline/versioning) for the full rationale.
**Unversioned references are discouraged.** Do not use `@main` or a bare **Unversioned references are discouraged.** Do not use `@main` or a bare
`acdl/pipelines/contract.yml`. `nova/pipelines/contract.yml`.
## Prerequisites ## Prerequisites
@@ -47,7 +47,7 @@ platform-managed. See [Environments](environments/).
environment is bound, your first pipeline run emits a friendly onboarding environment is bound, your first pipeline run emits a friendly onboarding
prompt. See [Environments](environments/). prompt. See [Environments](environments/).
- **Authorization to reference the central pipeline.** Onboarding grants - **Authorization to reference the central pipeline.** Onboarding grants
your repo the right to `uses: acdl/.github/workflows/deploy.yml@v1.13`. your repo the right to `uses: nova/.github/workflows/deploy.yml@v1.19`.
Contact the platform team if you have not been onboarded. Contact the platform team if you have not been onboarded.
## Step 1 — Create a consumer repo ## Step 1 — Create a consumer repo
@@ -94,7 +94,7 @@ Nova deployment workflow with a **versioned tag** (floating MAJOR + MINOR):
```yaml ```yaml
jobs: jobs:
deploy: deploy:
uses: acdl/.github/workflows/deploy.yml@v1.13 uses: nova/.github/workflows/deploy.yml@v1.19
with: with:
contract: .nova/contract.yml contract: .nova/contract.yml
environment: dev environment: dev
@@ -140,7 +140,7 @@ name: microservice
| Field | Type | Required | Description | | Field | Type | Required | Description |
|-------|------|----------|-------------| |-------|------|----------|-------------|
| `uses` | string | yes | Reference to the central deployment pipeline, **versioned** with a floating MAJOR+MINOR tag (e.g. `acdl/pipelines/contract.yml@v1.13`). Bare or `@main` references are discouraged. See [Versioning](pipeline/versioning). | | `uses` | string | yes | Reference to the central deployment pipeline, **versioned** with a floating MAJOR+MINOR tag (e.g. `nova/pipelines/contract.yml@v1.19`). Bare or `@main` references are discouraged. See [Versioning](pipeline/versioning). |
| `module` | string | yes | Module name from the registry — any primitive or module (e.g. `static-assets`, `microservice`, `s3`). See the [module catalog](modules/). | | `module` | string | yes | Module name from the registry — any primitive or module (e.g. `static-assets`, `microservice`, `s3`). See the [module catalog](modules/). |
| `environment` | string | yes | The platform-managed environment to deploy to (e.g. `dev`). See [Environments](environments/). | | `environment` | string | yes | The platform-managed environment to deploy to (e.g. `dev`). See [Environments](environments/). |
| `inputs` | object | yes | Module-specific inputs (see the module's README). | | `inputs` | object | yes | Module-specific inputs (see the module's README). |
@@ -177,14 +177,14 @@ on:
branches: [main] branches: [main]
jobs: jobs:
deploy: deploy:
uses: acdl/.github/workflows/deploy.yml@v1.13 uses: nova/.github/workflows/deploy.yml@v1.19
with: with:
contract: .nova/contract.yml contract: .nova/contract.yml
``` ```
That is the entire consumer-side workflow. When you push to `main`: That is the entire consumer-side workflow. When you push to `main`:
1. The platform runner resolves `uses: acdl/.github/workflows/deploy.yml@v1.13` 1. The platform runner resolves `uses: nova/.github/workflows/deploy.yml@v1.19`
to the reusable workflow **at the pinned tag**. to the reusable workflow **at the pinned tag**.
2. A **platform-provided runner** checks out **your** repo. 2. A **platform-provided runner** checks out **your** repo.
3. The runner checks out the **Nova platform repo** into the workspace — 3. The runner checks out the **Nova platform repo** into the workspace —
@@ -326,8 +326,8 @@ per-module extension points. Common examples:
| Contract schema | `schemas/contract.schema.json` | JSON Schema for consumer contracts. | | Contract schema | `schemas/contract.schema.json` | JSON Schema for consumer contracts. |
| Stack schema | `schemas/stack.schema.json` | JSON Schema for the resolved stack instance. | | Stack schema | `schemas/stack.schema.json` | JSON Schema for the resolved stack instance. |
| Module catalog | [modules/](modules/) | All primitives and modules. | | Module catalog | [modules/](modules/) | All primitives and modules. |
| Sample contract | `contracts/static-assets.yaml` | The reference example contract (uses `@v1.13`). | | Sample contract | `contracts/static-assets.yaml` | The reference example contract (uses `@v1.19`). |
| Sample contract | `contracts/microservice.yaml` | The microservice example contract (uses `@v1.13`). | | Sample contract | `contracts/microservice.yaml` | The microservice example contract (uses `@v1.19`). |
| Module examples | `modules/<name>/examples/` | Validated per-module example contracts (`simple.yaml` + `complex.yaml`). | | Module examples | `modules/<name>/examples/` | Validated per-module example contracts (`simple.yaml` + `complex.yaml`). |
| Contract resolver | `core/contract_resolver.py` | Resolves contracts to stack instances. | | Contract resolver | `core/contract_resolver.py` | Resolves contracts to stack instances. |
| Angine adapter | `adapters/terraform/adapter.py` | Compiles stack instances to infrastructure. | | Angine adapter | `adapters/terraform/adapter.py` | Compiles stack instances to infrastructure. |
@@ -353,7 +353,7 @@ destruction:
use `mode: decommission` with the `changeRequestId` input: use `mode: decommission` with the `changeRequestId` input:
```yaml ```yaml
uses: acdl/.github/workflows/deploy.yml@v1.13 uses: nova/.github/workflows/deploy.yml@v1.19
with: with:
contract: .nova/contract.yml contract: .nova/contract.yml
mode: decommission mode: decommission
@@ -421,7 +421,7 @@ name: static-assets
``` ```
**Shape 2 — single contract + `environment` workflow input:** the **Shape 2 — single contract + `environment` workflow input:** the
reusable deploy workflow (`acdl/.github/workflows/deploy.yml@v1.13`) reusable deploy workflow (`nova/.github/workflows/deploy.yml@v1.19`)
declares an `environment` input. When non-empty, it overrides the declares an `environment` input. When non-empty, it overrides the
contract's `environment` field at load time (before interpolation), so contract's `environment` field at load time (before interpolation), so
the same contract can be promoted by passing a different environment: the same contract can be promoted by passing a different environment:
@@ -436,7 +436,7 @@ on: workflow_dispatch:
required: true required: true
jobs: jobs:
deploy-qa: deploy-qa:
uses: acdl/.github/workflows/deploy.yml@v1.13 uses: nova/.github/workflows/deploy.yml@v1.19
with: with:
environment: qa environment: qa
contract: .nova/contract.yml contract: .nova/contract.yml
-7
View File
@@ -78,10 +78,3 @@ Planned future features (no dates; tracked in the internal roadmap):
- [Consumer Guide](consumer-guide) — start here if you are a consumer. - [Consumer Guide](consumer-guide) — start here if you are a consumer.
- [Architecture](architecture) — start here if you are a platform engineer. - [Architecture](architecture) — start here if you are a platform engineer.
- The [README](https://github.com/nova/nova) describes the platform repo. - The [README](https://github.com/nova/nova) describes the platform repo.
> **Note:** The product brand is **Nova** (formerly ACDL — Agentic Cloud
> Delivery Platform). The Gitea repository name (`continuous-intelligence/acdl`)
> and the GitHub `uses:` reference (`acdl/.github/workflows/deploy.yml@…`)
> are unchanged during the rebrand transition; only the product name is
> changing. See the [Nova migration guide](NOVA_MIGRATION) for the
> scheduled breaking changes.
+1 -1
View File
@@ -39,7 +39,7 @@ It is exposed to consumer repos as a **reusable workflow**:
- `.github/workflows/deploy.yml` — GitHub Actions (production) - `.github/workflows/deploy.yml` — GitHub Actions (production)
A consumer repo invokes the reusable workflow via a **versioned tag** A consumer repo invokes the reusable workflow via a **versioned tag**
(floating MAJOR + MINOR, e.g. `acdl/.github/workflows/deploy.yml@v1.13`). (floating MAJOR + MINOR, e.g. `nova/.github/workflows/deploy.yml@v1.19`).
The workflow checks out the consumer repo, then checks out the Nova platform The workflow checks out the consumer repo, then checks out the Nova platform
repo into the runner workspace, and runs `scripts/run_platform.sh` against repo into the runner workspace, and runs `scripts/run_platform.sh` against
the consumer's contract. The consumer never clones the platform repo or the consumer's contract. The consumer never clones the platform repo or
+2 -2
View File
@@ -26,7 +26,7 @@ tag** in a consumer's CI workflow definition:
```yaml ```yaml
jobs: jobs:
deploy: deploy:
uses: acdl/.github/workflows/deploy.yml@v1.13 uses: nova/.github/workflows/deploy.yml@v1.19
with: with:
contract: .nova/contract.yml contract: .nova/contract.yml
``` ```
@@ -36,7 +36,7 @@ itself — the contract no longer carries a `uses:` field). The CI workflow
`uses:` tag is the only immutability lever a consumer has. `uses:` tag is the only immutability lever a consumer has.
**Unversioned references are discouraged.** Do not use `@main` or a bare **Unversioned references are discouraged.** Do not use `@main` or a bare
`acdl/.github/workflows/deploy.yml``main` is constantly updated and can `nova/.github/workflows/deploy.yml``main` is constantly updated and can
cause unexpected failures. Pinning to a MAJOR+MINOR tag means: cause unexpected failures. Pinning to a MAJOR+MINOR tag means:
- **Immutability** — the pipeline behavior you tested is the behavior you - **Immutability** — the pipeline behavior you tested is the behavior you
+71 -178
View File
@@ -13,17 +13,18 @@ every deck and a presenter-ready cue sheet for delivery.
``` ```
Step 1: full markdown Step 2: Marp deck Step 3: HTML + PPTX Step 4: Talking points Step 1: full markdown Step 2: Marp deck Step 3: HTML + PPTX Step 4: Talking points
(source of truth) ──► (lean, 10 slides) ──► (rendered) ──► (presenter cues) (source of truth) ──► (lean, 19 slides) ──► (rendered) ──► (presenter cues)
*.md *-marp.md *.html / *.pptx *-talking-points.md *.md *-marp.md *.html / *.pptx *-talking-points.md
+ speaker notes + embedded PNG diagrams + 3-6 bullets per slide + speaker notes + embedded PNG diagrams + 3-6 bullets per slide
+ mermaid code blocks + Marp frontmatter + key takeaway per slide + mermaid code blocks + Marp frontmatter + key takeaway per slide
+ maturity badges + indexed by Marp slide # + no speaker notes + indexed by Marp slide #
+ no speaker notes + content distilled from Step 1 + no maturity badges + content distilled from Step 1
+ no version in footer
``` ```
### Step 1 — Full markdown (source of truth) ### Step 1 — Full markdown (source of truth)
**File convention:** `<deck-name>.md` (e.g. `how-the-platform-works.md`). **File convention:** `<deck-name>.md` (e.g. `nova-autonomous-cloud-delivery.md`).
Write the complete deck as a standard markdown file. This is the **source of Write the complete deck as a standard markdown file. This is the **source of
truth** — it contains: truth** — it contains:
@@ -34,9 +35,9 @@ truth** — it contains:
the "who cares and why," and the honesty caveats. the "who cares and why," and the honesty caveats.
- Mermaid diagrams as ```` ```mermaid ```` fenced code blocks (these render - Mermaid diagrams as ```` ```mermaid ```` fenced code blocks (these render
on GitHub/Pages but not in Marp — Step 2 converts them to images). on GitHub/Pages but not in Marp — Step 2 converts them to images).
- An honest "shipped vs. planned" framing: every "available today" claim is - An honest "shipped vs. deferred" framing: every "available today" claim is
grounded in shipped/verified work; every "planned" item is explicitly grounded in shipped/verified work; every "deferred" item is explicitly
marked. marked with the blocking work in plain language.
**Why this file is the source of truth:** it is reviewable in any markdown **Why this file is the source of truth:** it is reviewable in any markdown
viewer, diffs cleanly in git, and carries the full reasoning (speaker notes) viewer, diffs cleanly in git, and carries the full reasoning (speaker notes)
@@ -45,13 +46,13 @@ fact is wrong, fix it here and re-run Steps 2 and 3.
### Step 2 — Marp deck synthesis ### Step 2 — Marp deck synthesis
**File convention:** `<deck-name>-marp.md` (e.g. `how-the-platform-works-marp.md`). **File convention:** `<deck-name>-marp.md` (e.g. `nova-autonomous-cloud-delivery-marp.md`).
Synthesize the full markdown into a lean Marp deck: Synthesize the full markdown into a lean Marp deck:
- **Marp frontmatter** at the top: `marp: true`, `theme: default`, - **Marp frontmatter** at the top: `marp: true`, `theme: nova-sp`,
`paginate: true`, `size: 16x9`, a header/footer, and an inline `style:` `paginate: true`, `size: 16x9`, a header/footer, and an inline `style:`
block for fonts, colors, tables, badges. block for fonts, colors, tables.
- **No speaker notes.** The Marp deck is what the audience sees; the - **No speaker notes.** The Marp deck is what the audience sees; the
speaker notes live only in the Step 1 source of truth. speaker notes live only in the Step 1 source of truth.
- **Mermaid diagrams → PNG images.** Marp does not render mermaid fenced - **Mermaid diagrams → PNG images.** Marp does not render mermaid fenced
@@ -60,8 +61,10 @@ Synthesize the full markdown into a lean Marp deck:
and embed it with `![w:1000](assets/png/<name>.png)`. and embed it with `![w:1000](assets/png/<name>.png)`.
- **`<!-- _class: title -->` + `<!-- _paginate: false -->`** on title and - **`<!-- _class: title -->` + `<!-- _paginate: false -->`** on title and
closing slides for the dark-background title style. closing slides for the dark-background title style.
- **Maturity badges** using inline spans: - **No maturity badges.** The deck no longer uses `<span class="badge">`
`<span class="badge planned">Planned</span>` spans. Deferred items are named in plain language with their blocking
work, not tagged with a badge.
- **No version in the footer.** The footer carries the deck title only.
- **Tighter prose** than Step 1 — strip the speaker-note nuance; keep the - **Tighter prose** than Step 1 — strip the speaker-note nuance; keep the
leadership-relevant selling points. leadership-relevant selling points.
@@ -69,10 +72,8 @@ Synthesize the full markdown into a lean Marp deck:
Both formats are derived from the Marp deck. **HTML is committed to the repo** Both formats are derived from the Marp deck. **HTML is committed to the repo**
(viewable in any browser, self-contained with base64-embedded images). **PPTX (viewable in any browser, self-contained with base64-embedded images). **PPTX
is uploaded to the Gitea release** as a downloadable attachment (binary, not is also committed to the repo** as a first-class binary artifact and is
committed to git). attached to the phase's release via `scripts/attach_release_asset.py`.
#### HTML export (committed to repo)
```bash ```bash
CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \ CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
@@ -81,150 +82,66 @@ CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
-o docs/presentations/<deck-name>.html -o docs/presentations/<deck-name>.html
``` ```
HTML export inlines images as base64 data URIs — no `--allow-local-files` HTML export inlines images as base64 data URIs. PPTX export requires
needed for self-contained output, but it's required when the Marp deck `--allow-local-files` so the local PNG diagrams are embedded in the file.
references local PNG assets. The resulting HTML is a single self-contained The render + commit + attach pipeline is automated by `scripts/render_slides.sh`.
file that renders the full deck with the S&P Global Energy theme.
**Re-render the HTML whenever the Marp source changes.** The HTML files are
committed artifacts, not generated on-the-fly — they must be re-rendered and
re-committed when the Marp deck is updated.
#### PPTX export (uploaded to Gitea release)
```bash
CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
npx --yes @marp-team/marp-cli@latest --allow-local-files \
docs/presentations/<deck-name>-marp.md \
-o <output-path>.pptx
```
The `--allow-local-files` flag is **required** for PPTX export so the local
PNG diagrams are embedded in the file. As of v1.18 (REQ-228, D-141), PPTX
files **are committed to the repo** as first-class binary artifacts (no LFS)
and are also attached to the phase's Gitea release via
`scripts/attach_release_asset.py`. The render + commit + attach pipeline is
automated by `scripts/render_deck.sh`.
### Step 4 — Talking points (presenter cues) ### Step 4 — Talking points (presenter cues)
**File convention:** `<deck-name>-talking-points.md` (e.g. **File convention:** `<deck-name>-talking-points.md` (e.g.
`how-the-platform-works-talking-points.md`). `nova-autonomous-cloud-delivery-talking-points.md`).
Distill the source of truth (Step 1) into presenter-ready cues, indexed by Distill the source of truth (Step 1) into presenter-ready cues, indexed by
the Marp deck (Step 2) slide structure: the Marp deck (Step 2) slide structure:
- **One section per Marp slide**`## Slide N — Title`, matching the Marp - **One section per Marp slide**`## Slide N — Title`, matching the Marp
deck's 11 main + Appendix TOC + appendix slide structure exactly. The Marp deck deck's 18 main + 1 appendix slide structure exactly.
provides the indexing and context (what the audience sees); the source
markdown provides the content (the speaker notes, the detail, the nuance).
- **3-6 talking point bullets per slide** — punchy, actionable cues distilled - **3-6 talking point bullets per slide** — punchy, actionable cues distilled
from the source markdown's speaker notes. NOT the speaker notes verbatim from the source markdown's speaker notes.
(those are too long and too contextual). These are prompts: "Land this
point," "Contrast with X," "Be honest about Y."
- **Key takeaway per slide** — the one memorable thing the audience should - **Key takeaway per slide** — the one memorable thing the audience should
walk away with from that slide. walk away with from that slide.
- **No content duplication** — the talking points reference the Marp slides - **No content duplication** — the talking points reference the Marp slides
for visual context and the source markdown for full detail. They don't for visual context and the source markdown for full detail.
repeat either; they bridge them.
**Why this file exists:** a presenter needs a cue sheet they can glance at
during delivery — not the full speaker notes (too long), not the Marp slides
(no detail). The talking points file is the middle layer: what to say, in
what order, with what emphasis, per slide.
**When to update:** re-distill the talking points whenever the Marp deck
structure changes (slides added, removed, merged, or re-ordered) or whenever
the source markdown's speaker notes are updated. The talking points are a
*derived artifact* — if a fact is wrong, fix it in the source markdown (Step 1)
and re-distill.
## Directory layout ## Directory layout
``` ```
docs/presentations/ docs/presentations/
├── README.md ← this file ├── README.md ← this file
├── how-the-platform-works.md ← Step 1: full source of truth ├── nova-autonomous-cloud-delivery.md ← Step 1: full source of truth (18 main slides + speaker notes)
├── how-the-platform-works-marp.md ← Step 2: Marp deck (11 main + TOC + 8 appendix = 20) ├── nova-autonomous-cloud-delivery-marp.md ← Step 2: Marp deck (18 main + 1 appendix = 19 slides)
├── how-the-platform-works.html ← Step 3: rendered HTML (committed) ├── nova-autonomous-cloud-delivery.html ← Step 3: rendered HTML (committed, S&P-themed)
├── how-the-platform-works-talking-points.md ← Step 4: presenter cues (20 sections) ├── nova-autonomous-cloud-delivery.pptx ← Step 3: rendered PPTX (committed, S&P-themed)
├── the-developer-experience.md ← Step 1: full source of truth ├── nova-autonomous-cloud-delivery-talking-points.md ← Step 4: presenter cues (19 sections)
├── the-developer-experience-marp.md ← Step 2: Marp deck (11 main + TOC + 7 appendix = 19)
├── the-developer-experience.html ← Step 3: rendered HTML (committed)
├── the-developer-experience-talking-points.md ← Step 4: presenter cues (19 sections)
└── assets/ └── assets/
├── nova-sp-theme.css ← S&P Global Energy Marp theme (all slide chrome)
├── puppeteer-config.json ← no-sandbox config for mmdc ├── puppeteer-config.json ← no-sandbox config for mmdc
├── mmd/ ← mermaid source files (Step 2 input) ├── mmd/ ← mermaid source files (Step 2 input)
│ ├── sp-theme.json ← S&P Red/Black/White theme (mermaid-cli --configFile) │ ├── sp-theme.json ← S&P Red/Black/White theme (mermaid-cli --configFile)
── platform-works-01-contract-driven.mmd ── ... (per-slide .mmd files)
│ ├── platform-works-02-frictions.mmd └── png/ ← rendered mermaid PNGs (committed, S&P-themed)
│ ├── platform-works-02-end-to-end-flow.mmd
│ ├── platform-works-03-north-star.mmd
│ ├── platform-works-03-scope-boundary.mmd
│ ├── platform-works-04-confidence-signal.mmd
│ ├── platform-works-05-attestation-flow.mmd
│ ├── platform-works-07-zero-trust.mmd
│ ├── developer-experience-01b-scope-boundary.mmd
│ ├── developer-experience-02-what-dev-does.mmd
│ ├── developer-experience-03-no-cloning.mmd
│ ├── developer-experience-04-promotion-journey.mmd
│ ├── developer-experience-05-catalog.mmd
│ ├── developer-experience-07-decommission.mmd
│ ├── developer-experience-08-semver.mmd
│ ├── platform-architecture.mmd ← shared high-level logical architecture (both decks)
│ └── road-to-north-star.mmd
└── png/ ← rendered PNGs (embedded in Marp)
├── platform-works-01-contract-driven.png
├── platform-works-02-frictions.png
├── platform-works-02-end-to-end-flow.png
├── platform-works-03-north-star.png
├── platform-works-03-scope-boundary.png
├── platform-works-04-confidence-signal.png
├── platform-works-05-attestation-flow.png
├── platform-works-07-zero-trust.png
├── developer-experience-01b-scope-boundary.png
├── developer-experience-02-what-dev-does.png
├── developer-experience-03-no-cloning.png
├── developer-experience-04-promotion-journey.png
├── developer-experience-05-catalog.png
├── developer-experience-07-decommission.png
├── developer-experience-08-semver.png
├── platform-architecture.png ← shared high-level logical architecture (both decks)
└── road-to-north-star.png
``` ```
## Conventions ## Conventions
### Appendix structure ### Appendix structure
Each Marp deck has **11 main slides + an Appendix TOC + appendix slides**. The Each Marp deck has **18 main slides + 1 appendix slide**. The main 18 are the
main 11 are the presentation; the appendix is for deep dives and Q&A backup. presentation; the appendix is for Q&A backup.
The platform-works deck has 8 appendix slides (A1A8); the developer-experience
deck has 7 appendix slides (A1A7). Both include an Appendix TOC slide.
- **Main slides** (1-11): the story arc, high-impact, minimal text, - **Main slides** (1-18): the story arc — Problem → Solution → Proof →
visual-heavy. These are what the audience sees during the talk. Roadmap + Ask. These are what the audience sees during the talk.
- **Appendix slides** (TOC + A1..An): detail-heavy slides moved out of the - **Appendix slide** (A1): the Metrics Glossary — detail-heavy reference for
main 10 to preserve the narrative flow. The appendix starts with a TOC Q&A.
slide listing the contents, followed by detail slides and a glossary.
- **The Road to the North Star** is a required appendix slide in both decks
— a phased timeline from v1.0 demo to the North Star, annotated as
"proposed phasing, not formally planned."
- **The Glossary** is a required appendix slide in both decks — defines
acronyms (OIDC, ABAC, CMK, CMDB, RPO, HITL, VCS, NFR) for the audience.
### Maturity framing ### Honesty framing
Every capability claim in a deck is tagged with a `Planned` badge when the item is on the roadmap but not yet implemented: Every capability claim in the deck is grounded, derived, or honestly
deferred with its blocking work named in plain language. Internal provenance
| Badge | Meaning | (decision IDs, requirement IDs, internal file paths) is kept out of the
|---|---| audience-facing slides — those live in the `.ciagent/` files only. When in
| `Planned` | On the roadmap, not yet implemented | doubt, check `.ciagent/ROADMAP.md` and the milestone status in
`.ciagent/PROJECT.md`.
This is non-negotiable for a leadership audience: never present a roadmap
item as a current capability, and never bury a tested capability's
availability. When in doubt, check `.ciagent/ROADMAP.md` and the milestone
status in `.ciagent/PROJECT.md`.
### Audience ### Audience
@@ -236,8 +153,10 @@ Head of Infrastructure, Head of DevOps. The framing rules:
"composition." "composition."
- **Selling points forward.** Each slide leads with the leadership-relevant - **Selling points forward.** Each slide leads with the leadership-relevant
outcome; the mechanism follows. outcome; the mechanism follows.
- **Zero-trust, security, observability, auditability, DX, citizen - **Security, remediation velocity, reliability, lead time, observability,
developer** are the themes — not implementation details. citizen developer** are the themes — not implementation details.
- **"Infrastructure operations become visible"** is the recurring theme across
the deck.
### Diagrams ### Diagrams
@@ -247,8 +166,7 @@ style (renders on GitHub/Pages). For the Marp deck (Step 2):
1. Extract the mermaid block into `assets/mmd/<deck>-<slide>-<name>.mmd`. 1. Extract the mermaid block into `assets/mmd/<deck>-<slide>-<name>.mmd`.
2. Use **horizontal layouts** (`flowchart LR`) or **subgraph row-wrapping** 2. Use **horizontal layouts** (`flowchart LR`) or **subgraph row-wrapping**
for wide diagrams so the PNG fits a 16:9 slide without shrinking to for wide diagrams so the PNG fits a 16:9 slide without shrinking to
illegibility. A 9-node sequential `flowchart TD` renders as a tall thin illegibility.
strip — restructure it as 2-row subgraphs or `flowchart LR`.
3. Render with a 2x scale factor and transparent background for crisp slides. 3. Render with a 2x scale factor and transparent background for crisp slides.
4. Embed with `![w:1000](assets/png/<name>.png)` (or `h:320` for tall images). 4. Embed with `![w:1000](assets/png/<name>.png)` (or `h:320` for tall images).
@@ -276,42 +194,16 @@ for f in mmd/*.mmd; do
done done
``` ```
The `puppeteer-config.json` passes `--no-sandbox` to the headless browser ### Render a Marp deck to HTML + PPTX (committed artifacts)
(required when running as root in this environment). The `--configFile
mmd/sp-theme.json` applies the S&P Global Red/Black/White theme (dark
`#1B1B1B` accent nodes with `#D6002A` red borders, white supporting nodes,
`#F0F0F0` subgraph backgrounds). Each `.mmd` file also carries the same
theme inline via a `%%{init:...}%%` block so it renders correctly even
without the `--configFile` flag.
### Export a Marp deck to HTML (committed to repo)
```bash ```bash
CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \ bash scripts/render_slides.sh nova-autonomous-cloud-delivery
npx --yes @marp-team/marp-cli@latest --allow-local-files \
docs/presentations/<deck-name>-marp.md \
-o docs/presentations/<deck-name>.html
``` ```
HTML export inlines images as base64 data URIs. The `--allow-local-files` This renders all mermaid PNGs, the HTML, and the PPTX, and stages them for
flag is needed when the Marp deck references local PNG assets (like the commit. The `--allow-local-files` flag is required so local PNG diagrams are
diagram images in `assets/png/`). The resulting HTML is self-contained. embedded. Both HTML and PPTX are committed to the repo; the PPTX is also
attached to the phase's release.
**The HTML files are committed artifacts** — re-render and re-commit whenever
the Marp source changes.
### Export a Marp deck to PPTX (uploaded to Gitea release)
```bash
CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
npx --yes @marp-team/marp-cli@latest --allow-local-files \
docs/presentations/<deck-name>-marp.md \
-o <output-path>.pptx
```
`--allow-local-files` is **required** for PPTX so local PNG diagrams are
embedded in the file. PPTX files are not committed to git — upload them as
attachments to the Gitea release.
## Adding a new presentation ## Adding a new presentation
@@ -321,16 +213,14 @@ attachments to the Gitea release.
2. **Extract any mermaid diagrams** into `assets/mmd/<deck-name>-<slide>-<name>.mmd` 2. **Extract any mermaid diagrams** into `assets/mmd/<deck-name>-<slide>-<name>.mmd`
and render them to `assets/png/` (command above). and render them to `assets/png/` (command above).
3. **Synthesize the Marp deck** as `<deck-name>-marp.md` with frontmatter, 3. **Synthesize the Marp deck** as `<deck-name>-marp.md` with frontmatter,
no speaker notes, embedded PNGs, and maturity badges. no speaker notes, embedded PNGs, and no badges.
4. **Render to HTML** with `--allow-local-files` and commit the HTML to 4. **Render to HTML + PPTX** via `scripts/render_slides.sh <deck-name>` and
`docs/presentations/<deck-name>.html`. commit both to `docs/presentations/`.
5. **Render to PPTX** with `--allow-local-files` and upload to the Gitea 5. **Distill the talking points** as `<deck-name>-talking-points.md` — one
release (do not commit PPTX to git).
6. **Distill the talking points** as `<deck-name>-talking-points.md` — one
section per Marp slide, 3-6 talking point bullets + key takeaway, content section per Marp slide, 3-6 talking point bullets + key takeaway, content
distilled from the source markdown (Step 1), indexed by the Marp deck distilled from the source markdown (Step 1), indexed by the Marp deck
(Step 2) slide structure. (Step 2) slide structure.
7. **Verify** the PPTX slide count and that media files are embedded: 6. **Verify** the PPTX slide count and that media files are embedded:
```bash ```bash
python3 -c " python3 -c "
import zipfile, re import zipfile, re
@@ -345,11 +235,14 @@ attachments to the Gitea release.
| Deck | Source of truth (Step 1) | Marp deck (Step 2) | Rendered HTML + PPTX (Step 3) | Talking points (Step 4) | Slides | Audience | | Deck | Source of truth (Step 1) | Marp deck (Step 2) | Rendered HTML + PPTX (Step 3) | Talking points (Step 4) | Slides | Audience |
|---|---|---|---|---|---|---| |---|---|---|---|---|---|---|
| Nova — The No-Humans Infrastructure Platform | `nova-no-humans-platform.md` | `nova-no-humans-platform-marp.md` | `nova-no-humans-platform.html` + `.pptx` (committed + release-attached) | `nova-no-humans-platform-talking-points.md` | 19 main + 2 appendix (21) | CTO, Head of Cloud, Head of Infra, Head of DevOps | | Nova — The Autonomous Cloud Delivery Platform | `nova-autonomous-cloud-delivery.md` | `nova-autonomous-cloud-delivery-marp.md` | `nova-autonomous-cloud-delivery.html` + `.pptx` (committed + release-attached) | `nova-autonomous-cloud-delivery-talking-points.md` | 18 main + 1 appendix (19) | CTO, Head of Cloud, Head of Infra, Head of DevOps |
> **v1.18 (D-130):** the two legacy decks (How the Platform Works + The > **v1.21:** the deck was renamed from "No-Humans Infrastructure Platform"
> Developer Experience) were consolidated into a single unified narrative > to "Autonomous Cloud Delivery Platform" (professional framing; conveys
> deck with a 5-act arc (Problem → Vision → How → Proof → Roadmap). v1.18 > autonomy without the provocative wording). The narrative restructured to
> (REQ-226) adds 3 slides (17 Scope, 18 RACI, 19 Atelier) → 21 total. The > a 4-beat arc (Problem → Solution → Proof → Roadmap + Ask). Internal
> S&P Global Energy theme is restored (REQ-214, P1). PPTX is committed to > provenance (decision IDs, requirement IDs, file paths) removed from
> git + attached to the Gitea release (REQ-228, D-141). > audience-facing slides. Maturity badges removed. The RACI matrix expanded
> to four roles (Quality Engineering + SRE). The Atelier slide split into
> two. The pipeline hardened: Checkov on static code before the plan;
> Wiz-or-Checkov on the plan (never both).
@@ -0,0 +1,11 @@
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#1B1B1B", "primaryBorderColor": "#D6002A", "primaryTextColor": "#fff", "secondaryColor": "#fff", "secondaryBorderColor": "#D6002A", "secondaryTextColor": "#1B1B1B", "tertiaryColor": "#F0F0F0", "clusterBkg": "#F0F0F0", "lineColor": "#1B1B1B", "fontFamily": "\"Akkurat Pro\", \"Helvetica Neue\", \"Arial\", sans-serif"}}}%%
flowchart TB
A["Contract → Resolver → Adapter"] --> D["Checkov (static code)"]
D --> E["Terraform plan"]
E --> F["Wiz (on plan) → Confidence signal → Stage gate"]
F --> I["Apply → Evidence + Ledger"]
classDef accent fill:#1B1B1B,color:#fff,stroke:#D6002A,stroke-width:2px
classDef supporting fill:#fff,color:#1B1B1B,stroke:#D6002A,stroke-width:1px
class D,E,F accent
class A,I supporting
@@ -0,0 +1,17 @@
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#1B1B1B", "primaryBorderColor": "#D6002A", "primaryTextColor": "#fff", "secondaryColor": "#fff", "secondaryBorderColor": "#D6002A", "secondaryTextColor": "#1B1B1B", "tertiaryColor": "#F0F0F0", "clusterBkg": "#F0F0F0", "lineColor": "#1B1B1B", "fontFamily": "\"Akkurat Pro\", \"Helvetica Neue\", \"Arial\", sans-serif"}}}%%
flowchart TB
A["Platform<br/>components"] --> B["CloudEvents<br/>envelope"]
B --> C["Event log"]
B --> D["Decision<br/>ledger"]
B --> E["Run records"]
C --> F["Collector"]
D --> F
E --> F
F --> G["Cold store"]
G --> H["PowerBI<br/>views"]
H --> I["Live ops<br/>dashboard"]
classDef accent fill:#1B1B1B,color:#fff,stroke:#D6002A,stroke-width:2px
classDef supporting fill:#fff,color:#1B1B1B,stroke:#D6002A,stroke-width:1px
class B,F,G,H,I accent
class A,C,D,E supporting
+131
View File
@@ -0,0 +1,131 @@
/* @theme nova-sp */
/* Nova S&P Global Energy theme for Marp decks.
*
* Palette: S&P Red (#D6002A), Black (#1B1B1B), White (#FFFFFF), Grey (#F0F0F0).
* Font: Akkurat Pro (fallback Helvetica Neue / Arial).
*
* This theme is a STANDALONE stylesheet (applied via `marp --theme
* nova-sp-theme.css`). It does NOT `@import "default"` because Marp's
* default theme applies `padding: 56px 64px` (which does not reserve
* header/footer space) and other base styles (font, color, list spacing)
* that would conflict with the S&P palette. Instead, this theme sets
* the padding explicitly: 48px top (reserves header space), 40px bottom
* (reserves footer space), 56px sides. This gives precise control over
* the padding budget. (GRILL revision 2 @import rejection documented.)
*
* v1.22 (REQ-254,255,256): added section padding + overflow handling,
* aspect-ratio-aware image rules, title-slide chrome suppression,
* paragraph/list/table spacing tightening.
*/
:root {
--sp-red: #D6002A;
--sp-black: #1B1B1B;
--sp-white: #FFFFFF;
--sp-grey: #F0F0F0;
--sp-dark-grey: #2E2E2E;
}
/* Base section padding reserves header (top) + footer (bottom) space.
* REQ-254: zero padding was the root cause of "out of whack" layout.
* 48px top reserves header chrome; 40px bottom reserves footer chrome;
* 56px sides give breathing room. */
section {
font-family: "Akkurat Pro", "Helvetica Neue", "Arial", sans-serif;
font-size: 22px;
color: var(--sp-black);
background: var(--sp-white);
padding: 48px 56px 40px;
overflow: auto;
}
/* Headings — S&P Red */
h1 { color: var(--sp-red); font-size: 34px; margin-bottom: 0.3em; }
h2 { color: var(--sp-red); font-size: 26px; margin-bottom: 0.2em; }
h3 { color: var(--sp-red); font-size: 22px; margin-bottom: 0.2em; }
h4 { color: var(--sp-dark-grey); font-size: 20px; margin-bottom: 0.15em; }
/* REQ-256: tighten h2 + lead-paragraph spacing (the deck's recurring
* `## Slide N Title` + `**bold lead**` pattern). Default <p> margins
* waste ~44px per slide; this reclaims ~22px. */
section h2 + p { margin-top: 0.2em; }
section p { margin: 0.4em 0; }
/* Title slides — black background, red top border */
section.title {
background: var(--sp-black);
color: var(--sp-white);
border-top: 8px solid var(--sp-red);
}
section.title h1 { color: var(--sp-white); }
section.title h2 { color: var(--sp-white); }
/* REQ-256: suppress header/footer chrome on title slides. The
* `<!-- _class: title -->` + `<!-- _paginate: false -->` directives
* only suppress the page number, not the chrome. This prevents the
* header/footer from colliding with title/appendix content. */
section.title header, section.title footer { display: none; }
/* Tables — grey header with red underline, explicit white body for readability on any background */
table { font-size: 18px; width: 100%; border-collapse: collapse; background: var(--sp-white); }
th { background: var(--sp-grey); border-bottom: 2px solid var(--sp-red); padding: 6px 10px; text-align: left; }
td { background: var(--sp-white); color: var(--sp-black); border-bottom: 1px solid var(--sp-grey); padding: 6px 10px; }
/* Ensure tables on dark/title slides remain readable: white card with a subtle border */
section.title table, section table { background: var(--sp-white); }
section.title td, section td { background: var(--sp-white); color: var(--sp-black); }
section.title th, section th { background: var(--sp-grey); color: var(--sp-black); }
/* REQ-256: dense tables (8 rows) use tighter cell padding so 10-13 row
* tables (slides 8, 12, A1) fit. Apply via `table.dense` class in the
* marp deck. */
table.dense td, table.dense th { padding: 4px 8px; }
table.dense { font-size: 16px; }
/* Blockquotes — red left border */
blockquote { border-left: 4px solid var(--sp-red); color: var(--sp-dark-grey); font-size: 20px; padding-left: 12px; }
/* Code — dark background */
pre { background: var(--sp-black); color: var(--sp-white); border-radius: 4px; padding: 12px; font-size: 16px; }
code { background: var(--sp-grey); color: var(--sp-black); border-radius: 2px; padding: 1px 4px; font-size: 18px; }
pre code { background: transparent; color: inherit; }
/* REQ-255: aspect-ratio-aware image rules. The blunt `max-height: 320px`
* broke `w:` directives on tall images (slide 9) and did nothing for
* ultra-wide images (slide 6). The new rule uses `object-fit: contain`
* and `max-width: 100%` so images scale within the content area without
* ignoring explicit `w:`/`h:` directives. */
img { display: block; margin: 0 auto; max-width: 100%; max-height: 380px; object-fit: contain; }
/* Wide diagrams (ultra-wide aspect): tighter max-height so they don't
* render as a thin strip. Apply via `![w:1000 class:wide]` or rely on
* the default max-height which is already tighter. */
img.wide { max-height: 280px; }
/* Tall diagrams: more vertical room. Apply via `![h:480 class:tall]`. */
img.tall { max-height: 480px; }
/* Header/footer — subtle grey */
header { color: var(--sp-dark-grey); border-bottom: 1px solid var(--sp-grey); }
footer { color: var(--sp-dark-grey); border-top: 1px solid var(--sp-grey); }
/* Maturity badges */
.badge { display: inline-block; padding: 2px 8px; border-radius: 4px; font-size: 14px; font-weight: 600; }
.badge.today { background: #c6f6d5; color: #22543d; }
.badge.planned { background: #fef3c7; color: #78350f; }
/* Pagination — S&P Red progress bar */
.bespoke-progress-parent { background: var(--sp-grey); }
.bespoke-progress-bar { background: var(--sp-red) !important; }
/* Lists — tighter. REQ-256: add ol styling (match ul). */
ul { margin-top: 0.3em; }
ol { margin-top: 0.3em; }
li { margin-bottom: 0.2em; }
/* Strong — S&P Red for emphasis in lead lines */
strong { color: var(--sp-red); }
/* REQ-256: PPTX export fidelity no scrollbars in exported slides.
* The `overflow: auto` above is an authoring-time signal; in print/PPTX
* we clamp to `hidden` so the exported slide is clean. */
@media print {
section { overflow: hidden; }
}
Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 63 KiB

@@ -0,0 +1,327 @@
---
marp: true
theme: nova-sp
paginate: true
size: 16x9
header: 'Nova — The Autonomous Cloud Delivery Platform'
footer: 'Nova — The Autonomous Cloud Delivery Platform'
---
<!-- _class: title -->
<!-- _paginate: false -->
# Nova — The Autonomous Cloud Delivery Platform
**Shifting from Operational Overhead to Strategic Value**
Product Development & Citizen Developer Overview
---
## Slide 1 — The Problem
**Product teams now own their cloud infrastructure — but ownership without discipline is destroying value.**
- **No lifecycle planning.** Resources are authored for creation, not for patching, decommissioning, or rollback — so changes are destructive.
- **Proactive scanning is not part of authoring.** AI-frontier models exploit zero-days at a rapid pace; teams cannot keep up by reacting. Modules must be scanned as code and at runtime — and remediated at the pace the threat moves.
- **Bandwidth gaps in infrastructure operations.** Time spent on remediation + the push for innovation leaves operations chronically under-resourced; detections are missed, incidents grow.
- **Tribal knowledge and the rockstar-operator problem.** Operations depend on a handful of administrators; when they leave, the knowledge leaves with them. The platform should encode the discipline, not the person.
Every hour a developer spends writing, deploying, fixing, or remediating infrastructure is an hour not spent releasing features to production.
**Benefit:** the answer is an autonomous cloud delivery platform that encodes discipline as policy, scans proactively, remediates rapidly, and makes operations visible to leadership rather than hidden in tribal knowledge.
---
## Slide 2 — Nova's Vision
> **Infrastructure operations become visible. Every environment provisioned, every incident healed, every risk remediated — by an autonomous system whose trustworthiness is provable, not promised. Human attestation remains required at stage gates; the operator is never in the loop of normal operations.**
- **Visibility is the recurring theme** — security posture, remediation velocity, reliability, and lead time as queryable signals
- **Provable, not promised** — trust established by deterministic scripts that calculate a score; the platform functions without AI
- **Autonomy in operations, human at stage gates** — QA signs off for production; SRE greenlights operational readiness
**Benefit:** the destination is autonomous operations with provable trust — security, remediation velocity, reliability, and lead time made visible to leadership, not promised to them.
---
## Slide 3 — Strategic Objectives + Anti-Goals
**4 Strategic Objectives:**
1. **Zero-touch operations** — autonomy as the default, not the demo; stage-gate attestation (QA, SRE) remains human by design
2. **Provable trust in automated decisions** — deterministic scripts calculate a score; the platform functions without AI; Decision Ledger, confidence scoring, circuit breakers, blast-radius controls
3. **Compounding, quantifiable ROI** — four CTO-grade metrics, all flowing into PowerBI:
- **Lead Time** (PR → Production) · **Infrastructure Vulnerability Count** (trend) · **MTTR** · **Cloud Spend Reduction**
4. **Integrate with externally owned development platforms — regardless of source** — PDLC, SDLC, Agentic, or Citizen Developer; Nova provides skills + MCP endpoints; all prod intents go through the same controls and quality gates
**4 Anti-Goals (what Nova is NOT):**
1. Not a general-purpose AI agent platform
2. Not a system that removes humans from accountability — only from normal operations
3. Not an upstream development platform (no product backlogs, IDE, code authorship)
4. Not a replacement for the Product Development Lifecycle (PDLC)
**Benefit:** the scope is explicit — Nova governs infrastructure and delivery, integrates with any upstream source through one validated contract, and measures success on four metrics a CTO can repeat back.
---
## Slide 4 — Scope: Downstream of PDLC
**Nova governs infrastructure and delivery. The PDLC is upstream — Nova never penetrates it. Integration is through one validated contract.**
- **The PDLC is upstream:** product backlog, code authorship (AI agent, IDE, agentic SDLC), sprint planning, application business logic
- **Nova is downstream:** contract ingestion → submission-readiness gate → policy enforcement → cloud resource lifecycle → environment progression (dev → qa → prod → dr) → immutable audit + attestation
- **The integration point is one contract** — any upstream source (AI agent, agentic SDLC, dev platform) produces submissions subject to the same compliance standards
- **Nova validates the submission, not the author** — the audit trail, the policy envelope, and the evidence stream are the same regardless of source
**Benefit:** a clean scope boundary — Nova is purpose-built for infrastructure operations and integrates with any upstream source through one validated contract, so the platform team's surface area stays bounded.
---
## Slide 5 — RACI: Who Owns What
**Four roles, one matrix — citizen developer owns FRs + UAT, platform owns NFRs + infra, quality engineering owns the gate evidence, SRE owns operational readiness.**
| Work Category | Citizen Dev | Platform | Quality Eng | SRE |
|---|---|---|---|---|
| Functional Requirements | **R/A** | C | I | I |
| User Acceptance Testing | **R/A** | C | I | I |
| Non-Functional Requirements | I | **R/A** | C | C |
| Infrastructure (cloud, state, IAM) | I | **R/A** | I | C |
| QA (policy, confidence, schema) | C | R | **R/A** | I |
| Production deployment to cloud | I | **R/A** | C | C |
| Quality attestation (QA sign-off) | **A** | R | **R** | I |
| Production readiness (SRE sign-off) | **A** | R | C | **R** |
**R**=Responsible · **A**=Accountable (sign-off) · **C**=Consulted · **I**=Informed. Production readiness is co-owned: the platform runs attestations agentically; the citizen developer authorizes the promotion at the stage gate.
**Benefit:** every party knows what they bring, what the platform provides, what quality engineering guards, and where SRE signs off — accountability is explicit, never diffuse.
---
## Slide 6 — The Platform Pipeline
**How intent becomes verified infrastructure — fail-fast policy scanning before the plan, runtime scanning after it.**
![h:480](assets/png/platform-pipeline.png)
- **Contract → resolver → adapter → Checkov on static code (before plan) → terraform plan → Wiz on the plan → confidence signal → stage gate → apply → evidence + ledger**
- **Fail-fast, quick feedback** — Checkov runs on the authored Terraform code before `terraform plan` so developers get immediate policy feedback
- **Wiz on the plan when configured; Checkov as a drop-in otherwise** — Wiz scans the plan output; when Wiz credentials are absent, Checkov runs against the plan. **Wiz and Checkov are never both run on the plan.**
- **Dev is autonomous** (no stage gate); **qa/prod/dr require human attestation** (QA for quality, SRE for production readiness)
**Benefit:** two layers of scanning, zero operator involvement in normal operations — fast deterministic feedback at authoring time and a runtime scan on the resolved plan.
---
## Slide 7 — The Decision Ledger
**Every automated decision is captured, immutable, queryable — and accountable.**
- **What is captured:** the chosen action, the confidence score, the alternatives considered, whether a human overrode it, and the outcome (backfilled once the apply completes). Every stage-gate attestation (QA, SRE) is captured with approver identity and the evidence presented.
- **"AI decisions" are really automated decisions** — made by deterministic scripts that calculate a score and a band; the platform functions without AI. When an LLM planner is added later, it will emit richer alternatives without breaking the schema.
- **The value is accountability, not the storage engine** — the ledger is append-only and tamper-evident; every decision is queryable for auditing, traceable to an outcome, and impossible to rewrite after the fact.
**Benefit:** "autonomous" is defensible because every decision is immutable, queryable, and accountable — and the audience knows exactly what "automated" means here: deterministic scoring, not a black-box LLM.
---
## Slide 8 — The Attestation Matrix
**The designed controls that keep humans at stage gates — structured, freshness-validated, separation-of-duties-enforced.**
| Concern | Env | Freshness | Description |
|---------|-----|-----------|-------------|
| Functional correctness | qa | 24h | The application behaves as specified; evidence accepted from the consumer's UAT. |
| Performance baseline | qa | 7d | The deployment meets its performance envelope vs. the agreed baseline. |
| Security posture | qa | 24h | The deployment's security findings have been reviewed and accepted. |
| Operational readiness | prod | 30d | SRE confirms the deployment is operable: runbooks, dashboards, on-call. |
| Incident response | prod | 90d | The on-call path has been exercised; a working incident-response plan exists. |
| Capacity & cost | prod | 30d | Capacity headroom and monthly cost are within the agreed envelope. |
| Resilience: DR drill | prod | 180d | A DR drill has been run and recovery met the RTO. |
| Resilience: chaos | prod | 90d | A chaos exercise has been run and the deployment absorbed the failure. |
| Resilience: backup | prod | 30d | Backups are restorable and tested within the freshness window. |
| DR region deploy | dr | 180d | The DR region can be deployed and is reachable. |
Separation-of-duties on prod: the approver cannot be the same person who built the deployment.
**Benefit:** the gate model is explicit — autonomy in operations, human in accountability, by design. The matrix is what makes autonomous operations safe enough to trust in production.
---
## Slide 9 — Telemetry & Live Ops
**Every metric in this deck is traceable to a real emitted signal — the live-ops dashboard makes operations visible in PowerBI.**
![h:480](assets/png/telemetry-live-ops.png)
- **Platform components → CloudEvents envelope → event log + decision ledger + run records → collector → cold store → PowerBI views → live ops dashboard**
- **The live ops dashboard (PowerBI)** surfaces the four CTO-grade metrics (Lead Time, Vulnerability Count, MTTR, Cloud Spend) alongside trust metrics (Decision Ledger coverage, Attestation coverage) and efficiency metrics (touchless resolution, escalation frequency)
- **Deliberately minimal** — Nova-native envelopes; no Kafka, no Prometheus, no ClickHouse. The cold store handles batch and historical analysis; the live-ops surface is built in PowerBI on the exported views
- **Every number is traceable to a signal** — when a CFO asks "where does this number come from?", the answer is a query against the cold store, not a Slack thread
**Benefit:** the architecture is the trust substrate — leadership sees the same numbers the platform produces, in PowerBI, with full traceability. Operations become visible.
---
## Slide 10 — Decision Ledger + Attestation Coverage
**By design, no change reaches production without a ledger entry and a human attestation — both queryable for auditing, with full traceability.**
- **Decision Ledger coverage: 100%** — every platform run emits a decision record with outcome backfill; no automated decision is ever lost
- **Attestation coverage: 100%** — every prod/dr promotion is attested by a human (QA for quality, SRE for production readiness), recorded with approver identity, separation-of-duties check, and the evidence matrix
- **No change to production without both** — the ledger entry and the human attestation are mandatory, enforced by the pipeline, not by policy
- **Easily queried for auditing** — queryable by run, by environment, by approver, and by outcome; the audit trail is a query, not a forensic exercise
- **Full traceability** — a production change is traceable from the contract that declared intent, through the policy scan, the confidence score, the attestation, to the applied outcome
**Benefit:** trust is provable — not a marketing claim, a queryable record. An auditor answers "who approved this, when, on what evidence?" in one query; a CTO answers "how many of last quarter's prod changes were touchless?" in one query.
---
## Slide 11 — Cost & ROI
**The ROI formula and the cost estimates — grounded, with the production denominator honestly flagged.**
- **Cost estimates are pre-apply and offline** — the platform reads the terraform plan and estimates cost before anything is applied; a cost regression is caught before the spend happens
- **The ROI formula:**
`Platform ROI = (FTE hours saved × blended rate + cloud savings + avoided downtime) ÷ platform op cost`
- **The four CTO-grade metrics are the ROI proof:** Lead Time (PR → Prod), Infrastructure Vulnerability Count (trend), MTTR, Cloud Spend Reduction — all flow into PowerBI
- **Honest caveat:** derived metrics are computed on internal runs today; the production-denominator activates when a pilot estate runs. The formula is grounded; the production numbers are not yet.
**Benefit:** the ROI is not a black box — the formula is shown, the four metrics are committed, and the production-denominator caveat is stated up front. The CFO sees exactly what is real today and what activates with a pilot.
---
## Slide 12 — What's Deferred — and Why
**Honesty about what is not measured yet — and the blocking work for each.**
To be clear: these deferrals are *measurement infrastructure*, not the autonomy itself. The platform runs without an operator in the loop of normal operations. What is deferred is the evidence pipeline for certain metrics — not the autonomy.
| # | Deferred metric | Blocking work |
|---|-----------------|---------------|
| 1 | Live infrastructure health | Live AWS re-provisioning (currently torn down to zero-cost steady state) |
| 2 | Live outbox write rate | Live AWS re-provisioning |
| 3 | Tamper-evident ledger checkpoints | Audit-ledger build-out (Object Lock + signed checkpoints) |
| 4 | Onboarding funnel (requested → granted) | Auto-grant implementation |
| 5 | Drift auto-reversal | Drift-detection scheduler (not yet built) |
| 6 | Live cost reconciliation | Live AWS re-provisioning + actual-spend feed |
| 7 | SLA / unplanned downtime | Live AWS re-provisioning |
| 8 | Predictive vs reactive ratio | ML anomaly-forecasting service (not yet built) |
**Benefit:** the boundaries are explicit — what Nova measures today, and exactly what blocks the rest. The autonomy is real; the measurement gaps are documented with the work that unblocks each one.
---
## Slide 13 — Roadmap to the North Star
**The path from the grounded metrics to the 1218 month targets — each deferred metric has an unblock path and a timeframe.**
| Timeframe | Work | Unblocks |
|-----------|------|----------|
| Near-term | Live AWS re-provisioning | Live infra health, outbox write rate, live cost reconciliation, SLA |
| Near-term | Auto-grant implementation | Onboarding funnel (requested → granted) |
| Mid-term | Drift-detection scheduler | Drift auto-reversal |
| Mid-term | Audit-ledger build-out (Object Lock + signed checkpoints) | Tamper-evident ledger checkpoints |
| Mid-term | Hot-path activation (batch → near-real-time) | Live-ops dashboard freshness |
| Longer-term | ML anomaly-forecasting service | Predictive vs reactive ratio |
Re-evaluation triggers: each blocking piece of work lifts on its own schedule; the metrics layer evolves as each one lands.
**Benefit:** every deferred metric has an unblock path — nothing is hand-waved; everything has a plan and a timeframe.
---
## Slide 14 — 12-Month Product Roadmap
**The product arc from pilot activation to integration — four quarters, four outcomes.**
| Quarter | Theme | Board-level outcome |
|---------|-------|---------------------|
| **Q1** | Pilot Activation | Nova runs a real customer estate end-to-end, autonomously, with a measurable zero-touch rate. |
| **Q2** | Provable Trust | Every automated decision lands in a tamper-evident ledger; the CFO sees real cloud-spend reconciliation. |
| **Q3** | Compounding ROI | Quarter-over-quarter cloud spend drops; drift is detected and reversed without a human. |
| **Q4** | Integration & Predictive | AI agents deploy through Nova by default; the ML anomaly-forecasting service goes live. |
Grounded in the four strategic objectives (autonomy, provable trust, ROI, integration) and the deferred-metric unblock paths.
**Benefit:** the 12-month product arc — each quarter activates a strategic objective and its corresponding board-level metric, from pilot activation through integration leadership.
---
## Slide 15 — Quarter-by-Quarter Outcomes
| Quarter | Product theme | Key deliverable | Target metric | Grounding |
|---------|---------------|-----------------|---------------|-----------|
| **Q1** | Pilot Activation | Re-provision live AWS; activate first pilot estate; onboarding auto-grant | Touchless ≥ 99% · Escalation < 0.1% · Accuracy ≥ 99.5% | Objective #1 — autonomy as the default |
| **Q2** | Provable Trust | Tamper-evident ledger (Object Lock + signed checkpoints); daily checkpoints; live cost reconciliation | Decision Ledger Coverage 100% · Cost Savings ≥ 25% | Objective #2 — trust is the moat |
| **Q3** | Compounding ROI + Drift | Drift-detection scheduler; auto-reversal; pre-apply → actual-spend reconciliation on the pilot estate | Drift Auto-Reversal ≥ 95% · Spend Reduction ≥ 25% | Objective #3 — CFO-pointable numbers |
| **Q4** | Integration + Predictive | ML anomaly-forecasting; AI-agent intent surface; multi-cloud (Azure/GCP) preview | Predictive:Reactive ≥ 3:1 · AI-Agent Intent Share (first measurement) | Objective #4 — default substrate for agents |
**Month-18 destination:** *"Nova is the layer enterprise leadership points to when they say 'we don't have an infrastructure ops team anymore, and the audit trail is stronger than it ever was.'"*
**Benefit:** each quarter has a concrete deliverable, a target metric grounded in a strategic objective, and a path from "honestly deferred" to "shipped and measured."
---
## Slide 16 — Production-Grade Guidance via Atelier (1/2)
**Nova instructs the citizen developer's AI agent on production-grade engineering — a set of skills and an MCP server.**
- **Skills** — markdown files keyed to production-grade engineering domains (API, security, data, testing, observability, errors, DevOps, infrastructure-as-code, compliance); the skills extend the baseline catalog with Nova-specific production-grade principles
- **MCP server** — a plugin-registry, stdio server exposing four tools: `lookup_principle`, `list_domains`, `matrix_lookup`, `validate_against_principles`. The developer's AI agent (or any agentic SDLC platform) calls these tools to look up the principles that apply to its submission
- **The integration point is the same regardless of source** — whether the submission comes from an AI coding agent, an agentic SDLC platform, or a traditional IDE, the same skills and MCP server apply. This is how Nova makes the citizen developer production-grade without owning the PDLC
**Benefit:** the citizen developer's AI agent is not unguided — Nova provides production-grade engineering principles as skills and as an MCP surface, so submissions arrive at the contract boundary already aligned with the platform's standards.
---
## Slide 17 — Production-Grade Guidance via Atelier (2/2)
**Agentic validation catches engineering-discipline gaps that deterministic scanners miss — and the validation is reproducible.**
- **Beyond deterministic scanners** — Wiz, Checkmarx, and Mend check policy and secrets; they do not check engineering discipline. The Atelier MCP server catches correctness, clarity, and observability gaps that deterministic tools cannot: "is this service observable?", "is this error path handled?", "is this API contract clear?"
- **Agentic validation, not a second policy engine** — the MCP server gives the AI agent the principles to validate against; the agent does the validation. The agent reasons about the submission against the principles, not a second static scan
- **Vendored for audit reproducibility** — Atelier is vendored at a pinned tag. A validation result is replayable against the exact principles that produced it, so an audit can reproduce a validation months later, not just trust a log line
**Benefit:** the citizen developer's submission is checked for engineering discipline, not just policy compliance — and the check is reproducible for audit. That is what makes the submission production-grade, regardless of which upstream platform produced it.
---
## Slide 18 — Recap + Ask
**The 4-beat recap + the business decision.**
**Recap:**
- **Problem:** product teams own infrastructure without the discipline and lifecycle planning it requires; bandwidth gaps and tribal knowledge leave operations exposed
- **Solution:** autonomous cloud delivery — operations become visible, trust is provable (deterministic scoring), humans at stage gates
- **Proof:** 100% ledger coverage, 100% attestation coverage, grounded ROI formula, four CTO-grade metrics flowing into PowerBI
- **Roadmap:** deferred metrics have unblock paths; the 12-month product arc activates one strategic objective per quarter
**The ask:** "Approve a pilot estate to activate the production-denominator metrics (Lead Time, Vulnerability Count, MTTR, Cloud Spend), and approve the tamper-evident ledger build-out to move from the local hash-chain to S3 Object Lock + signed checkpoints. These two decisions move Nova from 'pipeline-ready' to 'production-proven.'"
**Benefit:** a clear business decision — approve a pilot and the ledger build-out — with the confidence that every claim in this deck is grounded, derived, or honestly deferred.
---
<!-- _class: title -->
<!-- _paginate: false -->
## Appendix A1 — Metrics Glossary
| KPI | Definition | Status |
|-----|-----------|--------|
| Touchless Resolution Rate | runs without operational stage-gate block ÷ total | partial (Post-Pilot) |
| Human Escalation Frequency | operational stage-gate blocks ÷ total | partial (Post-Pilot) |
| Automated Decision Accuracy | decisions not followed by failure within 5min | partial (Post-Pilot) |
| MTTR (p95) | apply.failed → successful retry | grounded |
| Confidence-Gate Halt Rate | runs with band=block ÷ total | grounded |
| Provisioning Lead Time | run.completed run.started | grounded |
| Deployment Frequency | count(run.completed) per day | grounded |
| Cost Savings (pre-apply) | sum(delta_usd where delta < 0) | partial (live reconciliation deferred) |
| FTE Hours Saved | run count × manual baseline × rate | derived (N=0 caveat) |
| Platform ROI | (labor + cloud + avoided downtime) ÷ op cost | derived (N=0 caveat) |
| Decision Ledger Coverage | decisions with outcome ÷ total | grounded |
| Attestation Coverage | prod/dr attested ÷ total prod/dr | grounded |
| Policy Compliance Rate | 1 failed_assets ÷ total | grounded |
**Benefit:** a reference for every metric mentioned in the deck.
@@ -0,0 +1,129 @@
# Nova — The Autonomous Cloud Delivery Platform: Talking Points
> Step 4 of the 4-step deck process. Presenter cues distilled from the
> source of truth (`nova-autonomous-cloud-delivery.md`). 3-6 bullets per
> slide + key takeaway. Indexed by Marp slide #.
> v1.21 — REQ-245
---
### Slide 1 — The Problem
- Open with the shift: "you build it, you run it" put Terraform into product teams — ownership without discipline is destroying value
- Land the lifecycle-planning gap: resources authored for creation, not for patching/rollback → destructive changes
- Land the urgency: AI-era 0-day pace demands proactive scanning as code + at runtime, remediated at threat pace
- Call out tribal knowledge / the rockstar-operator problem — the platform should encode the discipline, not the person
- Do NOT frame this as "humans are the problem" — the problem is ownership without the discipline and tooling
- **Key takeaway:** the problem is infrastructure ownership without discipline; the answer is an autonomous platform that encodes the discipline
### Slide 2 — Nova's Vision
- Read the vision verbatim — "infrastructure operations become visible" is the operative phrase
- Emphasize "provable, not promised" — trust established by deterministic scripts; the platform functions without AI
- State the attestation model up front: QA for production, SRE for operational readiness
- **Key takeaway:** autonomous operations with provable trust — security, remediation velocity, reliability, lead time made visible, not promised
### Slide 3 — Strategic Objectives + Anti-Goals
- Objective #2 is the one to land carefully: trust = deterministic scoring, not an LLM; the platform functions without AI
- Objective #3: four CTO-grade metrics (Lead Time, Vuln Count, MTTR, Spend) — all flow into PowerBI
- Objective #4 is the integration thesis: Nova integrates with any upstream source; provides skills + MCP; all prod intents go through the same controls
- Anti-goals #3 and #4 protect the scope: not an upstream dev platform, not a PDLC replacement
- **Key takeaway:** purpose-built for infra ops, integrates with any source through one contract, measures success on four CTO metrics
### Slide 4 — Scope: Downstream of PDLC
- Nova governs infra + delivery only; the PDLC (backlog, code authorship, IDE) is upstream — Nova never penetrates it
- Integration is only through the validated contract boundary
- Any upstream source (AI agent, agentic SDLC, dev platform) produces submissions subject to the same compliance standards
- Nova validates the submission, not the author
- **Key takeaway:** Nova is purpose-built for infrastructure operations; the scope boundary is clean and bounded
### Slide 5 — RACI: Who Owns What
- Four roles now: Citizen Developer, Platform, Quality Engineering, SRE
- Quality attestation is owned by Quality Engineering (not the Platform); Production readiness is owned by SRE
- The Platform runs the checks agentically but is never the Accountable party for the gate — that separation keeps the platform honest
- Production readiness is co-owned: the platform runs attestations; the citizen developer authorizes the promotion at the stage gate
- **Key takeaway:** you bring FRs + UAT; Nova provides NFRs + infra; QE guards the gate evidence; SRE signs off on production readiness
### Slide 6 — The Platform Pipeline
- Walk the pipeline left-to-right: contract → resolver → adapter → Checkov (static) → plan → Wiz (on plan) → confidence → gate → apply
- Two-stage scan: Checkov on static code BEFORE the plan (fail-fast dev feedback); Wiz on the plan (or Checkov as drop-in if no Wiz creds)
- Never both Wiz + Checkov on the plan — avoid duplicate noise
- Dev is autonomous; qa/prod/dr require attestation (QA for quality, SRE for production readiness)
- **Key takeaway:** two layers of scanning, zero operator involvement in normal operations
### Slide 7 — The Decision Ledger
- "AI decisions" are really automated decisions — deterministic scripts calculate a score; the platform functions without AI
- Do not dwell on the storage substrate — the value is accountability (immutable, queryable, traceable to outcome), not the database
- Every stage-gate attestation is captured with approver identity and the evidence presented
- When an LLM planner is added later, it emits richer alternatives without breaking the schema
- **Key takeaway:** autonomous is defensible because every decision is immutable, queryable, accountable — and "automated" means deterministic scoring, not a black-box LLM
### Slide 8 — The Attestation Matrix
- The matrix is not a rubber stamp — structured, freshness-validated, separation-of-duties-enforced
- Each concern now has a plain-language description of what is being attested (the old "operator-supplied" label is gone)
- SoD on prod: the approver can't be the same person who built it
- **Key takeaway:** autonomy in operations, human in accountability, by design — the matrix is what makes autonomous operations safe enough to trust in production
### Slide 9 — Telemetry & Live Ops
- Deliberately minimal: Nova-native CloudEvents; no Kafka/Prometheus/ClickHouse
- The live-ops dashboard is built in PowerBI on top of the exported views — leadership sees the same numbers the platform produces
- Every number in the Proof slides is traceable to a signal — "where does this number come from?" → a query against the cold store
- This is where the "infrastructure operations become visible" theme lands concretely
- **Key takeaway:** the architecture is the trust substrate — operations become visible in PowerBI, with full traceability
### Slide 10 — Decision Ledger + Attestation Coverage
- Both 100% — no automated decision is ever lost; no prod/dr promotion lands without a human sign-off
- The mandatory-by-design point: the ledger entry + the human attestation are a gate, not a best-effort feature
- Easily queried: by run, by environment, by approver, by outcome — the audit trail is a query, not a forensic exercise
- **Key takeaway:** trust is provable — not a marketing claim, a queryable record; no change to production without both the ledger entry and the human attestation
### Slide 11 — Cost & ROI
- The ROI formula is shown inline — not hidden in a footnote
- The four CTO-grade metrics are the ROI proof — Lead Time, Vuln Count, MTTR, Cloud Spend
- The N=0 caveat is stated explicitly: the formula is grounded; the production numbers activate with a pilot
- **Key takeaway:** the ROI is not a black box — the formula is shown, the four metrics are committed, the production-denominator caveat is up front
### Slide 12 — What's Deferred — and Why
- The preempt is critical: these deferrals are measurement infrastructure, not autonomy — the platform IS autonomous in operations
- The blocking work is named in plain language (no decision IDs) — "live AWS re-provisioning", "drift-detection scheduler", "ML service"
- Showing this to leadership demonstrates honesty, not weakness
- **Key takeaway:** the autonomy is real; the measurement gaps are documented with the work that unblocks each one
### Slide 13 — Roadmap to the North Star
- Each deferred metric has an unblock path and a timeframe — near-term, mid-term, longer-term
- No status column: most of it is not implemented yet, so status would be noise
- Re-evaluation triggers: each blocking piece of work lifts on its own schedule
- **Key takeaway:** every deferred metric has a plan and a timeframe — nothing is hand-waved
### Slide 14 — 12-Month Product Roadmap
- This is the *product* roadmap, forward-looking only
- Q1 Pilot Activation → Q2 Provable Trust → Q3 Compounding ROI → Q4 Integration & Predictive
- Each quarter activates one strategic objective from the North Star
- **Key takeaway:** the 12-month product arc — each quarter activates a strategic objective and its board-level metric
### Slide 15 — Quarter-by-Quarter Outcomes
- Q1: three post-pilot metrics go live (Touchless ≥99%, Escalation <0.1%, Accuracy ≥99.5%) — denominator activates with the pilot
- Q2: Decision Ledger Coverage was already grounded — tamper-evidence is the Q2 upgrade (local hash-chain → Object Lock + signed checkpoints)
- Q3: Drift Auto-Reversal ≥95% unblocks when the drift scheduler ships; Spend Reduction ≥25% measured against the pilot baseline
- Q4: Predictive:Reactive ≥3:1 requires the ML forecasting service; AI-Agent Intent Share is a first measurement (aspirational-metric)
- **Key takeaway:** each quarter has a concrete deliverable, a target metric grounded in a strategic objective, and a path from deferred to shipped
### Slide 16 — Production-Grade Guidance via Atelier (1/2)
- Nova instructs the citizen developer's AI agent via skills (markdown, keyed to engineering domains) + an MCP server (4 tools, plugin-registry, stdio)
- The integration point is the same regardless of source — AI agent, agentic SDLC, traditional IDE all get the same skills + MCP
- This is how Nova makes the citizen developer production-grade without owning the PDLC
- **Key takeaway:** the citizen developer's AI agent is not unguided — Nova provides engineering principles as skills + MCP
### Slide 17 — Production-Grade Guidance via Atelier (2/2)
- The value is the gap deterministic scanners leave: engineering discipline (Wiz/Checkmarx/Mend check policy/secrets, not discipline)
- The MCP server catches "is this service observable?", "is this error path handled?", "is this API contract clear?"
- Vendored at a pinned tag → audit reproducibility — a validation result is replayable months later
- **Key takeaway:** submissions are checked for engineering discipline, not just policy compliance — and the check is reproducible for audit
### Slide 18 — Recap + Ask
- Recap the 4-beat arc so the audience leaves with the structure
- The ask is a business decision: approve a pilot estate + the tamper-evident ledger build-out
- "Pipeline-ready" → "production-proven" is the value proposition
- **Key takeaway:** approve a pilot + the ledger build-out to move from pipeline-ready to production-proven
### Appendix A1 — Metrics Glossary
- Reference for every metric mentioned in the deck
- Use if the audience asks "what does X mean?"
File diff suppressed because one or more lines are too long
@@ -0,0 +1,713 @@
# Nova — The Autonomous Cloud Delivery Platform
> **Source of truth** (Step 1 of the 4-step deck process).
> Unified narrative deck. 4-beat arc: Problem → Solution → Proof →
> Roadmap + Ask. x3 structure at deck level (opening = the problem + the
> arc, body = tell them, closing = recap + ask) AND per slide (opens with
> what it covers, delivers, closes with a benefit callout written for a
> tech-leadership audience).
>
> **Honesty model:** every metric cited is grounded (cites a source),
> derived (documented formula), or deferred (cites the blocking work).
> No fabricated numbers. Internal provenance (decision IDs, requirement
> IDs, internal file paths) is kept out of the audience-facing slides —
> those live in the appendix and the `.ciagent/` files only.
>
> v1.21 — Deck Refinement & Pipeline Hardening
---
## Slide 1 — The Problem
**Product teams now own their cloud infrastructure — but ownership without
discipline is destroying value.**
The broad shift to "you build it, you run it" put Terraform into the hands
of product teams. The intention was right: teams that own their stack ship
faster. The reality is that infrastructure-as-code is a different craft
from software development, and the engineering standards that teams apply
to application code are rarely applied to the infrastructure that carries
it.
- **No lifecycle planning.** Resources are authored for creation, not for
patching, decommissioning, or rollback. When a change is needed, the
change is destructive — because no one planned the lifecycle.
- **Proactive scanning is not part of authoring.** In a year where
AI-frontier models discover and exploit zero-day vulnerabilities at a
rapid pace, teams cannot keep up by reacting. Infrastructure modules
must be scanned as code and at runtime, post-deployment — and remediated
at the pace the threat moves, not the pace a sprint allows.
- **Bandwidth gaps in infrastructure operations.** An unusual amount of
time is spent on remediation, the push for innovation does not pause,
and the result is that operational work is chronically under-resourced.
Gaps open. Detections are missed. Incidents grow.
- **Tribal knowledge and the rockstar-operator problem.** Operations
depend on a handful of administrators who hold the infrastructure in
their heads. When they leave, the knowledge leaves with them. The
platform should encode the discipline, not the person.
Every hour a developer spends writing, deploying, fixing, or remediating
infrastructure is an hour not spent releasing features to production and
generating value.
> **Benefit:** the rest of this deck shows the answer — an autonomous
> cloud delivery platform that encodes infrastructure discipline as
> policy, scans proactively, remediates rapidly, and makes operations
> visible to leadership rather than hidden in tribal knowledge.
> **Speaker notes:** Do not frame this as "humans are the problem." The
> problem is that ownership was granted without the discipline, tooling,
> and lifecycle planning that infrastructure requires. The operator is
> not the bottleneck because operators exist — the bottleneck is that
> operations depend on a few individuals instead of an encoded system.
> **Transition:** "Here is the destination Nova is building toward."
---
## Slide 2 — Nova's Vision
**Infrastructure operations become visible. Every environment provisioned,
every incident healed, every risk remediated — by an autonomous system
whose trustworthiness is provable, not promised. Human attestation remains
required at stage gates; the operator is never in the loop of normal
operations.**
- **Visibility is the recurring theme.** Security posture, remediation
velocity, reliability, and lead time are surfaced as queryable signals —
not hidden in a person's head or a Slack thread.
- **Provable, not promised.** Trust is established by deterministic
scripts that calculate a score and gate the action. The platform
functions without AI. "AI decisions" are really automated decisions.
- **Autonomy in operations, human at stage gates.** QA signs off for
production; SRE greenlights based on operational readiness. The
absence of an operator in the loop is never the absence of a record.
> **Benefit:** the destination is autonomous operations with provable
> trust — security, remediation velocity, reliability, and lead time made
> visible to leadership, not promised to them.
> **Speaker notes:** "Visible" is the operative word. The vision is not
> just that operations run without an operator — it is that operations
> become observable, queryable, and accountable. That is what makes the
> trust defensible.
> **Transition:** "The vision is ambitious — here are the strategic
> objectives that make it concrete, and the anti-goals that keep it
> focused."
---
## Slide 3 — Strategic Objectives + Anti-Goals
**Four objectives Nova is building toward; four anti-goals that keep it
focused.**
**4 Strategic Objectives:**
1. **Demonstrate production-grade zero-touch operations** — autonomy as
the default, not the demo. Stage-gate attestation (QA, SRE) remains
human by design.
2. **Establish provable trust in automated decisions** — deterministic
scripts calculate a score; a band outcome gates the action. The
platform functions without AI. The Decision Ledger, confidence
scoring, circuit breakers, and blast-radius controls make
"autonomous" a defensible claim, not a marketing one.
3. **Deliver compounding, quantifiable ROI** — measured on four CTO-grade
metrics, all flowing into PowerBI:
- **Lead Time** (PR → Production) — downward trend.
- **Infrastructure Vulnerability Count** — downward trend
(proactive scanning keeps up with the AI-era 0-day pace).
- **MTTR** — for platform-detected and platform-remediated incidents.
- **Cloud Spend Reduction** — on pilot estates vs. the pre-Nova
baseline.
4. **Integrate with externally owned development platforms — regardless
of source.** Nova integrates with externally owned PDLC, SDLC,
Agentic, and Citizen Developer platforms. Nova provides skills and
MCP endpoints that help the developer or AI agent make their
application production-grade. Regardless of the source, all intents
to deploy to production go through the same rigorous controls,
quality gates, attestation, and evidence stream.
**4 Anti-Goals (what Nova is NOT):**
1. Not a general-purpose AI agent platform.
2. Not a system that removes humans from accountability — only from
normal operations.
3. Not an upstream development platform (no product backlogs, IDE, code
authorship).
4. Not a replacement for the Product Development Lifecycle (PDLC).
> **Benefit:** the scope is explicit — Nova governs infrastructure and
> delivery, integrates with any upstream source through one validated
> contract, and measures success on four metrics a CTO can repeat back.
> **Speaker notes:** Objective #2 is the one to land carefully: trust is
> established by deterministic scoring, not by an LLM. The platform
> functions without AI. Anti-goals #3 and #4 protect the scope boundary —
> Nova will not become an IDE or a product-planning tool.
> **Transition:** "The scope boundary is explicit — here is exactly
> where Nova sits relative to the product development lifecycle."
---
## Slide 4 — Scope: Downstream of PDLC
**Nova governs infrastructure and delivery. The PDLC is upstream — Nova
never penetrates it. Integration is through one validated contract.**
- **The PDLC is upstream:** product backlog, code authorship (AI agent,
IDE, agentic SDLC), sprint planning, application business logic.
- **Nova is downstream:** contract ingestion → submission-readiness gate
→ policy enforcement → cloud resource lifecycle → environment
progression (dev → qa → prod → dr) → immutable audit + attestation.
- **The integration point is one contract.** The citizen developer's AI
coding agent, an upstream agentic SDLC platform, or any development
platform may all produce submissions — the source does not matter
because all are subject to the same compliance standards.
- **Nova validates the submission, not the author.** The audit trail is
the same; the policy envelope is the same; the evidence stream is the
same.
> **Benefit:** a clean scope boundary — Nova is purpose-built for
> infrastructure operations and integrates with any upstream source
> through one validated contract, so the platform team's surface area
> stays bounded.
> **Speaker notes:** This slide protects the scope. The moment Nova
> starts owning the PDLC, it loses focus. The contract boundary is what
> keeps Nova deep on infrastructure and delivery rather than shallow on
> everything.
> **Transition:** "With the scope clear, here is who owns what across the
> delivery lifecycle."
---
## Slide 5 — RACI: Who Owns What
**Four roles, one matrix — the citizen developer owns FRs + UAT, the
platform owns NFRs + infra, quality engineering owns the gate evidence,
and SRE owns operational readiness.**
| Work Category | Citizen Dev | Platform | Quality Eng | SRE |
|---|---|---|---|---|
| Functional Requirements | **R/A** | C | I | I |
| User Acceptance Testing | **R/A** | C | I | I |
| Non-Functional Requirements | I | **R/A** | C | C |
| Infrastructure (cloud, state, IAM) | I | **R/A** | I | C |
| QA (policy, confidence, schema) | C | R | **R/A** | I |
| Production deployment to cloud | I | **R/A** | C | C |
| Quality attestation (QA sign-off) | **A** | R | **R** | I |
| Production readiness (SRE sign-off) | **A** | R | C | **R** |
**R** = Responsible · **A** = Accountable (sign-off) · **C** = Consulted · **I** = Informed.
- **Compliance-standard equivalence:** FRs + UAT may come from any
upstream source (AI agent, agentic SDLC, dev platform) — all pass the
same submission-readiness gate.
- **Production readiness is co-owned:** the platform runs the
attestations agentically; the citizen developer authorizes the
promotion at the stage gate.
> **Benefit:** every party knows what they bring, what the platform
> provides, what quality engineering guards, and where SRE signs off —
> accountability is explicit, never diffuse.
> **Speaker notes:** Quality attestation is now owned by Quality
> Engineering (not the Platform), and Production readiness is owned by
> SRE. The Platform runs the checks agentically but is never the
> Accountable party for the gate — that separation keeps the platform
> honest.
> **Transition:** "With ownership clear, here is how the pipeline
> enforces it."
---
## Slide 6 — The Platform Pipeline
**How intent becomes verified infrastructure — with fail-fast policy
scanning before the plan and runtime scanning after it.**
```mermaid
graph LR
A[Contract] --> B[Resolver]
B --> C[Adapter]
C --> D["Checkov (static code)"]
D --> E[Terraform Plan]
E --> F["Wiz (on plan)"]
F --> G[Confidence Signal]
G --> H{Stage Gate}
H -->|dev: autonomous| I[Apply]
H -->|qa/prod/dr: attested| I
I --> J[Evidence + Ledger]
```
- **Contract → resolver → adapter → Checkov on static code (before the
plan) → terraform plan → Wiz on the plan → confidence signal → stage
gate → apply → evidence + ledger.**
- **Fail-fast, quick feedback.** Checkov runs on the authored Terraform
code before `terraform plan` so developers get immediate policy
feedback, not a delayed plan-stage failure.
- **Wiz on the plan when configured; Checkov as a drop-in otherwise.**
Wiz scans the terraform plan output. When Wiz credentials are not
available, Checkov runs against the plan as a drop-in replacement. Wiz
and Checkov are never both run on the plan.
- **Dev is autonomous** (no stage gate); **qa/prod/dr require human
attestation** (QA for quality, SRE for production readiness).
> **Benefit:** the pipeline gives developers fast, deterministic feedback
> on policy at authoring time and gives the platform a runtime scan on the
> resolved plan — two layers of scanning, zero operator involvement in
> normal operations.
> **Speaker notes:** The two-stage scan is the key design: static code
> scanning catches policy violations before the cost of a plan; runtime
> plan scanning catches what the static code cannot (resolved values,
cross-resource issues). The platform picks the runtime scanner based on
configuration — never both, to avoid duplicate noise.
> **Transition:** "The pipeline produces decisions — here is how every
> decision is captured and made accountable."
---
## Slide 7 — The Decision Ledger
**Every automated decision is captured, immutable, queryable — and
accountable.**
- **What is captured:** every action the platform takes — the chosen
action, the confidence score, the alternatives considered, whether a
human overrode it, and the outcome (backfilled once the apply
completes). Every stage-gate attestation (QA sign-off, SRE
production-readiness sign-off) is captured with approver identity and
the evidence that was presented.
- **"AI decisions" are really automated decisions.** The decisions are
made by deterministic scripts that calculate a score and a band; the
platform functions without AI. The ledger captures the real decision
path — not a fabricated "AI agent." When an LLM planner is added later,
it will emit richer alternatives without breaking the schema.
- **The value is accountability, not the storage engine.** The ledger is
an append-only, tamper-evident record. The point is not which database
it lives in — the point is that every decision is queryable for
auditing, traceable to an outcome, and impossible to rewrite after the
fact.
> **Benefit:** "autonomous" is defensible because every decision the
> platform makes is immutable, queryable, and accountable — and the
> audience knows exactly what "automated" means here: deterministic
> scoring, not a black-box LLM.
> **Speaker notes:** Do not dwell on the storage substrate. The audience
> cares that the ledger is append-only, queryable, and tied to outcomes —
> not that it is a hash-chain in a SQLite file. The D-122 honesty point
> is restated without the decision ID: the platform's decisions are
> deterministic; the ledger captures that real path.
> **Transition:** "Decisions are captured — here is how stage-gate
> attestation keeps humans in accountability."
---
## Slide 8 — The Attestation Matrix
**The designed controls that keep humans at stage gates — structured,
freshness-validated, and separation-of-duties-enforced.**
| Concern | Env | Freshness | Description |
|---------|-----|-----------|-------------|
| Functional correctness | qa | 24h | The application behaves as specified; evidence accepted from the consumer's UAT. |
| Performance baseline | qa | 7d | The deployment meets its performance envelope vs. the agreed baseline. |
| Security posture | qa | 24h | The deployment's security findings have been reviewed and accepted. |
| Operational readiness | prod | 30d | SRE confirms the deployment is operable: runbooks, dashboards, on-call coverage. |
| Incident response | prod | 90d | The on-call path has been exercised; the deployment has a working incident-response plan. |
| Capacity & cost | prod | 30d | Capacity headroom and monthly cost are within the agreed envelope. |
| Resilience: DR drill | prod | 180d | A DR drill has been run and the deployment recovered within the RTO. |
| Resilience: chaos | prod | 90d | A chaos exercise has been run and the deployment absorbed the failure. |
| Resilience: backup | prod | 30d | Backups are restorable and have been tested within the freshness window. |
| DR region deploy | dr | 180d | The DR region can be deployed and the deployment is reachable from it. |
- Each concern has a freshness window — evidence older than the window
does not satisfy the gate.
- **Separation-of-duties on prod:** the approver cannot be the same
person who built the deployment.
- Concerns that are offline-testable run for real; concerns that require
external evidence accept signed artifacts.
> **Benefit:** the gate model is explicit — autonomy in operations,
> human in accountability, by design. The matrix is what makes autonomous
> operations safe enough to trust in production.
> **Speaker notes:** The matrix is not a rubber stamp. Each concern has a
> freshness window, a description, and a separation-of-duties rule. The
> "operator-supplied" label from the prior deck was dropped — every
> concern now has a plain-language description of what is being attested.
> **Transition:** "You've seen how Nova works — the pipeline, the ledger,
> the attestation gates. Here is how Nova instruments itself so that
> every claim in this deck is traceable to a real signal."
---
## Slide 9 — Telemetry & Live Ops
**Every metric in this deck is traceable to a real emitted signal — and
the live-ops dashboard makes operations visible in PowerBI.**
```mermaid
graph TB
A[Platform components] --> B[CloudEvents envelope]
B --> C[Event log]
B --> D[Decision ledger]
B --> E[Run records]
C --> F[Collector]
D --> F
E --> F
F --> G[Cold store]
G --> H[PowerBI views]
H --> I[Live ops dashboard]
```
- **Platform components emit a CloudEvents envelope** → event log,
decision ledger, and run records → collector → cold store → PowerBI
views → **live ops dashboard.**
- **The live ops dashboard (PowerBI)** surfaces the four CTO-grade
metrics — Lead Time, Infrastructure Vulnerability Count, MTTR, Cloud
Spend — alongside the trust metrics (Decision Ledger coverage,
Attestation coverage) and the efficiency metrics (touchless
resolution, escalation frequency).
- **The architecture is deliberately minimal.** Nova-native envelopes;
no Kafka, no Prometheus, no ClickHouse. The cold store is sufficient
for batch and historical analysis; the live-ops surface is built in
PowerBI on top of the exported views.
- **Every number in the Proof slides is traceable to a signal.** When a
CFO asks "where does this number come from?", the answer is a query
against the cold store, not a Slack thread.
> **Benefit:** the architecture is the trust substrate — leadership sees
> the same numbers the platform produces, in PowerBI, with full
> traceability to the emitted signal. Operations become visible.
> **Speaker notes:** The value is not the plumbing — it is that the
> platform's metrics surface in a tool leadership already uses (PowerBI),
> and every number is traceable. The live-ops dashboard is where the
> "infrastructure operations become visible" theme lands concretely.
> **Transition:** "The architecture is sound — here is the measured
> proof."
---
## Slide 10 — Decision Ledger + Attestation Coverage
**By design, no change reaches production without a ledger entry and a
human attestation — both queryable for auditing, with full
traceability.**
- **Decision Ledger coverage: 100%.** Every platform run emits a
decision record with outcome backfill. No automated decision is ever
lost.
- **Attestation coverage: 100%.** Every prod/dr promotion is attested by
a human — QA for quality, SRE for production readiness — recorded with
approver identity, separation-of-duties check, and the evidence matrix.
- **No change to production without both.** The ledger entry and the
human attestation are mandatory, not optional. This is enforced by the
pipeline, not by policy.
- **Easily queried for auditing.** The ledger and the attestation
records are queryable by run, by environment, by approver, and by
outcome — the audit trail is a query, not a forensic exercise.
- **Full traceability.** A production change is traceable from the
contract that declared intent, through the policy scan, the confidence
score, the attestation, to the applied outcome. Nothing is opaque.
> **Benefit:** trust is provable — not a marketing claim, a queryable
> record. An auditor can answer "who approved this, when, on what
> evidence?" in one query; a CTO can answer "how many of last quarter's
> prod changes were touchless?" in one query.
> **Speaker notes:** The mandatory-by-design point is the one to land.
> The ledger + attestation are not a best-effort feature; they are a
> gate. No change reaches production without both. That is what makes
> the 100% numbers credible — they are enforced, not aspirational.
> **Transition:** "Trust is provable — here is the cost side of the ROI."
---
## Slide 11 — Cost & ROI
**The ROI formula and the cost estimates — grounded, with the production
denominator honestly flagged.**
- **Cost estimates are pre-apply and offline.** The platform reads the
terraform plan and estimates cost before anything is applied — so a
regression in cost is caught before the spend happens, not after.
- **The ROI formula:**
`Platform ROI = (FTE hours saved × blended rate + cloud savings + avoided downtime) ÷ platform op cost`
- **The four CTO-grade metrics (from Slide 3) are the ROI proof:**
Lead Time (PR → Prod), Infrastructure Vulnerability Count (trend), MTTR,
Cloud Spend Reduction. All flow into PowerBI.
- **Honest caveat:** the derived metrics are computed on internal runs
today; the production-denominator activates when a pilot estate runs.
The formula is grounded; the production numbers are not yet.
> **Benefit:** the ROI is not a black box — the formula is shown, the
> four metrics are committed, and the production-denominator caveat is
> stated up front. The CFO can see exactly what is real today and what
> activates with a pilot.
> **Speaker notes:** The formula is shown inline, not hidden. The
> "no fabrication" constraint in action: show the formula, show the
> caveat, do not pretend the production numbers exist.
> **Transition:** "The proof is grounded — here is what is honestly
> deferred, and why."
---
## Slide 12 — What's Deferred — and Why
**Honesty about what is not measured yet — and the blocking work for
each.**
To be clear: these deferrals are measurement infrastructure, not the
autonomy itself. The platform runs without an operator in the loop of
normal operations. What is deferred is the evidence pipeline for certain
metrics — not the autonomy.
| # | Deferred metric | Blocking work |
|---|-----------------|---------------|
| 1 | Live infrastructure health | Live AWS re-provisioning (currently torn down to a zero-cost steady state) |
| 2 | Live outbox write rate | Live AWS re-provisioning |
| 3 | Tamper-evident ledger checkpoints | Audit-ledger build-out (S3 Object Lock + signed checkpoints) |
| 4 | Onboarding funnel (requested → granted) | Auto-grant implementation |
| 5 | Drift auto-reversal | Drift-detection scheduler (not yet built) |
| 6 | Live cost reconciliation | Live AWS re-provisioning + actual-spend feed |
| 7 | SLA / unplanned downtime | Live AWS re-provisioning |
| 8 | Predictive vs reactive ratio | ML anomaly-forecasting service (not yet built) |
> **Benefit:** the boundaries are explicit — what Nova measures today,
> and exactly what blocks the rest. The autonomy is real; the measurement
> gaps are documented with the work that unblocks each one.
> **Speaker notes:** The preempt is critical: these deferrals are
> measurement infrastructure, not autonomy. The platform runs without an
> operator in the loop. What is deferred is the evidence pipeline for
> live-infra health, drift, predictive remediation — not the autonomy
> itself.
> **Transition:** "The proof is honest — here is the roadmap from here to
> the targets."
---
## Slide 13 — Roadmap to the North Star
**The path from the grounded metrics to the 1218 month targets — each
deferred metric has an unblock path and a candidate milestone.**
| Timeframe | Work | Unblocks |
|-----------|------|----------|
| Near-term | Live AWS re-provisioning | Live infra health, live outbox write rate, live cost reconciliation, SLA |
| Near-term | Auto-grant implementation | Onboarding funnel (requested → granted) |
| Mid-term | Drift-detection scheduler | Drift auto-reversal |
| Mid-term | Audit-ledger build-out (Object Lock + signed checkpoints) | Tamper-evident ledger checkpoints |
| Mid-term | Hot-path activation (live-ops dashboard goes from batch to near-real-time) | Live-ops dashboard freshness |
| Longer-term | ML anomaly-forecasting service | Predictive vs reactive ratio |
- Each deferred metric has a specific unblock requirement and a
candidate future milestone.
- Re-evaluation triggers: each blocking piece of work lifts on its own
schedule; the metrics layer evolves as each one lands.
> **Benefit:** every deferred metric has an unblock path — nothing is
> hand-waved; everything has a plan and a timeframe.
> **Speaker notes:** This is the bridge from "honestly deferred" to
> "here is how we get there." The roadmap uses timeframes, not status —
> most of it is not implemented yet, so a status column would be noise.
> **Transition:** "The unblock path is clear — here is the 12-month
> product arc."
---
## Slide 14 — 12-Month Product Roadmap
**The product arc from pilot activation to integration — four quarters,
four outcomes.**
| Quarter | Theme | Board-level outcome |
|---------|-------|---------------------|
| **Q1** | Pilot Activation | Nova runs a real customer estate end-to-end, autonomously, with a measurable zero-touch rate. |
| **Q2** | Provable Trust | Every automated decision lands in a tamper-evident ledger; the CFO sees real cloud-spend reconciliation. |
| **Q3** | Compounding ROI | Quarter-over-quarter cloud spend drops; drift is detected and reversed without a human. |
| **Q4** | Integration & Predictive | AI agents deploy through Nova by default; the ML anomaly-forecasting service goes live. |
Grounded in the four strategic objectives (autonomy, provable trust, ROI,
integration) and the deferred-metric unblock paths.
> **Benefit:** the 12-month product arc — each quarter activates a
> strategic objective and its corresponding board-level metric, from
> pilot activation through integration leadership.
> **Speaker notes:** The roadmap is organized by product outcome, not
> by technical milestone. Each quarter activates one strategic
> objective from the North Star.
> **Transition:** "Here is the quarter-by-quarter detail."
---
## Slide 15 — Quarter-by-Quarter Outcomes
| Quarter | Product theme | Key deliverable | Target metric | Grounding |
|---------|---------------|-----------------|---------------|-----------|
| **Q1** | Pilot Activation | Re-provision live AWS; activate first pilot estate; onboarding auto-grant | Touchless ≥ 99% · Escalation < 0.1% · Accuracy ≥ 99.5% | Objective #1 — autonomy as the default |
| **Q2** | Provable Trust | Tamper-evident ledger (Object Lock + signed checkpoints); daily checkpoints; live cost reconciliation | Decision Ledger Coverage 100% · Cost Savings ≥ 25% | Objective #2 — trust is the moat |
| **Q3** | Compounding ROI + Drift | Drift-detection scheduler; auto-reversal; pre-apply → actual-spend reconciliation on the pilot estate | Drift Auto-Reversal ≥ 95% · Spend Reduction ≥ 25% | Objective #3 — CFO-pointable numbers |
| **Q4** | Integration + Predictive | ML anomaly-forecasting; AI-agent intent surface; multi-cloud (Azure/GCP) preview | Predictive:Reactive ≥ 3:1 · AI-Agent Intent Share (first measurement) | Objective #4 — default substrate for agents |
**Month-18 destination:** *"Nova is the layer enterprise leadership
points to when they say 'we don't have an infrastructure ops team
anymore, and the audit trail is stronger than it ever was.'"*
> **Benefit:** each quarter has a concrete deliverable, a target metric
> grounded in a strategic objective, and a path from "honestly deferred"
> to "shipped and measured."
> **Speaker notes:** Q1Q3 are committed (grounded pipeline + known
> unblock paths). Q4 targets are committed-deliverable,
> aspirational-metric — the ML service ships, the intent-share number is
> a first measurement (we do not control adoption rate).
> **Transition:** "Production-grade guidance is how Nova helps the
> citizen developer's AI agent meet the bar — here is the first half."
---
## Slide 16 — Production-Grade Guidance via Atelier (1/2)
**Nova instructs the citizen developer's AI agent on production-grade
engineering — a set of skills and an MCP server.**
- **Skills** — markdown files keyed to production-grade engineering
domains (API, security, data, testing, observability, errors, DevOps,
infrastructure-as-code, compliance). The skills extend the baseline
catalog with Nova-specific production-grade principles.
- **MCP server** — a plugin-registry, stdio server exposing four tools:
`lookup_principle`, `list_domains`, `matrix_lookup`, and
`validate_against_principles`. The developer's AI agent (or any
agentic SDLC platform) calls these tools to look up the principles
that apply to its submission.
- **The integration point is the same regardless of source.** Whether
the submission comes from an AI coding agent, an agentic SDLC
platform, or a traditional IDE, the same skills and MCP server apply.
This is how Nova makes the citizen developer production-grade without
owning the PDLC.
> **Benefit:** the citizen developer's AI agent is not unguided — Nova
> provides production-grade engineering principles as skills and as an
> MCP surface, so submissions arrive at the contract boundary already
> aligned with the platform's standards.
> **Speaker notes:** This is the first half of the Atelier story — the
> surface (skills + MCP). The next slide is what the surface catches
> that deterministic scanners cannot.
> **Transition:** "Here is what that guidance catches that deterministic
> scanners cannot."
---
## Slide 17 — Production-Grade Guidance via Atelier (2/2)
**Agentic validation catches engineering-discipline gaps that deterministic
scanners miss — and the validation is reproducible.**
- **Beyond deterministic scanners.** Wiz, Checkmarx, and Mend check
policy and secrets — they do not check engineering discipline. The
Atelier MCP server catches correctness, clarity, and observability gaps
that deterministic tools cannot: "is this service observable?",
"is this error path handled?", "is this API contract clear?"
- **Agentic validation, not a second policy engine.** The MCP server
gives the AI agent the principles to validate against; the agent does
the validation. This is agentic validation — the agent reasons about
the submission against the principles, not a second static scan.
- **Vendored for audit reproducibility.** Atelier is vendored at a
pinned tag. A validation result is replayable against the exact
principles that produced it — so an audit can reproduce a validation
months later, not just trust a log line.
> **Benefit:** the citizen developer's submission is checked for
> engineering discipline, not just policy compliance — and the check is
> reproducible for audit. That is what makes the submission
> production-grade, regardless of which upstream platform produced it.
> **Speaker notes:** The value is the gap deterministic scanners leave:
engineering discipline. Policy scanners catch "is this S3 bucket
public?"; the MCP server catches "is this service observable if that
bucket fails?". The vendoring point is audit reproducibility — the
validation is not a black box.
> **Transition:** "You've seen the problem, the solution, and the proof.
> Here is the recap and the ask."
---
## Slide 18 — Recap + Ask
**The 4-beat recap + the business decision.**
**Recap:**
- **Problem:** product teams own infrastructure without the discipline
and lifecycle planning it requires; bandwidth gaps and tribal
knowledge leave operations exposed.
- **Solution:** autonomous cloud delivery — operations become visible,
trust is provable (deterministic scoring), humans at stage gates.
- **Proof:** 100% ledger coverage, 100% attestation coverage, grounded
ROI formula, four CTO-grade metrics flowing into PowerBI.
- **Roadmap:** deferred metrics have unblock paths; the 12-month product
arc activates one strategic objective per quarter.
**The ask:** "Approve a pilot estate to activate the production-denominator
metrics (Lead Time, Vulnerability Count, MTTR, Cloud Spend), and approve
the tamper-evident ledger build-out to move from the local hash-chain to
S3 Object Lock + signed checkpoints. These two decisions move Nova from
'pipeline-ready' to 'production-proven.'"
> **Benefit:** a clear business decision — approve a pilot and the ledger
> build-out — with the confidence that every claim in this deck is
> grounded, derived, or honestly deferred.
> **Speaker notes:** The ask is a business decision, not insider
> language. "Approve a pilot estate" is a C-suite decision. "Approve the
> ledger build-out" is a budget decision. The recap reinforces the 4-beat
> arc — the audience leaves with the structure, not a pile of facts.
---
## Appendix A1 — Metrics Glossary
| KPI | Definition | Status |
|-----|-----------|--------|
| Touchless Resolution Rate | runs without operational stage-gate block ÷ total | partial (Post-Pilot) |
| Human Escalation Frequency | operational stage-gate blocks ÷ total | partial (Post-Pilot) |
| Automated Decision Accuracy | decisions not followed by failure within 5min | partial (Post-Pilot) |
| MTTR (p95) | apply.failed → successful retry | grounded |
| Confidence-Gate Halt Rate | runs with band=block ÷ total | grounded |
| Provisioning Lead Time | run.completed run.started | grounded |
| Deployment Frequency | count(run.completed) per day | grounded |
| Cost Savings (pre-apply) | sum(delta_usd where delta < 0) | partial (live reconciliation deferred) |
| FTE Hours Saved | run count × manual baseline × rate | derived (N=0 caveat) |
| Platform ROI | (labor + cloud + avoided downtime) ÷ op cost | derived (N=0 caveat) |
| Decision Ledger Coverage | decisions with outcome ÷ total | grounded |
| Attestation Coverage | prod/dr attested ÷ total prod/dr | grounded |
| Policy Compliance Rate | 1 failed_assets ÷ total | grounded |
> **Benefit:** a reference for every metric mentioned in the deck.
---
> **End of deck.** 18 main slides + 1 appendix slide = 19 total.
@@ -1,386 +0,0 @@
---
marp: true
theme: default
paginate: true
size: 16x9
header: 'Nova — The No-Humans Infrastructure Platform'
footer: 'Act %{page}/5 — v1.17'
style: |
section {
font-family: "Akkurat Pro", "Helvetica Neue", "Arial", sans-serif;
font-size: 22px;
color: #1B1B1B;
}
h1 { color: #D6002A; font-size: 34px; margin-bottom: 0.3em; }
h2 { color: #D6002A; font-size: 26px; margin-bottom: 0.2em; }
section.title { background: #1B1B1B; color: #fff; border-top: 8px solid #D6002A; }
section.title h1 { color: #fff; }
table { font-size: 18px; width: 100%; }
th { background: #F0F0F0; }
blockquote { border-left: 4px solid #D6002A; color: #2E2E2E; font-size: 20px; }
img { display: block; margin: 0 auto; max-height: 320px; }
.badge {
display: inline-block; padding: 2px 8px; border-radius: 4px;
font-size: 14px; font-weight: 600;
}
.badge.today { background: #c6f6d5; color: #22543d; }
.badge.planned { background: #fef3c7; color: #78350f; }
---
<!-- _class: title -->
<!-- _paginate: false -->
# Nova — The No-Humans Infrastructure Platform
**Shifting from Operational Overhead to Strategic Value**
v1.18 — Citizen Developer & Production-Grade Guidance
---
## Slide 1 — Arc Preview
**This deck proves Nova is the no-humans infrastructure platform — and shows you the metrics that make the claim defensible.**
**Today:** 18 capabilities verified, 0 consumer estates in production.
**The 5-act arc:**
1. **Problem** — why the operator is the bottleneck
2. **Vision** — Nova's strategic direction (NORTH_STAR)
3. **How** — the pipeline, Decision Ledger, attestation gates
4. **Proof** — grounded metrics that make the claim defensible
5. **Roadmap** — deferred metrics with unblock paths + the ask + scope + RACI
**Benefit:** you leave knowing which claims are proven today, which are pipeline-ready, and which are deferred with a documented unblock path — no marketing, just grounded evidence.
---
## Slide 2 — The No-Humans Imperative
**Why the operator is the bottleneck — and why removing them from operations (not accountability) is the imperative.**
- **The cost of humans-in-the-loop:** L1/L2 ops hours, escalation latency, the trust gap
- **The operator is the bottleneck:** provisioning takes days, not minutes
- **The attestation model:** autonomy in operations, human at stage gates
- Cites `docs/NO_HUMANS_THESIS.md`
**Benefit:** you now know the problem framing — autonomy in operations, human at stage gates, is the path forward.
---
## Slide 3 — Nova's Vision
> **Infrastructure operations become invisible. Every environment provisioned, every incident healed, every risk remediated — by an autonomous system whose trustworthiness is provable, not promised. Human attestation remains required at stage gates — QA signs off for production, SRE greenlights based on operational readiness — but the operator is never in the loop of normal operations.**
- Autonomy in operations, not in accountability
- Cites `docs/NO_HUMANS_THESIS.md`
**Benefit:** you now know the destination — invisible operations with provable trust, not promised trust.
---
## Slide 4 — Strategic Objectives + Anti-Goals
**4 Strategic Objectives:**
1. **Zero-touch operations** — autonomy as the default, not the demo
2. **Provable trust in AI decisions** — Decision Ledger, confidence scoring, circuit breakers
3. **Compounding, quantifiable ROI** — each quarter must reduce spend, free hours, avoid downtime
4. **Default substrate for agentic consumption** — the platform AI agents reach for first
**5 Anti-Goals (what Nova is NOT):**
1. Not a hyperscaler competitor
2. Not a general-purpose AI platform
3. Not removing humans from accountability
4. Not for legacy, untagged, or freeform infrastructure
5. Not sold to operators
**Benefit:** you now know the scope boundaries — Nova is purpose-built for infrastructure operations, sold to leadership on outcomes.
---
## Slide 5 — 1218 Month Targets
**Current-milestone targets (grounded/derived):**
| Domain | Target | Status |
|---|---|---|
| MTTR (p95) | < 60s | grounded |
| Cloud Spend Reduction | ≥ 25% | partial (CUR deferred D-096) |
| L1/L2 Ops Hours Avoided | ≥ 70% | derived (N internal runs) |
| Platform ROI | ≥ 250% | derived (formula; N=0 caveat) |
| Decision Ledger Coverage | 100% | grounded |
| Attestation Coverage | 100% | grounded |
**Post-Pilot targets (pipeline grounded; 0 consumers today):**
| Domain | Target | Status |
|---|---|---|
| Touchless Resolution Rate | ≥ 99% | partial |
| Human Escalation Frequency | < 0.1% | partial |
| AI Decision Accuracy | ≥ 99.5% | partial |
**Deferred:** Predictive vs Reactive ≥3:1 <span class="badge planned">Planned</span> · Drift Auto-Reversal ≥95% <span class="badge planned">Planned</span>
**Benefit:** you now know the destination numbers — and which are measurable today vs deferred honestly.
---
## Slide 6 — The Platform Pipeline
**How intent becomes verified infrastructure without an operator.**
Contract → Resolver → Adapter → Terraform Plan → Checkov (Policy) → Confidence Signal → HITL Gate → Apply → Evidence
- Dev: autonomous (no HITL gate)
- qa/prod/dr: attested (human sign-off required)
- Grounded in `run_platform.sh` + `contract_resolver.py` + `confidence_signal.py`
**Benefit:** you now know the path from intent to evidence — and where the human appears (stage gates only).
---
## Slide 7 — The Decision Ledger
**Every AI decision captured with confidence, alternatives, and outcome.**
- `outbox_writer.py` → SQLite append-only hash-chain table
- `ai.decision.made`: decision_id=run_id, chosen_action=band, confidence=score, alternatives=perInput, human_override=HITL block
- `attestation.recorded`: qa/prod/dr sign-offs
- D-121, D-122, D-132. Honors D-083 (no S3 Object Lock/JWS — local hash-chain)
**D-122 honesty:** Nova's "AI" is the confidence-gated policy engine (confidence_signal + HITL gate), not an LLM planner. The Decision Ledger captures this real decision path — not a fabricated "AI agent."
**Benefit:** you now know why 'autonomous' is defensible — every decision is immutable, queryable, and accountable. And you know exactly what 'AI' means here: a confidence-gated policy engine, not a black-box LLM.
---
## Slide 8 — The 8-Concern Attestation Matrix
**Designed controls that keep humans at stage gates.**
| Concern | Env | Freshness | Type |
|---------|-----|-----------|------|
| functional_correctness | qa | 24h | operator-supplied |
| performance_baseline | qa | 7d | operator-supplied |
| security_posture | qa | 24h | operator-supplied |
| operational_readiness | prod | 30d | operator-supplied |
| incident_response | prod | 90d | operator-supplied |
| capacity_cost | prod | 30d | operator-supplied |
| resilience_dr_drill | prod | 180d | operator-supplied |
| dr_region_deploy | dr | 180d | operator-supplied |
- Offline-testable concerns run for real; operator-supplied concerns accept signed evidence
- Separation-of-duties on prod
- Grounded in `attestation_matrix.py` + `hitl_gates.py`
**Benefit:** you now know the gate model — autonomy in operations, human in accountability, by design.
---
## Slide 9 — Telemetry Architecture
**How Nova instruments itself — CloudEvents envelope, cold store, PowerBI export.**
Platform → CloudEvents 1.0 → `metrics/events.jsonl` + `metrics/decision_ledger.db` + `metrics/runs/` → Collector → `metrics/nova_metrics.db` (SQLite cold store) → `metrics/powerbi/` (CSV/JSON) → PowerBI
- D-120 (Nova-native), D-125 (hybrid), D-126 (cold-only)
- <span class="badge planned">Planned</span>: Hot-path (live ops dashboard) — D-126
**Benefit:** you now know that every metric in this deck is traceable to a real emitted event — the architecture IS the trust substrate. When a CFO asks 'where does this number come from?', the answer is a file path, not a Slack thread.
---
## Slide 10 — Capability Health + Confidence Distribution
**Grounded proof: capability health and confidence distribution from real runs.**
| Status | Count |
|--------|-------|
| Verified | 18 |
| Skipped | 4 |
| Broken | 0 |
| Decayed | 0 |
- 4 Skipped = live-AWS caps (CAP-013..016), honestly skipped (D-096 teardown), not a failure
- Source: `.ciagent/REGRESSION_REPORT.json`
**Benefit:** you now know the platform is verified — 18 capabilities pass, 4 are honestly skipped, 0 broken.
---
## Slide 11 — Decision Ledger + Attestation Coverage
**Trust metrics — both 100%.**
- **Decision Ledger Coverage:** 100% of platform runs emit `ai.decision.made` with outcome backfill
- **Attestation Coverage:** 100% of prod/dr promotions attested by a human
- **AI Decision Accuracy:** decisions not followed by apply.failed/incident within 5min
- Trust snapshot: `metrics/TRUST_SNAPSHOT.md` with chain-integrity verdict
- <span class="badge planned">Planned</span>: Tamper-Evident Ledger Checkpoints (D-083)
**Benefit:** you now know the trust is provable — not a marketing claim, a queryable record.
---
## Slide 12 — Zero-Touch Efficiency
**Touchless resolution, human escalation, and MTTR.**
- **Touchless Resolution Rate:** runs without operational HITL block ÷ total (attestation gates excluded)
- **Human Escalation Frequency:** operational HITL blocks only (confidence-driven; attestation sign-offs excluded)
- **MTTR (platform-run):** apply.failed → successful retry (D-131)
**Post-Pilot caveat:** computed on N internal runs today; production-denominator activates when a pilot estate runs.
**Benefit:** you now know the zero-touch efficiency is measurable — the pipeline works today on internal runs, and the denominator expands to production estates when a pilot activates.
---
## Slide 13 — Cost & ROI
**Cost estimates and the ROI formula — with honest caveats.**
- **Cost Estimates via Infracost:** pre-apply, grounded (reads plan JSON, offline)
- **ROI formula:** `Platform ROI = (FTE hours saved × blended rate + cloud savings + avoided downtime) ÷ platform op cost`
- **N=0 caveat:** "Computed on N internal runs today; production-denominator activates post-pilot. The formula is grounded; the production numbers are not yet."
- <span class="badge planned">Planned</span>: Live CUR Reconciliation (D-096)
**Benefit:** you now know the ROI formula — and you know it's computed on internal runs today, not fabricated production numbers.
---
## Slide 14 — What's Deferred — and Why
**Honesty about what isn't measured yet.**
**To be clear:** these deferrals are *measurement infrastructure*, not whether the platform runs without humans. The platform IS autonomous in operations. What's deferred is the *evidence pipeline* for certain metrics — not the autonomy itself.
| # | Deferred Metric | Blocking Decision |
|---|----------------|-------------------|
| 1 | Live Infrastructure Health | D-096 |
| 2 | Live Outbox Write Rate | D-096 |
| 3 | Tamper-Evident Ledger Checkpoints | D-083 |
| 4 | Onboarding Funnel (granted) | D-113/D-114/D-119 |
| 5 | Drift Auto-Reversal | D-096 + no scheduler |
| 6 | Live CUR Reconciliation | D-096 |
| 7 | SLA / Unplanned Downtime | D-096 |
| 8 | Predictive vs Reactive | future emitter |
**Benefit:** you now know the boundaries — what Nova measures today, and exactly what blocks the rest. The autonomy is real; the measurement gaps are documented.
---
## Slide 15 — Roadmap to the North Star
**The path from v1.17's grounded metrics to the 1218 month targets.**
- Each deferred metric → blocking decision → unblock requirement → candidate milestone
- Hot-path activation (post-D-096, Nova-native only, D-120)
- Re-evaluation triggers: D-096 lift, D-083 lift, onboarding-grant lift
From `docs/METRICS_DEFERRED_ROADMAP.md`.
**Benefit:** you now know the path — every deferred metric has an unblock requirement and a candidate milestone. Nothing is hand-waved; everything has a plan.
---
## Slide 16 — Recap + Ask
**The 5-act recap + the business decision.**
**Recap:**
- **Problem:** operator is the bottleneck; autonomy in operations, human at stage gates
- **Vision:** invisible operations with provable trust (NORTH_STAR)
- **How:** pipeline + Decision Ledger + 8-concern attestation matrix
- **Proof:** 18V+4S, 100% ledger coverage, 100% attestation, grounded ROI formula
- **Roadmap:** deferred metrics have unblock paths
**The ask:** "Approve a pilot estate to activate the production-denominator metrics (Touchless Resolution, Human Escalation, AI Decision Accuracy), and approve the tamper-evident ledger build-out (D-083 lift) to move from local hash-chain to S3 Object Lock + JWS. These two decisions move Nova from 'pipeline-ready' to 'production-proven.'"
**Benefit:** you leave with a clear business decision to make — approve a pilot + the ledger build-out — and the confidence that every claim in this deck is grounded, derived, or honestly deferred.
---
## Slide 17 — Scope: Downstream of PDLC
**Nova governs infrastructure + delivery. The PDLC (product backlog, code authorship, IDE) is upstream — Nova never penetrates it.**
- **The PDLC is upstream:** product backlog, code authorship (AI agent / IDE / agentic SDLC), sprint planning, application business logic
- **Nova is downstream:** contract ingestion → submission-readiness gate → policy → cloud lifecycle → environment progression → audit + attestation
- **Integration is only through the contract boundary:** the citizen developer's AI coding agent, an upstream agentic SDLC, or any dev platform may all produce submissions — the source does not matter as all are subject to the same compliance standards
- Nova validates the submission, not the author
- Cites `docs/scope.md` + `PROJECT.md` § Scope
**Benefit:** you now know the scope boundary — Nova is purpose-built for infrastructure operations, not product development; integration is through one validated contract.
---
## Slide 18 — RACI: Who Owns What
**Three roles, one matrix — the citizen developer owns FRs + UAT, the platform owns NFRs + infra + QA + prod deploy, release management is co-owned.**
| Work Category | Citizen Dev | Platform | Release Mgmt |
|---|---|---|---|
| Functional Requirements (FRs) | **R/A** | C | I |
| User Acceptance Testing (UAT) | **R/A** | C | I |
| Non-Functional Requirements (NFRs) | I | **R/A** | C |
| Infrastructure (cloud, state, IAM) | I | **R/A** | C |
| QA (policy, confidence, schema) | C | **R/A** | I |
| Production deployment to cloud | I | **R/A** | C |
| Release attestation (QA + SRE) | **A** | R | **R** |
- **Compliance-standard equivalence:** FRs + UAT may come from any upstream source (AI agent, agentic SDLC, dev platform) — all pass the same submission-readiness gate
- **Release co-ownership:** the platform runs the attestations agentically; the citizen developer oversees and triggers the actual release (human at the stage gate)
- Cites `docs/raci.md` + `PROJECT.md` § RACI Matrix
**Benefit:** you now know exactly what you bring (FRs + UAT), what Nova provides (NFRs + infra + QA + prod deploy), and what you co-own (the release attestation).
---
## Slide 19 — Production-Grade Guidance via Atelier
**Nova instructs the citizen developer's AI agent on production-grade engineering — skills + an MCP server with agentic validation beyond deterministic scanners.**
- **Skills (9):** markdown files under `skills/` keyed to Atelier domain paths (api, security, data, testing, observability, errors, devops, infrastructure-as-code, compliance) — extending the BA.A 5-skill catalog
- **MCP server:** `mcp/atelier/server.py` (plugin-registry, stdio) — 4 tools: `lookup_principle`, `list_domains`, `matrix_lookup`, `validate_against_principles`
- **Agentic validation:** catches C1 correctness + C2 clarity + C7 observability gaps that Wiz/Checkmarx/Mend cannot — deterministic tools check policy/secrets; the MCP server checks engineering discipline
- **Vendored Atelier** (pinned tag v0.3.6): audit reproducibility — a validation result is replayable against the exact principles that produced it
- Cites `docs/skills.md` + `mcp/atelier/README.md`
**Benefit:** you now know the citizen developer is not unguided — Nova provides production-grade engineering principles via skills + an MCP server, so the AI agent's submissions meet the same standards regardless of upstream source.
---
<!-- _class: title -->
<!-- _paginate: false -->
## Appendix A1 — Metrics Glossary
| KPI | Definition | Status |
|-----|-----------|--------|
| Touchless Resolution Rate | runs without operational HITL block ÷ total | partial (Post-Pilot) |
| Human Escalation Frequency | operational HITL blocks ÷ total | partial (Post-Pilot) |
| AI Decision Accuracy | decisions not followed by failure within 5min | partial (Post-Pilot) |
| MTTR (p95) | apply.failed → successful retry | grounded |
| Confidence-Gate Halt Rate | runs with band=block ÷ total | grounded |
| Provisioning Lead Time | run.completed run.started | grounded |
| Deployment Frequency | count(run.completed) per day | grounded |
| Cost Savings (Infracost) | sum(delta_usd where delta < 0) | partial (CUR deferred) |
| FTE Hours Saved | run count × manual baseline × rate | derived (N=0 caveat) |
| Platform ROI | (labor + cloud + avoided downtime) ÷ op cost | derived (N=0 caveat) |
| Decision Ledger Coverage | decisions with outcome ÷ total | grounded |
| Attestation Coverage | prod/dr attested ÷ total prod/dr | grounded |
| Policy Compliance Rate | 1 failed_assets ÷ total | grounded |
---
<!-- _class: title -->
<!-- _paginate: false -->
## Appendix A2 — Operating Model & Cost
- **Cost figures** from `COST.md`: $0.001883 over 8 days, ~$0.007/month, S3-dominated, zero BAU compute
- **Zero-cost steady state:** all resources torn down post-v1.11 (D-096); the platform runs offline
- References the pre-mortem (`PRE_MORTEM.md`: v1.10 decay root cause + structural mitigations)
**Benefit:** you now know the operating cost is negligible — and the structural mitigation that prevents decay.
@@ -1,134 +0,0 @@
# Nova — The No-Humans Infrastructure Platform: Talking Points
> Step 4 of the 4-step deck process. Presenter cues distilled from the
> source of truth (`nova-no-humans-platform.md`). 3-6 bullets per slide
> + key takeaway. Indexed by Marp slide #.
> v1.17 — REQ-196, REQ-197
---
### Slide 1 — Arc Preview
- Open with the stake line: "18 capabilities verified, 0 consumer estates in production"
- Preview the 5-act arc so the audience knows the structure
- Set the honesty frame: "this is an evidence deck, not a hype deck"
- **Key takeaway:** you'll leave knowing what's proven, what's pipeline-ready, and what's deferred
### Slide 2 — The No-Humans Imperative
- The operator is the bottleneck: days vs. minutes for provisioning
- Key reframing: "no-humans" = no human in normal operations; stage-gate attestation is human by design
- Cite the no-humans thesis doc
- **Key takeaway:** autonomy in operations, human at stage gates
### Slide 3 — Nova's Vision
- Read the vision statement verbatim — it's precise
- Emphasize "provable, not promised" — the difference between marketing and defensible
- State the attestation model up front to prevent mishearing
- **Key takeaway:** invisible operations with provable trust
### Slide 4 — Strategic Objectives + Anti-Goals
- The 4 objectives are the "what"; the 5 anti-goals are the "what NOT"
- Anti-goal #3 (not removing humans from accountability) reinforces slide 3
- Anti-goal #5 (not sold to operators) explains why this deck is for leadership
- **Key takeaway:** purpose-built for infra ops, sold to leadership on outcomes
### Slide 5 — 1218 Month Targets
- The three-section split (current / post-pilot / deferred) IS the honesty model
- "Partial" means the pipeline works but the denominator is zero (0 consumers)
- The Post-Pilot targets are committed; the numbers fill when a pilot runs
- **Key takeaway:** which numbers are real today vs. deferred honestly
### Slide 6 — The Platform Pipeline
- Walk the pipeline left-to-right: contract → resolver → adapter → plan → policy → confidence → gate → apply
- Key insight: dev is autonomous; qa/prod/dr require attestation
- The confidence signal is the "AI" — 6-input weighted score, not an LLM
- **Key takeaway:** the path from intent to evidence, with humans at stage gates only
### Slide 7 — The Decision Ledger
- The D-122 honesty sentence is critical: "Nova's AI is the confidence-gated policy engine, not an LLM"
- The ledger is the moat: features can be copied, an immutable decision history cannot
- Every decision has outcome backfill from apply.completed
- **Key takeaway:** autonomous is defensible because every decision is immutable, queryable, accountable
### Slide 8 — The 8-Concern Attestation Matrix
- The matrix is not a rubber stamp — it's structured, freshness-validated, SoD-enforced
- Offline-testable concerns run for real; operator-supplied concerns accept signed evidence
- SoD on prod: the approver can't be the same person who built it
- **Key takeaway:** autonomy in operations, human in accountability, by design
### Slide 9 — Telemetry Architecture
- Deliberately minimal (Nova-native, no Kafka/Prometheus/ClickHouse)
- Every number in the Proof act is traceable to a file path
- The hot path is deferred (D-126) — cold store is sufficient for batch
- **Key takeaway:** the architecture IS the trust substrate — "where does this number come from?" → file path
### Slide 10 — Capability Health
- 18V+4S is the single most important proof point
- The 4 Skipped are live-AWS caps — honestly skipped (D-096), not broken
- When live AWS is re-provisioned, they reactivate
- **Key takeaway:** the platform works, and we're honest about what we can't test
### Slide 11 — Decision Ledger + Attestation Coverage
- Both 100% — no AI decision is ever lost; no prod/dr promotion lands without a human sign-off
- The trust snapshot has a chain-integrity verdict (the ledger hasn't been tampered with)
- D-083 (S3 Object Lock + JWS) is the next step for the ledger
- **Key takeaway:** trust is provable — not a marketing claim, a queryable record
### Slide 12 — Zero-Touch Efficiency
- The Post-Pilot caveat is the honesty model: pipeline works, denominator is zero
- This is NOT a fabricated "99% touchless" claim
- The numbers fill when a pilot runs
- **Key takeaway:** the measurement works; the numbers activate with a pilot
### Slide 13 — Cost & ROI
- The ROI formula is shown inline — not hidden in a footnote
- The N=0 caveat is stated explicitly
- This is the "no fabrication" constraint in action
- **Key takeaway:** the formula is ready; the production denominator activates with a pilot
### Slide 14 — What's Deferred — and Why
- The preempt is critical: deferrals are measurement infrastructure, not autonomy
- The platform IS autonomous in operations; what's deferred is the evidence pipeline
- Showing this to leadership demonstrates honesty, not weakness
- **Key takeaway:** the autonomy is real; the measurement gaps are documented
### Slide 15 — Roadmap to the North Star
- Every deferred metric has a specific unblock requirement and a candidate milestone
- The re-evaluation triggers ensure the metrics layer evolves
- Nothing is hand-waved; everything has a plan
- **Key takeaway:** the path from "honestly deferred" to "here's how we get there"
### Slide 16 — Recap + Ask
- Recap the 5-act arc so the audience leaves with the structure
- The ask is a business decision: approve a pilot + the ledger build-out
- "Pipeline-ready" → "production-proven" is the value proposition
- **Key takeaway:** approve a pilot + the ledger build-out to move from pipeline-ready to production-proven
### Slide 17 — Scope: Downstream of PDLC
- Nova governs infra + delivery only; the PDLC (product backlog, code authorship, IDE) is upstream
- Integration is only through the validated contract boundary
- Any upstream source (AI agent, agentic SDLC, dev platform) may produce submissions — all subject to the same compliance standards
- Nova validates the submission, not the author
- **Key takeaway:** Nova is purpose-built for infrastructure operations, not product development; the scope boundary is clean
### Slide 18 — RACI: Who Owns What
- Citizen Developer owns FRs + UAT (via any upstream source — AI agent, SDLC, dev platform — all pass the same gate)
- Platform owns NFRs + infra + QA + prod deploy
- Release Management is co-owned: platform runs attestations agentically, citizen developer oversees + triggers the release (human at stage gate)
- The compliance-standard equivalence is the key: the source does not matter; the submission does
- **Key takeaway:** you bring FRs + UAT; Nova provides NFRs + infra + QA + prod deploy; the release is co-owned with you at the stage gate
### Slide 19 — Production-Grade Guidance via Atelier
- Nova instructs the citizen developer's AI agent via skills (9 markdown files) + an MCP server (4 tools, plugin-registry, stdio)
- The MCP server provides agentic validation beyond deterministic scanners — catches correctness, clarity, observability gaps that Wiz/Checkmarx/Mend cannot
- Atelier is vendored (pinned tag) for audit reproducibility — a validation result is replayable
- This is how Nova ensures the citizen developer's submissions meet production-grade standards regardless of upstream source
- **Key takeaway:** the citizen developer is not unguided — Nova provides engineering principles via skills + MCP, so every submission meets the same standards
### Appendix A1 — Metrics Glossary
- Reference for every metric mentioned in the deck
- Use if the audience asks "what does X mean?"
### Appendix A2 — Operating Model & Cost
- The operating cost is negligible (~$0.007/month)
- The zero-cost steady state (D-096 teardown) is the structural mitigation
- References the pre-mortem for the decay-prevention story
File diff suppressed because one or more lines are too long
@@ -1,417 +0,0 @@
# Nova — The No-Humans Infrastructure Platform
> **Source of truth** (Step 1 of the 4-step deck process).
> Unified narrative deck merging `how-the-platform-works` + `the-developer-experience`.
> 5-act arc: Problem → Vision → How → Proof → Roadmap.
> x3 structure at deck level (opening = arc preview, body = tell them, closing = recap + ask)
> AND per slide (opens with what it covers, delivers, closes with benefit callout).
> Act indicator in the Marp footer: `Act N/5: <act name>`.
>
> **Honesty model:** every metric cited is grounded (cites a source file),
> derived (documented formula), or deferred (cites a blocking decision ID).
> No fabricated numbers. Deferred metrics marked `<span class="badge planned">Planned</span>`.
>
> v1.17 — Strategic Direction, Leadership Metrics & Unified Story (REQ-196, REQ-197)
---
## Slide 1 — Arc Preview (the "what I'm going to tell you" deck-level opening)
This deck proves Nova is the no-humans infrastructure platform — and shows you the metrics that make the claim defensible.
**Today:** 18 capabilities verified, 0 consumer estates in production. This deck shows what's proven, what's pipeline-ready, and what's honestly deferred.
The 5-act arc:
1. **Problem** — why the operator is the bottleneck
2. **Vision** — Nova's strategic direction (NORTH_STAR)
3. **How** — the pipeline, Decision Ledger, attestation gates
4. **Proof** — grounded metrics that make the claim defensible
5. **Roadmap** — deferred metrics with unblock paths + the ask
> **Benefit:** you leave this deck knowing which claims are proven today, which are pipeline-ready, and which are deferred with a documented unblock path — no marketing, just grounded evidence.
> **Speaker notes:** The stake line (18V + 0 consumers) sets the honesty frame. The audience knows from slide 1 that this is not a hype deck — it's an evidence deck. The arc preview orients them for the next 15 slides.
---
## Slide 2 — The No-Humans Imperative
This slide shows why the operator is the bottleneck — and why removing them from operations (not accountability) is the imperative.
- **The cost of humans-in-the-loop:** L1/L2 ops hours, escalation latency, the trust gap (autonomous claims without proof)
- **The operator is the bottleneck:** provisioning takes days, not minutes; escalations pile up; the trust gap means "autonomous" is a marketing claim, not a defensible one
- **The attestation model:** autonomy in operations, human at stage gates — not "no humans ever"
- Cites `docs/NO_HUMANS_THESIS.md` (the thesis, grounded proof, deferred proof, anti-claims)
> **Benefit:** you now know the problem framing — autonomy in operations, human at stage gates, is the path forward.
> **Speaker notes:** The key reframing: "no-humans" means no human in the loop of *normal operations*. Stage-gate attestation (QA for production, SRE for operational readiness) remains human by design. This is not about removing humans from accountability — only from operations.
> **Transition:** "Having defined the problem, here is Nova's strategic direction toward solving it."
---
## Slide 3 — Nova's Vision
This slide states Nova's vision — infrastructure operations become invisible, with provable trust.
> **Infrastructure operations become invisible. Every environment provisioned, every incident healed, every risk remediated — by an autonomous system whose trustworthiness is provable, not promised. Human attestation remains required at stage gates — QA signs off for production, SRE greenlights based on operational readiness — but the operator is never in the loop of normal operations.**
- The attestation model: human attestation required at stage gates (QA for production, SRE for operational readiness); autonomy in operations, not in accountability
- Cites `docs/NO_HUMANS_THESIS.md` (the thesis, grounded proof, deferred proof, anti-claims incl. D-122 honesty)
> **Benefit:** you now know the destination — invisible operations with provable trust, not promised trust. And you know the attestation model: humans at stage gates, not in the ops loop.
> **Speaker notes:** The vision is ambitious but precise. "Provable, not promised" is the key phrase — it's the difference between a marketing claim and a defensible one. The attestation clarification is stated up front so the audience doesn't mishear "no-humans" as "no accountability."
> **Transition:** "The vision is ambitious — here are the 4 strategic objectives that make it concrete."
---
## Slide 4 — Strategic Objectives + Anti-Goals
This slide pairs what Nova is building toward (4 objectives) with what Nova refuses to build (5 anti-goals).
**4 Strategic Objectives:**
1. **Demonstrate production-grade zero-touch operations** — autonomy as the default, not the demo
2. **Establish provable trust in AI decisions** — Decision Ledger, confidence scoring, circuit breakers, blast-radius controls
3. **Deliver compounding, quantifiable ROI** — each quarter must reduce spend, free hours, avoid downtime measurably
4. **Become the default substrate for agentic infrastructure consumption** — the platform AI agents reach for first
**5 Anti-Goals (what Nova is NOT):**
1. Not a Terraform, Kubernetes, or hyperscaler competitor
2. Not a general-purpose AI agent platform
3. Not a system that removes humans from accountability
4. Not for legacy, untagged, or freeform infrastructure
5. Not sold to operators
From `NORTH_STAR.md`.
> **Benefit:** you now know the scope boundaries — Nova is purpose-built for infrastructure operations, sold to leadership on outcomes, and explicitly not a general-purpose AI platform or a hyperscaler competitor.
> **Speaker notes:** The anti-goals are as important as the objectives. They tell the audience what Nova will NOT be distracted by. Anti-goal #3 (not removing humans from accountability) reinforces the attestation model from slide 3.
> **Transition:** "The objectives are committed to measurable targets — here is the 1218 month scorecard, with honest grounding status."
---
## Slide 5 — 1218 Month Targets (the scorecard)
This slide shows the committed targets — numbers a board member can repeat back — with their grounding status.
**Current-milestone targets (grounded or derived this milestone):**
| Domain | Target | Status |
|---|---|---|
| MTTR (p95) | < 60 seconds | grounded (platform-run) |
| Cloud Spend Reduction | ≥ 25% on pilot estates | partial (Infracost grounded; CUR deferred D-096) |
| L1/L2 Ops Hours Avoided | ≥ 70% of pre-Nova FTE | derived (N internal runs; prod activates post-pilot) |
| Platform ROI | ≥ 250% annually | derived (formula; N internal runs caveat) |
| Decision Ledger Coverage | 100% of AI actions | grounded (this milestone builds it) |
| Attestation Coverage | 100% of prod/dr promotions | grounded |
**Post-Pilot targets (pipeline grounded; denominator activates with a pilot estate):**
| Domain | Target | Status |
|---|---|---|
| Touchless Resolution Rate | ≥ 99% | partial (pipeline grounded; 0 consumers today) |
| Human Escalation Frequency | < 0.1% | partial (pipeline grounded; 0 consumers today) |
| AI Decision Accuracy | ≥ 99.5% | partial (pipeline grounded; 0 consumers today) |
**Deferred targets:** Predictive vs Reactive ≥3:1 <span class="badge planned">Planned</span> · Drift Auto-Reversal ≥95% <span class="badge planned">Planned</span>
> **Benefit:** you now know the destination numbers — and which ones are measurable today vs deferred honestly. The Post-Pilot targets are committed; the pipeline works; the numbers fill when a pilot estate runs.
> **Speaker notes:** The three-section split (current / post-pilot / deferred) is the honesty model. The "partial" status means the measurement pipeline is grounded but the denominator is zero (0 consumers). This is the same honesty as Cloud Spend (Infracost grounded, CUR deferred). A board member can see exactly which numbers are real today and which are waiting for a pilot.
> **Transition:** "The targets are committed — here is how Nova works to achieve them."
---
## Slide 6 — The Platform Pipeline
This slide shows the contract-to-evidence pipeline — how intent becomes verified infrastructure without an operator.
```mermaid
graph LR
A[Contract] --> B[Resolver]
B --> C[Adapter]
C --> D[Terraform Plan]
D --> E[Checkov Policy]
E --> F[Confidence Signal]
F --> G{HITL Gate}
G -->|dev: autonomous| H[Apply]
G -->|qa/prod/dr: attested| H
H --> I[Evidence + Outbox]
```
- Contract → resolver → adapter → terraform plan → Checkov (policy) → confidence signal → HITL gate (dev autonomous; qa/prod/dr attested) → apply → evidence
- Grounded in `scripts/run_platform.sh` + `core/contract_resolver.py` + `adapters/terraform/adapter.py` + `core/confidence_signal.py`
> **Benefit:** you now know the path from intent to evidence — and where the human appears (stage gates only, not in the ops loop).
> **Speaker notes:** The pipeline is the engine. The key insight: dev is autonomous (no HITL gate); qa/prod/dr require human attestation. The confidence signal is the "AI" — it's a 6-input weighted score, not an LLM. The HITL gate is where the human appears, but only for qa/prod/dr, not for dev.
> **Transition:** "The pipeline produces decisions — here is how every decision is captured and made accountable."
---
## Slide 7 — The Decision Ledger
This slide shows the Decision Ledger — every AI decision captured with confidence, alternatives, and outcome.
- **Architecture:** `outbox_writer.py` extended → SQLite append-only hash-chain table
- **`ai.decision.made` events:** decision_id=run_id, chosen_action=band, confidence=score, alternatives=perInput, human_override=HITL block, outcome backfilled from apply.completed
- **`attestation.recorded` events:** qa/prod/dr sign-offs (approver, env, concerns, result)
- D-121, D-122, D-132. Honors D-083 (no S3 Object Lock/JWS — local hash-chain this milestone)
**D-122 honesty:** Nova's "AI" is the confidence-gated policy engine (confidence_signal + HITL gate), not an LLM planner. The Decision Ledger captures this real decision path — not a fabricated "AI agent" that doesn't exist yet.
> **Benefit:** you now know why 'autonomous' is defensible — every decision is immutable, queryable, and accountable. And you know exactly what 'AI' means here: a confidence-gated policy engine, not a black-box LLM.
> **Speaker notes:** The D-122 honesty sentence is critical. If the audience walks away thinking Nova has an LLM planner, we've violated the "no fabrication" constraint. The Decision Ledger is the trust substrate (NORTH_STAR Objective #2) — it's the moat. Features can be copied; an immutable, queryable decision history cannot.
> **Transition:** "Decisions are captured — here is how stage-gate attestation keeps humans in accountability."
---
## Slide 8 — The 8-Concern Attestation Matrix
This slide shows the 8-concern attestation matrix — the designed controls that keep humans at stage gates.
| Concern | Env | Freshness | Type |
|---------|-----|-----------|------|
| functional_correctness | qa | 24h | operator-supplied |
| performance_baseline | qa | 7d | operator-supplied |
| security_posture | qa | 24h | operator-supplied |
| contract_nfrs | qa/prod/dr | — | offline-testable |
| operational_readiness | prod | 30d | operator-supplied |
| incident_response | prod | 90d | operator-supplied |
| capacity_cost | prod | 30d | operator-supplied |
| resilience_dr_drill | prod | 180d | operator-supplied |
| resilience_chaos | prod | 90d | operator-supplied |
| resilience_backup | prod | 30d | operator-supplied |
| dr_region_deploy | dr | 180d | operator-supplied |
- Offline-testable concerns run for real; operator-supplied concerns accept signed evidence artifacts
- Separation-of-duties on prod (the approver can't be the same person who built it)
- Grounded in `core/attestation_matrix.py` + `core/hitl_gates.py`
> **Benefit:** you now know the gate model — autonomy in operations, human in accountability, by design. The 8-concern matrix is what makes "no-humans in ops" safe.
> **Speaker notes:** The attestation matrix is the human-in-the-loop safeguard. It's not a rubber stamp — it's a structured, freshness-validated, separation-of-duties-enforced gate. This is what Anti-Goal #3 means: "not a system that removes humans from accountability."
> **Transition:** "You've now seen how Nova works — the pipeline, the Decision Ledger, the attestation gates. But 'how it works' is not 'proof it works.' The next four slides show the measured evidence: capability health, trust metrics, efficiency, and cost — every number grounded in a real file, not a marketing claim."
---
## Slide 9 — Telemetry Architecture
This slide shows how Nova instruments itself — the CloudEvents envelope, the cold store, and the PowerBI export.
```mermaid
graph TB
A[Platform components] --> B[CloudEvents 1.0 envelope]
B --> C[metrics/events.jsonl]
B --> D[metrics/decision_ledger.db]
B --> E[metrics/runs/]
C --> F[Collector]
D --> F
E --> F
F --> G[metrics/nova_metrics.db]
G --> H[metrics/powerbi/]
H --> I[PowerBI dashboards]
```
- Platform components → CloudEvents 1.0 envelope → `metrics/events.jsonl` + `metrics/runs/` + `metrics/decision_ledger.db` → collector → `metrics/nova_metrics.db` (SQLite cold store) → `metrics/powerbi/` (CSV/JSON views) → PowerBI
- D-120 (Nova-native), D-125 (hybrid events/files), D-126 (cold-only)
- <span class="badge planned">Planned</span>: Hot-path (live ops dashboard) — D-126
> **Benefit:** you now know that every metric in this deck is traceable to a real emitted event — the architecture IS the trust substrate. When a CFO asks 'where does this number come from?', the answer is a file path, not a Slack thread.
> **Speaker notes:** The architecture is deliberately minimal (Nova-native, no Kafka/Prometheus/ClickHouse). The hot path is deferred (D-126) — the cold store is sufficient for batch/historical analysis. The key point: every number in the Proof act is traceable to a file path. This is the "no fabrication" constraint made architectural.
> **Transition:** "The architecture is sound — here is the measured proof."
---
## Slide 10 — Capability Health + Confidence Distribution
This slide shows the grounded proof: capability health and confidence distribution from real runs.
**Capability Health:** 18 Verified + 4 Skipped (post-D-096 teardown) from `.ciagent/REGRESSION_REPORT.json`
| Status | Count |
|--------|-------|
| Verified | 18 |
| Skipped | 4 |
| Broken | 0 |
| Decayed | 0 |
- The 4 Skipped are live-AWS capabilities (CAP-013..016) — honestly skipped because resources are torn down (D-096), not a failure
- Confidence distribution: from `metrics/nova_metrics.db` `fact_confidence` — score histogram, band breakdown (pass/halt)
> **Benefit:** you now know the platform is verified — 18 capabilities pass, 4 are honestly skipped, 0 broken. The honesty model (Skipped ≠ failure) is what makes the Verified count credible.
> **Speaker notes:** The 18V+4S number is the single most important proof point. It says "the platform works, and we're honest about what we can't test." The 4 Skipped are live-AWS capabilities — they're skipped because the live AWS resources are torn down (D-096), not because they're broken. When live AWS is re-provisioned, they reactivate.
> **Transition:** "Capability health is necessary — here is the trust substrate that makes autonomy defensible."
---
## Slide 11 — Decision Ledger + Attestation Coverage
This slide shows the trust metrics — Decision Ledger coverage and attestation coverage, both 100%.
- **Decision Ledger Coverage:** 100% of platform runs emit `ai.decision.made` with outcome backfill (source: `metrics/decision_ledger.db`)
- **Attestation Coverage:** 100% of prod/dr promotions attested by a human (source: `hitl_gates.py` + outbox `approver_*` attributes)
- **AI Decision Accuracy:** decisions not followed by apply.failed/incident within 5min
- The trust-snapshot report (`metrics/TRUST_SNAPSHOT.md`) with chain-integrity verdict
- <span class="badge planned">Planned</span>: Tamper-Evident Ledger Checkpoints (D-083)
> **Benefit:** you now know the trust is provable — not a marketing claim, a queryable record. The Decision Ledger is the moat; features can be copied, an immutable decision history cannot.
> **Speaker notes:** The trust metrics are the "provably trustworthy" proof. Decision Ledger Coverage = 100% means no AI decision is ever lost. Attestation Coverage = 100% means no prod/dr promotion lands without a human sign-off. The chain-integrity verdict (from the trust snapshot) proves the ledger hasn't been tampered with.
> **Transition:** "Trust is provable — here is the operational efficiency that makes the ROI real."
---
## Slide 12 — Zero-Touch Efficiency
This slide shows the zero-touch efficiency metrics — touchless resolution, human escalation, and MTTR.
- **Touchless Resolution Rate:** runs without operational HITL block ÷ total (attestation gates excluded)
- **Human Escalation Frequency:** operational HITL blocks only (confidence-driven; attestation sign-offs excluded)
- **MTTR (platform-run):** apply.failed → successful retry (D-131)
**Post-Pilot caveat:** these three metrics are computed on N internal runs today; the production-denominator activates when a pilot estate runs (see NORTH_STAR Post-Pilot Targets section).
> **Benefit:** you now know the zero-touch efficiency is measurable — the pipeline works today on internal runs, and the denominator expands to production estates when a pilot activates.
> **Speaker notes:** The Post-Pilot caveat is the honesty model. The pipeline is grounded (it works); the denominator is zero (0 consumers). This is not a fabricated "99% touchless" claim — it's "the measurement works, and the numbers fill when a pilot runs."
> **Transition:** "Efficiency is half the ROI story — here is the cost side."
---
## Slide 13 — Cost & ROI
This slide shows the cost estimates and the ROI formula — with honest caveats about the current denominator.
- **Cost Estimates via Infracost:** pre-apply, grounded (reads plan JSON, offline)
- **ROI formula (shown inline):** `Platform ROI = (FTE hours saved × blended rate + cloud savings + avoided downtime) ÷ platform op cost`
- **N=0 caveat:** "These derived metrics are computed on N internal runs today; the production-denominator activates post-pilot. The formula is grounded; the production numbers are not yet."
- **FTE Hours Saved** (derived), **Platform ROI** (derived formula)
- <span class="badge planned">Planned</span>: Live CUR Reconciliation (D-096), Drift Auto-Reversal (D-096)
> **Benefit:** you now know the ROI formula — and you know it's computed on internal runs today, not fabricated production numbers. The formula is ready; the production denominator activates with a pilot.
> **Speaker notes:** The ROI formula is shown inline — not hidden in a footnote. The N=0 caveat is stated explicitly. This is the "no fabrication" constraint in action: we show the formula, we show the caveat, we don't pretend the production numbers exist.
> **Transition:** "The proof is grounded — here is what is honestly deferred."
---
## Slide 14 — What's Deferred — and Why
This slide pairs each deferred metric with its blocking decision — honesty about what isn't measured yet.
**To be clear:** these deferrals are *measurement infrastructure*, not whether the platform runs without humans. The platform IS autonomous in operations. What's deferred is the *evidence pipeline* for certain metrics — not the autonomy itself.
| # | Deferred Metric | Blocking Decision |
|---|----------------|-------------------|
| 1 | Live Infrastructure Health | D-096 |
| 2 | Live Outbox Write Rate | D-096 |
| 3 | Tamper-Evident Ledger Checkpoints | D-083 |
| 4 | Onboarding Funnel (granted) | D-113/D-114/D-119 |
| 5 | Drift Auto-Reversal | D-096 + no scheduler |
| 6 | Live CUR Reconciliation | D-096 |
| 7 | SLA / Unplanned Downtime | D-096 |
| 8 | Predictive vs Reactive | future emitter |
From `docs/METRICS_DEFERRED_ROADMAP.md`.
> **Benefit:** you now know the boundaries — what Nova measures today, and exactly what blocks the rest. The autonomy is real; the measurement gaps are documented.
> **Speaker notes:** The preempt is critical: these deferrals are measurement infrastructure, not autonomy. The platform runs without humans in operations. What's deferred is the evidence pipeline for live-infra health, drift detection, predictive remediation — not the autonomy itself. Showing this slide to leadership demonstrates honesty, not weakness.
> **Transition:** "The proof is honest — here is the roadmap from here to the 1218 month targets."
---
## Slide 15 — Roadmap to the North Star
This slide shows the path from v1.17's grounded metrics to the 1218 month targets — the unblock path for each deferred metric.
- Each deferred metric → blocking decision → unblock requirement → candidate milestone
- The hot-path activation section (post-D-096, Nova-native only, D-120)
- Re-evaluation triggers: D-096 lift, D-083 lift, onboarding-grant lift
From `docs/METRICS_DEFERRED_ROADMAP.md`.
> **Benefit:** you now know the path — every deferred metric has an unblock requirement and a candidate milestone. Nothing is hand-waved; everything has a plan.
> **Speaker notes:** The roadmap is the bridge from "honestly deferred" to "here's how we get there." Each deferred metric has a specific unblock requirement and a candidate future milestone. The re-evaluation triggers ensure the metrics layer evolves when the blocking decisions lift.
> **Transition:** "The roadmap is clear — here is the recap and the ask."
---
## Slide 16 — Recap + Ask (the "what I told you" deck-level closing)
This slide recaps the 5 acts and states the ask.
**Recap:**
- **Problem:** the operator is the bottleneck; autonomy in operations, human at stage gates
- **Vision:** invisible operations with provable trust (NORTH_STAR)
- **How:** pipeline + Decision Ledger + 8-concern attestation matrix
- **Proof:** 18V+4S, 100% ledger coverage, 100% attestation, grounded ROI formula
- **Roadmap:** deferred metrics have unblock paths
**The ask:** "The ask is a business decision: approve a pilot estate to activate the production-denominator metrics (Touchless Resolution, Human Escalation, AI Decision Accuracy), and approve the tamper-evident ledger build-out (D-083 lift) to move from local hash-chain to S3 Object Lock + JWS. These two decisions move Nova from 'pipeline-ready' to 'production-proven.'"
> **Benefit:** you leave with a clear business decision to make — approve a pilot + the ledger build-out — and the confidence that every claim in this deck is grounded, derived, or honestly deferred.
> **Speaker notes:** The ask is a business decision, not insider language. "Approve a pilot estate" is something a C-suite can decide. "Approve the ledger build-out" is a budget decision. The recap reinforces the 5-act arc — the audience leaves with the structure, not a pile of facts.
---
## Appendix Slide A1 — Metrics Glossary
This appendix defines every KPI in one line with its grounding badge.
| KPI | Definition | Status |
|-----|-----------|--------|
| Touchless Resolution Rate | runs without operational HITL block ÷ total | partial (Post-Pilot) |
| Human Escalation Frequency | operational HITL blocks ÷ total | partial (Post-Pilot) |
| AI Decision Accuracy | decisions not followed by failure within 5min | partial (Post-Pilot) |
| MTTR (p95) | apply.failed → successful retry | grounded |
| Confidence-Gate Halt Rate | runs with band=block ÷ total | grounded |
| Provisioning Lead Time | run.completed run.started | grounded |
| Deployment Frequency | count(run.completed) per day | grounded |
| Cost Savings (Infracost) | sum(delta_usd where delta < 0) | partial (CUR deferred) |
| FTE Hours Saved | run count × manual baseline × rate | derived (N=0 caveat) |
| Platform ROI | (labor + cloud + avoided downtime) ÷ op cost | derived (N=0 caveat) |
| Decision Ledger Coverage | decisions with outcome ÷ total | grounded |
| Attestation Coverage | prod/dr attested ÷ total prod/dr | grounded |
| Policy Compliance Rate | 1 failed_assets ÷ total | grounded |
> **Benefit:** you now have a reference for every metric mentioned in the deck.
---
## Appendix Slide A2 — Operating Model & Cost
This appendix shows the real cost figures + the zero-cost steady state.
- **Cost figures** from `COST.md`: $0.001883 over 8 days, ~$0.007/month, S3-dominated, zero BAU compute
- **Zero-cost steady state:** all resources torn down post-v1.11 (D-096); the platform runs offline
- References the pre-mortem (`PRE_MORTEM.md`: v1.10 decay root cause + four forward failure modes + structural mitigations)
> **Benefit:** you now know the operating cost is negligible — and the structural mitigation that prevents decay.
---
> **End of deck.** 16 main slides + 2 appendix slides = 18 total.
> Both old decks (`how-the-platform-works` + `the-developer-experience`) are retired (D-130).
Binary file not shown.
+45 -33
View File
@@ -1,13 +1,12 @@
# RACI — Who Owns What # RACI — Who Owns What
> **Source of truth:** `.ciagent/PROJECT.md` § RACI Matrix (v1.18, REQ-215, > This page is the citizen-developer-facing copy.
> D-139). This page is the citizen-developer-facing copy.
Nova's delivery lifecycle has three roles. This page clarifies who owns Nova's delivery lifecycle has four roles. This page clarifies who owns
what — so the citizen developer knows what they bring, what the platform what — so the citizen developer knows what they bring, what the platform
provides, and what is co-owned. provides, what quality engineering guards, and what is co-owned with SRE.
## The Three Roles ## The Four Roles
### Citizen Developer (CD) ### Citizen Developer (CD)
@@ -15,40 +14,49 @@ That's you — the consumer (technical developer L3A or non-technical L3B).
You are **Responsible** for all **Functional Requirements (FRs)** and You are **Responsible** for all **Functional Requirements (FRs)** and
**User Acceptance Testing (UAT)**. You produce the FRs + UAT via your AI **User Acceptance Testing (UAT)**. You produce the FRs + UAT via your AI
coding agent, an upstream agentic SDLC platform, or any upstream coding agent, an upstream agentic SDLC platform, or any upstream
development platform. **The source does not matter** — all are subject development platform. **The source does not matter** — all are subject to
to the same compliance standards (the submission-readiness gate, the the same compliance standards (the submission-readiness gate, the
contract schema, the policy envelope, the immutable audit stream). Nova contract schema, the policy envelope, the immutable audit stream). Nova
validates the submission, not the author. validates the submission, not the author.
### Platform (Nova) ### Platform (Nova)
Nova is **Responsible** for all **Non-Functional Requirements (NFRs)**, Nova is **Responsible** for all **Non-Functional Requirements (NFRs)**,
**Infrastructure** (cloud resource lifecycle, state, IAM), **QA** (the **Infrastructure** (cloud resource lifecycle, state, IAM), and
platform-side quality checks: policy enforcement, confidence scoring, **Production deployments to cloud** (the apply path, the pipeline, the
schema validation), and **Production deployments to cloud** (the apply release mechanics).
path, the pipeline, the release mechanics).
### Release Management (RM) — co-owned ### Quality Engineering (QE)
The release is **co-owned**. The platform performs the QA + SRE Quality Engineering is **Responsible** for the platform-side quality
attestations agentically (it runs the confidence signal, the policy checks: policy enforcement, confidence scoring, schema validation, and
checks, the separation-of-duties). The citizen developer **oversees and the functional/contract/non-functional evidence that feeds attestation.
triggers** the actual release — the human attestation at the stage gate QE owns the **quality** of what the platform produces — the gate
is your authorization. The platform runs the checks; you authorize the evidence, not the gate decision.
promotion. This is the "autonomy in operations, human at stage gates"
model. ### SRE — co-owned with you
Production readiness is **co-owned**. SRE owns operational readiness:
the operational attestation (incident response, capacity, resilience,
DR). The platform performs the QA + SRE attestations agentically (it
runs the confidence signal, the policy checks, the
separation-of-duties). The citizen developer **oversees and triggers**
the actual release — the human attestation at the stage gate is your
authorization. The platform runs the checks; you authorize the promotion.
This is the "autonomy in operations, human at stage gates" model.
## The Matrix ## The Matrix
| Work Category | Citizen Developer | Platform | Release Management | | Work Category | Citizen Developer | Platform | Quality Engineering | SRE |
|---|---|---|---| |---|---|---|---|---|
| **Functional Requirements (FRs)** | **R/A** | C | I | | **Functional Requirements (FRs)** | **R/A** | C | I | I |
| **User Acceptance Testing (UAT)** | **R/A** | C | I | | **User Acceptance Testing (UAT)** | **R/A** | C | I | I |
| **Non-Functional Requirements (NFRs)** | I | **R/A** | C | | **Non-Functional Requirements (NFRs)** | I | **R/A** | C | C |
| **Infrastructure (cloud, state, IAM)** | I | **R/A** | C | | **Infrastructure (cloud, state, IAM)** | I | **R/A** | I | C |
| **QA (policy, confidence, schema checks)** | C | **R/A** | I | | **QA (policy, confidence, schema checks)** | C | R | **R/A** | I |
| **Production deployment to cloud** | I | **R/A** | C | | **Production deployment to cloud** | I | **R/A** | C | C |
| **Release attestation (QA + SRE sign-off)** | **A** | R | **R** | | **Quality attestation (QA sign-off)** | **A** | R | **R** | I |
| **Production readiness (SRE sign-off)** | **A** | R | C | **R** |
**Key:** **R** = Responsible (does the work) · **A** = Accountable (owns **Key:** **R** = Responsible (does the work) · **A** = Accountable (owns
the outcome, sign-off) · **C** = Consulted · **I** = Informed. the outcome, sign-off) · **C** = Consulted · **I** = Informed.
@@ -64,11 +72,15 @@ the outcome, sign-off) · **C** = Consulted · **I** = Informed.
- The NFRs (security, observability, compliance — baked into the - The NFRs (security, observability, compliance — baked into the
pipeline, not your concern). pipeline, not your concern).
- The infrastructure (cloud resources, state management, IAM scoping). - The infrastructure (cloud resources, state management, IAM scoping).
- The QA (policy enforcement, confidence scoring, schema validation).
- The production deployment (the apply path, the pipeline, the release). - The production deployment (the apply path, the pipeline, the release).
**You co-own the release:** **Quality Engineering guards:**
- Nova runs the attestations (QA confidence, SRE operational readiness). - The policy enforcement, confidence scoring, schema validation.
- The quality attestation evidence that feeds the stage gates.
**You co-own production readiness with SRE:**
- Nova + SRE run the attestations (QA quality sign-off, SRE operational
readiness).
- You authorize the promotion at the stage gate. No promotion happens - You authorize the promotion at the stage gate. No promotion happens
without your recorded attestation. without your recorded attestation.
@@ -79,7 +91,7 @@ agentic SDLC platform, or a traditional IDE. Nova does not
differentiate. All submissions pass through the same gate differentiate. All submissions pass through the same gate
(`schemas/submission-readiness.schema.json`): tags, environment (`schemas/submission-readiness.schema.json`): tags, environment
metadata, policy preconditions, profile markers. The compliance metadata, policy preconditions, profile markers. The compliance
standards are the same regardless of how the code was authored. This standards are the same regardless of how the code was authored. This is
is by design: the audit trail is the same, the policy envelope is the by design: the audit trail is the same, the policy envelope is the
same, the evidence stream is the same. The source does not matter; the same, the evidence stream is the same. The source does not matter; the
submission does. submission does.
+6 -2
View File
@@ -1,6 +1,5 @@
# Scope — Nova is Downstream of PDLC # Scope — Nova is Downstream of PDLC
> **Source of truth:** `.ciagent/PROJECT.md` § Scope (v1.18, REQ-216).
> This page is the citizen-developer-facing copy. > This page is the citizen-developer-facing copy.
## The Boundary ## The Boundary
@@ -15,7 +14,12 @@ PDLC includes:
- IDE workflows / developer experience - IDE workflows / developer experience
Nova never penetrates the PDLC. Nova's domain is **infrastructure + Nova never penetrates the PDLC. Nova's domain is **infrastructure +
delivery only**. delivery only**. Nova integrates with externally owned PDLC, SDLC,
Agentic, and Citizen Developer platforms with no regard for the source
of the intent: Nova provides a set of skills and MCP endpoints that help
the developer or AI agent make their application production-grade, and
all intents to deploy to production go through the same rigorous
controls, quality gates, attestation, and evidence stream.
## What Nova Does ## What Nova Does
+2 -2
View File
@@ -34,14 +34,14 @@
## Atelier Provenance ## Atelier Provenance
The skills are derived from [Atelier](https://git.cloudinit.dev/coreci/atelier) The skills are derived from [Atelier](https://example.com/atelier)
— a first-principles docs-as-code engineering framework with 8 core — a first-principles docs-as-code engineering framework with 8 core
principles (C1C8) and 19 domains, each with 10 derived P-rules. The principles (C1C8) and 19 domains, each with 10 derived P-rules. The
skills distill the citizen-developer-relevant subset of each domain's skills distill the citizen-developer-relevant subset of each domain's
first-principles, link to the agent-checklist triggers, and map to the first-principles, link to the agent-checklist triggers, and map to the
existing BA.A catalog. existing BA.A catalog.
Atelier is vendored under `mcp/atelier/vendor/` (pinned tag, D-136) for Atelier is vendored under `mcp/atelier/vendor/` (pinned tag) for
audit reproducibility — an agentic validation result is replayable audit reproducibility — an agentic validation result is replayable
against the exact principles that produced it. against the exact principles that produced it.
+5 -6
View File
@@ -1,9 +1,8 @@
# Nova Atelier MCP Server # Nova Atelier MCP Server
> **v1.18, REQ-223, REQ-224.** An MCP (Model Context Protocol) server that
> exposes Atelier engineering principles to the citizen developer's AI > exposes Atelier engineering principles to the citizen developer's AI
> agent. Plugin-registry architecture (D-140); stdio transport (D-135); > agent. Plugin-registry architecture; stdio transport;
> vendored Atelier (D-136) for audit reproducibility. > vendored Atelier for audit reproducibility.
## What This Is ## What This Is
@@ -22,7 +21,7 @@ observability gaps.
| `atelier.matrix_lookup(domain)` | Look up the domain→core principle mapping for a given domain. | | `atelier.matrix_lookup(domain)` | Look up the domain→core principle mapping for a given domain. |
| `atelier.validate_against_principles(snippet, domains?)` | Validate a code/diff snippet against the Atelier agent-checklist. Returns pass/fail per check item with the principle citation. | | `atelier.validate_against_principles(snippet, domains?)` | Validate a code/diff snippet against the Atelier agent-checklist. Returns pass/fail per check item with the principle citation. |
## Architecture — Plugin Registry (D-140) ## Architecture — Plugin Registry
``` ```
mcp/atelier/ mcp/atelier/
@@ -31,7 +30,7 @@ mcp/atelier/
│ ├── __init__.py │ ├── __init__.py
│ ├── principles.py # lookup_principle, list_domains, matrix_lookup │ ├── principles.py # lookup_principle, list_domains, matrix_lookup
│ └── validation.py # validate_against_principles │ └── validation.py # validate_against_principles
├── vendor/ # pinned Atelier snapshot (D-136) ├── vendor/ # pinned Atelier snapshot
│ ├── VERSION.md # pinned tag + upgrade instructions │ ├── VERSION.md # pinned tag + upgrade instructions
│ ├── core/first-principles.md │ ├── core/first-principles.md
│ ├── domains/security/first-principles.md │ ├── domains/security/first-principles.md
@@ -68,7 +67,7 @@ s.load_plugins()
result = s.call_tool("atelier_lookup_principle", {"domain": "security", "principle_id": "P4"}) result = s.call_tool("atelier_lookup_principle", {"domain": "security", "principle_id": "P4"})
``` ```
## Vendoring (D-136) ## Vendoring
Atelier is vendored under `vendor/` at a pinned tag (`v0.3.6`, see Atelier is vendored under `vendor/` at a pinned tag (`v0.3.6`, see
`vendor/VERSION.md`). An agentic validation result is only reproducible if `vendor/VERSION.md`). An agentic validation result is only reproducible if
-1
View File
@@ -1,6 +1,5 @@
# Nova Metrics Directory # Nova Metrics Directory
> v1.17 — Strategic Direction, Leadership Metrics & Unified Story (D-128)
This directory holds Nova's telemetry/observability artifacts. The This directory holds Nova's telemetry/observability artifacts. The
metrics layer is **Nova-native** (D-120): JSONL event log + SQLite cold metrics layer is **Nova-native** (D-120): JSONL event log + SQLite cold
-2
View File
@@ -1,7 +1,5 @@
# Nova PowerBI Dashboard — Import Guide # Nova PowerBI Dashboard — Import Guide
> v1.17 — Strategic Direction, Leadership Metrics & Unified Story (REQ-208)
> Generated: 2026-08-04
This guide documents how to import Nova's metrics views into PowerBI This guide documents how to import Nova's metrics views into PowerBI
via the folder connector, and suggests a starter visual model. via the folder connector, and suggests a starter visual model.
+34 -7
View File
@@ -48,6 +48,11 @@
"description": "Target group target type (ip or instance).", "description": "Target group target type (ip or instance).",
"required": false, "required": false,
"default": "ip" "default": "ip"
},
"enabled": {
"type": "boolean",
"default": true,
"description": "Feature flag: enable/disable this module. Set to false to skip resource creation."
} }
}, },
"outputs": { "outputs": {
@@ -85,20 +90,42 @@
{ {
"type": "aws:elbv2:loadbalancer", "type": "aws:elbv2:loadbalancer",
"description": "Application load balancer in the VPC subnets.", "description": "Application load balancer in the VPC subnets.",
"inputs": ["name", "subnets", "security_group", "load_balancer_type"], "inputs": [
"outputs": ["lb_arn"] "name",
"subnets",
"security_group",
"load_balancer_type"
],
"outputs": [
"lb_arn"
]
}, },
{ {
"type": "aws:elbv2:targetgroup", "type": "aws:elbv2:targetgroup",
"description": "Target group for the ECS service tasks.", "description": "Target group for the ECS service tasks.",
"inputs": ["name", "port", "protocol", "vpc_id", "target_type"], "inputs": [
"outputs": ["target_group_arn"] "name",
"port",
"protocol",
"vpc_id",
"target_type"
],
"outputs": [
"target_group_arn"
]
}, },
{ {
"type": "aws:elbv2:listener", "type": "aws:elbv2:listener",
"description": "Listener forwarding the LB port to the target group.", "description": "Listener forwarding the LB port to the target group.",
"inputs": ["lb_arn", "port", "protocol", "target_group_arn"], "inputs": [
"outputs": ["listener_arn"] "lb_arn",
"port",
"protocol",
"target_group_arn"
],
"outputs": [
"listener_arn"
]
} }
] ]
} }
+5 -2
View File
@@ -1,4 +1,5 @@
resource "aws_lb" "this" { resource "aws_lb" "this" {
count = var.enabled ? 1 : 0
name = var.name name = var.name
load_balancer_type = var.load_balancer_type load_balancer_type = var.load_balancer_type
subnets = local.subnet_list subnets = local.subnet_list
@@ -6,6 +7,7 @@ resource "aws_lb" "this" {
} }
resource "aws_lb_target_group" "this" { resource "aws_lb_target_group" "this" {
count = var.enabled ? 1 : 0
name_prefix = "${var.name}-" name_prefix = "${var.name}-"
port = var.port port = var.port
protocol = var.protocol protocol = var.protocol
@@ -18,13 +20,14 @@ resource "aws_lb_target_group" "this" {
} }
resource "aws_lb_listener" "this" { resource "aws_lb_listener" "this" {
load_balancer_arn = aws_lb.this.id count = var.enabled ? 1 : 0
load_balancer_arn = aws_lb.this[0].id
port = var.port port = var.port
protocol = var.protocol protocol = var.protocol
default_action { default_action {
type = "forward" type = "forward"
target_group_arn = aws_lb_target_group.this.arn target_group_arn = aws_lb_target_group.this[0].arn
} }
depends_on = [aws_lb_target_group.this] depends_on = [aws_lb_target_group.this]
+3 -3
View File
@@ -1,14 +1,14 @@
output "lb_arn" { output "lb_arn" {
value = aws_lb.this.id value = aws_lb.this[0].id
description = "The load balancer ARN." description = "The load balancer ARN."
} }
output "listener_arn" { output "listener_arn" {
value = aws_lb_listener.this.arn value = aws_lb_listener.this[0].arn
description = "The listener ARN." description = "The listener ARN."
} }
output "target_group_arn" { output "target_group_arn" {
value = aws_lb_target_group.this.arn value = aws_lb_target_group.this[0].arn
description = "The target group ARN." description = "The target group ARN."
} }
+6
View File
@@ -50,3 +50,9 @@ variable "vpc_id" {
description = "VPC ID for the target group (ref to vpc or platform VPC)." description = "VPC ID for the target group (ref to vpc or platform VPC)."
default = null default = null
} }
variable "enabled" {
type = bool
description = "Feature flag: enable/disable this module. Set to false to skip resource creation."
default = true
}
+31 -6
View File
@@ -43,6 +43,11 @@
"type": "string", "type": "string",
"description": "AWS region (CloudFront is global but the provider region is used for the OAC).", "description": "AWS region (CloudFront is global but the provider region is used for the OAC).",
"required": true "required": true
},
"enabled": {
"type": "boolean",
"default": true,
"description": "Feature flag: enable/disable this module. Set to false to skip resource creation."
} }
}, },
"outputs": { "outputs": {
@@ -75,17 +80,37 @@
{ {
"type": "aws:cloudfront:distribution", "type": "aws:cloudfront:distribution",
"description": "CloudFront distribution with S3 origin via OAC.", "description": "CloudFront distribution with S3 origin via OAC.",
"inputs": ["bucket_regional_domain_name", "price_class", "viewer_protocol_policy", "default_ttl", "max_ttl", "waf_web_acl_arn", "oac_id"], "inputs": [
"outputs": ["distribution_arn", "distribution_domain_name"] "bucket_regional_domain_name",
"price_class",
"viewer_protocol_policy",
"default_ttl",
"max_ttl",
"waf_web_acl_arn",
"oac_id"
],
"outputs": [
"distribution_arn",
"distribution_domain_name"
]
}, },
{ {
"type": "aws:cloudfront:originaccesscontrol", "type": "aws:cloudfront:originaccesscontrol",
"description": "Origin Access Control for the S3 origin.", "description": "Origin Access Control for the S3 origin.",
"inputs": ["name", "origin_type", "signing_behavior"], "inputs": [
"outputs": ["oac_id"] "name",
"origin_type",
"signing_behavior"
],
"outputs": [
"oac_id"
]
} }
], ],
"intra_refs": [ "intra_refs": [
{"from": "aws:cloudfront:distribution.oac_id", "to": "aws:cloudfront:originaccesscontrol.oac_id"} {
"from": "aws:cloudfront:distribution.oac_id",
"to": "aws:cloudfront:originaccesscontrol.oac_id"
}
] ]
} }
+3 -1
View File
@@ -1,4 +1,5 @@
resource "aws_cloudfront_origin_access_control" "this" { resource "aws_cloudfront_origin_access_control" "this" {
count = var.enabled ? 1 : 0
name = local.oac_name name = local.oac_name
origin_access_control_origin_type = local.oac_origin_type origin_access_control_origin_type = local.oac_origin_type
signing_behavior = local.oac_signing_behavior signing_behavior = local.oac_signing_behavior
@@ -6,10 +7,11 @@ resource "aws_cloudfront_origin_access_control" "this" {
} }
resource "aws_cloudfront_distribution" "this" { resource "aws_cloudfront_distribution" "this" {
count = var.enabled ? 1 : 0
origin { origin {
origin_id = "s3-origin" origin_id = "s3-origin"
domain_name = var.bucket_regional_domain_name domain_name = var.bucket_regional_domain_name
origin_access_control_id = aws_cloudfront_origin_access_control.this.id origin_access_control_id = aws_cloudfront_origin_access_control.this[0].id
s3_origin_config { s3_origin_config {
origin_access_identity = "" origin_access_identity = ""
} }
+3 -3
View File
@@ -1,14 +1,14 @@
output "distribution_arn" { output "distribution_arn" {
value = aws_cloudfront_distribution.this.arn value = aws_cloudfront_distribution.this[0].arn
description = "The CloudFront distribution ARN." description = "The CloudFront distribution ARN."
} }
output "distribution_domain_name" { output "distribution_domain_name" {
value = aws_cloudfront_distribution.this.domain_name value = aws_cloudfront_distribution.this[0].domain_name
description = "The CloudFront distribution domain name." description = "The CloudFront distribution domain name."
} }
output "oac_id" { output "oac_id" {
value = aws_cloudfront_origin_access_control.this.id value = aws_cloudfront_origin_access_control.this[0].id
description = "The Origin Access Control ID." description = "The Origin Access Control ID."
} }
@@ -38,3 +38,9 @@ variable "region" {
description = "AWS region (CloudFront is global but the provider region is used for the OAC)." description = "AWS region (CloudFront is global but the provider region is used for the OAC)."
default = null default = null
} }
variable "enabled" {
type = bool
description = "Feature flag: enable/disable this module. Set to false to skip resource creation."
default = true
}
+6 -1
View File
@@ -19,6 +19,11 @@
"type": "string", "type": "string",
"description": "ARN of the CMK for repository encryption; if absent, uses AWS-managed key.", "description": "ARN of the CMK for repository encryption; if absent, uses AWS-managed key.",
"required": false "required": false
},
"enabled": {
"type": "boolean",
"default": true,
"description": "Feature flag: enable/disable this module. Set to false to skip resource creation."
} }
}, },
"outputs": { "outputs": {
@@ -48,4 +53,4 @@
"default": true "default": true
} }
} }
} }
+1
View File
@@ -6,6 +6,7 @@ locals {
} }
resource "aws_ecr_repository" "this" { resource "aws_ecr_repository" "this" {
count = var.enabled ? 1 : 0
name = var.name name = var.name
image_tag_mutability = "MUTABLE" image_tag_mutability = "MUTABLE"
image_scanning_configuration { image_scanning_configuration {
+2 -2
View File
@@ -1,9 +1,9 @@
output "repository_url" { output "repository_url" {
value = aws_ecr_repository.this.repository_url value = aws_ecr_repository.this[0].repository_url
description = "The ECR repository URL." description = "The ECR repository URL."
} }
output "repository_arn" { output "repository_arn" {
value = aws_ecr_repository.this.arn value = aws_ecr_repository.this[0].arn
description = "The ECR repository ARN." description = "The ECR repository ARN."
} }
+7 -1
View File
@@ -13,4 +13,10 @@ variable "kms_key_arn" {
type = string type = string
description = "ARN of the CMK for ECR encryption; if absent, uses managed key." description = "ARN of the CMK for ECR encryption; if absent, uses managed key."
default = null default = null
} }
variable "enabled" {
type = bool
description = "Feature flag: enable/disable this module. Set to false to skip resource creation."
default = true
}
+6 -1
View File
@@ -19,6 +19,11 @@
"type": "string", "type": "string",
"description": "ARN of the CMK for CloudWatch log group encryption; if absent, uses managed key.", "description": "ARN of the CMK for CloudWatch log group encryption; if absent, uses managed key.",
"required": false "required": false
},
"enabled": {
"type": "boolean",
"default": true,
"description": "Feature flag: enable/disable this module. Set to false to skip resource creation."
} }
}, },
"outputs": { "outputs": {
@@ -43,4 +48,4 @@
"default": true "default": true
} }
} }
} }
+1
View File
@@ -1,3 +1,4 @@
resource "aws_ecs_cluster" "this" { resource "aws_ecs_cluster" "this" {
count = var.enabled ? 1 : 0
name = var.name name = var.name
} }
+2 -2
View File
@@ -1,9 +1,9 @@
output "cluster_arn" { output "cluster_arn" {
value = aws_ecs_cluster.this.arn value = aws_ecs_cluster.this[0].arn
description = "The ECS cluster ARN." description = "The ECS cluster ARN."
} }
output "cluster_id" { output "cluster_id" {
value = aws_ecs_cluster.this.id value = aws_ecs_cluster.this[0].id
description = "The ECS cluster ID." description = "The ECS cluster ID."
} }
@@ -15,3 +15,9 @@ variable "kms_key_arn" {
description = "ARN of the CMK for CloudWatch log group encryption; if absent, uses managed key." description = "ARN of the CMK for CloudWatch log group encryption; if absent, uses managed key."
default = null default = null
} }
variable "enabled" {
type = bool
description = "Feature flag: enable/disable this module. Set to false to skip resource creation."
default = true
}
+28 -5
View File
@@ -79,6 +79,11 @@
"description": "ECS task definition family name.", "description": "ECS task definition family name.",
"required": false, "required": false,
"default": "app" "default": "app"
},
"enabled": {
"type": "boolean",
"default": true,
"description": "Feature flag: enable/disable this module. Set to false to skip resource creation."
} }
}, },
"outputs": { "outputs": {
@@ -107,14 +112,32 @@
{ {
"type": "aws:ecs:task_definition", "type": "aws:ecs:task_definition",
"description": "Fargate task definition; the adapter jsonencodes image/port/env into container_definitions.", "description": "Fargate task definition; the adapter jsonencodes image/port/env into container_definitions.",
"inputs": ["image", "port", "cpu", "memory", "env", "family"], "inputs": [
"outputs": ["task_def_arn"] "image",
"port",
"cpu",
"memory",
"env",
"family"
],
"outputs": [
"task_def_arn"
]
}, },
{ {
"type": "aws:ecs:service", "type": "aws:ecs:service",
"description": "Fargate service running the task definition in the cluster + subnets.", "description": "Fargate service running the task definition in the cluster + subnets.",
"inputs": ["cluster_arn", "subnets", "security_group", "lb_target_group_arn", "desired_count", "launch_type"], "inputs": [
"outputs": ["service_arn"] "cluster_arn",
"subnets",
"security_group",
"lb_target_group_arn",
"desired_count",
"launch_type"
],
"outputs": [
"service_arn"
]
} }
] ]
} }
+3 -1
View File
@@ -1,4 +1,5 @@
resource "aws_ecs_task_definition" "this" { resource "aws_ecs_task_definition" "this" {
count = var.enabled ? 1 : 0
family = var.family family = var.family
cpu = tostring(var.cpu) cpu = tostring(var.cpu)
memory = tostring(var.memory) memory = tostring(var.memory)
@@ -8,9 +9,10 @@ resource "aws_ecs_task_definition" "this" {
} }
resource "aws_ecs_service" "this" { resource "aws_ecs_service" "this" {
count = var.enabled ? 1 : 0
name = "nova-microservice" name = "nova-microservice"
cluster = var.cluster_arn cluster = var.cluster_arn
task_definition = aws_ecs_task_definition.this.arn task_definition = aws_ecs_task_definition.this[0].arn
desired_count = var.desired_count desired_count = var.desired_count
launch_type = var.launch_type launch_type = var.launch_type
+2 -2
View File
@@ -1,9 +1,9 @@
output "service_arn" { output "service_arn" {
value = aws_ecs_service.this.id value = aws_ecs_service.this[0].id
description = "The ECS service ARN." description = "The ECS service ARN."
} }
output "task_def_arn" { output "task_def_arn" {
value = aws_ecs_task_definition.this.arn value = aws_ecs_task_definition.this[0].arn
description = "The ECS task definition ARN." description = "The ECS task definition ARN."
} }
@@ -78,3 +78,9 @@ variable "family" {
description = "ECS task definition family name." description = "ECS task definition family name."
default = "app" default = "app"
} }
variable "enabled" {
type = bool
description = "Feature flag: enable/disable this module. Set to false to skip resource creation."
default = true
}
+6 -1
View File
@@ -24,6 +24,11 @@
"type": "string", "type": "string",
"description": "AWS region the role is created in.", "description": "AWS region the role is created in.",
"required": true "required": true
},
"enabled": {
"type": "boolean",
"default": true,
"description": "Feature flag: enable/disable this module. Set to false to skip resource creation."
} }
}, },
"outputs": { "outputs": {
@@ -48,4 +53,4 @@
"default": true "default": true
} }
} }
} }
+3 -2
View File
@@ -1,11 +1,12 @@
resource "aws_iam_role" "this" { resource "aws_iam_role" "this" {
count = var.enabled ? 1 : 0
name = var.role_name name = var.role_name
assume_role_policy = local.assume_role_policy assume_role_policy = local.assume_role_policy
} }
resource "aws_iam_role_policy" "ecr_logs" { resource "aws_iam_role_policy" "ecr_logs" {
count = local.inline_policy != null ? 1 : 0 count = (local.inline_policy != null && var.enabled) ? 1 : 0
name = local.inline_policy.name name = local.inline_policy.name
role = aws_iam_role.this.id role = aws_iam_role.this[0].id
policy = local.inline_policy.policy policy = local.inline_policy.policy
} }
+2 -2
View File
@@ -1,9 +1,9 @@
output "role_arn" { output "role_arn" {
value = aws_iam_role.this.arn value = aws_iam_role.this[0].arn
description = "The IAM role ARN." description = "The IAM role ARN."
} }
output "role_id" { output "role_id" {
value = aws_iam_role.this.id value = aws_iam_role.this[0].id
description = "The IAM role ID." description = "The IAM role ID."
} }
@@ -21,3 +21,9 @@ variable "region" {
description = "AWS region (provider-level; not a resource arg)." description = "AWS region (provider-level; not a resource arg)."
default = null default = null
} }
variable "enabled" {
type = bool
description = "Feature flag: enable/disable this module. Set to false to skip resource creation."
default = true
}
+6 -1
View File
@@ -20,6 +20,11 @@
"description": "Number of days before the key is deleted after deletion is requested (default 30).", "description": "Number of days before the key is deleted after deletion is requested (default 30).",
"required": false, "required": false,
"default": 30 "default": 30
},
"enabled": {
"type": "boolean",
"default": true,
"description": "Feature flag: enable/disable this module. Set to false to skip resource creation."
} }
}, },
"outputs": { "outputs": {
@@ -49,4 +54,4 @@
"default": true "default": true
} }
} }
} }
+3 -1
View File
@@ -1,10 +1,12 @@
resource "aws_kms_key" "this" { resource "aws_kms_key" "this" {
count = var.enabled ? 1 : 0
description = var.description description = var.description
enable_key_rotation = true enable_key_rotation = true
deletion_window_in_days = var.deletion_window_days deletion_window_in_days = var.deletion_window_days
} }
resource "aws_kms_alias" "this" { resource "aws_kms_alias" "this" {
count = var.enabled ? 1 : 0
name = local.alias_name name = local.alias_name
target_key_id = aws_kms_key.this.key_id target_key_id = aws_kms_key.this[0].key_id
} }
+2 -2
View File
@@ -1,9 +1,9 @@
output "kms_key_arn" { output "kms_key_arn" {
value = aws_kms_key.this.arn value = aws_kms_key.this[0].arn
description = "The KMS key ARN." description = "The KMS key ARN."
} }
output "kms_key_id" { output "kms_key_id" {
value = aws_kms_key.this.key_id value = aws_kms_key.this[0].key_id
description = "The KMS key ID." description = "The KMS key ID."
} }
+7 -1
View File
@@ -14,4 +14,10 @@ variable "deletion_window_days" {
type = number type = number
description = "Deletion window in days (7-30)." description = "Deletion window in days (7-30)."
default = 30 default = 30
} }
variable "enabled" {
type = bool
description = "Feature flag: enable/disable this module. Set to false to skip resource creation."
default = true
}
+5
View File
@@ -79,6 +79,11 @@
"description": "Database admin password", "description": "Database admin password",
"required": false, "required": false,
"default": "ACdlcI2026!" "default": "ACdlcI2026!"
},
"enabled": {
"type": "boolean",
"default": true,
"description": "Feature flag: enable/disable this module. Set to false to skip resource creation."
} }
}, },
"outputs": { "outputs": {
+1
View File
@@ -5,6 +5,7 @@ resource "aws_db_subnet_group" "this" {
} }
resource "aws_db_instance" "this" { resource "aws_db_instance" "this" {
count = var.enabled ? 1 : 0
engine = var.engine engine = var.engine
engine_version = var.engine_version engine_version = var.engine_version
instance_class = var.instance_class instance_class = var.instance_class
+2 -2
View File
@@ -1,9 +1,9 @@
output "db_endpoint" { output "db_endpoint" {
value = aws_db_instance.this.endpoint value = aws_db_instance.this[0].endpoint
description = "The RDS instance endpoint." description = "The RDS instance endpoint."
} }
output "db_arn" { output "db_arn" {
value = aws_db_instance.this.arn value = aws_db_instance.this[0].arn
description = "The RDS instance ARN." description = "The RDS instance ARN."
} }
+6
View File
@@ -64,3 +64,9 @@ variable "subnet_ids" {
description = "Comma-separated subnet IDs for the DB subnet group (VPC-dependent)." description = "Comma-separated subnet IDs for the DB subnet group (VPC-dependent)."
default = "" default = ""
} }
variable "enabled" {
type = bool
description = "Feature flag: enable/disable this module. Set to false to skip resource creation."
default = true
}
+6 -1
View File
@@ -19,6 +19,11 @@
"type": "string", "type": "string",
"description": "ARN of the CMK for SSE-KMS; if absent, uses managed key.", "description": "ARN of the CMK for SSE-KMS; if absent, uses managed key.",
"required": false "required": false
},
"enabled": {
"type": "boolean",
"default": true,
"description": "Feature flag: enable/disable this module. Set to false to skip resource creation."
} }
}, },
"outputs": { "outputs": {
@@ -57,4 +62,4 @@
"default": true "default": true
} }
} }
} }
+5 -2
View File
@@ -1,10 +1,12 @@
resource "aws_s3_bucket" "this" { resource "aws_s3_bucket" "this" {
count = var.enabled ? 1 : 0
bucket = var.bucket_name bucket = var.bucket_name
tags = local.tags tags = local.tags
} }
resource "aws_s3_bucket_versioning" "this" { resource "aws_s3_bucket_versioning" "this" {
bucket = aws_s3_bucket.this.id count = var.enabled ? 1 : 0
bucket = aws_s3_bucket.this[0].id
versioning_configuration { versioning_configuration {
status = "Enabled" status = "Enabled"
@@ -12,7 +14,8 @@ resource "aws_s3_bucket_versioning" "this" {
} }
resource "aws_s3_bucket_server_side_encryption_configuration" "this" { resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
bucket = aws_s3_bucket.this.id count = var.enabled ? 1 : 0
bucket = aws_s3_bucket.this[0].id
rule { rule {
apply_server_side_encryption_by_default { apply_server_side_encryption_by_default {
+3 -3
View File
@@ -1,14 +1,14 @@
output "bucket_arn" { output "bucket_arn" {
value = aws_s3_bucket.this.arn value = aws_s3_bucket.this[0].arn
description = "The S3 bucket ARN." description = "The S3 bucket ARN."
} }
output "bucket_name" { output "bucket_name" {
value = aws_s3_bucket.this.id value = aws_s3_bucket.this[0].id
description = "The bucket name (echoes the input)." description = "The bucket name (echoes the input)."
} }
output "bucket_regional_domain_name" { output "bucket_regional_domain_name" {
value = aws_s3_bucket.this.bucket_regional_domain_name value = aws_s3_bucket.this[0].bucket_regional_domain_name
description = "The bucket regional domain name (e.g. nova-spike-bucket.s3.us-east-1.amazonaws.com)." description = "The bucket regional domain name (e.g. nova-spike-bucket.s3.us-east-1.amazonaws.com)."
} }
+7 -1
View File
@@ -19,4 +19,10 @@ variable "tags" {
type = map(string) type = map(string)
description = "Additional tags to merge with the module defaults." description = "Additional tags to merge with the module defaults."
default = {} default = {}
} }
variable "enabled" {
type = bool
description = "Feature flag: enable/disable this module. Set to false to skip resource creation."
default = true
}
+6 -1
View File
@@ -71,6 +71,11 @@
"type": "string", "type": "string",
"description": "ECS cluster ARN to deploy the service into", "description": "ECS cluster ARN to deploy the service into",
"required": false "required": false
},
"enabled": {
"type": "boolean",
"default": true,
"description": "Feature flag: enable/disable this module. Set to false to skip resource creation."
} }
}, },
"outputs": { "outputs": {
@@ -99,4 +104,4 @@
"default": true "default": true
} }
} }
} }
+1 -1
View File
@@ -11,7 +11,7 @@ resource "aws_ecs_service" "uptime" {
name = "nova-uptime" name = "nova-uptime"
cluster = local.cluster_ref cluster = local.cluster_ref
task_definition = aws_ecs_task_definition.uptime.arn task_definition = aws_ecs_task_definition.uptime.arn
desired_count = var.feature_flag_enabled ? 1 : 0 desired_count = var.enabled ? (var.feature_flag_enabled ? 1 : 0) : 0
launch_type = "FARGATE" launch_type = "FARGATE"
dynamic "network_configuration" { dynamic "network_configuration" {

Some files were not shown because too many files have changed in this diff Show More