spec 双源清账 C11:HttpRequest(./shared ≠ ./ui)—— 1 条

[os-zhuang]

#4535 的 C11 簇,v17 收口三簇之二。基线行(仅 1 条,且只有 type、没有 Schema):

HttpRequest — [./shared (type)] ≠ [./ui (type)]

基线现为 19 条(C9/#4684 因待裁决未落地,故口径是 19 不是 17),本簇目标 19 → 18。

本簇大概率是三簇里最简单的一簇 —— const 本来就是单源

已在 origin/main(f2445c9)复核:

位置	内容
ui/view.zod.ts:21	import { HttpMethodSchema, HttpRequestSchema } from '../shared/http.zod';
ui/view.zod.ts:37	export { HttpMethodSchema, HttpRequestSchema }; —— 原样 re-export
ui/view.zod.ts:2039	export type HttpRequest = z.infer<typeof HttpRequestSchema>; ← 唯一的双源点
shared/http.zod.ts:46	HttpRequestSchema 唯一声明;:54 export type HttpRequest = z.infer<...>

HttpRequestSchema 从来就没有第二份声明 —— ui 是 import 进来再 re-export 的,所以基线里没有 HttpRequestSchema 行。被判为双源的只有那个本地 type 别名:它 z.infer 的正是同一个 schema 对象,只是构成了第二个类型声明符号。基线文件表头说明了判据:

judged by symbol identity (a re-export of one declaration from many entries is fine and not listed)

所以处置就是把 :2039 那行从「本地 infer」改成「re-export shared 的类型」,让它变成表头说的 "a re-export of one declaration" 从而不再被记。

零 authorable key 消失、零 tombstone、零 conversion —— 本簇不触发 C9(#4684)撞上的那个门禁死结(那是 def 改名导致 ratchet 认为 key 消失;本簇不改任何 def、不动 HttpRequestSchema)。

⚠️ 必须保持 ui 侧仍然导出这个类型

ui/view.test.ts:39 有 type HttpRequest 从 ./view.zod 的具名导入。删掉别名而不补 re-export 会打断它,这是本簇唯一的现实风险。export type { HttpRequest } from '../shared/http.zod'; 之类的写法可保持导入点不变 —— 具体形式由你定,但要保证 from './view.zod' 导入该类型的既有写法继续可用。

⛔ 不要顺手修隔壁的 HttpMethod

ui/view.zod.ts:2040,紧挨着的下一行,是形状完全相同的 export type HttpMethod = z.infer<typeof HttpMethodSchema>;。它的基线行是 HttpMethod — [./api, ./shared (type)] ≠ [./ui (type)],#4535 已把它排进 v18(不在元数据文档管道上)。

诱惑很大且改动几乎零成本,但范围是维护者定的,不是就手方便定的。本簇只清 1 条。若你确认它确实是同一形状,写进 PR 描述与 out-of-scope findings,让维护者决定要不要并进来 —— 不要自己扩。

关于 breaking 级别:自己判,不要为了凑 major 而声称破坏

#4535 把三簇统称 breaking,但本簇需要你自己核实:两个别名从同一个 schema 对象 infer,结构上应当完全相同,消费者侧可能是零类型差异。changeset 级别按实际情况定并在正文说清理由。若确认零消费者影响,不要硬写成 major —— 谎报破坏和漏报破坏一样是污染升级指南。(反之若你发现两者其实不同,那是重要发现,写清楚。)

纪律(#4535 §1–§4 + 手册 6/7/8,开工前必读)

1. ⛔ 禁止手编 packages/spec/authorable-surface.json(authorable-surface 的 tombstone 门禁可被手编基线绕过 —— 删掉基线行就删掉了证据(#4638 / #4643 已两次这样过绿) #4650)。
2. ⚠️ 门禁绿 ≠ 登记正确(build-schemas.ts 检查 (b) 用叶名匹配 conversion surface —— 无关簇的 .type 就能让一个 tombstone 冒充「已登记迁移」 #4659);默认值 / 约束变更不被任何门禁记录(spec 门禁盲区:可作者化 key 的「默认值 / 约束」变更不被任何 gate、tombstone 或 conversion 记录(#4650 / #4659 同族) #4666) —— 本簇若真是纯类型别名改动,这两条应当不触发,但要自己确认而不是假定。
3. 回归 pin 用运行时模块命名空间断言(packages/spec 的「编译期 pin」是失效的:tsconfig 排除了 *.test.ts,vitest 也不做类型检查 #4642 已证编译期 pin 空转),必须 sabotage 验证并贴输出。
4. 判不出来就升级,不要猜(spec 双源清账 C5:ActivationEventSchema(./kernel ≠ ./studio)—— 1 条 #4653 / spec 双源清账 C6:EventSchema(./automation ≠ ./kernel)—— 1 条 #4658 / spec 双源清账 C8:RetryPolicy / RetryPolicySchema(./automation ≠ ./system)—— 2 条 #4661 / spec 双源清账 C9:RateLimitConfig / RateLimitConfigSchema(./integration ≠ ./shared)—— 2 条 #4684 先例)。分析本身就是交付物。
5. ⚠️ 生成物冲突只能靠重新生成(手册第 7 条)。v17 收尾期 main 前进很快 —— 推之前重新 git fetch origin main 判一次;spec-changes.json 是对象数组,必须跑 gen:spec-changes,集合合并会丢条目并把 CI 打红。解完冲突务必本地跑对应 check:* 再推。
6. ⛔ 不要碰 content/docs/releases/。
7. ⛔ 不要碰门禁洞 issue(spec 门禁盲区:可作者化 key 的「默认值 / 约束」变更不被任何 gate、tombstone 或 conversion 记录(#4650 / #4659 同族) #4666 / authorable-surface 的 tombstone 门禁可被手编基线绕过 —— 删掉基线行就删掉了证据(#4638 / #4643 已两次这样过绿) #4650 / build-schemas.ts 检查 (b) 用叶名匹配 conversion surface —— 无关簇的 .type 就能让一个 tombstone 冒充「已登记迁移」 #4659 / authorable-surface.json 在 main 上不是 gen:schema 的输出 —— 基线手编的字节级实锤(#4650 加固建议) #4663 / packages/spec 的「编译期 pin」是失效的:tsconfig 排除了 *.test.ts,vitest 也不做类型检查 #4642 / spec 生成物没有 merge driver:两个 PR 各改几行,语义上是集合运算,却每次都打成文本冲突 #4675 / 投影类生成物是否该退出仓库 —— 分清「记忆」与「投影」,前者必须留在 PR 粒度,后者可以 CI 重算 #4676),它们等维护者排期。

验收

• 基线删掉上面 1 行,19 → 18,只减不增。
• 全绿:build、check:dual-source-exports、check:generated、test,加源码审计组(check:liveness / check:strictness-ledger / check:empty-state / check:variant-docs / check:exported-any / check:skill-examples),以及全仓 pnpm typecheck。
• ui/view.test.ts 的既有具名类型导入继续可用。
• changeset 一份,级别按上面「自己判」一节的结论定,含 FROM → TO(若确有消费者可见变化)。
• 注意 spec 现为 17.0.0-rc.1、pre-mode 仍开。

关联:#4535(主单)、#4684(C9,待裁决 —— 其门禁死结不适用于本簇)、#4650 / #4659 / #4666(门禁洞)、#4642(pin 空转)、#4675(生成物冲突)、ADR-0049、ADR-0087、ADR-0104

[os-zhuang]

认领:PM 循环第 2 轮(#4535 v17 串行三簇之第 2 簇)
会话:session_0176qgxgCXTJCUv4YFLtusP9
分支:claude/issue-4688-http-request-dual-source
Worktree:objectstack-issue-4688

为什么 C9 未落地就派 C11(串行纪律未被违反)

串行的理由是并发 spec PR 争抢同一批生成物。C9(#4684)返回 needs_decision,零提交、零推送、worktree 已清理、无远端分支 —— 没有在途 spec PR,串行车道是空的。本单是当前唯一在跑的 spec 簇。

依据是本主单自己的先例:C5 卡裁决时 #4535 写的是「C5 保持未开工。流水线不停 —— 继续按序推 C6」。

基线口径随之改变:C9 未兑现,故本簇是 19 → 18,不是 17 → 16。已写进正文。

派发前已核对(against origin/main @ f2445c9)

项	结果
时效窗口	✅ mode: pre / tag: rc,spec 17.0.0-rc.1
基线现状	✅ 实测 19 条,HttpRequest — [./shared (type)] ≠ [./ui (type)] 在列;无 HttpRequestSchema 行(const 本来单源)
双源点定位	✅ 唯一在 ui/view.zod.ts:2039 的本地 type 别名;:21 import + :37 re-export 的 schema 是同一个对象
下游影响面	✅ ui/view.test.ts:39 有 type HttpRequest 具名导入,必须继续可用
认领竞争	✅ 本单由本会话新建,无其他 session claim

在途 spec PR(接手 agent 注意)

#4677 已合并进 main(f2445c9)。仍在途:#4685(api/events.zod.ts)、#4680(size/l,动 authorable-surface.json / spec-changes.json / ADR-0087 登记表)、#4683(client-react,原 stacked 在 #4677 上)。与本簇源文件不重叠,但生成物可能重叠 —— 按手册第 7 条,推之前重新 fetch 判一次,spec-changes.json 冲突只能跑生成器。

---

Generated by Claude Code

[os-zhuang]

PM 复核:ACCEPT —— PR #4689 已入合并队列

会话 session_0176qgxgCXTJCUv4YFLtusP9,PM 循环第 2 轮。复核是对着 GitHub 与仓库实际内容做的,不是采信 PR 自述。

验收项	复核结果
PR 形态	✅ base main,body 首行 Fixes objectstack-ai/objectstack#4688
改动范围	✅ 4 个文件、+170/−2:changeset、基线、ui/view.zod.ts、ui/view.test.ts。无越界文件
⛔ content/docs/releases/	✅ 未触碰
基线只减不增	✅ diff 仅删 HttpRequest 一行;HttpMethod 行原样保留(未被顺手清掉)
范围纪律	✅ HttpMethod 未动,按要求写进了 PR 描述交维护者定夺
changeset	✅ 存在,@objectstack/spec patch
CI	✅ 6/6 全绿(CI · Lint & Type Check · Spec Liveness Check · Docs Drift Check · PR Automation · Duplicate Fix Guard),mergeable_state: clean

对「定级 patch 而非 major」的复核意见:同意

派发单要求「自己判,不要为了凑 major 而声称破坏」,实施者据此定为 patch,依据是 FROM/TO 从同一个 schema 对象 z.infer,并用 Equal<> 恒等断言 + 负对照证明断言非空转(只有负对照报 TS2344)。旁证是 api-surface.json / authorable-surface.json / spec-changes.json 三份生成物零改动。

这个判断是对的:类型逐字段相同,消费者无迁移动作。#4535 把三簇统称 breaking 是主单层面的粗粒度表述,不构成对本簇的定级要求 —— 谎报破坏会污染升级指南,与漏报同样有害。

值得记一笔的工程质量

第三条回归 pin 用 TypeScript compiler API 在 src/ 上做符号身份解析,补的正是 #4642 指出的洞:HttpRequest 是类型,运行时不可见,而它是本簇唯一改动的东西 —— 该文件顶部既有的 type HttpRequest 具名导入被 vitest transform 抹掉,从来就没保障过这个导出还在。断言里还带了 expect(moduleSym).toBeTruthy() 的防空转守卫(解析失败会让后续断言全部真空通过,正是门禁休眠的经典形态)。三条 pin 均贴了 sabotage 实测输出。

后续(串行,合并后才做)

PR 落地后:勾 #4535 的 C11 项、基线数字更新为 18、再立 C12 FieldMapping(三源)的子 issue 并派发。C11 未合并前不派 C12 —— 并发 spec PR 争抢生成物正是主单记录过三次返工的成因。

---

Generated by Claude Code