mino-interface-implementation-separation

接口／实现分离

结果约定

分离 consumer 所需的目的、操作和契约与内部技术和步骤，并判断是否存在泄漏或过度抽象。如果已请求修正，且公开语义和范围已确定，则继续完成更改和验证。 权威 package 的根目录是boundary_package。 适用 mode：design、review、implementation。

参考资料路由

• 首次使用时读取skills/mino-core/references/shared-policies.md，并遵循其中的 Evidence、审批和判定规则。同一 context 中已读过则无需重读。通常的判断依据是正文和这些通用规则。
• 更改 code 的职责或命名时，读取skills/mino-core/references/code-design.md；更改现有行为或公开契约时，读取skills/mino-core/references/change-safety.md，并据此落实具体更改和验证。
• 涉及目标 system 的 file/process/test 执行或多 OS 要求时，读取skills/mino-core/references/platform-compatibility.md，区分 host、目标和验证层。仅保存回答记录时无需额外读取。
• 仅在收到创建、更新或交接权威 package 的请求时，读取skills/mino-interface-implementation-separation/schemas/package.md，并保留必填 field 和实际存在的引用。

工作流

1. 根据 caller、公开契约、code、依赖、质量和实际存在的 variant，对 domain 判断、use-case 调整、持久化、外部 I/O、表现和运维进行分类。不要因局部 guard 的问题而要求提供整个 system 的 package。
2. 明确 consumer 的 purpose、must_know、must_not_know，以及 operation 的输入、结果、失败、副作用和不变量。若有适用的 domain 契约，则引用现有 Contract。对于通用技术边界，使用附有理由的 N/A 和 consumer semantic operation，不要臆造业务。
3. 针对每个 operation，分别将 end_to_end_deadline、retry_semantics、idempotency、duplicate_semantics、ambiguous_outcome 标记为 applicable / not_applicable / unknown。明确 deadline 的上限、owner 和超时结果；retry 的允许／禁止条件和 owner；idempotency／duplicate 的重复结果和 owner；以及模糊结果的观测结果和核对／恢复 owner。
4. 为 N/A 记录理由和 Evidence；为 unknown 记录确认方法和影响。不要将不适用的语义 field 留空展开。不要仅因名称为 pure/read-only 就将所有项标为 N/A，应检查外部依赖和要求。只有存在必要依据时才定义幂等性 key。
5. 将 SDK 类型、DB row、framework 类型、provider 步骤、serialization、cache、algorithm、backoff 和单次尝试的 timeout 放在实现侧。将 consumer 判断所需的 retry、重复和模糊结果语义保留在公开面。依赖方向应为 consumer 使用契约，adapter 负责实现。
6. 对 semantic/invariant/contract/state/source-of-truth/failure-recovery/operational owner，引用现有 authority；不要重新确定整个 system 的权威来源或保证条件。
7. 仅为实际存在的 variant 设置 selection boundary。即使只有一种实现，只要有隔离外部故障或稳定契约的依据，也可以使用小型 port。保持简短的 guard，不要创建面向未来的 factory 或层级。区分状态、规则、实现 variant 和临时 flag 分支。
8. 使用 pass / fail / not_applicable / unknown 和 Evidence 评估适用的实现替换、实际存在的 variant 新增／变更及业务规则变更场景。仅在更改现有 caller 或公开契约时，才设置 consumer 列表、兼容 window、分阶段迁移、恢复方案，以及对旧 path 使用量归零的观测。

硬性门槛

• 不要将 if 数量或 interface 数量视为质量标准。将 state、判断和更新集中到承担相同目的与不变量的职责中，并检查能否通过所有 public writer 阻止非法状态。
• 只有在目的、契约和变更理由一致时才进行共用。不要保留掩盖不同语义的抽象或向 caller 泄漏技术细节的设计。
• 不要凭假设确定语义不明之处。不要将计划中的临时 path 当作已引入，也只引用实际存在的 TMP ID。

完成状态

语义与内部实现已分离时，判为 separated；存在技术泄漏或职责错误时，判为 leaky；存在缺乏依据的抽象时，判为 overabstracted；不需要应用时，判为 not_applicable；存在重要未确认事项时，判为 indeterminate。保留并存的 finding，并区分目标 verdict 与当前 artifact 的完成情况。