v4.9.2
v4.9.2 — corrective release
Full entry: CHANGELOG.md § [4.9.2], § [4.9.1] and § [4.9.0]. This file records release evidence
and the upgrade note.
v4.9.1 was tagged but never published, for the same reason v4.9.0 was not: its release run went
red on verify-windows-msys. The failing row was a test-harness capability probe, never the shipped
hook code — Linux was green on every attempt. Both tags were left in place rather than moved, and
v4.9.2 supersedes them with the cause fixed. It contains everything v4.9.0 and v4.9.1 intended to
ship.
What changed since v4.9.1
The Windows release gate had been non-deterministic for five hosted runs. The cause is no longer a
hypothesis — it was measured, and it was the gate's own bound, not the code under test.
| Change | Effect on you |
|---|---|
| The Job-Object capability probe's watchdog is 15s → 46s | Only reachable with the opt-in FFHC_USE_JOB_OBJECT=1. A loaded host whose PowerShell cold start needs more than 15s now gets a correct answer instead of a false "capability absent". A hung PowerShell is still killed. |
The opt-in Windows fence moved to hooks/local/lib/job-fence.sh |
No behaviour change. run-with-timeout.sh keeps the platform-neutral bounded run and degrades to "unavailable" if the fence file is absent. |
Everything else is identical to v4.9.1.
Upgrade note
Unchanged from v4.9.0 — nothing here changes runtime behaviour beyond what that release described.
| Change | Effect on you |
|---|---|
A resolved python3 must prove it is ≥3.10 |
Previously only the python / py -3 fallbacks were checked. python3 -S -c support is NOT required. |
A broken or missing git inside a repository now BLOCKS |
Previously it exited 0 and silently skipped the secret scan and protected-path check. Genuine outside-a-repository execution is unchanged. |
| Deploy reports embed an approval receipt | The committed report no longer cites a gitignored path. The live approval is unchanged and still gates the deploy. |
No migration, no config change.
Identify which tree you have
docs/release-fingerprints.md maps every released tree to its manifest fingerprint. Use the
hook-layer fallback if audit/managed-content-manifest.json is missing — it is absent on
repositories upgraded by a pre-4.7.0 engine.
A released tree cannot contain its own row: adding it changes the digest it describes. Each tree's
row is published in the following release. The v4.9.2 row will appear in the next one.
Release evidence
| Item | Value |
|---|---|
| Tag verification | the v4.9.2 run is the authoritative gate; a local run is never release evidence |
| Pre-tag verification | run 31832137608 on 3999a4a — verify-linux, verify-windows-msys and verify-gate all green, 1037/1037 on Windows |
| Superseded | v4.9.1 and v4.9.0 — both tagged, both release runs failed, neither published, neither tag moved |
Known residuals
Unchanged from v4.9.0 except the last, and stated rather than omitted:
- The command gate still denies honest prose quoting a destructive pattern. Only the diagnostic
improved; matching is unchanged and remains blocked on decisions K21/M8. - Tag immutability is enforced by operator confirmation, not a repository ruleset. A human gate
cannot stop a tag moved directly on the hosting platform or by an automation that never asks. - Nothing here authenticates git, the interpreter, or the operator.
- The Windows job-object probe flake is diagnosed and fixed, correcting v4.9.1's statement that
it was an unresolved hypothesis.docs/backlog/release-gate-flaky-job-proberecords the
measurement that established the cause and the two theories it excluded. One related sizing
question is open and recorded there: the fence's own ASSIGN-OK confirm still allows ~3s for
PowerShell to start, so on a host slow enough to produce this ticket's cold start it falls back to
the WS2-core path rather than fencing. That fallback is safe — the reap still applies.