越范围发现,记录于 #5310 (path 的 .describe() 举例被 ADR-0121 D1 拒)实现期。不在该 PR 内修 —— #5310 的判据是「举例失实」,下面三处不是举错例子,而是「文案推销的能力,门整键拒绝」,是另一类问题;其中一处还要连带动 packages/runtime。
事实
packages/spec/src/api/endpoint.zod.ts 里三处文案,描述的都是 endpoint-publish-gate.ts 会整键拒绝 的东西:
文案
门怎么判
type: z.enum(['flow','script','object_operation','proxy']).describe('Implementation type')
targetGate:Only 'object_operation' and 'flow' endpoints execute in 17.x,script / proxy 一律拒
target: z.string().describe('Target Flow ID, Script Name, or Proxy URL')
文案里三选项中的两个(Script Name、Proxy URL)对应的 type 都会被上面那条拒掉
transform: z.string().optional().describe('Transformation function name')
mappingGate:There is no transformation-function registry anywhere in the platform,声明即拒
为什么和 #5310 是同一个要紧的理由
#5271 之后 api 是注册元数据类型,这些 .describe() 成为 metadata-admin 端点表单的字段说明,并进入生成的 JSON Schema。作者(按 ADR-0033,常常是 AI 作者)照着表单里「Target Flow ID, Script Name, or Proxy URL 」写一个 proxy URL,publish 才告诉他这条路不存在 —— 一次可以在授权时 就避免的往返。
门的拒绝文案本身写得很好(点名事实、给出处方),所以这不是「作者被卡死」,而是「词表在邀请一个它自己会拒的写法」。
为什么不是简单改掉就完事(需要裁决,不要预判)
词表是冻结的 (17.x 立项:建设声明式 ApiEndpoint 执行器(挂载 + matchEndpoint + authRequired/cacheTtl/inputMapping/outputMapping 逐键接线) #5040 )。script / proxy / transform 是故意留在词表里、在门上响亮拒绝 的 —— targetGate 明说 Both stay in the vocabulary and are rejected here rather than parsed and ignored。所以问题不是「删掉」,而是「一个被冻结保留、当前被拒的键,该不该在作者表单里自陈『暂不可用』」。这是产品面裁决,不是打字错误。
transform 的文案是被引用的规范来源。 packages/runtime/src/api-mapping.ts 的词表小节把五条 .describe() 逐字 列成表格,并声明「everything below is the MINIMAL faithful reading of them」。改 transform 的文案必须同批改那张表,否则运行期的最小忠实解读引用了一段不存在的文本 —— 文件面会从 packages/spec 扩到 packages/runtime。
可能的方向(不预判,列给裁决)
A :文案原样,靠门的拒绝文案兜底(现状)。成本零,代价是表单持续邀请被拒写法。
B :三处文案各加一句「17.x 尚不执行,publish 会拒」,措辞复用门的拒绝文案。要同批更新 packages/runtime/src/api-mapping.ts 的引用表格 + 重生成 content/docs/references/api/endpoint.mdx。
C :更进一步,让表单层按门的判据把这些取值置灰/标注 —— 落在 objectui,范围远大于文案。
倾向 B(在授权时结构性地防错,而不是靠消费端容忍),但 A/B 之间取舍取决于维护者对「冻结词表里的被拒键要不要自陈」的态度,故不在 #5310 里替裁决。
关联
#5310 (出处,已修 path 的举例)、#5271 、#5040 E7、ADR-0121 D1、ADR-0049 declared-vs-enforced。
越范围发现,记录于 #5310(
path的.describe()举例被 ADR-0121 D1 拒)实现期。不在该 PR 内修 —— #5310 的判据是「举例失实」,下面三处不是举错例子,而是「文案推销的能力,门整键拒绝」,是另一类问题;其中一处还要连带动packages/runtime。事实
packages/spec/src/api/endpoint.zod.ts里三处文案,描述的都是endpoint-publish-gate.ts会整键拒绝的东西:type: z.enum(['flow','script','object_operation','proxy']).describe('Implementation type')targetGate:Only 'object_operation' and 'flow' endpoints execute in 17.x,script/proxy一律拒target: z.string().describe('Target Flow ID, Script Name, or Proxy URL')type都会被上面那条拒掉transform: z.string().optional().describe('Transformation function name')mappingGate:There is no transformation-function registry anywhere in the platform,声明即拒为什么和 #5310 是同一个要紧的理由
#5271 之后
api是注册元数据类型,这些.describe()成为 metadata-admin 端点表单的字段说明,并进入生成的 JSON Schema。作者(按 ADR-0033,常常是 AI 作者)照着表单里「Target Flow ID, Script Name, or Proxy URL」写一个 proxy URL,publish 才告诉他这条路不存在 —— 一次可以在授权时就避免的往返。门的拒绝文案本身写得很好(点名事实、给出处方),所以这不是「作者被卡死」,而是「词表在邀请一个它自己会拒的写法」。
为什么不是简单改掉就完事(需要裁决,不要预判)
script/proxy/transform是故意留在词表里、在门上响亮拒绝的 ——targetGate明说Both stay in the vocabulary and are rejected here rather than parsed and ignored。所以问题不是「删掉」,而是「一个被冻结保留、当前被拒的键,该不该在作者表单里自陈『暂不可用』」。这是产品面裁决,不是打字错误。transform的文案是被引用的规范来源。packages/runtime/src/api-mapping.ts的词表小节把五条.describe()逐字列成表格,并声明「everything below is the MINIMAL faithful reading of them」。改transform的文案必须同批改那张表,否则运行期的最小忠实解读引用了一段不存在的文本 —— 文件面会从packages/spec扩到packages/runtime。可能的方向(不预判,列给裁决)
packages/runtime/src/api-mapping.ts的引用表格 + 重生成content/docs/references/api/endpoint.mdx。倾向 B(在授权时结构性地防错,而不是靠消费端容忍),但 A/B 之间取舍取决于维护者对「冻结词表里的被拒键要不要自陈」的态度,故不在 #5310 里替裁决。
关联
#5310(出处,已修
path的举例)、#5271、#5040 E7、ADR-0121 D1、ADR-0049 declared-vs-enforced。