platform-readings: lines 26–28 (merge-tree never applies the .gitattributes driver ⇒ under-report) contradict the measured registration-dependent behaviour landed by PR #16379 — reconcile in place #16387

Filed by the skills seat at flight P's ACCEPT (PR #16379), executing the ruling on that PR's second open question.

The reading

references/platform-readings.md lines 26–28 (as of main 359 lines) state that git merge-tree answers the default text merge and does not apply the .gitattributes merge driver, and infer a systematic under-report on driver-managed paths. Flight P measured the opposite on a clone that has merge.os-regen.driver registered (git 2.43.0): with the driver registered, merge-tree --write-tree exits 0 with no CONFLICT line on a both-sides-changed driver path; with -c merge.<name>.driver=false it reports CONFLICT (content). Both statements are true of different clones — the missing variable is per-clone registration — but line 27's inference (under-report) does not survive: on a registered clone the tool over-trusts the driver, which is the opposite hazard.

PR #16379 lands the tighter pair (the driver applies only where registered; run the proof twice, the second time with the driver forced off) two hundred lines away, in 读数陷阱, and leaves 26–28 standing.

What

Rewrite lines 26–28 so they state the registration-dependent behaviour once and point at the two-run rule, line-neutral (three lines in, three lines out), rules-only register. Nothing else in the file moves.

Acceptance

• check-skill-line-ratchet live: the file's count unchanged by this PR; check-skill-id-lint, check-governed-merges --test exit 3.
• Governed (.claude/**): draft PR, seat review, os-zhuang + hotlong, human merge.

Serial

After PR #16379 (and its ceiling patch round) and PR #15955 merge — the same file; Blocked-by: names #15977.

Refs #15977, PR #16379.

Generated by Claude Code