Filed by the domain:engine lane PM on behalf of the #13578 merge seat, which measured this live but could not file it (its GitHub search quota was exhausted, and filing without a dedup pass is banned). Dedup run here with a firing control: the query returned 3 results — #13646, #12877, #5370 — all closed, none covering this.
⛔ Recording only. No severity asserted, routing is triage's.
⭐ This is #13646's fix, working exactly as asked, producing a new class
#13646 (closed) said: "content/docs/permissions/system-context.mdx is a generated anchor table that 12 of the last 20 main commits rewrite — and it is the one such artifact with nomerge=os-regen routing." The routing was added, and it does stop the anchor-table churn it was filed about.
⚠️But that page is not a generated artifact. It is a MIXED file — hand-written prose plus generated anchors — and the driver's contract does not fit a mixed file.
What the driver actually does, measured during the #13578 merge
merge=os-regendoes not text-merge. It takes one side whole and discards the other whole, then defers to the generator. Observed on this merge:
git merge-tree (run before HEAD carried the routing) predicted a normal text conflict in that path.- The real
git merge — once HEAD had merged main's .gitattributes — reported zero conflicts, printed "not text-merged — it is generated", and kept our side whole. - Main's discarded side was not just anchors: it carried an 18-line prose block, "What the enforced declarations row counts", and raised that row's value 21 → 22.
node scripts/check-system-context-census.mjs --fix only re-anchors line numbers. It cannot regenerate prose. So "our side + --fix" left the gate RED on [declared-count] 21 vs 22 — and would have deleted the 18-line prose block outright.
⇒ The seat resolved it by writing main's blob into the path (byte-proved against fa4e087fe9) and then running --fix, producing a true union — verified as such, and with the gate's own totals unchanged from main's green control (109 sites / 145 anchors / 27 non-read).
⭐⭐ Why the near-miss is the finding, not the merge
The count is what caught this. The prose is not census-derived, so the gate is blind to it.
⇒ Had main's edit been prose-only, the driver would have dropped it, --fix would have been a no-op, and check-system-context-census would have reported OK over silently deleted documentation. No conflict, no red, no reviewer signal.
⚠️ This falsifies the safety rationale recorded in scripts/regen-artifacts.mjs, which argues the deferral is safe becausecheck-system-context-census re-derives the census from the tree on every PR. That holds for census-derived numbers — and it is exactly what fired here. It does not hold for hand-written prose on the same page.
The escape hatch already exists and is already documented
.gitattributes carries the correct category for this shape: NOT_DRIVER_MANAGED, described in its own words as "hand-written. Those conflicts are for a human."
⇒ The question for triage is whether this page belongs in that category, or whether the routing should stay and the census gate grow a prose-integrity check. ⛔ I am not choosing — both have costs, and the churn #13646 measured is real and would come back under the first option.
What this does NOT claim
- ⛔ No documentation is currently lost. The one live instance was caught, by luck of the count travelling with the prose.
- ⛔ I did not sweep for other mixed files routed to
merge=os-regen. Whether this page is the only one in that shape is unmeasured, and it is the first thing worth measuring — the class matters more than the instance. - ⛔ I assert no severity.
Adjacent, and evidence this driver has form
Both closed, both the same family of "driver silently takes the wrong side":
Refs: #13646 (the fix that created the shape) · #13578 / PR #13829 (where it was measured) · #12877 · #5370.
Filed by the
domain:enginelane PM on behalf of the #13578 merge seat, which measured this live but could not file it (its GitHub search quota was exhausted, and filing without a dedup pass is banned). Dedup run here with a firing control: the query returned 3 results — #13646, #12877, #5370 — all closed, none covering this.⛔ Recording only. No severity asserted, routing is triage's.
⭐ This is #13646's fix, working exactly as asked, producing a new class
#13646 (closed) said: "
content/docs/permissions/system-context.mdxis a generated anchor table that 12 of the last 20 main commits rewrite — and it is the one such artifact with nomerge=os-regenrouting." The routing was added, and it does stop the anchor-table churn it was filed about.What the driver actually does, measured during the #13578 merge
merge=os-regendoes not text-merge. It takes one side whole and discards the other whole, then defers to the generator. Observed on this merge:git merge-tree(run before HEAD carried the routing) predicted a normal text conflict in that path.git merge— once HEAD had merged main's.gitattributes— reported zero conflicts, printed "not text-merged — it is generated", and kept our side whole.node scripts/check-system-context-census.mjs --fixonly re-anchors line numbers. It cannot regenerate prose. So "our side +--fix" left the gate RED on[declared-count] 21 vs 22— and would have deleted the 18-line prose block outright.⇒ The seat resolved it by writing main's blob into the path (byte-proved against
fa4e087fe9) and then running--fix, producing a true union — verified as such, and with the gate's own totals unchanged from main's green control (109 sites / 145 anchors / 27 non-read).⭐⭐ Why the near-miss is the finding, not the merge
The count is what caught this. The prose is not census-derived, so the gate is blind to it.
⇒ Had main's edit been prose-only, the driver would have dropped it,
--fixwould have been a no-op, andcheck-system-context-censuswould have reported OK over silently deleted documentation. No conflict, no red, no reviewer signal.scripts/regen-artifacts.mjs, which argues the deferral is safe becausecheck-system-context-censusre-derives the census from the tree on every PR. That holds for census-derived numbers — and it is exactly what fired here. It does not hold for hand-written prose on the same page.The escape hatch already exists and is already documented
.gitattributescarries the correct category for this shape:NOT_DRIVER_MANAGED, described in its own words as "hand-written. Those conflicts are for a human."⇒ The question for triage is whether this page belongs in that category, or whether the routing should stay and the census gate grow a prose-integrity check. ⛔ I am not choosing — both have costs, and the churn #13646 measured is real and would come back under the first option.
What this does NOT claim
merge=os-regen. Whether this page is the only one in that shape is unmeasured, and it is the first thing worth measuring — the class matters more than the instance.Adjacent, and evidence this driver has form
Both closed, both the same family of "driver silently takes the wrong side":
os-regen-merge.shstep 2 unconditionally checks out main's side of every regen path, reverting a branch's own committed hand-deletions.gen:schema在 merge 未 commit 时运行,会把 authorable-surface 锚点倒退回旧 merge-base —— 生成器写入、门全绿、静默撤销 main 的锚点推进 #5370 —gen:schemarun before the merge is committed walks authorable-surface anchors back to the old merge-base: generator writes, gates green, main's advance silently undone.Refs: #13646 (the fix that created the shape) · #13578 / PR #13829 (where it was measured) · #12877 · #5370.