Repository navigation
[VERIFY][cap:extension-package-ingestion] 外部包到 Alpha Runtime 的兼容、认证、事务与旧宿主矩阵 #700
Description
Capability
extension-package-ingestion —— Alpha 原生 package 从 producer 声明、经签名 Catalog,
到桌面端兼容判定、prerequisite、事务安装的跨仓生产链。
Purpose
本票是 capability harness,不是逐实现票重复单测。
它要回答一个单张实现票回答不了的问题:这些票合起来是不是一个能用的能力。
AGENTS.md 与本仓治理都写着同一条:harness 失败不得由实现票里的局部 mock 证据替代。
范围:收敛到 Phase 1 面
2026-07-31 范围收敛。 治理文档
governance/req128-extension-package-development-guide.md
阶梯 8 的标题早已写明「Phase 1(harness 范围收敛到 Phase 1 面)」,但正文覆盖清单仍是全量 ——
那是标注 phase 时漏改正文造成的文档缺陷。本票面按标题对齐,不是新的范围决策。照原文,本票 exit condition 依赖
#703/#704/#705/#706/#712/#697/#698/#699
与alpha-web#96/#98/#99—— 全属 Phase 2/3/4,尚未开工,因此本票在 Phase 1 内结构上关不掉。
本票覆盖(Phase 1 已交付的面)
- producer → signed Catalog:声明 → normalized record → Envelope → Catalog 的确定性;
- old-host oracle:
v0.1.0–v0.1.2只消费 legacy-safe entries,
新增的packages同级键不可见且不改变旧宿主行为; - foundation host capability gate:未知 profile / 未知 profileVersion / 未知 capability /
mediaType 不匹配,在 fetch / secret / disk 之前就判update-required或blocked,
无 legacy fallback; - safe view 与安装重判:renderer 只消费 main 的 safe view;main 重取重验;
renderer 篡改无效; - secret prerequisite 生命周期:ready / cancel / failure / replacement / uninstall;
- 单组件 admission:四组 digest 绑定、重取逐条重验、attemptId 一次性、
confirmed 必须覆盖全量 diff key、secrets 键集与已签集合完全相等; - 用户可达路径:renderer 真实按钮点击 → 两趟往返 → 密钥真落盘
0600→ 全程零明文回显。
明确不在本票
MCP OAuth(#703)、Alpha Connection(#704)、V3 ledger / claim(#706)、
Bundle(#697/#698/#705/#712)、managed Plugin(#699/alpha-web#99)、
local import(Phase 3)、外部适配器(alpha-web#96/#98)、
packaged RC(L3)—— 它需要真实签名 package,归 alpha-web#108。
Development plan
- 先勘破,再动笔:Phase 1 的十一张实现票已经建了大量闸门(
scripts/gate-files.tsv在册)。
本票不重复造已有闸门 —— 已被完整覆盖的项,矩阵里指向它,
并在gate-files.tsv用delegates_to登记委派关系。 - 建机器可读矩阵:每格记录 producer / consumer / fixture / expected verdict /
reason code / evidence path。它是本票的主产物 —— 让「这条链的哪一格有证据、证据在哪」
成为可查询的事实,而不是散落在十一张票的 PR 描述里。 - 只为矩阵里空着的格新增用例。
- corpus 覆盖 Phase 1 四个 profile 的 good / blocked / malicious;
deterministic canonical case 永跑,property/fuzz 固定 seed、有界、可重放。
Acceptance and named gates
- 上述七项每一项在矩阵里有 named evidence 路径与单一 owner;
- 矩阵本身有闸:新增一个 Phase 1 面而矩阵没有对应格 ⇒ 红;
- 委派关系在
gate-files.tsv登记且被委派方也在册(下界取精确实跑条数,不留余量); - harness 失败不得由实现票里的局部 mock 证据替代。
诚实记录:今天的可达性边界
真实 Catalog 里 0 个 package(alpha-web/catalog-src/packages/ 目录不存在,
签名 catalog.json 连 packages 键都没有)。
所以本票的全部夹具必然是构造的,且必须在测试里如实标注。
这不是本票的缺陷,是本票诚实的边界。 让整条链真的载一次真实载荷归
alpha-web#108(需 owner 先定发布什么)。
Dependencies
Phase 1 全部实现票(已全部合并)。
Exit condition
矩阵合并 + 七项各有 evidence-backed PASS + 矩阵自身的闸在册且真跑过。
父需求 alpha-work#49 不由本票关闭 ——
它的 AC1–AC8 逐条映射到 Phase 2/3/4 的票(AC2 明写 flat Bundle、AC5 六分之五是 Phase 2、
AC6 是 Phase 4),结构上要等到 Phase 4 落地才能验收。实现 PR 不得使用 closing keyword 关闭父需求。
Activity
jinjunnn commentedon Jul 31, 2026
编排者:本票范围收敛到 Phase 1 面(与治理文档对齐)+ 一个必须先说清楚的发现
一、票面与治理文档不一致,本条是对齐不是新决策
governance/req128-extension-package-development-guide.md第 598 行的阶梯 8 标题写着「Phase 1(harness 范围收敛到 Phase 1 面)」,但正文的覆盖清单还是全量
(含 MCP OAuth、Alpha Connection、V3 ledger、mixed Bundle、managed Plugin、local import)。
标注 phase 时只改了标题、没改正文 —— 这是文档缺陷,不是范围争议。
本票的 exit condition 照原文写着 Phase A+B+C 全部,而 B/C 依赖的是
#703/#704/#705/#706/#712/#697/#698/#699与alpha-web#96/#98/#99——全部属于 Phase 2/3/4,尚未开工。照原文本票在 Phase 1 内结构上关不掉。
收敛后的范围(只保留 Phase 1 已交付的面):
#703)#704)#706)#697/#698/#705/#712)#699、aw#99)aw#96/#98)二、一个比范围更要紧的发现:这条链从没载过真实载荷
实测三条:
alpha-web/catalog-src/packages/目录不存在;catalog-src/catalog.json连packages键都没有,只有 26 条 legacyentries;(
gh issue list --search两条轴查过)。管道本身是通的 ——
scripts/build-catalog.mjs:275调loadAndCompilePackages读
catalog-src/packages/,无声明时compiledPackages=[]且不加packages键(所以 legacy 字节语义不变)。缺的不是代码,是从没有人往里放过一个声明。
后果:Phase 1 的十一张实现票、每一道闸、每一次对抗审计,跑的全是构造夹具。
而
alpha-work#49的用户结果是「发布者可用标准声明发布 Alpha 扩展」——今天没有任何发布者发布过任何东西。
这是 [
scope-cut-must-close-user-path] 那条教训在更上一层的重演:Phase 1 剪裁时我逐跳点名了宿主侧的用户路径,但没问发布者侧那条路径谁拥有。
⇒ 已另开票承接(见下方评论)。本票不吞掉它 —— 发布什么内容是产品决定,
而 harness 是确定性的、要在 CI 里反复跑的东西,两者不该混在一张票里。
三、收敛后的 Acceptance
v0.1.0–v0.1.2只见 legacy-safe entries,packages同级键不可见;update-required/blocked,无 legacy fallback;四、明确不在本票
jinjunnn commentedon Jul 31, 2026
承接上一条第二节的那张票已建:
alpha-web#108(P1)——「发布第一个真实 package,整条链至今没载过一次真实载荷」。它需要 owner 先定发布哪一个(产品内容决定),所以不在本票内。本票只做确定性的、要在 CI 里反复跑的 harness。
jinjunnn commentedon Jul 31, 2026
编排者:砍掉 old-host oracle,并说明理由
勘破(2026-07-31,只读)查出本票范围第 2 项「
v0.1.0–v0.1.2old-host oracle」有两个问题:一、现有那道闸几乎是空的。
catalog-package-legacy-compat.test.ts:1第一行自己写着「v0.1.1/v0.1.2 的
saneCatalog()与今天逐字相同,故本测试是忠实代理;v0.1.0 尚无此文件」——这是一句人写的等价性主张,不是可执行判据。全仓搜三个 pin 的 commit sha:零命中。下界 2,与"这道闸只值 2 条"吻合。
二、票面要求的方向是反的。 票面写「
packages同级键不可见」,而:25断言的恰恰是原样透传。透传是当前宿主必需的(它要读
packages才能显示扩展包),"不可见"只对旧宿主才有意义。
裁决:不建这个 oracle
owner 直令:本 portfolio 没有真实用户、没有租户,不做任何向后兼容,只向前推。
实测补充:
packages/ui-mac/package.json的当前版本就是0.1.2——所谓"old host"只剩
0.1.0/0.1.1,而现实里没有任何一台机器装着它们。为零个用户建一个三版本兼容 oracle,正是要砍的包袱。
保留现有那 2 条(成本为零,且确实在守「新增同级键不打断当前读端」);
不新建三版本语义快照、不补
legacyProjectionDigest(它在整个仓库里只出现在设计文档,没有实现、没有 schema、没有测试 —— 那是纸面设计,不是欠账)。
矩阵里这一格标
cut — 无真实用户,不做向后兼容(owner 直令 2026-07-31),不留空格:空格会被下一轮 review 当成欠账,标注过的"明确不做"才是事实。
相应地,本票的范围第 2 项改为
其余六项不变。
[#700][VERIFY] REQ-128 Phase 1 capability 矩阵 + 矩阵自闸 (#746)
[#737][CODE] 消除宿主为契约文法写的替身:枚举整类,收口到共享 predicate (#747)
[#700][DOC] 撤掉已解决的 known-defect 边界:#737 已合并 (#748)
docs(verification): aw#163 —— 桌面端对公网 stable 的 package:alpha-first 浏览/…