mino-reproducible-development

可复现开发路由器

结果约定

design 对应 Implementation Spec，implementation 对应 Verified Change，review 对应 Review Result，reproduction-test 对应 Reproduction Report。整合必要的专业成果物与真实 ID 的 trace。 正本 package 的根目录为 reproducible_development_result。 支持的 mode：design、implementation、review、reproduction-test。

参考资料路由

• 首次执行时读取 skills/mino-core/references/shared-policies.md，并应用其中关于 Evidence、审批和判定的规则。同一 context 中已读过则无需重读。通常的判断依据是主体内容与这套共通规则。
• 对需求规范化和成果物间的 trace，读取 skills/mino-core/references/requirements-and-traceability.md；对现有行为的变更，读取 skills/mino-core/references/change-safety.md。
• 仅 reproduction-test 读取 skills/mino-reproducible-development/references/reproduction.md，以创建隔离的运行环境和比较结果。
• 根据需要，仅请求所需的成果物：问题定义交给 $mino-problem-framing，质量、正本和迁移交给 $mino-architecture-quality-strategy，model 缺失交给 $mino-domain-model-completeness，条件保证交给 $mino-design-by-contract，公开边界交给 $mino-interface-implementation-separation。
• 如果涉及目标 system 的 file/process/test 执行或多 OS 要求，读取 skills/mino-core/references/platform-compatibility.md，并区分 host、目标和验证层。仅保存普通回答记录时不额外读取。
• 仅在请求创建、更新或交接正本 package 时，读取 skills/mino-reproducible-development/schemas/package.md，并保留必填 field 和真实引用。

工作流

1. 如果主要成果物是单一的专业设计，则只需交给对应的 Skill 一次，然后结束。仅处理需要整合两个或更多成果物，或从需求到实现和验证的范围。
2. 对齐需求、审批、revision 和变更边界，并创建或引用需求与拒绝条件。为各项专业工作定义 run_if、输入、依赖和成果物 owner。已有 artifact 已满足的流程不重复执行。
3. 原则上按问题定义→必要的质量/术语整理→model→契约→边界→实现/验证的顺序进行。不要求执行所有 Skill。仅可并行处理输入已确定的独立部分。
4. 如果分工有益，则向子任务传递 scope、成果物、允许的 Evidence、revision、mode、变更权限、结束条件以及返回给 caller 的内容。即使 parent 处于 implementation mode，设计专用的子任务也必须设为 read-only。不得让子任务再次路由到 peer/router，也不得让多个 writer 修改同一个 file。没有 tool 时，按顺序执行并记录。
5. 通过 handle 和 revision 注册每个 artifact。保留各 Skill 的 owner、unknown、coverage 和 subject_verdict，并将 obligation 关联到后续创建的 CI/T 等真实 ID。不得仅因字符串相同就合并相同的 local ID。摘要应引用正本，不要把相同内容复制成另一个版本。
6. 实现前确认需求→对应的 model/contract/boundary→test/oracle trace。在 implementation 允许的范围内，以单一目的的小 step 推进；仅在操作依赖于含义不明或未经批准的选择时暂停。不得要求重新审批已选定目标的投资优先级。
7. parent 将子任务的主张与原始资料、实际 code 和 test 对照核实。区分确定性运行结果与独立 review。独立 review 应提供需求、契约、revision、diff 和所需 code，不得将实现者的结论作为答案注入。相同历史的 fork 或自我 review 不算独立评估。
8. 仅使依赖新指示和 revision 差异的结果失效。不得将 stale/pending/timeout 视为成功。必要 check 均通过且没有顾虑或新差异时，返回结果。

硬性门槛

• 不得为了填补专业成果物的不适用项而创建空 package。不得一律要求幂等性 key、migration 或投资评估。
• 不得在摘要中丢失 Function 的 ID、authority、未知项和验证状态。不得将子任务的投票或结构检查作为实现正确性的证据。
• 单独进行 review 时不得编辑目标 system。如果请求修复，则更新权限和实际 mode。

完成

返回当前 mode 的主要成果物、未解决的 obligation，以及变更和验证的 Evidence。不能仅因名称是 Verified Change 就认定其已验证。应区分当前 artifact 的缺失，与已完成的条件式设计中后续步骤停止的情况。