[rmorozov]

Requested by Ruslan · project thread

Problem

Phase 1 (#725) lets a build run the parity suite against another Python Jinja2, but nothing runs it. Without a scheduled run, a behaviour change in Jinja2's next release, or in a newer Python, shows up only after users report it. This is phase 2 of the approved 0186 plan (section 5, revised in section 10). Phase 3 was dropped, so this PR closes 0186.

Resulting behaviour

• New .github/workflows/parity-oracles.yml, modelled on bindings.yml:

  • It runs on pull requests that touch the oracle harness (generate.py, parity_test.cpp, requirements.txt, cmake/parity_oracle*.cmake, the workflow itself), nightly on master, and on demand.
  • Actions are pinned by SHA, reusing pins already in the SBOM.

• It has four rows, each using JINJA2CPP_TEST_ORACLE=venv with a gcc-14 Release build and one shared ccache key:

  Row	Python	Requirements
  jinja2 main	3.12	jinja2 @ git+https://github.com/pallets/jinja@main
  jinja2 3.0.3	3.12	jinja2==3.0.3;markupsafe==2.1.5
  python 3.13	3.13	the pinned jinja2==3.1.6;markupsafe==3.0.3
  python 3.14	3.14	the pinned jinja2==3.1.6;markupsafe==3.0.3

• Where the two oracles agree, a case is judged by the allow-list as in every build job. A delta is only reported (decision O4): report.md goes to the job summary and is uploaded as an artifact.

• test/parity/README.md, "Other oracles", describes the workflow. The 0186 task file records phase 2 and says this PR closes the task. The status line is left for the steward.

Validation

• The same configurations were run locally on master 808cbdb (2972 cases):

  Row	Agree	Differ	Verdicts
  Jinja2 main (3.2.0.dev0, MarkupSafe 3.0.4) on 3.12	2972	0	none
  Jinja2 3.1.6 on Python 3.14.6	2968	4	all tracks-bundled

  The 3.14 deltas are the 4 that the plan measured on 3.13: two \N{} name-rule cases and wordwrap m141/m142. The 3.0.3 row has 22 deltas on the 2850-case corpus, measured in Parity suite against another Python Jinja2: JINJA2CPP_TEST_ORACLE (0186 phase 1) #725.

• scripts/preflight.sh and scripts/sbom.py --check pass, and the workflow parses as YAML.

• This PR itself triggers the workflow through the paths filter, so its CI run is the first real run.

Process

• Roles: the main session only. No verifier ran: this is a CI workflow and docs change, the case the instructions exempt.
• Red CI pushes: 0.
• Codex: 0 findings, 0 fixed, 0 declined (reviewed 211e831).
• CI: green on 211e831, and all four oracle rows passed on their first run. One macOS job was cancelled by GitHub and re-run.

---

Generated by Claude Code

[rmorozov]

@codex review

---

Generated by Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-03T09:00:57.001513Z	211e831	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit: 211e8316c4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".