chore: release v0.23.0

[mmcky]

Cuts v0.23.0, bundling the three issues that had to land before shadow-mode calibration could start. All three are merged and harness-validated.

What ships

PR	Issue	Change
#150	#149	forward/init resolve the built-in glossary package-relative and report which one they loaded; forward --glossary added
#151	#146	Review mode honours glossary-path; a custom glossary becomes an override rather than a dead input
#152	#148	Two of four diffChecks computed rather than model-asserted; all four declare provenance via a new diffCheckSources field

Behavioural impact on upgrade: none for the fleet

Worth stating explicitly, because two of these are gate-adjacent:

• No edition sets glossary-path — verified across all five editions' workflows — so the override/fail-fast change alters nothing in production today. It matters for the first edition to adopt a custom glossary.
• auto-merge-mode still defaults to off, so no gate acts anywhere.
• Routing is unchanged by Verdict v2 diffChecks are model output but gate absolutely — a hallucinated boolean routes a correct PR to editor, and biases Stage 4 calibration #148. A model-asserted diff check that reports failure still routes to editor; it arrives as a diff-check finding instead of a boolean. What changes is that shadow data can distinguish model opinion from measured fact.
• schemaVersion stays 1. diffCheckSources is a pure, optional field addition — no renames, removals or type changes. Blocks written before this release simply lack it, and absence means treat every check as gating (documented in docs/user/metadata-contract.md).

The one change that could newly gate a healthy PR is the deterministic headingMapCorrect. That was checked against the live estate rather than reasoned about: of 249 production files with sections, 248 carry a heading map. The single exception — lecture-python-programming.fa's autodiff.md, an in-_toc lecture with 16 sections and no map — was a genuine gap, not a false positive, and is already fixed in that edition (fa#142). So the fleet-wide blast radius is zero.

Validation

Harness runs against the built bundle (the convention for unreleased code — never pinning a harness workflow to a branch):

• zh-cn #642 — diffCheckSources present and correct, both deterministic checks pass, scores.diff consistent with the booleans, auto-merge still reachable. That last point matters: the 2026-07-23 fixture trap was a headingMapCorrect artefact making auto-merge unreachable and the harness silently useless for the Stage 4 base-rate question.
• zh-cn #638 — head predates the fixture migration and carries the legacy heading-map: key. The deterministic check reads it and passes, so the new gate will not false-gate an unmigrated repo.
• fa Design: should French typography apply to the action's sync path, and how? #81 — same result on RTL content.

Earlier in the same session, #149 was validated by a live forward run from a directory with no glossary (357 terms loaded package-relative, and the generated text used the glossary renderings), and #146 by a review run against a deliberately conflicting custom glossary, whose verdict flipped to editor citing the exact planted terms.

Not covered on the harness: a deterministic check failing end-to-end, and a model-asserted check failing. Every harness fixture legitimately passes and the model returned true in all three runs; manufacturing failures would mean pushing throwaway branches to the harness. Both paths are covered by unit tests, including the full reviewPR path with a map-less target asserting scores.diff === 7.5, deterministic provenance and the diff check failed: headingMapCorrect reason.

Pre-flight

• Rebuilt dist-action/index.js and diffed against the committed bundle: identical. (The version bump does not touch the bundle — getEngineVersion() reads package.json at runtime.)
• 55 suites, 1297 passing (6 pre-existing skips); lint and format clean.

After merge — the tags do not cut themselves

There is no release workflow, so merging this PR ships nothing. @v0 keeps resolving to v0.22.0 until three tags are created by hand at the release commit:

• v0.23.0 — annotated, with a GitHub release
• v0.23 — the minor series
• v0 — force-moved

This has bitten the program before: #145 merged, main read 0.22.0, and v0.22.0 did not exist. Merged, released and working are three separate states. engineVersion in the next review's verdict block is the field that confirms the release actually took.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Release prep for v0.23.0 of action-translation, updating repository metadata/docs to reflect the new version and the bundled changes described in the PR description.

