my-take-dev Design by Contract
自然言語要件を、実装が守る観測可能な契約へ変換する。人物の口調やtemplateの充足ではなく、条件、owner、traceability、test oracleを成果とする。
Outcome Contract
主成果物としてContract Packageを作る。通常は次の最小構成を返し、condition単位の詳細schemaはworkflow referenceへ置く。
- requirement ID、Evidence、対象operation boundary
- ID付きprecondition、postcondition、invariant、environment condition、failure guarantee
- failure後state、禁止遷移、retry / duplicate / idempotencyの適用判定
- contract itemごとのlevel、authority種別、authoritative owner、入口のdefensive validation
- contract item IDを検証するGiven-When-Then test specificationと観測可能なoracle
- 分母・分子を明示したrequirement / contract / test coverage
- 公開契約を変更する場合だけ、approval、compatibility、migration、rollback / recoveryを含むChange Safety
- platform差が契約またはtest実行を分岐させる場合だけ、environment conditionとWindows / Linux / macOS test matrix
subject_verdict: sufficient | insufficient | indeterminateとcanonicaldecision- implementationが明示的に依頼され、変更権限がある場合だけtest codeと実行結果
Reference Routing
- 内部pathは、配置先にかかわらず、インストールされた
skills/directoryを参照rootとして解決する。 - 最初に
skills/mino-core/references/core.md、skills/mino-core/references/shared-policies.md、skills/mino-core/references/requirements-and-traceability.mdを読み、共通gateを再定義しない。 - 契約抽出、condition authority、test設計、coverageでは
skills/mino-design-by-contract/references/workflow.mdを読む。 - concept、state、failureの意味が未確定で、このSkillだけでは契約を安全に定義できないstandalone依頼では
$mino-domain-model-completenessを先に使う。 - 既存挙動または公開契約を変更する場合は
skills/mino-core/references/change-safety.mdを読む。 - filesystem、process、shell、path、line ending等が契約またはtest実行を変える場合だけ
skills/mino-core/references/platform-compatibility.mdを読む。 - standalone依頼が複数成果物、実装、独立検証まで求める場合は
$mino-reproducible-developmentへ一度hand offする。 - routerまたはpeer Skillからscoped artifactを依頼された場合は再routingせず、Contract Packageと未解決model obligationだけをcallerへ返す。
- condition ID、coverage、test oracle schemaはsuite operationalizationとして扱う。
Authority Boundary
- このSkillが所有するのは、operationとcondition単位の契約、保証責務、authoritative enforcement、test oracleである。
- system-wideなdata authority、target / transition architecture、consumer boundaryを新たに決定しない。既存成果物のIDを参照するか、未解決obligationとして返す。
- operation boundary ownerを、すべてのconditionのauthoritative ownerへ流用しない。
Workflow
- Core、Requirement Catalog、変更mode、operation boundaryを確認する。
- 各公開operationをcaller、state、input、result、side effect、failureからinventory化する。
- 条件をID付きcontract itemへ分け、pre / post / invariant / environment / failure guarantee等へ分類し、Evidenceと適用状態を付ける。
- 各itemを最も確実に守るauthority種別とauthoritative ownerへ一つずつ割り当て、入口のdefensive validationと区別する。
- 正常、境界、禁止遷移、partial failure、retry、duplicate、concurrency、必要なplatform conditionを定義する。idempotencyは独立にapplicabilityを判定する。
- contract item IDを
verifiesで参照し、観測可能なoracleを持つtestを先に設計する。 - requirement → contract item → test coverageを、明示した分母・分子で監査する。
- implementation modeだけtestを実装・実行し、それ以外は仕様と未実行状態を返す。
Platform Compatibility
- 業務上同じoperationは、Windows、Linux、macOSで同じprecondition、postcondition、invariant、failure guaranteeを使う。
- OS固有差が結果を分岐させる場合だけenvironment conditionへ置き、domain invariantを複製しない。
- required platformごとにtest commandと結果を記録し、未実行platformをcontract verifiedとしない。
Hard Gates
以下のいずれかに該当する場合は契約をreadyにせず、不足condition、owner、Evidence、確認方法を返す。
- 仕様にない業務条件を追加している。
- DTO / UI validationをdomain invariantの唯一の保証にしている。
- requiredなcontract itemにstatement、authority種別、authoritative owner、根拠、test oracleがない。
- operation boundary ownerを全conditionのauthoritative ownerとして流用している。
not_applicableに理由とEvidenceがない、またはunknownをN/Aへ置き換えている。- retry、duplicate、idempotencyを互いから推定している。
- 公開契約変更のapproval、compatibility、migrationが必要なのに未解決である。
- test planと実行済みtestを混同している。
- public contract、money、authorization、data meaningをAIが確定している。
- 一部platformだけのtest成功から、required platform全体の契約適合を推定している。
Completion
- 全requirementがEvidence付きcontract itemと、そのIDを検証するtestへ追跡できる。
- operation boundary ownerと各itemのauthoritative ownerが区別され、defensive validationとの差を説明できる。
- 正常、失敗、境界、禁止遷移、再実行の必要経路がある。
- idempotencyの適用状態をEvidence付きで判定し、N/Aまたはunknownを架空のkeyやmechanismで埋めていない。
- retryとduplicateがidempotencyから独立した観測可能なconditionとして追跡される。
- requirement / contract / test coverageの分母・分子と未coverage itemが明示される。
- 既存挙動を変える場合はChange Safetyを同じpackageに保持し、migration contractは公開契約差分またはEvidence上の移行対象がある場合だけ要求する。
- 複数platform対応がrequiredなら、同一oracleによるplatform別test結果または未実行理由がある。
subject_verdict、unknown、矛盾、未実行test、残存riskをcanonical decisionと分離して残す。