SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsmino-interface-implementation-separation

mino-interface-implementation-separation

Coding & development

View repository

Updated 10-16 06:49

About this skill

Interface / Implementation Separation

Outcome Contract

Separate the purpose, operations, and contract that consumers need from internal technology and procedures, and judge leakage and over-abstraction. If a fix has been requested and the public meaning and scope are settled, proceed through change and verification. The root of the authoritative package isboundary_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 already read in the same context, do not reread. Make ordinary judgments using the main body and these common rules.
  • When changing code responsibilities or naming, readskills/mino-core/references/code-design.md; when changing existing behavior or public contracts, readskills/mino-core/references/change-safety.md, and bring it down to concrete changes and verification.
  • If there are requirements for file/process/test execution on the target system or multiple OSes, readskills/mino-core/references/platform-compatibility.md, and separate host, target, and verification layer. Do not load additional material merely to save a record of an answer.
  • Only when asked to create, update, or hand over the authoritative package, readskills/mino-interface-implementation-separation/schemas/package.md, and preserve required fields and existing references.

Workflow

  1. From callers, public contracts, code, dependencies, quality, and existing variants, classify domain judgment, use-case coordination, persistence, external I/O, presentation, and operations. Do not require packages for the entire system for a local guard question.
  2. Define the consumer's purpose, must_know, and must_not_know, as well as the operation's inputs, results, failures, side effects, and invariants. If a domain contract applies, reference the existing Contract. For generic technical boundaries, use a reasoned N/A and consumer semantic operations, and do not invent business logic.
  3. For each operation, screen end_to_end_deadline, retry_semantics, idempotency, duplicate_semantics, and ambiguous_outcome individually as applicable / not_applicable / unknown. For deadline, clarify the upper limit, owner, and timeout result; for retry, the permission/prohibition conditions and owner; for idempotency/duplicate, the duplicate result and owner; for ambiguous outcomes, the observed result and the reconciliation/recovery owner.
  4. For N/A, leave the reason and Evidence; for unknown, leave the confirmation method and impact. Do not expand non-applicable semantic fields as empty. Do not make everything N/A just because it is named pure/read-only; investigate external dependencies and requirements. Define an idempotency key only when there is a necessary basis.
  5. Place SDK types, DB rows, framework types, provider procedures, serialization, cache, algorithms, backoff, and per-attempt timeouts on the implementation side. Leave the meanings of retry, duplication, and ambiguous outcomes that consumers need for judgment on the public surface. Make the dependency direction such that consumers use the contract and adapters implement it.
  6. For semantic/invariant/contract/state/source-of-truth/failure-recovery/operational owners, reference existing authorities, and do not re-decide the authoritative source for the entire system or the guarantees of conditions.
  7. Create selection boundaries only for existing variants. Even with a single implementation, a small port can be used if there is a basis in external failure isolation or contract stability. Keep short guards, and do not create future-use factories or hierarchies. Distinguish branches for state, rules, implementation variants, and temporary flags.
  8. Evaluate the applicable scenarios of implementation replacement, addition/change of existing variants, and business rule changes as pass / fail / not_applicable / unknown with Evidence. Only when changing existing callers or public contracts, establish a consumer list, compatibility window, phased migration, recovery, and observation of zero usage of old paths.

Hard Gates

  • Do not treat the number of ifs or interfaces as quality. Gather state, decisions, and updates into responsibilities with the same purpose and invariants, and investigate whether invalid states can be prevented from all public writers.
  • Perform commonization only when the purpose, contract, and reason for change align. Do not leave abstractions that hide different meanings or technical leakage to callers.
  • Do not settle unclear points by assumption. Do not treat a provisional path planned for change as already introduced, and reference only TMP IDs that actually exist.

Completion

If meaning and internal implementation are separated, it is separated; technical leakage or misassigned responsibility is leaky; abstraction without basis is overabstracted; if application itself is unnecessary, it is not_applicable; important unverified matters are indeterminate. Retain coexisting findings, and separate the target verdict from the completion of the current artifact.