You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// probe.mjsimport{readDisposition}from'./scripts/check-adr-0087-registration.mjs';console.log('PROBE OWN OUTPUT: readDisposition ->',JSON.stringify(readDisposition('nothing here')));
第一次(门无可判) —— 门的判决先于消费方自己的那行打出来:
=== everything below this line came from a bare `import` of the gate module ===
✓ check-adr-0087-registration: this PR adds no declared-breaking changeset (0 non-breaking changeset(s) seen).
PROBE OWN OUTPUT: readDisposition -> {"ok":false,"reason":"no `adr-0087:` disposition marker"}
PROBE_EXIT=0
第二次(同一个 import,但仓里有一份声明破坏、没带标记的 changeset,默认 base 落在 HEAD 之前) —— 门判红并 process.exit(1),消费方自己的代码一行都没执行到:
✗ check-adr-0087-registration: 1 problem(s).
• .changeset/new-breaking.md
declares a breaking change (major, BREAKING) but no `adr-0087:` disposition marker.
…
PROBE_EXIT=1
--- did the importer's own line ever run? ---
NO — the gate called process.exit(1); the importer never reached its own code
发现于 #6494 / PR #6556 实施期间(devx 车道执行座位)。按 Prime Directive #10 只记录不修,未认领,不自评级别(定级是分诊座位的单一通道)。
事实
scripts/check-adr-0087-registration.mjs的 CLI 派发写在模块顶层,没有import.meta.url === process.argv[1]这类入口守卫(同仓scripts/objectui-changeset-digest.mjs末尾就有一个)。文件尾部形如:四个分支没有一个是 no-op。因此
import它 = 运行它(对导入方进程的REPO_ROOT与process.argv)。实测(不是从代码形状推断的)
临时仓 + 从
origin/main取出的门脚本副本,写一个只想借一个纯函数的消费方:第一次(门无可判) —— 门的判决先于消费方自己的那行打出来:
第二次(同一个 import,但仓里有一份声明破坏、没带标记的 changeset,默认 base 落在 HEAD 之前) —— 门判红并
process.exit(1),消费方自己的代码一行都没执行到:即:导入方拿不到函数、拿不到控制权、还会被按门的判决决定退出码,而门判的是导入方的
REPO_ROOT,与导入方想问的问题无关。这正是 PR #6556 绕开它的原因
#6494 要让
objectui-changeset-digest.mjs生成的 changeset 携带一份「门仍会判红」的 ADR-0087 处置脚手架。想证明「门确实把这份占位认成 present-but-unanswered」,最直接的写法是 import 门的parseChangeset/breakingDeclaration/readDisposition—— 一个判据、两个消费方、不会漂移,正是本仓一贯偏好的形状(objectui-range.mjs与 digest 共用classifyRange()就是先例)。这条堵死了这个写法。PR #6556 改为子进程 + 临时仓驱动门的二进制来钉一致性。附带一条也值得记:即便可以 import,也要权衡「给发布关键路径(
bump-objectui.sh调用链)加一个『门被改名/移动就崩』的耦合点」;两条理由叠加,子进程是对的,但第一条本不该存在。代价
一个不能被安全 import 的门,等于强迫每一个想与它保持一致的调用方自己起进程。 具体开销:
assertInputs的输入(两份 ledger 源、spec-changes.json、一份存量 breaking changeset),只为问一句「这段正文算不算带了处置标记」。PR fix(scripts): objectui digest 声明破坏性时写入门仍判红的 ADR-0087 处置脚手架 (#6494) #6556 为此写了约 40 行 fixture。extractIds/hasMigrationPrescription/readDisposition这些明显是纯函数的导出,都会踩同一颗雷,而且踩到时的现象是「我的脚本莫名其妙打印了一段 ADR-0087 判决然后退出 1」,第一眼根本不像 import 的锅。它们全部导出了(
export function readDisposition等),形状上就是给人复用的;只是现在没有一个可以被使用。相邻(非重复)
check-*.mjs的--self-test只在可被skip-changeset整体豁免的 job 里跑。方向不同(那条讲谁在跑自检,本条讲能不能被 import 复用),但同一批脚本。not-required (no-migration-prescription)可被合法豁免绕过,存量已见 4 条同形 #6497 / #6497 之后:迁移说明探测器仍读不到「只由表头/标签起框」的改写表 —— 存量 11 条声明为 breaking 的 changeset 仍在拿豁免 #6559 / [finding] #6148 的门禁只判 diff,v17 列车已有的 227 条 breaking changeset 从未被比对过 —— 抽样已见 2 条疑似同形漏登记 #6350 —— 门的判据与存量覆盖面,与本条正交。去重检索:
adr-0087 import、import.meta.url top-level CLI dispatch、check-adr-0087-registration三次search_issues均无同形单。发现会话:
session_01BDmDsu2575gDxeMCxXhDE3(devx 车道执行座位)。严重度与路由留分诊座位判定。Generated by Claude Code