方法注册表

先看当前可见能力 #

请使用 artifact-chain-help 展示可用的 Family API 和采用步骤，不要修改项目。

Family API Catalog 来自插件自带文件，Registry 缺失时静态能力仍可展示。动态安装状态在 Registry v2 verifier 未接入时显示为不可用，不得把候选清单写成已验证提供方。

配置是否合法，仍用图入口核对：

artifact-graph validate --root . --warning-only
artifact-graph contract list --format json

Registry 管五件事 #

• 身份：每个方法提供方有稳定标识，重试和审计都能对准同一个提供方。
• 清单：登记有哪些方法、各自提供什么能力。宿主发现的插件只能形成候选，不能直接当成可信提供方。
• 绑定：把能力名映射到具体实现。默认整族原子绑定，避免 author 来自实现 A、review 来自不兼容实现 B。
• 投影：按调用方视角裁剪暴露的方法；从 API、实现与可信清单确定性生成。
• 运行期选择：一次运行内，同名方法不许中途替换。安装插件不得自动改写已有项目的有效绑定。

本仓 where-am-i 生成 Method Query candidate，把已解析的绑定对象交给 Registry 的 buildEffectiveIndex 与 queryEffectiveIndex。下游消费返回的 serviceId、apiId、apiMajor 及原生选择状态。

为什么需要它 #

同一项目可能同时看到开源实现与内部实现，两者都提供同名能力。没有注册表时，今天走到开源、明天走到内部，结果不可复现。有了 Registry：身份区分两个提供方；绑定按项目配置锁定整族实现；运行期选择保证这次运行始终路由到同一实现；投影避免规划器调到未验证的候选。

和图内核的关系 #

Registry 与 artifact-graph 的图结构正交：图管制品与关系，注册表管能力提供方。两者不互相导入内部实现。缺绑定时保留 Registry 原始不可执行状态；help 与单纯图检查不受影响。

从需求到正文、测试与独立审阅 #

ACA 设计开发在正向与反向路径中，均在确定验证范围、接受或停止时实际加载所选测试 plan 及方法并返回真实计划。P0 默认使用 TEST0.2.0 skill-family-test-plan；codex/claude-code 的 P1 则通过 Registry 0.2.0 v1 读取同一项目原选择，严格验证默认 TEST、项目自有 Skill 或明确采用的外部插件，失败不回落。仅当存在对象、已接受计划、输入、原判据与执行授权时，才实际衔接所选 run。反向前置条件不齐者维持讨论状态，不设未来执行结果前置；仅收集查询，不强制触发 TEST。入口缺失保留缺口，普通盘点与信息收集持续进行。其他宿主保持原合同，不宣称 P1 全宿主支持；现有 contract-backed v2 仍维持原合同，动态未验证前不冒称可用。

artifact.requirement.manage 沿原需求入口执行保存、查询、处置与迭代承接；artifact.spec.author 仅在必要正文、关系与适用评审完成后生成正式 SPEC 与执行输入。artifact-generate 初始化模板后，作者按分型方法完成实际领域正文，再验证最终目标；artifact-review 由具备不同职责的成员真实审阅全文，将语义 Review Result 交由公共 worker 关联证据。模板、清单、目录或脚本退出码均不可替代正文与独立判断。