Step D: add the Puppet 9 profile and wire the major through the pipeline

profiles/puppet_profiles.json gains 9-latest-maintained: Puppet 9.0.0 (the
deliberate starting point per the 2026-08-21 product decision, not "newest
9.x"), facter 4.21.0, Ruby 3.4, bundler 2.5.22, private gem source. No
9-previous-maintained — 9.0.0 is the first 9.x, so there is nothing previous
to pin until 9.1 ships.

Plumbing so the two majors stay independent (design §3, §5):
- classify_module_result.py resolves and stamps puppet_major from the run's
  profile. update_ledger.py has keyed on that field since Step B but nothing
  ever set it, so every row silently landed in puppet_majors["8"].
- detect_changes.py takes the major from PUPPET_MAJOR instead of a hardcoded
  DEFAULT_MAJOR, so each caller's leanness is computed against its own
  ledger slice.
- prepare-test-matrix exposes it as a puppet-major input; both callers set it
  explicitly ('8' / '9') rather than leaning on the default.
- compatibility-runner-puppet9.yml gets its nightly cron (03:00 UTC, an hour
  after the Puppet 8 caller — runner contention only; the shared
  compat-ledger-* group already serializes the one racing step).

build_matrix.rb needed no change despite the design listing it: a caller
selects its major via the profile it passes to run-module-test, and per-major
leanness arrives pre-resolved in INCLUDE_IDS, so matrix rows are
major-agnostic. Added a comment saying so.

Facter is pinned by assumption, not lookup: 4.21.0 is the newest build known
to exist on the private source and satisfies Puppet 9.0.0's declared
facter >= 4.3.0, < 5. Without an API key here it couldn't be confirmed that
the private source pairs a different facter with 9.0.0. bootstrap.rb pins
facter exactly, so a wrong pin fails loudly at bundle install in the gate
dispatch.

Verified locally against the real ledger, no CI needed:
- PUPPET_MAJOR=9 includes all 75 modules (never-tested); PUPPET_MAJOR=8
  includes 0 (all green and fresh).
- After merging a synthetic Puppet 9 run (one clean, one failing) into a
  ledger copy: 74 included on 9 (73 never-tested + 1 unit-failing), still 0
  on 8, with puppet-telegraf sitting at unit+acceptance on 8 and unit-failing
  on 9 in the same row. That is §5's independence requirement end to end.
- render_status_dashboard.py rendered both majors' column pairs off that
  ledger with no changes needed; build_matrix.rb built 74 unit rows from the
  major-9 include list.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: jst-cyr

.github/actions/prepare-test-matrix/action.yml

@@ -24,6 +24,10 @@ inputs:
     description: 'Path to the calling thin trigger workflow file, scoped out of the sibling major material-path matching'
     required: false
     default: ''
+  puppet-major:
+    description: "Puppet major this caller tests ('8' | '9'); scopes every ledger read to that major's slice"
+    required: false
+    default: '8'
   window-hours:
     description: 'Upstream/harness change window in hours'
     required: false
@@ -80,6 +84,7 @@ runs:
         LEAN: ${{ inputs.lean }}
         GITHUB_TOKEN: ${{ github.token }}
         CALLER_WORKFLOW_FILE: ${{ inputs.caller-workflow-file }}
+        PUPPET_MAJOR: ${{ inputs.puppet-major }}
 
     - name: Build module matrix
       id: matrix

.github/workflows/compatibility-runner-puppet8.yml

@@ -23,10 +23,10 @@ name: Puppet Core 8 Compatibility
 # strategy, dynamic name, runs-on, timeout, needs/if gates, env passthrough)
 # that GitHub has no sharing primitive for below a full reusable workflow -
 # a small, mostly-static block that should look nearly identical to
-# compatibility-runner-puppet9.yml (once Step D adds it) except for the
-# profile name and concurrency-group suffix.
+# compatibility-runner-puppet9.yml except for the profile name, the
+# concurrency-group suffix, the puppet-major input, and the cron hour.
 #
-# This is now the sole owner of the nightly cron: the old
+# This is now the sole owner of the Puppet 8 nightly cron: the old
 # compatibility-runner.yml (retired in this same commit, per its gate
 # passing — see docs/puppet-core-9-dual-major-support.md §12) previously
 # owned it. Both never ran on the same cron at once — that would have
@@ -101,6 +101,7 @@ jobs:
           event-name: ${{ github.event_name }}
           lean: ${{ github.event.inputs.lean || 'true' }}
           caller-workflow-file: .github/workflows/compatibility-runner-puppet8.yml
+          puppet-major: '8'
           window-hours: ${{ vars.PUPPET_CHANGE_WINDOW_HOURS || '48' }}
           stale-days: ${{ vars.PUPPET_STALE_DAYS || '30' }}
 

.github/workflows/compatibility-runner-puppet9.yml

@@ -10,19 +10,22 @@ name: Puppet Core 9 Compatibility
 #   - .github/actions/run-module-test        (the actual per-module test)
 #   - .github/actions/publish-compatibility-results (ledger/dashboard write)
 # A diff against the Puppet 8 caller should show only the profile name, the
-# concurrency-group suffix, the caller-workflow-file path, and this comment —
-# anything more is drift to catch in review.
+# concurrency-group suffix, the caller-workflow-file path, the puppet-major
+# input, the cron hour, and this comment — anything more is drift to catch in
+# review.
 #
-# STATUS: skeleton only, landed on main ahead of the rest of Step D so that
-# workflow_dispatch is discoverable (GitHub only exposes dispatch for workflow
-# files that exist on the default branch). The `9-latest-maintained` profile
-# does not exist in profiles/puppet_profiles.json yet, and the `major`
-# parameter is not yet wired through detect_changes.py / build_matrix.rb — so
-# dispatching this today will fail at profile resolution. Intentionally has NO
-# `schedule:` trigger for that reason; the nightly cron gets added when the
-# profile lands and Step D's gate dispatch passes.
+# The file itself landed on main ahead of the rest of Step D, because GitHub
+# only exposes workflow_dispatch for workflow files present on the default
+# branch (the constraint hit in Step C).
+#
+# The cron is offset an hour after the Puppet 8 caller's so the two nightly
+# runs don't contend for runners; correctness doesn't depend on the offset —
+# the shared compat-ledger-* concurrency group on `publish` already serializes
+# the one step that would otherwise race (§4.2).
 
 on:
+  schedule:
+    - cron: "0 3 * * *"  # Nightly at 03:00 UTC (an hour after the Puppet 8 caller)
   workflow_dispatch:
     inputs:
       profile:
@@ -88,6 +91,7 @@ jobs:
           event-name: ${{ github.event_name }}
           lean: ${{ github.event.inputs.lean || 'true' }}
           caller-workflow-file: .github/workflows/compatibility-runner-puppet9.yml
+          puppet-major: '9'
           window-hours: ${{ vars.PUPPET_CHANGE_WINDOW_HOURS || '48' }}
           stale-days: ${{ vars.PUPPET_STALE_DAYS || '30' }}
 

AGENTS.md

@@ -38,7 +38,7 @@ must **not** be pre-emptively marked incompatible.
 - `config/modules.schema.json`: schema for module config validation.
 - `config/beaker/setfiles/`: Beaker host definition files (one per acceptance target, e.g. `el9.yml`).
 - `scripts/validate_modules_config.py`: local schema validation helper.
-- `.github/workflows/compatibility-runner-puppet8.yml`: CI pipeline and matrix execution for Puppet 8 (a `compatibility-runner-puppet9.yml` sibling is added in Step D of `docs/puppet-core-9-dual-major-support.md`). Shared prepare/publish logic lives in `.github/actions/prepare-test-matrix` and `.github/actions/publish-compatibility-results` — see that doc's §12 for why these are composite actions, not a reusable workflow.
+- `.github/workflows/compatibility-runner-puppet8.yml` / `compatibility-runner-puppet9.yml`: CI pipeline and matrix execution, one self-contained caller per Puppet major (see `docs/puppet-core-9-dual-major-support.md` §4). They are deliberate near-copies — a diff between them should show only the profile name, concurrency-group suffix, `puppet-major` input, and cron hour; anything else is drift. Shared prepare/publish logic lives in `.github/actions/prepare-test-matrix` and `.github/actions/publish-compatibility-results` — see that doc's §12 for why these are composite actions, not a reusable workflow.
 - `profiles/puppet_profiles.json`: profile constraints used by the runner.
 - `docs/architecture-flow.md`: end-to-end architecture diagram and stage reference. Must be kept in sync with runner logic, classification rules, and CI workflow changes.
 
@@ -198,7 +198,7 @@ When you need a narrow CI run, use workflow input `modules_json` with only new o
 | Downgrade override rules (`lib/module_tester/adapters.rb`) | Downgrade overrides table — add, remove, or update trigger conditions and reclassification outcome |
 | Guardrails checks (`lib/module_tester/guardrails.rb`) | Guardrails row in stage table |
 | Acceptance adapter or Docker isolation model (`lib/module_tester/adapters.rb`, `lib/module_tester/docker.rb`) | Two-Stage Docker Isolation Model section; Docker Container Modes table; S1/S2S/S2D node labels in diagram; FOSS fallback description |
-| CI workflow (`.github/workflows/compatibility-runner-puppet8.yml`, `.github/actions/prepare-test-matrix/action.yml`, `.github/actions/publish-compatibility-results/action.yml`) | CI: Prepare section; diagram CI subgraph |
+| CI workflow (`.github/workflows/compatibility-runner-puppet8.yml`, `compatibility-runner-puppet9.yml`, `.github/actions/prepare-test-matrix/action.yml`, `.github/actions/publish-compatibility-results/action.yml`) | CI: Prepare section; diagram CI subgraph |
 | Reporting outputs (`lib/module_tester/reporting.rb`) | Reporting section |
 
 ### Rules for diagram edits

CLAUDE.md

@@ -63,6 +63,7 @@ STATUS.md                         # Generated fleet dashboard (do not hand-edit)
 KNOWN_COMPATIBLE.md               # Generated list of fully-validated modules (do not hand-edit)
 .github/
   workflows/compatibility-runner-puppet8.yml    # Puppet 8 CI trigger + full pipeline
+  workflows/compatibility-runner-puppet9.yml    # Puppet 9 CI trigger + full pipeline (same shape)
   actions/run-module-test/action.yml            # Composite action: run one module's test
   actions/prepare-test-matrix/action.yml        # Composite action: change detection + matrix build
   actions/publish-compatibility-results/action.yml  # Composite action: ledger update + dashboard render

CONTRIBUTING.md

@@ -59,7 +59,7 @@ If invalid, the script prints path-based errors and exits non-zero.
 
 The GitHub Actions workflow validates [config/modules.json](config/modules.json) before building the module matrix.
 
-Workflow: [.github/workflows/compatibility-runner-puppet8.yml](.github/workflows/compatibility-runner-puppet8.yml)
+Workflows: [.github/workflows/compatibility-runner-puppet8.yml](.github/workflows/compatibility-runner-puppet8.yml) and [.github/workflows/compatibility-runner-puppet9.yml](.github/workflows/compatibility-runner-puppet9.yml) (one per Puppet major; both validate identically)
 
 If schema validation fails, the `prepare` job fails and module test jobs are blocked.
 

README.md

@@ -31,7 +31,7 @@ Some modules are no longer maintained or are incompatible with Puppet Core:
 	- Markdown summary: `results/.../compatibility-summary.md`
 	- Stage logs per module: `results/.../artifacts/<module>/.stage-*.log`
 	- Per-module dependency status/message (`dependency_status`, `dependency_message`) in JSON report
-- GitHub Actions workflow with module matrix: `.github/workflows/compatibility-runner-puppet8.yml`
+- GitHub Actions workflow with module matrix, one per Puppet major: `.github/workflows/compatibility-runner-puppet8.yml`, `.github/workflows/compatibility-runner-puppet9.yml`
 
 ## Quick start (local)
 
@@ -101,11 +101,14 @@ Split-source behavior (default):
 
 ## GitHub Actions usage
 
-Workflow file: `.github/workflows/compatibility-runner-puppet8.yml`
+Workflow files, one self-contained caller per Puppet major:
+`.github/workflows/compatibility-runner-puppet8.yml` and
+`.github/workflows/compatibility-runner-puppet9.yml`. They take the same inputs
+and run the same pipeline; only the default profile differs.
 
-- Trigger: **Actions → Puppet Core 8 Compatibility → Run workflow**
+- Trigger: **Actions → Puppet Core 8 Compatibility** (or **Puppet Core 9 Compatibility**) **→ Run workflow**
 - Inputs:
-	- `profile` (default `8-latest-maintained`)
+	- `profile` (default `8-latest-maintained` / `9-latest-maintained`)
 	- `metadata_mode` (`warn` or `fail`, default `warn`)
 	- `modules_json` (optional JSON array override)