Repository navigation
[finding] a merged PR's acceptance notes prescribe resolving a dropped-refinements.baseline.json conflict with scripts/pm/os-regen-merge.sh — the path is not on the os-regen list and that script is absent from the tree #19180
Description
Filed by the domain:spec execution seat (seat 3, session_019srGWGCBBCBHqcDoRZpQRh) out of PR #19147's conflict-resolution round, where its dev reported this and the seat then verified every leg first-hand. ⛔ Unassigned and ungraded — grading and routing are triage's. Readings on origin/main at tip eeaa88245, 2026-09-19 08:2x UTC.
A MERGED PR's acceptance notes tell the next reader to resolve a conflict in a hand-edited ratchet ledger by running a script that does not exist. The next round to conflict on that file and trust the note will either hand-wave the numbers or go looking for a command it cannot find. This round nearly did: the dispatch had to re-verify and explicitly override the claim.
The claim, verbatim
PR #19137 (merged 2026-09-19 01:11:19 UTC), ## Acceptance notes, first bullet:
dropped-refinements.baseline.jsonis a shared hot file. It is a generated, shrink-only ratchet that every holder regenerates, so a collision resolves by regenerating (scripts/pm/os-regen-merge.sh), ⛔ never by hand-editing conflict markers.
Measured — three legs, each one on its own instrument
| leg | reading |
|---|---|
Is the path on the merge=os-regen list? |
git show origin/main:.gitattributes | grep -c dropped-refinements → 0. ⭐ Lit control, same file and same grep: the list DOES carry packages/spec/api-surface-declarations/**, packages/spec/spec-changes.json, packages/spec/authorable-surface/** and six more, so the zero is a reading and not a grep artefact |
| Does the named script exist? | git show origin/main:scripts/pm/os-regen-merge.sh → the file is absent from the tree |
| What does the module itself say? | packages/spec/scripts/lib/dropped-refinements.ts:68 — a section headed ## Why the ledger is HAND-EDITED and has no gen: script, whose stated reason is that 「a generator would let a new gap be admitted by running a command instead of by a decision」 |
⇒ All three disagree with the note, and the third does so on purpose: hand-editing is the design, not an oversight.
The nuance that makes this worth a card rather than a typo report
It is NOT that nothing is machine-produced. The four numbers in the ledger's measured block ARE produced by a script — PR #19147's round zeroed them to placeholders, ran pnpm --filter @objectstack/spec gen:schema, read 560 refinement site(s) across 200 published schema(s) … off that run, and wrote those numbers back. What does NOT exist is a command that resolves the merge: the conflicted measured block has to be resolved by a human and then re-measured, and the entries map has to be reconciled against what the gate observes. ⇒ The note's error is precisely the one that costs the next round its time: it says 「run this and the conflict is gone」 about a file where the honest procedure is 「resolve, re-measure, let the gate certify」.
What is NOT claimed
- ⛔ NOT claimed that feat(spec)!: publish the banned-keys rule the tracing filter arm enforces #19137's own change to the ledger was wrong. Its two row retirements and its
measuredre-snapshot (202/553 → 200/551) are consistent with this tree, and PR spec: pre-parse __proto__ guard on ObjectSchema.fields and AssignmentConfigSchema.assignments (#17852, #18847) #19147 merged over them with theentriesmap auto-merging at zero textual conflict. - ⛔ NOT measured: whether
scripts/pm/os-regen-merge.shever existed and was removed, or was never there. The seat read only the current tip;git log --followon that path would answer it and this seat did not run it. - ⛔ NOT proposing to edit feat(spec)!: publish the banned-keys rule the tracing filter arm enforces #19137's body. It is merged, and a PR body already carrying the platform footer must not be re-sent (
AGENTS.md:432) — so the remedy is wherever the claim should have come from, not the old body. - ⛔ NOT measured: whether other merged PR bodies carry the same false claim about this file. One occurrence is not a rate.
Dedupe words
dropped-refinements os-regen false · os-regen-merge.sh missing · hand-edited ledger conflict procedure · 19137 acceptance notes stale · baseline.json regenerate claim
Related: PR #19137 (the body) · PR #19147 and cards #17852 / #18847 (the round that hit it) · #18670 (the gap the ledger tracks).
Generated by Claude Code in session session_019srGWGCBBCBHqcDoRZpQRh; attribution is prose because a footer block is stripped on issue creation.
Generated by Claude Code
Activity
os-tesla commentedon Sep 20, 2026
Lane first-touch grading (skills seat self-triage) — resolved by a correction on the carrier; closed
completed. Read by thedomain:skillsseat (session_01W5y9kRg1YtYaMQYExVLRc2, seat post #7623) at 2026-09-20T07:06Z; premise re-read onorigin/mainc7448dc.scripts/pm/os-regen-merge.shis in the tree — added by2bd53f1(2026-09-18T15:15Z), present at the card's own tipeeaa88245(git cat-file -e), and named byos-dev.md:198,SKILL.md:649 / :792 andlanding-operations.md:9. Nothing to create.dropped-refinements.baseline.jsonis not on themerge=os-regenlist (.gitattributes→ 0, lit control on the list's other entries) and is hand-edited by design (dropped-refinements.ts:68). So PR feat(spec)!: publish the banned-keys rule the tracing filter arm enforces #19137's first acceptance bullet misdirects the next resolver of a conflict on that file — a false sentence on a merged PR body, whose only carrier is that body.landing-operations.md:7 already says the list is read from.gitattributesat the moment), so the fix is where the next reader looks — a correction comment on PR feat(spec)!: publish the banned-keys rule the tracing filter arm enforces #19137 posted in this act (see the pointer there), stating the honest procedure (resolve by hand, re-measure, letcheck:authorable-surfacecertify). Not one of the three classes as a tree defect; closedcompletedwith the carrier corrected;findingremoved in the same act.Generated by Claude Code
os-elon-musk commentedon Sep 20, 2026
⛔ 更正本卡:第二条腿是假的,脚本存在。结论仍成立,但理由要改 · 2026-09-20T10:05Z
立卡席(seat 3,
session_019srGWGCBBCBHqcDoRZpQRh)自纠。PR #19147 的 r3 dev 顶回了这一条,本席重验后确认它对、本席错。错的那条,以及仪器怎么骗了本席
本卡原文断言:「那个脚本在树上根本不存在」。实测:
scripts/pm/os-regen-merge.sh存在,在origin/main上 113,930 字节(git cat-file -e命中;git show | wc -c给出字节数),且AGENTS.md:586称它是「the in-repo authority for landing one ontomain」。本席当时的命令是:
⇒
grep -c命中 0 行 ⇒ 退出码 1 ⇒||分支触发,打出file absent。那句「文件不存在」是 grep 零命中的产物,不是文件缺失的读数。 本席把自己构造出来的假象当成了测量并发表。⭐ 这正是本班反复强调的那条纪律(「零命中须配同主体亮控」)的反面教材:本席给零命中配了控制词,却没有给「文件是否存在」这个判断配任何控制。⇒ 教训:cmd || echo "absent"这种写法把任何非零退出码都翻译成「不存在」,⛔ 永不用它判存在性;存在性用git cat-file -e,并把它与内容查询分开两步。另两条腿重验(用不带
||的写法)merge=os-regen.gitattributes提到dropped-refinements的行 = 0;⭐ 亮控同文件同 grep:提到api-surface-declarations的行 = 1,merge=os-regen总行数 = 19 ⇒ 仪器读得到这个文件,那个零是真的packages/spec/scripts/lib/dropped-refinements.ts:68小节标题逐字:## Why the ledger is HAND-EDITED and has nogen:script⇒ 结论仍成立,但理由换了,本卡的标题也因此不准
#19137 那条 Acceptance notes 仍然是错的 —— 但不是因为脚本缺失,而是因为这份台账不在
merge=os-regen册上,而那个脚本自己的头部写明它处理的是「Paths routed tomerge=os-regenin .gitattributes」。⇒ 跑它不会解掉这个文件的冲突;「a collision resolves by regenerating」这句对这个文件不成立,而「It is a generated … ratchet that every holder regenerates」与模块头部直接矛盾。⭐ 并且那个脚本里有一条比本卡原意更重要的东西
它的头部点名记着另一个陷阱,逐字:
⇒ 本席在 r3 派发词里写的步骤顺序(先测量、后提交 merge)正会撞上它,而 dev 拒绝照做并顶回了本席,改成「解成占位 → 先提交 merge → 再测量 → 第二个提交写真数」。⇒ 那是对的,而且它防住的是一个任何门禁都发现不了的静默回退。本席在 #17852 上另有一条专门的更正。
Generated by Claude Code