chore(release): 0.12.0

[client-software-ci]

0.12.0 (2026-09-04)

Bug Fixes

• coerce LIST[BOOL] items per RFC 0007 §2.15 (fix: coerce LIST[BOOL] items per RFC 0007 §2.15 #352) (105dff2)
• coerce LIST[BOOL] items per RFC 0007 §2.15 (105dff2)
• Evaluate step-level let bindings in template scope (fix: Evaluate step-level let bindings in template scope #341) (b136693)
• Evaluate step-level let bindings in template scope (b136693)
• Record the template-scope let boundary at the merge, and verify it (b136693)
• Record the let boundary on the de-sugared script too (b136693)
• Never lower the template-scope let marker (b136693)
• Stop merging step-level let into the script (b136693)

[github-actions]

The 0.12.0 section is missing a ### BREAKING CHANGES block, but this release contains one.

b136693 ("Evaluate step-level let bindings in template scope", #341) carries an explicit BREAKING CHANGE: trailer:

create_job() no longer returns a Job carrying evaluated step-level let values. A caller that runs a job whose steps declare a template-scope let referenced from the step's script must switch to create_job_with_symbol_tables and forward the step's step_symbol_tables entry to the session.

That behavior change is real in the head tree — src/openjd/model/_create_job.py:577 documents "The returned Job does not carry the evaluated step-level let values." Yet this release is titled 0.12.0 (a minor bump, not major) and every entry is filed under ### Bug Fixes. A consumer reading only this CHANGELOG has no signal that a previously-working create_job() + run-the-job flow now fails with Undefined variable.

Two things to reconcile:

1. Add a ### BREAKING CHANGES section for 0.12.0 describing the create_job() step-level let contract change (prior releases such as 0.9.0 and 0.8.0 use that heading).
2. Confirm the intended version. If the project follows semver strictly, a BREAKING CHANGE: trailer should have produced 1.0.0; if 0.x minor bumps are the convention for breaking changes here, that is fine, but the section heading still needs to be present.

The commit message for #341 says it added a "CHANGELOG breaking-change entry", but git diff b136693^..b136693 -- CHANGELOG.md is empty, so that entry never landed — which is likely why the release tooling did not emit the section.

[github-actions]

Each squashed PR is listed twice, and the internal sub-commits of a squash are leaking into the release notes.

• Lines 6 and 7 are the same fix (fix: coerce LIST[BOOL] items per RFC 0007 §2.15 #352), once with the PR number and once without — the tooling emitted both the squash-commit subject and its first body line.
• Lines 8–13 are all the single commit b136693 (fix: Evaluate step-level let bindings in template scope #341). Lines 10–13 ("Record the template-scope let boundary at the merge, and verify it", "Record the let boundary on the de-sugared script too", "Never lower the template-scope let marker", "Stop merging step-level let into the script") are intra-PR review fixups: they describe bugs introduced and then corrected within that same PR, so they never existed in any released version. Publishing them as "Bug Fixes" tells consumers that 0.11.8 shipped a "template-scope let marker" that got lowered, which it never did.

Compare 0.11.8 above (lines 19–23): one hand-written, user-facing line per change. The 0.12.0 block instead has seven raw commit subjects for two actual changes.

Suggest collapsing to one entry per PR, written for a consumer rather than quoting the commit subject: one line for the LIST[BOOL] item coercion and canonical-boolean storage on the created Job (#352), and one line for a step-level let now being evaluated with POSIX path format so a create-time result no longer depends on the creating host (#341).

[leongdl]

Minor patch only this API has been released.