Changes:

• Bump package version to 0.23.0 in package.json and package-lock.json.
• Cut the 0.23.0 section in CHANGELOG.md dated 2026-07-23.
• Refresh internal docs/state to reflect the new release (current version/test count, and .dev/STATE.md verified date + release summary).

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
package.json	Version bump to 0.23.0.
package-lock.json	Lockfile package version bump to 0.23.0 (root + package entry).
CHANGELOG.md	Adds ## [0.23.0] - 2026-07-23 release notes section.
.github/copilot-instructions.md	Updates “Current Version” and test/suite counts to v0.23.0.
.dev/STATE.md	Updates verified: date and records the v0.23.0 “recently landed” summary.

[mmcky]

Why this PR shows no checks: a GitHub incident, not anything in this repo.

GitHub Status reports an active incident — "Latency issues across a number of services … degraded availability for Actions, Issues and Webhooks" — with Actions in partial outage and Webhooks degraded. It began at 07:53:59 UTC. This PR was created at 07:54:02 UTC, three seconds later.

That accounts for every observation:

Event	Time	CI fired?
PR #152 pull_request	07:28:12	✅ before the incident
PR #153 opened	07:54:02	❌
PR #153 reopened	~08:02	❌
PR #153 synchronize (new head)	~08:06	❌
workflow_dispatch	07:56	✅ — a direct API path that does not depend on webhook delivery
Copilot review (dynamic)	07:54	✅ — also a separate dispatch path

Ruled out first, before reaching for the incident: paths-ignore (PR #145 fired on its own release commit with an identical five-file set including .dev/STATE.md), Actions disabled, workflow inactive, draft PR, a push/create race (31s apart), skip-ci tokens in the commit message, workflow-file drift on the branch (byte-identical to main), and base/head/cross-repo configuration.

The release commit is verified regardless. The workflow_dispatch run on 6439ad07 passed all nine steps — install, lint, format check, build, test, and Verify dist-action bundle is up to date. It simply is not attached to the PR as a check, because dispatch runs never are.

Recommendation: wait for Actions to recover before merging. Not because this PR is unsafe, but because a release cut during an Actions outage is hard to verify — the post-merge push CI may not fire either, and the first sync or review run on the new @v0 might not fire, which would look like a release defect rather than an outage. Tag creation is a Git operation and would succeed, giving the misleading impression that everything shipped.

The empty commit above was a diagnostic (testing whether a fresh head SHA was evaluated); it is squashed away on merge.

[mmcky]

Correction to my analysis above: the events were not dropped, they were late.

The run timestamps show what actually happened:

Run created	Event	Head	Result
07:59:25Z	workflow_dispatch	6439ad0	success (my manual trigger)
08:12:50Z	pull_request	6439ad0	success
08:20:00Z	pull_request	6439ad0	success
08:55:20Z	pull_request	3c26b4e	success
09:37:52Z	pull_request	3c26b4e	success

The opened, reopened and synchronize events all arrived — delayed by roughly 15 to 50 minutes. I queried at ~08:02 and ~08:10, before the first of them was created, concluded they had been lost, and stopped looking. The incident title said "Latency issues" and that is exactly what it was; I read it as an availability failure.

That also means the empty diagnostic commit was unnecessary — the opened event's run landed at 08:12 regardless. It is squashed away on merge, so no harm, but it did not test what I thought it tested.

What stands from the earlier analysis: the cause was the GitHub incident rather than anything in this repo, and every repo-side hypothesis ruled out there (paths-ignore, workflow state, draft status, skip-ci tokens, workflow drift, base/head config) remains ruled out. What changes is the mechanism — latency, not loss — and the practical lesson: during a latency incident, absence of a run is not evidence of a missing run. Re-check before concluding.

All components returned to operational by 09:35Z. Checks are green and attached; mergeStateStatus is CLEAN.