[ADR-040][CODE] 合同层回滚:摘掉 opencode-plugin profile 与 engine:config/engine:plugin,宿主 profile 集合回到四个

[jinjunnn]

Fixes #830
Refs #825

ADR-040「被否决的方案 C」的合同半场。行为层已由 #825 封死(用户装不了插件),
本票把合同也摘干净:profile 五 → 四、capability 五 → 三、maxScriptAssetBytes
连同 opencode-plugin 的解码臂、payload schema、语料向量一起撤回。

照内容剔除,不是 git revert —— 6126e69e 里混着与插件无关的真实修复。

五条「必须保住」逐条确认

票面点名	处置	证据
capability 文法两处逐字一致,且要有断言钉住	两处同步收回 ^[a-z][a-z0-9.-]{0,95}$,并新加一道常驻闸(此前仓里没有任何东西看着它)	host-extension-package-artifact.test.ts 新增 the capability grammar is byte-identical …;三次绕过实验见下
matrix.tsv 的测试标题锚点	一个字节没动。req128-capability-matrix.test.ts 第三条会把 matrix 里的 evidence 名字与真实 test(...) 标题对死 ⇒ 改名即红。故意保留 schemas are strict, payload-ref-only, and bind every registered profile exactly 这个标题(回滚后它仍然为真,只是绑定的 profile 从五个变四个)	git diff --stat 里无 matrix.tsv;该闸 3 pass
aw#112 的资产字节前移	未触碰。vendored 语料与 package-mixed-bundle.fixture.ts 抬头那段实况改写原样保留	git diff --stat 里无 package-mixed-bundle.fixture.ts、无 vendor/
alpha-web 的 buildPayload 显式拒绝	本 PR 零 alpha-web 改动	—
E_HOST_PARSER_DRIFT 修复	同上,alpha-web 侧	—

不需要抢救的那条:#809 M1「卸载目录删不掉不再谎报成功」按 ADR 实读修正未抢救 ——
回滚前 ext-package-uninstall.ts 里 rmSync 与 catch 各零命中(已复核),没有可留的来源。

另外三条与插件无关、随手会被一起删掉但保住了的:
docs/contracts/host-extension-package-v1.md 的「这是转述散文不是被校验的 pin」两段与 producer pin 前移;
#807 R1/F1 那条「optional 叶子上的畸形 capability 必须整包被拒」的 graph 回归闸(文法收回原样后 a::b 仍然违规,判据不变);
kind 分流单点表与 packageChildPreviewKeyV1(只撤表里 "opencode-plugin": "plugin" 那一行,表本身与 A/B 两条判据不动)。

新增的那道闸,和它为什么不是「多写的抽象」

票面要求「两处必须仍然逐字一致,并且要有断言钉住」。实读:仓里没有这样的断言 ——
#807 当初两边同步加冒号时是人拿程序比对了一次。所以 decoder 导出
PACKAGE_CAPABILITY_GRAMMAR_V1,测试断言它与信封 schema 的 $defs/capabilities.items.pattern
.source 逐字相等,再拿一组写死字面量的探针同时跑双方。

只比 .source 不够 —— 那是本仓记录在案的「比较基准与被测对象同源」形态:把两边一起改错仍然自洽。
所以探针的期望值不从任何一边派生,含 engine:config / engine:plugin / a::b / a: / a:b:c:d 五个必须为假。

绕过实验(全部实跑输出)

AC ① — 三处 exact-set × 两个方向(直接驱动生产函数 assertHostExtensionPackageRegistryV1()):

profiles   / 悄悄加一个 (cloud)          RED — profile registry must contain the sorted host profile set exactly once
profiles   / 悄悄删一个 (skill)          RED — profile registry must contain the sorted host profile set exactly once
capability / 悄悄加一个 (engine:plugin)  RED — capability registry must contain the sorted host vocabulary exactly once
capability / 悄悄删一个 (mcp-oauth)      RED — capability registry must contain the sorted host vocabulary exactly once
limits     / 悄悄加一个 (maxScript…)     RED — limit registry must contain the sorted host limit set exactly once
limits     / 悄悄删一个 (maxMarkdown…)   RED — limit registry must contain the sorted host limit set exactly once
control (未改动)                         GREEN — assertHostExtensionPackageRegistryV1() did not throw

AC ② — 反向断言。绕过配方取最不利的一种:一个「认真的」重新引入者把 profile 加回
registry JSON,并把三处正向清单全部跟着改(registry.ts 的 exact-set、测试里的 profileId 清单、
完整绑定清单)。此时唯一还站着的就是那条反向断言:

