处理 #4480 (删除 integration/connector/* 六文件簇)时定级,发现"connector"这个业务需求在 spec 里被声明了三次 。#4480 删掉了第二份,这是第三份。
三份声明的关系(#4480 已查实的部分) 位置 状态 integration/connector.zod.ts(ADR-0097)活 —— engine.registerConnector() 在 service-automation/engine.ts:1379 用它校验;stack connectors: 集合走 DeclarativeConnectorEntrySchema(stack.zod.ts:395);GET /connectors 和 connector_action 跑在它上面integration/connector/*.zod.ts 六文件已删 (#4480 )automation/trigger-registry.zod.ts 的 Connector 簇本 issue —— 零运行时消费者
证据 automation/trigger-registry.zod.ts 导出一整套连接器词汇(~440 行):ConnectorSchema、ConnectorCategorySchema、AuthenticationSchema/AuthenticationTypeSchema/AuthFieldSchema/OAuth2ConfigSchema、OperationTypeSchema/OperationParameterSchema/ConnectorOperationSchema、ConnectorTriggerSchema。
引擎导入的是另一份 :service-automation/engine.ts:26 — import { ConnectorSchema } from '@objectstack/spec/integration'。automation 这份从未被任何注册/校验路径引用全仓 grep 这个簇的各 schema 名(排除 spec 自身与 dist):spec 之外的命中只有生成文档 (build-docs.ts 的 Flow & Execution 章节列表、build-skill-references.ts)——都是发布渠道,不是消费者 名字撞车但形状不同:integration 版有 provider/providerConfig/auth(ADR-0097 实例语义);automation 版是 category/authentication/operations/triggers/rateLimit —— 一套自成体系、没接任何执行器的词汇 integration/connector.zod.ts 的头注释还有一节 "When to use Integration Connector vs. Trigger Registry?" ,在教用户选择一个没接线的选项 —— 和 datasource 是注册的 metadata type,却不在 liveness 账本的 GOVERNED 里 —— 两个 PR 手工挖出 6 个死键,正是因为没有闸门看着它 #4487 修掉的 capabilities.readOnly 处方同一种病:平台权威口吻指向死角定级注意(别照搬 #4480 的结论) trigger-registry.zod.ts 可能不止 Connector 簇 —— 文件里如果还有 trigger 注册表相关的其他 导出被 flow/automation 侧使用,需要逐个甄别,不能整文件删。生成文档侧还牵涉 build-docs.ts Flow & Execution 章节的页面列表和 build-skill-references.ts:82 的显式引用,两处都要跟着改。
处置倾向 remove (Connector 簇部分)。业务需求已由 ADR-0097 活路径承担;留着第三份拼写违反 Prime Directive #12 (one capability, one contract)。顺带删掉 connector.zod.ts 里指向它的 "When to use" 对比段。
按 .claude/skills/spec-property-retirement 走:这是导出面(非存储元数据),预计与 #4480 同型 —— manifest / authorable-surface 基线删行、生成文档重算、v17 dead-clusters 表、major changeset;无 D2 conversion(没有 stack 源可改写)。
参考 未指派 —— 记录 finding,谁开工谁认领(AGENTS.md 惯例)。
处理 #4480(删除
integration/connector/*六文件簇)时定级,发现"connector"这个业务需求在 spec 里被声明了三次。#4480 删掉了第二份,这是第三份。三份声明的关系(#4480 已查实的部分)
integration/connector.zod.ts(ADR-0097)engine.registerConnector()在service-automation/engine.ts:1379用它校验;stackconnectors:集合走DeclarativeConnectorEntrySchema(stack.zod.ts:395);GET /connectors和connector_action跑在它上面integration/connector/*.zod.ts六文件automation/trigger-registry.zod.ts的 Connector 簇证据
automation/trigger-registry.zod.ts导出一整套连接器词汇(~440 行):ConnectorSchema、ConnectorCategorySchema、AuthenticationSchema/AuthenticationTypeSchema/AuthFieldSchema/OAuth2ConfigSchema、OperationTypeSchema/OperationParameterSchema/ConnectorOperationSchema、ConnectorTriggerSchema。service-automation/engine.ts:26—import { ConnectorSchema } from '@objectstack/spec/integration'。automation 这份从未被任何注册/校验路径引用build-docs.ts的 Flow & Execution 章节列表、build-skill-references.ts)——都是发布渠道,不是消费者provider/providerConfig/auth(ADR-0097 实例语义);automation 版是category/authentication/operations/triggers/rateLimit—— 一套自成体系、没接任何执行器的词汇integration/connector.zod.ts的头注释还有一节 "When to use Integration Connector vs. Trigger Registry?",在教用户选择一个没接线的选项 —— 和 datasource 是注册的 metadata type,却不在 liveness 账本的 GOVERNED 里 —— 两个 PR 手工挖出 6 个死键,正是因为没有闸门看着它 #4487 修掉的capabilities.readOnly处方同一种病:平台权威口吻指向死角定级注意(别照搬 #4480 的结论)
trigger-registry.zod.ts可能不止 Connector 簇 —— 文件里如果还有 trigger 注册表相关的其他导出被 flow/automation 侧使用,需要逐个甄别,不能整文件删。生成文档侧还牵涉build-docs.tsFlow & Execution 章节的页面列表和build-skill-references.ts:82的显式引用,两处都要跟着改。处置倾向
remove(Connector 簇部分)。业务需求已由 ADR-0097 活路径承担;留着第三份拼写违反 Prime Directive #12(one capability, one contract)。顺带删掉
connector.zod.ts里指向它的 "When to use" 对比段。按
.claude/skills/spec-property-retirement走:这是导出面(非存储元数据),预计与 #4480 同型 —— manifest / authorable-surface 基线删行、生成文档重算、v17 dead-clusters 表、major changeset;无 D2 conversion(没有 stack 源可改写)。参考
capabilities.readOnly假处方的先例未指派 —— 记录 finding,谁开工谁认领(AGENTS.md 惯例)。