Repository navigation
spec: route-ledger entry 类型加可选 responseSchema 字段(#3877 最小首步,维护者 2026-08-06 已批) #5791
Description
Part of #3877(维护者批文见该单 2026-08-06 裁决评论)。devx 车道 PM 按跨分片协议立单转 spec 座位,未认领。
任务
给 route-ledger entry 类型(5 个 route ledger 共用的条目形状)加可选 responseSchema 字段:
- 只加类型位,不做批量填充——Response bodies are never checked against the schemas that declare them — staged plan, not a repo-wide sweep #3877 已裁定 Stage C(批量补 ~190 条无声明路由)永不排期;字段随 Stage A 各族落地与路由被触碰时增量填。
- 它把「这条路由声明了什么响应」变成可查询数据,是 Stage D 棘轮的前置;字段缺省即「未声明」,不改变任何现有行为。
验收
- 类型编译过;5 个 ledger 现有条目零改动(字段可选);
- 至少给 discovery 族已落地的 2 条路由(PR feat(spec,runtime,metadata-protocol)!: discovery 两个生产者统一到一个 schema —— capabilities 正名、features/endpoints 退役、scoping 声明 (#4828) #5682 的面)填上引用,作为字段可用性的实证;
- 不引入「声明了但没人验证」的新面——填了
responseSchema的路由应当已有(或同 PR 补上)feat(spec,runtime,metadata-protocol)!: discovery 两个生产者统一到一个 schema —— capabilities 正名、features/endpoints 退役、scoping 声明 (#4828) #5682 双断言口径的一致性覆盖,否则宁可不填。
关联
#3877(程序卡)、PR #5682(discovery 族一致性测试,双断言口径出处)、#5679(嵌套键同病,Stage D 递归收严时的第一个红)。
Activity
os-zhuang commentedon Aug 6, 2026
打包建议（致 spec 座位）：本单与 #5185（ProvisionEnvironmentResponse 补
hostnameAssignment）、#5767（OWNING_BUSINESS_UNIT_ID 声明同步）同为小型补键/声明同步族，建议同一接力棒内派发，摊薄四步重建 + CI 圈的每单固定成本。背景：维护者 2026-08-06 拍板 spec 车道缩盘方案，见 #5837。Generated by Claude Code
hotlong commentedon Aug 7, 2026
Release-board audit (maintainer-directed re-audit of non-board
domain:specitems, 2026-08-07): addingtarget:v17— metadata-protocol change, size S, low-risk: maintainer-approved (#3877 first step) optionalresponseSchemafield on the route-ledger entry type; additive-only, existing entries unchanged, zero behavior change. Maintainer directive: protocol changes land in v17 unless large/risky. Triage seat may veto.Generated by Claude Code
feat(runtime,rest,plugin-auth,service-i18n,service-storage): route-le…