Parent runbook: docs/slo/completed/RUNBOOK-hulumi-operations.md. Read Carmack-Style Best Practices, the Global Execution Rules + Global Entry Rules + docs/slo/lessons/hulumi-operations-m{1,2,3,4}.md before starting.
Goal: After M5, the /hulumi-threat-model skill ships three new prebuilt scenarios (aws-patch-compliance-lapse, aws-detective-service-disabled, aws-audit-pipeline-broken) and an atomic four-package release (@hulumi/baseline@1.2.0, @hulumi/policies@1.2.0, @hulumi/drift@1.2.0, @hulumi/k8s-baseline@1.2.0) lands with SLSA Build L3 attestation. CHANGELOG, README, getting-started, why-hulumi, three new cookbooks, three new examples (smoke), component reference docs, and the weekly-integration matrix all updated.
Context: This is the launch-readiness milestone. By end of M5, every Hulumi consumer who installs @hulumi/baseline@1.2.0 gets Ec2PatchBaseline + DetectiveServicesEnable + AuditTrail + the IdentityAlarms extension; consumers who install @hulumi/policies@1.2.0 get HulumiOperationsHardeningPack; consumers who run /hulumi-threat-model aws-patch-compliance-lapse get a structured threat-model markdown for the un-patched-fleet attack surface. The release pipeline mirrors the v1.0.0 + v1.1.0 atomic four-package pattern — no new infrastructure, just an extended publish list and CHANGELOG entry. Issues #47 and #49 closed in the release notes.
Carmack-style reliability goal: Strengthen Rule 6 — preserve compatibility until explicitly broken at the release-pipeline layer (every published tarball carries SLSA attestation; the consumer can gh attestation verify every package; the existing verify-provenance.md cookbook applies unchanged to the four new tarballs). Plus Rule 7 — no silent failure at the launch gate: if any of the three new skill scenarios fails its schema validation, or if any cookbook's runnable example fails the integration test, the release does NOT ship.
Important design rule: Atomic four-package release. All four packages bump to 1.2.0 together — even @hulumi/drift@1.2.0 (which has no functional changes in this runbook) gets a version bump for consistency. The atomic-release pattern is committed in docs/slo/lessons/hulumi-k8s-m5.md (existing) as the discipline that prevents version-skew confusion in the wild. Mirror it.
Refactor budget: Targeted refactor permitted for release-pipeline metadata only. All component / policy / skill code work is done in M1-M4; M5 is documentation, examples, scenarios, and the publish step. The "targeted" refactor scope: package.json version fields in four packages, CHANGELOG.md entry, release.yml (verify the existing atomic-release matrix covers all four — same pattern as v1.1.0 release; should be a no-op verify), weekly-integration.yml (extend matrix to include aws-ops).
| Field | Value |
|---|---|
| Inputs | Three new skill scenario JSON files; CHANGELOG / README / cookbook / example markdown + TypeScript additions; release tag v1.2.0 triggers the existing atomic-release workflow. |
| Outputs | Four published npm tarballs at 1.2.0 with SLSA Build L3 attestations; one GitHub release with SBOMs; three new prebuilt scenarios available in the /hulumi-threat-model skill; four new cookbooks indexed in docs/cookbooks/README.md (ec2-patch-baseline-bootstrap, detective-services-enable, audit-trail-from-scratch, hardened-base-images); three new examples under examples/. |
| Interfaces touched | /hulumi-threat-model scenario IDs (NEW × 3 — stable from M5 onward); @hulumi/baseline@1.2.0 (version bump only — surface from M1-M3 unchanged); @hulumi/policies@1.2.0 (version bump + new HulumiOperationsHardeningPack export from M4); @hulumi/drift@1.2.0 (version bump only — no functional change); @hulumi/k8s-baseline@1.2.0 (version bump only — no functional change). |
| Data classification | Public. Skill scenarios cite framework IDs only (no verbatim text); release artifacts are public; cookbooks are public; SBOMs are public. CHANGELOG closes issues #47 and #49 — both public. No consumer data involved. |
| Proactive controls in play | (a) C1 Define Security Requirements — skill scenarios encode the requirements for consumer threat-modeling. (b) Existing SLSA Build L3 release pipeline — unchanged; consumed at-release. (c) Existing verify-provenance.md cookbook — applies unchanged. (d) license-boundary-lint — covers new mapping doc + new cookbook content (no verbatim framework text). (e) Existing compliance-justified-suppressions test — applies unchanged. |
| Abuse acceptance scenarios | One BDD row below cites tm-hulumi-ops-abuse-rule-pack-feature-flag from the threat model: M5 ships the O_* rule pack as enabled-by-default (no feature flag) — assertion in the release-readiness test that the pack is exported from @hulumi/policies@1.2.0's top-level index.ts without any if (process.env.HULUMI_ENABLE_OPS) { ... } guard. The other M5 abuse cases (skill citation fabrication, supply-chain attestation tamper) are inherited from the existing v1.0.0 pipeline and need no new code in this milestone — they're verified by the existing release tests. |
| Files allowed to change | NEW: skills/hulumi-threat-model/scenarios/aws-patch-compliance-lapse.json, skills/hulumi-threat-model/scenarios/aws-detective-service-disabled.json, skills/hulumi-threat-model/scenarios/aws-audit-pipeline-broken.json, docs/cookbooks/ec2-patch-baseline-bootstrap.md, docs/cookbooks/detective-services-enable.md, docs/cookbooks/audit-trail-from-scratch.md, examples/ec2-patch-baseline-smoke/{index.ts,package.json,Pulumi.yaml}, examples/detective-services-smoke/{index.ts,package.json,Pulumi.yaml}, examples/audit-trail-smoke/{index.ts,package.json,Pulumi.yaml}, docs/slo/lessons/hulumi-operations-m5.md, docs/slo/completion/hulumi-operations-m5.md. MODIFIED: packages/baseline/package.json (version: "1.2.0"), packages/policies/package.json (version: "1.2.0"), packages/drift/package.json (version: "1.2.0"), packages/k8s-baseline/package.json (version: "1.2.0"), CHANGELOG.md (v1.2.0 entry — closes #47, #49 + new components + new policy pack + new scenarios), README.md (Operations surface section), AGENTS.md (pointer to RUNBOOK-hulumi-operations.md), docs/why-hulumi.md (paragraph on Operations + scope contract), docs/getting-started.md ("Operations" section), docs/cookbooks/README.md (three new entries), docs/components/{ec2-patch-baseline,detective-services-enable,audit-trail,hulumi-operations-hardening-pack}.md (full reference docs replacing the one-line stubs from M1-M4), docs/components/README.md (index entries), .github/workflows/weekly-integration.yml (extend matrix to include aws-ops), docs/issue-candidates.md (sync with v1.2 release). REFUSE TO TOUCH: any packages/*/src/*.ts file (release milestone — no functional code changes); release.yml if it already covers four packages (verify; do not modify unless it explicitly excludes one of the four). |
| Files to read before changing anything | docs/slo/completed/RUNBOOK-hulumi-operations.md; lessons-m1, m2, m3, m4; docs/cookbooks/verify-provenance.md (existing — applies to the new tarballs); docs/cookbooks/README.md (index pattern); docs/threat-model-examples/ (existing scenarios — shape precedent); skills/hulumi-threat-model/scenarios/aws-multi-account-baseline.json (the canonical scenario shape); skills/hulumi-threat-model/scripts/validate-scenarios.mjs (the existing validator the new scenarios must pass); .github/workflows/release.yml (verify the four-package matrix is complete); .github/workflows/weekly-integration.yml; CHANGELOG.md (v1.0.0 + v1.1.0 entry shape); examples/secure-bucket-smoke/ (smoke-example shape precedent). |
| New files allowed | All NEW entries above. |
| New dependencies allowed | none. Examples consume the existing @hulumi/* packages and @pulumi/aws. |
| Migration allowed | no — additive only. v1.2.0 is a minor bump (additions only); existing v1.1.x consumers see no breaking change. |
| Compatibility commitments | All four packages bump to 1.2.0 atomically. SemVer minor — additions only, no breakage. The three new skill scenario IDs are stable from M5; renaming them is a major skill-version bump. |
| Resource bounds introduced/changed (v4 Rule 4) | (a) /hulumi-threat-model total scenario count: 12 (existing 9 + 3 new); hard cap of 20 (a documented soft cap; if a 13th scenario is needed, it lands in v1.3 with a fresh contract). Asserted in skill-scenario-count.test.ts (NEW or extend existing). (b) Three new examples each have a hard cap of 100 lines per index.ts (smoke examples, not production patterns); enforced by a meta-test against the example dirs. |
| Invariants/assertions required (v4 Rule 3) | (i) Every new scenario JSON validates against the existing skills/hulumi-threat-model/scenarios/schema.json (no schema change in M5). (ii) Every new scenario's recommendedComponents[].availability field reads "Shipped in M<N>" (per the #15 sweep convention). (iii) Every new scenario's frameworks[].id field is one of the existing accepted IDs — no new frameworks introduced in M5. (iv) Every example's Pulumi.yaml declares runtime: nodejs and pins @hulumi/* to 1.2.0 exact. (v) The O_* rule pack is exported from @hulumi/policies@1.2.0's top-level index.ts with no feature-flag guard (the tm-hulumi-ops-abuse-rule-pack-feature-flag mitigation). |
| Debugger / inspection expectation (v4 Rule 1) | Release-failure inspection: if pnpm run release:dry fails, run gh attestation verify ./hulumi-baseline-1.2.0.tgz --repo kerberosmansour/hulumi to confirm the attestation chain renders correctly; if a skill scenario validation fails, run node skills/hulumi-threat-model/scripts/validate-scenarios.mjs --file <path> to inspect the schema violation directly. |
| Static analysis gates (v4 Rule 2) | Same as M1-M4. Plus: node skills/hulumi-threat-model/scripts/validate-scenarios.mjs against the three new scenarios — must pass. Plus: pnpm --filter examples-ec2-patch-baseline-smoke build (and the other two examples) — must pass (compile-only smoke; no real AWS deploy in M5 release readiness gate). |
| Forbidden shortcuts | (a) NEVER publish only some of the four packages — atomic four-package release is non-negotiable. (b) NEVER ship a scenario JSON that fails the schema validator. (c) NEVER ship verbatim CIS / NIST / PCI-DSS text in any new cookbook or scenario; license-boundary lint covers cookbooks too. (d) NEVER introduce a feature flag for the O_* pack; it ships enabled by default. (e) NEVER force-push to main to fix a failed release. If release.yml fails, fix forward. (f) NEVER skip gh attestation verify against the four published tarballs as part of the release-readiness smoke test. (g) NEVER publish a 1.2.0 if any of the M1-M4 lessons files records an unresolved invariant or unbounded resource — all M1-M4 milestones must be done before M5 ships. |
- No new components (M1-M3 ship them; M5 only documents).
- No new policy rules (M4 ships them; M5 only releases).
- No new frameworks in skill scenarios — IDs only from existing accepted list.
- No
release.ymlrewrite — verify it covers four packages; if it already does, no edit. If it doesn't (it should — v1.1.0 already shipped four packages), the fix is targeted: add the missing package to the matrix; do NOT refactor the workflow. - No
weekly-integration.ymlrewrite — additive matrix entry only. - No
verify-provenance.mdcookbook update — it's framework-pack-agnostic; applies to the new tarballs unchanged. - No CHANGELOG rewrite — additive v1.2.0 entry only.
- No skill-script changes — the new scenarios validate against the existing schema; no schema bump.
- Complete Global Entry Rules.
- Read lessons-m1, m2, m3, m4 — apply corrections.
- Confirm M1-M4 Milestone Tracker rows are all
done. - Read the existing
aws-multi-account-baseline.jsonscenario in full as the shape precedent for the three new scenarios. - Read
docs/cookbooks/verify-provenance.mdanddocs/cookbooks/README.mdfor the cookbook shape. - Read
examples/secure-bucket-smoke/for the smoke-example shape. - Verify the existing
release.ymlworkflow has all four packages in its publish matrix (@hulumi/baseline,@hulumi/policies,@hulumi/drift,@hulumi/k8s-baseline). If yes, norelease.ymledit needed. - Re-state load-bearing constraints: (i) atomic four-package release; (ii) no feature flag for
O_*pack; (iii) schema-validated scenarios withShipped in M<N>strings; (iv) every example pins@hulumi/*to1.2.0exact.
| File | Planned Change |
|---|---|
skills/hulumi-threat-model/scenarios/aws-patch-compliance-lapse.json |
NEW: full scenario per existing schema; recommended components = Ec2PatchBaseline (Shipped in M1), O_PATCH_1 (Shipped in M4); abuse-case rows from threat model |
skills/hulumi-threat-model/scenarios/aws-detective-service-disabled.json |
NEW: recommended components = DetectiveServicesEnable (Shipped in M2), O_DETECT_1 (Shipped in M4) |
skills/hulumi-threat-model/scenarios/aws-audit-pipeline-broken.json |
NEW: recommended components = AuditTrail + IdentityAlarms extension (Shipped in M3), O_AUDIT_1 (Shipped in M4) |
docs/cookbooks/ec2-patch-baseline-bootstrap.md |
NEW: bootstrap cookbook (covers Ec2PatchBaseline + Ec2PatchWaves together) |
docs/cookbooks/detective-services-enable.md |
NEW: bootstrap cookbook (covers dual-route + KEV-native via Inspector v2 + cost worked example + Trivy-in-CI fallback) |
docs/cookbooks/audit-trail-from-scratch.md |
NEW: bootstrap cookbook |
docs/cookbooks/hardened-base-images.md |
NEW 2026-05-01: decision tree for Docker Hardened Images (DHI) vs Chainguard Developer Images vs AL2023-Minimal vs Google Distroless — free hardened-image options. Covers FROM-digest-pinning pattern, ECR pull-through cache (DHI / Chainguard upstreams), Renovate config for auto-PR on digest bumps, devcontainer integration so the dev's laptop image matches CI. Cookbook only — no Hulumi component shipped in v1.2. Components (EcrPullThroughCache, Ec2GoldenAmiPipeline) ship in v1.3. |
examples/ec2-patch-baseline-smoke/{index.ts,package.json,Pulumi.yaml} |
NEW: ≤100 line smoke example |
examples/detective-services-smoke/{index.ts,package.json,Pulumi.yaml} |
NEW: smoke example |
examples/audit-trail-smoke/{index.ts,package.json,Pulumi.yaml} |
NEW: smoke example |
packages/baseline/package.json |
MODIFY: version: "1.2.0" |
packages/policies/package.json |
MODIFY: version: "1.2.0" |
packages/drift/package.json |
MODIFY: version: "1.2.0" |
packages/k8s-baseline/package.json |
MODIFY: version: "1.2.0" |
CHANGELOG.md |
MODIFY: v1.2.0 entry — lists Ec2PatchBaseline / DetectiveServicesEnable / AuditTrail / IdentityAlarms-extension / HulumiOperationsHardeningPack / 3 new scenarios; closes #47, #49 |
README.md |
MODIFY: Operations surface section + version bump in install snippets |
AGENTS.md |
MODIFY: pointer to RUNBOOK-hulumi-operations.md |
docs/why-hulumi.md |
MODIFY: paragraph on Operations + scope contract |
docs/getting-started.md |
MODIFY: "Operations" section |
docs/cookbooks/README.md |
MODIFY: three new entries |
docs/components/ec2-patch-baseline.md |
MODIFY: full reference replacing one-line stub |
docs/components/detective-services-enable.md |
MODIFY: full reference |
docs/components/audit-trail.md |
MODIFY: full reference |
docs/components/hulumi-operations-hardening-pack.md |
MODIFY: full reference |
docs/components/README.md |
MODIFY: index entries |
.github/workflows/weekly-integration.yml |
MODIFY: extend matrix to include aws-ops integration test path |
docs/issue-candidates.md |
MODIFY: sync with v1.2 release |
docs/slo/completed/RUNBOOK-hulumi-operations.md |
MODIFY: Milestone Tracker → M5 done, Documentation Update Table final fill-in |
docs/slo/runbook-milestones/hulumi-operations-m5.md |
MODIFY: Evidence Log fill-in |
docs/slo/lessons/hulumi-operations-m5.md |
NEW per v4 lessons template |
docs/slo/completion/hulumi-operations-m5.md |
NEW per v4 completion template |
- Pre-flight + verify M1-M4 done state.
- Write the three new scenario JSON files. Run
node skills/hulumi-threat-model/scripts/validate-scenarios.mjs— must pass for all three. - Write the four cookbooks (each ≤300 lines, copy-pasteable, framework-IDs-only):
ec2-patch-baseline-bootstrap.md,detective-services-enable.md,audit-trail-from-scratch.md, andhardened-base-images.md(added 2026-05-01). The hardened-base-images cookbook documents the v1.2 path (cookbook-only, no Hulumi component) and forward-references v1.3 forEcrPullThroughCache+Ec2GoldenAmiPipeline. - Write the three smoke examples (each ≤100 lines, compiles, doesn't deploy in CI).
- Run
pnpm --filter examples-* build— all green. - Update component reference docs (
ec2-patch-baseline.md,detective-services-enable.md,audit-trail.md,hulumi-operations-hardening-pack.md) from one-line stubs to full reference docs (each ≤500 lines). - Update README, AGENTS.md, why-hulumi.md, getting-started.md, cookbooks/README.md, components/README.md.
- Bump
version: "1.2.0"in all fourpackage.jsonfiles atomically (one commit). - Write CHANGELOG v1.2.0 entry — closes #47, #49, lists every new export.
- Verify
release.ymlcovers four packages; if not, add the missing one with a targeted patch. - Extend
weekly-integration.ymlmatrix. - Run full repo suite + the new scenario validator + the example builds. All green.
- Tag
v1.2.0and push (or document the manual tag step in the lessons file). Existing release pipeline runs the atomic four-package publish + SLSA attestation. - After release, smoke-verify with
gh attestation verify ./hulumi-baseline-1.2.0.tgz --repo kerberosmansour/hulumi(and the other three packages). Document the verification output in the Evidence Log. - Self-Review Gate. Update Tracker, write lessons + completion, sync
docs/issue-candidates.mdwith v1.2 state.
Feature: M5 release-readiness — three new scenarios, three new cookbooks, three new examples, atomic four-package v1.2.0 release
| Scenario | Category | Given | When | Then | Threat-model row | Control |
|---|---|---|---|---|---|---|
| Happy path — three new scenarios validate against existing schema | happy path | three new JSON files in skills/hulumi-threat-model/scenarios/ |
node skills/hulumi-threat-model/scripts/validate-scenarios.mjs |
exits 0; no schema violation; the existing 9 scenarios still validate | n/a | invariant (i) |
Happy path — every new scenario's availability reads "Shipped in M" |
happy path | three new scenario JSON files | grep availability field across the three |
every value matches ^Shipped in M\d+$ |
n/a | invariant (ii) |
| Invalid input — scenario JSON with malformed framework ID | invalid input | synthetic scenario JSON with frameworks[0].id: "FAKE-CTRL-99" |
validator script | exits non-zero; specific file + line of the unknown ID | n/a | invariant (iii) |
| Empty state — no examples deployed | empty state | M5 publishes packages but no consumer has imported @hulumi/baseline@1.2.0 yet |
(no consumer activity) | the release is published; npm view @hulumi/baseline@1.2.0 returns the new version; no consumer-side regression |
n/a | n/a |
| Dependency failure — release fails on a single package's SLSA attestation | partial failure | release.yml runs; SLSA attestation step fails on one package | (release pipeline) | the entire release rolls back; no package is left half-published; the lessons file documents the recovery | inherited supply-chain row | Forbidden (a) |
| Resource bound — total scenario count ≤ 20 | resource bound | 12 scenarios after M5 (9 existing + 3 new) | skill-scenario-count.test.ts |
count = 12; bound = 20; near-limit guidance documented in lessons | n/a | Rule 4 |
Invariant — O_* pack exported with no feature flag |
assertion violation | packages/policies/src/index.ts |
grep for process.env.HULUMI_ENABLE_OPS or similar |
grep returns zero matches; assertion fires the test if any feature-flag guard wraps the export | tm-hulumi-ops-abuse-rule-pack-feature-flag |
Rule 11 + Forbidden (d) |
Invariant — every example pins @hulumi/* to 1.2.0 exact |
assertion violation | examples/{ec2-patch-baseline,detective-services,audit-trail}-smoke/package.json |
grep @hulumi/ lines |
every match shows "1.2.0" exact (no ^, no ~, no range); assertion fails if any range modifier present |
n/a | invariant (iv) |
| Compatibility — existing v1.1.x consumers can install v1.2.0 with no breaking change | compatibility | a consumer at @hulumi/baseline@1.1.x |
upgrade to 1.2.0 and re-run pulumi preview |
no preview diff for resources unrelated to the new components; existing components produce identical output | n/a | SemVer minor |
Compatibility — gh attestation verify succeeds for all four tarballs |
compatibility | published @hulumi/{baseline,policies,drift,k8s-baseline}@1.2.0 |
run gh attestation verify against each .tgz |
each verification reports ✓ Verified attestation; commit SHA and workflow run URL match release expectations |
inherited supply-chain row | Rule 6 |
Smoke — three new examples compile under pnpm build |
smoke | three new examples with @hulumi/*@1.2.0 deps |
pnpm install --frozen-lockfile && pnpm --filter "examples-*-smoke" build |
all three examples build cleanly | n/a | release readiness |
| Abuse case — release without M1-M4 done state rejected | abuse case | one of M1-M4 has Status: in_progress in the runbook tracker |
release-readiness gate | the gate refuses to tag v1.2.0; lessons file documents the gate | n/a | Forbidden (g) |
- All M1 + M2 + M3 + M4 BDD continue to pass.
- All existing AWS / GitHub / K8s BDD continue to pass.
- All existing 9 skill scenarios validate against schema unchanged.
- License-boundary lint passes on the three new cookbooks + the three new scenario JSONs (no verbatim text).
- Existing
verify-provenance.mdcookbook applies unchanged — confirmed by re-runninggh attestation verifyon a v1.1.0 tarball as a baseline.
-
1.2.0published for all four packages atomically. - All four packages carry SLSA Build L3 attestations verifiable via
gh attestation verify. - Three new skill scenarios validate against the existing schema.
- No new dependencies in any of the four packages.
- Three new cookbooks indexed in
docs/cookbooks/README.md. - Three new examples build under
pnpm buildcleanly. -
O_*rule pack exported without feature-flag guard. - Static-analysis gates green.
- License-boundary lint green on the new files.
- All M1 + M2 + M3 + M4 + existing AWS / GitHub / K8s BDD scenarios produce valid output unchanged.
- Existing v1.1.x consumers can upgrade to 1.2.0 without breakage.
- CHANGELOG v1.2.0 entry closes #47 and #49 explicitly.
Files: tests/release-readiness/{scenarios,examples,attestations,packs}.test.ts (NEW or extending existing release-readiness suite).
| E2E Test | What It Proves | Pass Criteria |
|---|---|---|
three_new_scenarios_validate_against_schema |
Scenario shape is correct | node skills/hulumi-threat-model/scripts/validate-scenarios.mjs --files <three new files> exits 0. |
three_new_examples_build_with_v1_2_0_pinned_deps |
Examples are runnable | pnpm --filter "examples-{ec2-patch-baseline,detective-services,audit-trail}-smoke" build exits 0; package.json shows "@hulumi/baseline": "1.2.0" exact (regex check rejects ^, ~, ranges). |
four_packages_atomic_release_succeeds |
Atomic-release pattern holds | After release.yml runs to completion: npm view @hulumi/baseline@1.2.0 version returns 1.2.0; same for policies, drift, k8s-baseline. If any package returns "not found", the test fails. |
gh_attestation_verify_succeeds_for_all_four |
SLSA chain works | gh attestation verify ./hulumi-baseline-1.2.0.tgz --repo kerberosmansour/hulumi exits 0; same for the other three packages. |
O_pack_exported_without_feature_flag |
Abuse case tm-hulumi-ops-abuse-rule-pack-feature-flag mitigated |
grep process.env.HULUMI_ENABLE_OPS and similar feature-flag patterns in packages/policies/src/index.ts returns zero matches. |
- Full static-analysis suite green.
- All M1-M4 BDD + the new release-readiness E2E tests green.
-
pnpm --filter examples-ec2-patch-baseline-smoke buildgreen. -
pnpm --filter examples-detective-services-smoke buildgreen. -
pnpm --filter examples-audit-trail-smoke buildgreen. - In a Pulumi program:
import { Ec2PatchBaseline } from "@hulumi/baseline"resolves to the v1.2.0 export;pulumi previewsucceeds. -
gh attestation verify ./hulumi-baseline-1.2.0.tgz --repo kerberosmansour/hulumi→✓ Verified attestation. -
git statusclean. -
.gitignorecovers any new generated files.
| Step | Command / Check | Expected Result | Actual Result | Pass/Fail | Notes |
|---|---|---|---|---|---|
| Baseline tests | pnpm -r build && pnpm -r test |
green | filled during execution | pending | |
| M1-M4 done state verified | runbook Milestone Tracker shows M1-M4 = done |
confirmed | filled during execution | pending | Forbidden shortcut (g) gate |
| Three new scenarios written | filesystem | three JSON files present | filled during execution | pending | |
| Scenario validator green | node skills/hulumi-threat-model/scripts/validate-scenarios.mjs |
all 12 scenarios validate | filled during execution | pending | |
| Four cookbooks written | filesystem | four markdown files present, indexed (incl. hardened-base-images.md) |
filled during execution | pending | |
| Three examples written + build green | pnpm --filter "examples-*-smoke" build |
all three build clean | filled during execution | pending | |
| Component refs upgraded | filesystem | four full-reference docs replace stubs | filled during execution | pending | |
package.json versions bumped |
grep version in four package.json |
all four = "1.2.0" |
filled during execution | pending | |
| CHANGELOG v1.2.0 entry | cat CHANGELOG.md |
entry present; closes #47, #49 | filled during execution | pending | |
release.yml covers four packages |
grep release.yml |
matrix lists all four packages | filled during execution | pending | Forbidden shortcut (a) |
weekly-integration.yml extended |
grep aws-ops |
new matrix entry present | filled during execution | pending | |
| Formatter | pnpm -r format:check |
clean | filled during execution | pending | |
| Typecheck | pnpm -r typecheck |
clean | filled during execution | pending | |
| Static analyzer | pnpm -r lint |
clean | filled during execution | pending | |
| License-boundary lint | pnpm run lint:license-boundary |
OK on new cookbooks + scenarios | filled during execution | pending | |
| Exact-pin guard | pnpm run lint:exact-pin-guard |
OK | filled during execution | pending | |
| Full tests | pnpm -r test |
green | filled during execution | pending | |
| Release tag pushed | git tag v1.2.0 && git push --tags |
tag created; release.yml triggers | filled during execution | pending | |
| Atomic four-package publish | release.yml workflow run |
all four packages at v1.2.0 on npm | filled during execution | pending | |
gh attestation verify × 4 |
command listed above | each → ✓ Verified attestation |
filled during execution | pending | |
| Resource-bound verification | pnpm test -- skill-scenario-count |
total scenarios = 12 (≤ 20) | filled during execution | pending | |
| Invariant verification | grep feature-flag patterns in packages/policies/src/index.ts |
zero matches | filled during execution | pending | |
| Debugger / state inspection | gh attestation verify if release fails |
hypothesis confirmed | filled during execution | pending | |
| Smoke tests | (manual list) | all checked | filled during execution | pending | |
| Test artifact cleanup | git status --short |
only intentional files | filled during execution | pending | |
| .gitignore review | review | current | filled during execution | pending | |
| Compatibility checks | (manual list) | no regressions | filled during execution | pending |
- All BDD scenarios pass.
- All E2E release-readiness tests pass.
- Static-analysis gates green.
- Smoke tests checked off.
- Compatibility checklist complete.
- Resource bounds and invariants encoded + tested.
- No forbidden shortcuts.
git statusclean.- All M1 + M2 + M3 + M4 + existing surfaces unchanged.
- Self-Review Gate answered with
yes. - Lessons + completion files written per v4 templates.
1.2.0published for all four packages with verified SLSA attestations.- CHANGELOG v1.2.0 entry closes #47, #49 explicitly.
- Three new skill scenarios validated and live.
- Three new cookbooks indexed.
- Three new examples buildable.
- Milestone Tracker updated to
done. - Top-level runbook's Documentation Update Table fully filled.
docs/slo/completed/RUNBOOK-hulumi-operations.mdMilestone Tracker → M5done. Documentation Update Table → final fill-in.docs/issue-candidates.md— sync with v1.2 release state (any v1.3 candidates surfaced during M1-M5 lessons land here as new entries).README.md— confirm Operations surface section reads correctly post-release.CHANGELOG.md— verify v1.2.0 entry one last time.- Announce release per existing launch flow (
docs/launch/).
- Atomic four-package release is the load-bearing release pattern — recorded again in the lessons file. Even
@hulumi/drift@1.2.0(no functional changes) ships at the same version because consumers should never see a Hulumi monorepo with version-skewed packages. - The Operations surface is a minor version bump, not a major one, because every change is additive. The existing v1.1.x consumer who upgrades to 1.2.0 sees zero behavior change for their existing components.
O_*pack ships enabled-by-default. There is noHULUMI_ENABLE_OPSenv var — adding one would directly contradict abuse-case rowtm-hulumi-ops-abuse-rule-pack-feature-flagand the design record's "hardened-by-default" discipline. The lessons file should record this as a deliberate decision against the temptation to ship behind a flag.- The four cookbooks (Operations + Operations + Operations + the existing
verify-provenance.md) are the canonical learning path for a new consumer adopting the Operations surface in 2026.