SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsmino-design-by-contract

mino-design-by-contract

Testing & quality

View repository

Updated 10-16 01:33

About this skill

Design by Contract

Outcome Contract

Convert requirements into observable conditions, condition-level assurance responsibility, post-failure state, and contract tests that can identify incorrect implementations. For implementation, create and execute the requested contract tests. The root of the authoritative package iscontract_package. Supported modes: design, review, implementation.

Reference Routing

  • On the first occasion, readskills/mino-core/references/shared-policies.mdand apply Evidence, approval, and judgment. If it has already been read in the same context, do not read it again. Make ordinary decisions based on the main body and these common rules.
  • When changing existing behavior or public contracts, readskills/mino-core/references/change-safety.mdand create the baseline, change steps, and recovery conditions.
  • If there are file/process/test execution or multi-OS requirements for the target system, readskills/mino-core/references/platform-compatibility.mdand separate host, target, and verification layer. Do not read additional material merely to save a record of an answer.
  • Only when asked to create, update, or hand over the authoritative package, readskills/mino-design-by-contract/schemas/package.mdand preserve required fields and actual references.

Workflow

  1. Using requirements, model, existing contracts, code/tests, and obligations, classify changes into must-preserve / intentional-change / unknown. Do not make all unprovided artifacts a condition for starting; separate contracts that can be determined from undecided items.
  2. Distinguish the contract_owner of a public operation from the authoritative owner that guarantees each condition. Assign one CI ID to one observable condition.
  3. Classify pre as the caller's invocation conditions, post as guarantees on success, invariant as conditions that always hold in a valid model, environment as external/clock/OS conditions, and failure_guarantee as guarantees of domain/persisted state and external side effects after failure. Public responses to invalid input have not only pre but also a failure contract.
  4. Classify each condition as required / not_applicable / unknown. required has a statement, level, authority, a unique authoritative owner, and Evidence. Place the meaning and range of values, internal consistency, authorization and side-effect order, wire compatibility, and persistence uniqueness under responsibilities that can actually guarantee them. Do not substitute early UI validation or language type names for guarantees from another writer.
  5. Handle business/technical failure, external success/internal failure, order reversal, concurrent updates, cancel, timeout, and ambiguous results according to scope. Individually determine what remains after failure, whether retry is possible, duplicate results, and idempotency. Create an assessment for each operation, and define only the necessary semantics in CIs. Use keys only when there is a basis. Do not confuse the determinism of pure functions with the idempotency of side effects.
  6. Connect the test's verifies to existing required CIs. Identify boundary just-before/value/just-after, forbidden transitions, post-failure invariants, and applicable retry/concurrency with an oracle. Existing tests can be reused, and one test may verify multiple CIs.
  7. Count requirement coverage, satisfaction of required CI definitions, design coverage of tests with oracles, and successful execution on required platforms separately. Keep unknown CIs separately, and do not declare satisfaction based only on ratios. For design, treat as planned / not_run.

Hard Gates

  • N/A has a reason and Evidence, while unknown has a verification method and impact. Do not add empty defensive entries or mechanisms to N/A/unknown.
  • Even if a contract test fails due to a defect in the business implementation, do not change the oracle. If the request is only for test changes, return the failure Evidence and the correction obligation. If the business fix is also within the permitted root, hand it over to integration once; return scoped children to the caller.
  • Only when there are public changes or migrations, include a compatibility window, approval, migration, and recovery. Do not make migration mandatory for local test changes.

Completion

If the necessary conditions, failure guarantees, and oracle are all present, it is sufficient; if there is a known gap, it is insufficient; if something important is unverified, it is indeterminate. Separate the completion of the current contract artifact from the target's deficiencies. Implementations that depend on deficiencies are stopped at next_phase.