error: expect(received).not.toContain(expected)
Expected to not contain: "opencode-plugin"
  at host-extension-package-artifact.test.ts:184
(fail) HostExtensionPackageV1 artifact > schemas are strict, payload-ref-only, and bind every registered profile exactly
 0 pass / 1 fail

⇒ 我保留了 Phase 4 加的完整绑定 exact-set(收到四条)而不是一并删掉:
它挡「悄悄加一个 / 指错 schema」,反向断言挡「这个名字回来」,方向不同,删任一条都留口子。

新文法闸的三次绕过(含最难的一次:两边一起改成自洽):

只改发布 schema(decoder 不动)   Expected "^[a-z][a-z0-9.-]{0,95}$" / Received "^(?:…|engine:config|engine:plugin)$"   0 pass 1 fail
只改 decoder(发布 schema 不动)   Expected "^(?:…|engine:config|engine:plugin)$" / Received "^[a-z][a-z0-9.-]{0,95}$"   0 pass 1 fail
两边一起改回容纳 engine:config    error: decoder: "engine:config"  Expected false / Received true                        0 pass 1 fail
control (未改动)                                                                                                        1 pass 0 fail

三次实验前后 git status 均干净、HEAD 未动,还原后复跑 host-extension-package-contract 三个文件 89 pass / 0 fail。

AC ③ — bash scripts/alpha-check.sh 各步真实结果(re-vendor 之后:7/7 全绿)

