mino-design-by-contract

Design by Contract

Outcome Contract

将需求转化为可观测条件、各条件的保证责任、失败后的状态，以及能够识别错误实现的契约测试。implementation 创建并运行所请求的契约测试。 权威 package 的根目录为 contract_package。 适用 mode：design、review、implementation。

Reference Routing

• 首次使用时阅读 skills/mino-core/references/shared-policies.md，并应用 Evidence、审批和判定规则。同一 context 中已读过则无需重读。通常的判断依据正文和此共通规则。
• 变更现有行为或公开契约时，阅读 skills/mino-core/references/change-safety.md，并制定 baseline、变更 step 和恢复条件。
• 涉及目标 system 的 file/process/test 执行或多 OS 要求时，阅读 skills/mino-core/references/platform-compatibility.md，区分 host、目标和验证层。仅保存答复记录时无需额外阅读。
• 仅在受托创建、更新或移交权威 package 时，阅读 skills/mino-design-by-contract/schemas/package.md，并保留必填 field 和实际存在的引用。

Workflow

1. 使用需求、model、现有契约、code/test 和 obligation，将变更分为 must-preserve / intentional-change / unknown。不要将未提供的全部 artifact 作为开始工作的前提；区分已确定的契约和未决事项。
2. 区分公开 operation 的 contract_owner 与保证各 condition 的 authoritative owner。为每个可观测 condition 分配唯一 CI ID。
3. 将 pre 分类为 caller 的调用条件，post 分类为成功时的保证，invariant 分类为有效 model 始终成立的条件，environment 分类为外部、clock、OS 条件，failure_guarantee 分类为失败后 domain/persisted state 及外部副作用的保证。对无效输入的公开响应，不仅要有 pre，还必须有 failure contract。
4. 将各条件分为 required / not_applicable / unknown。required 必须包含 statement、level、authority、唯一的 authoritative owner 和 Evidence。将值的含义与范围、内部一致性、授权与副作用顺序、wire 兼容性、持久化唯一性，归到实际能够保证它们的责任方。不能用 UI 的早期 validation 或语言的类型名，替代对其他 writer 的保证。
5. 根据 scope 处理 business/technical failure、外部成功/内部失败、顺序反转、并发更新、cancel、timeout 和结果不明确等情况。分别判定失败后会留下什么、是否可 retry、是否会产生 duplicate 结果，以及 idempotency。为每个 operation 创建 assessment，仅将必要含义定义为 CI。仅在有依据时才设置 key。不要混淆 pure function 的确定性与副作用的幂等性。
6. 将 test 的 verifies 关联到实际存在的 required CI。使用 oracle 识别边界之前/边界值/边界之后、禁止的状态转换、失败后的不变性，以及适用的 retry/concurrency。可以复用现有 test，一个 test 也可以验证多个 CI。
7. 分别统计需求覆盖率、required CI 定义完整度、带 oracle 的 test 设计覆盖率，以及在 required platform 上的运行成功情况。单独保留未知 CI，不要仅凭比例宣称已满足。design 标记为 planned / not_run。

Hard Gates

• N/A 必须有理由和 Evidence，unknown 必须说明确认方法和影响。不要为 N/A/unknown 添加内容为空的 defensive entry 或 mechanism。
• 即使契约测试因业务实现存在缺陷而失败，也不得更改 oracle。若仅请求更改 test，则返回失败 Evidence 和修复 obligation。若也已获准修改业务逻辑且该 root 有权限，则统一移交整合；scoped child 则返回 caller。
• 仅在存在公开变更或迁移时，才需提供兼容性 window、审批、迁移和恢复方案。不要要求局部 test 变更必须进行迁移。

Completion

必要条件、失败保证和 oracle 均已齐备时为 sufficient；存在已知 gap 时为 insufficient；重要事项尚未确认时为 indeterminate。区分当前契约成果物是否完成与目标本身是否存在不足。依赖不足项的实现应在 next_phase 停止。