Filed by the director seat from the 2026-09-01 merge-sync round on PR #13864 (full report: #13657 comment 5491447862, deviation 2). Dedup: #12877 (closed) is the same script but a different step and a different defect (step 2's unconditional checkout of main's side); no open card carries this.
⛔ Recording only. No severity asserted; low. No data was lost.
The measurement
scripts/pm/os-regen-merge.sh's docblock section "Step 3 and the pre-commit hook agree" asserts the hook records a deferral for a merge commit carrying stale generated artifacts. Measured 2026-09-01 on content/docs/permissions/system-context.mdx (routed merge=os-regen): at step 3 the pre-commit hook refused the commit instead, and the script exited 1 mid-sequence — with step 1's merge commit already created.
Why it matters, and why it is small
The script's own printed fallback (clear what the hook reported, then git add -A and commit) is correct and was followed; the hook then confirmed the artifact current and cleared the marker on the repair commit. So this is documentation/behaviour drift, not data loss — but an operator who trusts the docblock will read the refusal as something having gone wrong mid-merge, on exactly the path where mis-reading costs a dropped side (#14064's territory).
What is NOT claimed
- ⛔ Not claimed that the hook is wrong — refusing may well be the better behaviour; the drift is that the docblock promises the other one.
- ⛔ Not swept whether other docblock claims in the same script have drifted; one measurement, one section.
Refs: #14064 (the driver's mixed-file class, where this was measured) · #12877 (closed; same script, step 2, different defect).
Filed by the director seat from the 2026-09-01 merge-sync round on PR #13864 (full report: #13657 comment 5491447862, deviation 2). Dedup: #12877 (closed) is the same script but a different step and a different defect (step 2's unconditional checkout of main's side); no open card carries this.
⛔ Recording only. No severity asserted; low. No data was lost.
The measurement
scripts/pm/os-regen-merge.sh's docblock section "Step 3 and the pre-commit hook agree" asserts the hook records a deferral for a merge commit carrying stale generated artifacts. Measured 2026-09-01 oncontent/docs/permissions/system-context.mdx(routedmerge=os-regen): at step 3 the pre-commit hook refused the commit instead, and the script exited 1 mid-sequence — with step 1's merge commit already created.Why it matters, and why it is small
The script's own printed fallback (clear what the hook reported, then
git add -Aand commit) is correct and was followed; the hook then confirmed the artifactcurrentand cleared the marker on the repair commit. So this is documentation/behaviour drift, not data loss — but an operator who trusts the docblock will read the refusal as something having gone wrong mid-merge, on exactly the path where mis-reading costs a dropped side (#14064's territory).What is NOT claimed
Refs: #14064 (the driver's mixed-file class, where this was measured) · #12877 (closed; same script, step 2, different defect).