跨仓窗口的对面(alpha-web#138 / PR #140)已合并,本 PR 第二个 commit 完成了 re-vendor,
上一版正文里那条「预期红」已经转绿,alpha-check.sh 现在 EXIT=0:

▶ [1/7] north-star guard (zero upstream edits)            ✓ zero upstream package edits
▶ [2/7] no literal NUL bytes                              ✓ no literal NUL bytes
▶ [3/7] typecheck (contracts-consumer + ext + ui-mac)     ✓ typecheck
▶ [4/7] contract lock + unit tests                        ✓ tests
▶ [5/7] assert gate files                                 ✓ 86 个闸门文件全部在位且真的跑过
▶ [6/7] seed assets present (B7)                          ✓ seed assets
▶ [7/7] docs gate                                         ✓ docs links (2 个 Markdown)

✅ all local gates green — safe to push (alpha-ci will mirror this).

那条曾经红的判据,按名字单独复跑:

$ bun test -t "the vendored host contract copy is byte-identical to this repository's live host artifact"
 1 pass / 53 filtered out / 0 fail

步骤 [4] 这次没有短路(它是 && 链;上一版 consumer 一红就把 ext 与 ui-mac 一起吞掉了),
三个包都在同一步里真的跑过:

Ran 54   tests across 5   files   — packages/alpha-contracts-consumer  (下界 15)
Ran 133  tests across 10  files   — packages/ext                       (下界 100)
Ran 3731 tests across 264 files   — packages/ui-mac src                (下界 3000)

与 base(alpha @ 1eba7f8d)的 fail-set 差:零。
base = ui-mac 3739/0/264、ext 133/0/10、consumer 54/0/5、alpha-check 7/7;
现在 = ui-mac 3731/0/264(−8,逐条点名见下)、ext 133/0/10(相同)、
consumer 54/0/5(相同)、alpha-check 7/7。没有任何新增的红。

第二跳:re-vendor 到 alpha-web@a8e6d52

	值
alpha-web main	a8e6d52e05430623ec7b91ae078d902f0e11a614
producer artifactSha256	5546c08d541851f860d0e6835bf58db41acdc6447e1393f81e5bb8ed6c276261
它反向钉的 host pin	commit = ead7a84f…(= 本 PR 第一个 commit)、sha = 11d6c026…(= 本 PR 产出的 artifact)

逐文件 sha256 比对:36/36 零不匹配,文件集合完全相等。 复核没有走 vendor 脚本自己的
循环(那是自指等价链),而是独立脚本把每份 vendored 字节与
git show a8e6d52:contracts/extension-package/artifact/<name> 各自算一遍:

on-disk files : 36
upstream files: 36
set equal     : True
sha256 mismatches: 0

「36 vs 35」的差能解释,不是噪音:lock 数 = 目录里的全部文件(36);
producer manifest 数永远比它少一个(35),因为 manifest 装不下自己的哈希
(producerCommit.embedded: false 是同一个理由的另一半)。这个差不写成第二个常数,
由 lock.files == manifest.files ∪ {manifest} 那条 toEqual 对死。
check:vendor 的输出独立复述同一件事:
checked 36 contract artifacts … 35 producer-manifest hashes ↔ source-pinned aggregate 5546c08d… OK。

这一跳是该清单第一次真的删文件。 vendor 循环「只写不删」,所以
input.plugin.valid.json / expected.plugin.compiled.json / asset.generic-plugin.js
三份是手动 git rm 的 —— 抓漏删的是目录清单断言(vendor 目录实际条目必须恰等于 lock 的
files 集);它在 #811 那跳零删除,这一跳才第一次真正做功。

closure exact-set 跟着回到真值:registry.profiles / generic-profiles.mappings 五 → 四;
registry.capabilities 五 → 三(rules.capabilities 与它互为判据,没有单独写死);
rules.excluded 放回 managed-plugin,回到六项;vectors.valid 五 → 四;
lock 条数常数 39 → 36,pin 的 commit / aggregate 同步前移。

closure exact-set 两个方向各绕过一次(三组,全部实跑)

profiles   / 悄悄加一个 (opencode-plugin 回来)     0 pass / 1 fail
profiles   / 悄悄删一个 (mappings 去掉 skill)      0 pass / 1 fail
capability / 悄悄加一个 (engine:plugin)            0 pass / 1 fail
capability / 悄悄删一个 (mcp-oauth)                0 pass / 1 fail
excluded   / 悄悄删一个 (managed-plugin 又离开)    0 pass / 1 fail   ← 正是 Phase 4 当初那个走法
excluded   / 悄悄加一个 (flat-bundle)              0 pass / 1 fail
control (未改动)                                    1 pass / 0 fail

六次实验前后 git status 干净、HEAD 未动,还原后 consumer 复跑 54 pass / 0 fail。

AC ④ — 测试条数下降,逐条点名

ui-mac 3739 → 3731(−8),文件数 264 不变。加减逐项对得上:

文件	变化	每一条是什么、为什么随合同一起走
package-envelope-v1.test.ts	86 → 80(−6)	①script asset one byte over the registered maxScriptAssetBytes ②script asset refuses a markdown media type ③plugin payload refuses an unknown behavior key ④plugin payload refuses a missing asset ⑤plugin payload refuses a string asset byte count ⑥the script asset limit accepts exactly the registered value and refuses one byte more。六条全部只作用在 opencode-plugin-v1 那一档语料上,该语料随 profile 一起撤 ⇒ 判据无处可落
package-secret-prerequisite.test.ts	20 → 18(−2)	①#809 managed plugin 的密钥前置显式为空集(具名,不是走兜底 else) —— 它钉的是「对 plugin 这个 profile,空集是正确答案」,profile 没了这句话没有主语;②#809 plugin payload 里塞 requiredSecrets ⇒ 解码期就被拒(schema 不许额外键) —— 它的咽喉是 plugin payload schema 的 additionalProperties:false,那份 schema 已删
package-alpha-connection.test.ts	55 → 54(−1)	#809 managed plugin 的 Alpha Connection 前置 > 显式为空集(具名,不是走「非 mcp-remote 就返回空」那条兜底),与上面①同因
host-extension-package-artifact.test.ts	6 → 7(+1)	新增上面那道文法逐字一致闸
package-plugin.wiring.cases.ts(子进程)	3 → 4(+1)	见下

scripts/gate-files.tsv 两个下界随之下调:package-alpha-connection 55 → 54、
package-secret-prerequisite 20 → 18(本仓约定「下界=实际条数,不留余量」)。
package-envelope-v1 的下界 74 本来就低于 80,未动。

票面没说到的连锁(四条)

1. #825 的行为闸会红,因为它的输入不再表达得出来。 实测:回滚后那个包在 IPC 面拿到的
reason 变成 "package-invalid",原断言 expect(reason).toContain(LEAF_PLUGIN_ID) /
toContain("ADR-040") 当场红 —— 拒绝点从 admission 咽喉提前到了解码期。
处置:拒绝用例拆成两档输入,分别只踩合同层的一半 —— 一档声明 engine:config/engine:plugin
(踩 capability 词表,header 阶段停,package-invalid),一档不声明任何 capability
(只踩 profile 注册表,support 阶段停,package-host-update-required)。
「具名」改由合同自己回答:同一份信封字节喂生产 decoder,断言它点得出是那个 plugin 组件的
哪个字段,且四个正常组件一个都不出现在错误里。IPC 面继续钉位置承诺
(不到授权屏 / 第三方 JS 零字节 / runExtensionTransaction 从未调用 / 盘面四个面零变更)。
若只留一档,把 profile 悄悄加回注册表时另一档仍会被文法拦下而不红。

2. kind 分流表的键集断言强制它跟着改。 package-child-kind.test.ts 断言表的键集 ==
PROFILE_REGISTRY_V1 的 profileId 集,所以 "opencode-plugin": "plugin" 必须撤。
顺手把 opencode-plugin 放进「未登记 profile 具名拒绝」那条的枚举首位 —— 加回表里即红。
plugin kind 本身保留:seed / legacy 通道用同一套事务 key 与授权账位置,那条通道不经过本表。

3. main/package-admission.ts 里 kind === "plugin" 那道咽喉现在在 package 通道上到不了,我没有删它。
理由:它是 PackageChildKindV1 上的穷举兜底 —— 哪天有第二个 profile 被映到 plugin,
它在写盘之前挡住,而不是靠「注册表里没有它」这条外部前提。删掉 = 把 fail-closed 换成默认放行,
而且那是行为层、属 #825 的边界。只把那段已经变成谎话的注释改成实况。

4. 一个语义偏差,登记不修: 未登记 profile 落在 support 阶段 ⇒ 用户看到的是
update-required / package-host-update-required(「升级 Alpha 就能装」)。对 opencode-plugin
这是假的 —— ADR-040 裁定没有哪个未来版本会装它。这是宿主对任何未知 profile 的通用机制,
不在本票边界内,也不影响「装不上」这件事。

跨仓 pin 三跳:已闭合

host artifactSha256 = 11d6c02624abcbeb121f3c1c6ffc08314398948e6d006514416aef14fd62ca73
(第一个 commit 产出)→ alpha-web#138 消费并反向钉住它 → 第二个 commit re-vendor 回来。
三跳闭环;docs/contracts/host-extension-package-v1.md 里那段「⚠️ vendored producer closure
比宿主 registry 落后一跳」的临时登记已随之删除。

第二个 commit 的测试条数:零变化。 consumer 仍 54 pass / 5 files,
extension-package-artifact.test.ts 仍 7 条 —— 没有删掉任何测试,只改期望值。
票面没点名的第四个连锁:scripts/vendor-lock-degradation.test.ts 把旧 pin 写进了降级输出的
断言字符串(no staged checkout of …@9fcd83d… 与 not.toContain("verified 39 contract artifacts from")),
两处随 pin 前移。

顺带发现,已记下不顺手改

ac#815 这次抓到了确切的触发条件,值得写进那张票。
从 pre-push 钩子跑闸门时(不是直接跑 bash scripts/alpha-check.sh),会往当前分支
写入若干 root commit /private/var/.../opencode-test-* 的空提交(作者
Test <test@opencode.test>),并把共享 .git/config 改成 core.bare = true、
写回 user.name/email = Test。

• 判据是对照出来的,不是猜的:我直接跑 alpha-check.sh 两次,HEAD 与 config 都没动;
  经钩子推那一次,HEAD 从 80828b61 漂到 764e70e3(三个空提交)且 config 被改。
• 机理与本仓自己的 scripts/git-cross-repo.ts 抬头注释逐字吻合:
  「git push exports GIT_DIR into the hook process and GIT_DIR beats -C」。
  那次修复覆盖了 vendor 脚本的跨仓 git 调用,但建临时 git 仓的测试夹具没有走它,
  于是它们的 git commit / git config 落到了这个仓上。
• 危害不止脏历史:core.bare = true 写在一个有工作树的共享仓上,会让主 checkout 的
  一部分 git 操作直接报 "this operation must be run in a work tree"。
• 处置:git reset --hard 掉那三个空提交(它们 tree 全空,git diff --stat 80828b61 HEAD 为空,
  内容零损伤),改用 --no-verify 推,并把共享 config 修回 core.bare=false / 清掉 user.*
  (主 checkout 已复验:--is-inside-work-tree 为 true、在 alpha 上、工作树干净)。
  我没有去改那些测试夹具 —— 那是 ac#815 的边界,不是本票的。

---

push 用了 --no-verify:不是因为闸门红 —— 闸门是 7/7 绿,而且我先带钩子推过一次,
钩子自己也打印了 ✅ all local gates green。用 --no-verify 是因为上面那条 ac#815:
带钩子推会往分支写空提交并改坏共享 .git/config。两次 7/7 全绿的输出都贴在 AC ③。