模块 XIV — 内部目录与市场
模块 XIV 是组织的内部目录（internal catalog）——一个经过策展、受治理的注册库， 收录已被批准供复用的智能体、MCP 服务器、技能、模板、模型与第三方连接器（connector）， 覆盖整个公司。它的存在是为了让一份资产清单（estate）标准化地采用经审核、带版本的能力，而非临时拷贝， 也为了让”已批准”意味着某种可验证的东西，而不只是 wiki 里的一个词。它位于智能层，且没有驱动面： 它进行策展和记录，而供给（provisioning）发生在别处。
该目录是一个注册库（registry），不是文档存储。一个条目（entry）是对一项可复用能力的、经策展的、带版本的单一定义，
其类别（kind）为 agent、mcp、skill、template、model 或 connector。每个 (kind, slug, version) 都是其自身的不可变产物
——发布一个新版本会创建一个新条目，而批准与签名是逐版本进行的。一个条目历经一个固定的生命周期：
draft → pending → approved → deprecated
只有 draft 是可变的；批准会将其冻结。一个条目的规约（spec）是一份操作员撰写的定义——传输、模型与提示词引用、范围， 以及对机密的引用——绝非凭据值本身。创建/批准路径会拒绝携带内联凭据的规约， 因此该模块存储的是定义、引用与治理元数据，从不存储机密或载荷。
赋版、冻结与签名
Section titled “赋版、冻结与签名”批准是”已批准”变得可验证的地方：
- 内容哈希。 批准时，条目被一个对其规范化、确定性序列化的原像（preimage）计算出的 SHA-256 内容哈希所固定。 每一个操作员撰写的字段都被覆盖，因此对一个已批准条目的任何后续篡改都是可被检测的——即便没有签名也能察觉篡改。
- 账本证明。 批准被记录到仅追加、哈希链式的审计账本（audit ledger）中，归属于批准它的真实主体（real principal）。
- Ed25519 签名。 当配置了目录签名密钥时，批准还会对内容哈希产生一个分离式（detached）Ed25519 签名， 携带公钥和一个短指纹——“已批准 = 可验证”。签名密钥在引擎的 fail-closed 密钥接缝下于启动时加载或铸造， 独立于审计账本密钥；该模块拥有自己的目录密钥，从不触及引擎内部的审计签名器，从而保持信任边界的洁净。
验证会重新计算哈希，并且当节点上配置了密钥时，将签名视为信任锚（trust anchor）：
一个被剥除的签名（降级攻击）或由任何其他密钥所做的签名（替换攻击）都会被报告为未验证（not verified）。
GET …/pubkey 报告签名是否启用；逐条目的 verified / signed / signed_by 状态由条目路由和验证路由返回。
经验证的第三方连接器
Section titled “经验证的第三方连接器”一个 connector 条目策展一个已发布的第三方连接器插件——一个已构建的二进制或 OCI 产物。
其规约记录它所策展的内容：该产物的 sha256（artifact_digest）、发布/OCI 引用、发布者，以及连接器的描述符名称。
该条目是外部连接器生态系统面向租户的认证记录（certification record）：
“已批准”可以被赋予”其供应链证明已被验证”的含义，而不只是”有人点了批准”。
该流程镜像 MCP 条目的准入对，拥有自己的策略与裁决记录（证据是逐类别计数的，因此连接器裁决从不与 MCP 裁决共享表）：
GET/PUT …/connector-admission/policy— 逐租户的信任根：require_signed、可选的require_subject_digest、Sigstore 身份/签发者固定项、裸公钥、CA 根， 以及 in-toto 谓词允许列表（predicate allow-list）（默认为 SLSA provenance v1/v0.2 和 SPDX/CycloneDX SBOM ——即 provenance 与 SBOM 形态，因为连接器是一个已构建的产物，而非模型权重）。没有策略则意味着观察模式（observe mode） ——在租户主动选择加入之前不设门，且策略端点会诚实地如此声明。POST …/entries/{id}/admit— 一条共享路由，按条目类别分派（mcp或connector）： 验证操作员提供的 Sigstore 证明捆绑包，并为每个条目记录一个声称对已验证（claim-vs-verified）裁决。 当请求未固定expected_digest时，绑定从条目的spec.artifact_digest默认取值—— 条目命名了它所策展的产物，因此除非被显式覆盖，准入将绑定到该产物。一个格式错误的捆绑包是400； 一个格式良好但验证失败的捆绑包是一个已记录的负面裁决，而非一个错误。GET …/connector-admissions— 已记录的裁决，可按条目（entry_ref）过滤，并可限定为已验证的裁决（verified=true）。- Deny-closed 批准门。 在
require_signed开启时，一个连接器条目只有在拥有一个绑定到该条目当前所策展摘要（spec.artifact_digest） 的、已验证的 provenance/SBOM 准入裁决时，才能被批准（并因此被列为一个已验证连接器）； 在require_subject_digest开启时，那个产物绑定本身也必须被确认。在准入之后编辑被策展的摘要会使该门失效 ——需要针对新产物重新准入。
受治理的自助式实例化
Section titled “受治理的自助式实例化”一个实例（instance）是一个将一个已批准条目实例化的自助式请求——只有已批准的条目才能被实例化。
该模块记录该请求、它的来源（provenance）（它来自哪个条目版本）、它的目标及其治理状态，
并强制执行一个合理的状态机（requested → approved/rejected → active）。它不决定谁可以批准，
也不进行供给：批准决定属于治理，实际供给属于部署。批准、弃用、签名与实例化都是特权的、受 RBAC 设门的、
并自审计到真实主体的操作。