SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsmino-architecture-quality-strategy

mino-architecture-quality-strategy

Testing & quality

View repository

Updated 10-16 06:50

About this skill

Architecture Quality Strategy

Outcome Contract

Design or audit the priority relationships of quality, structure/authority, and necessary migration/recovery based on product value. Fix the scope of the current decision, whether it concerns quality comparison, investment priority, structure, or migration. The root of the authoritative package isarchitecture_strategy_package. Supported modes: design, review.

Reference Routing

  • For the first time,skills/mino-core/references/shared-policies.mdRead this and apply Evidence, approval, and judgment. Do not reread it if it has already been read in the same context. Make ordinary judgments using the main body and these common rules.
  • When creating a quality catalog,skills/mino-core/references/quality.mdWhen handling investment priority and migration,skills/mino-core/references/change-safety.mdRead this and make only the relevant judgments.
  • If there are file/process/test execution requirements for the target system or multiple OS requirements,skills/mino-core/references/platform-compatibility.mdRead this and separate the host, target, and verification layers. Do not load additional content merely to save a record of an answer.
  • Only when asked to create, update, or hand over the authoritative package,skills/mino-architecture-quality-strategy/schemas/package.mdRead this and preserve the required fields and existing references.

Workflow

  1. Confirm the actor's purpose, value, success signals, scope, duration, constraints, reversibility, and decision owner. Return technology to the status of candidate means. Tentatively classify only business capabilities/subdomains into core / supporting / generic. For technical capabilities, in principle use N/A and handle quality, risk, operations, and cost; if the kind is unknown, also make the classification unknown.
  2. Divide quality into primary / secondary / constraint / intentionally_not_optimized / unknown. Reference existing IDs in the catalog, and do not confuse vocabulary with thresholds. Only when using a standard, specify an edition with a basis; if unverified, make it project_defined.
  3. Attach stimulus, target, environment, expected response, oracle, owner, Evidence, and measurement plan to the quality scenario. Separate local improvements from impacts on the system/journey/organization/future-change, and do not conclude structural causes from static metrics alone.
  4. Only when deciding the priority of debt resolution or remediation investment, compare business_criticality, expected_change, debt_impact, failure_risk, and remediation_cost. Do not add investment evaluation to a request concerning only quality primary/constraint. Do not create unknown costs, owners, or numerical scores.
    • For core areas with frequent changes, consider investment in models, boundaries, contracts, and tests. Even for supporting areas, if risk is high, preserve the necessary quality such as safety, legal compliance, accounting, and operations. For generic areas, compare purchase, reuse, and simple implementation. For low-change, low-risk areas, permit minimal fixes and maintaining the status quo. Do not determine priority by classification alone; connect it to Evidence for the five factors.
    • Do not create fictitious differentiation value for supporting / generic areas; show the value to maintain and the loss to avoid, along with the basis. If classification or cost is unknown, leave confirmation conditions and do not supplement unique value or final ranking.
  5. Compare maintaining the status quo, minimal fixes, and phased improvement, and if unrealistic, show the reason for exclusion. Compare build/migration/operation/learning cost, quality that improves or worsens, counterevidence, and reversibility. Separate human weighting and adoption from candidate creation.
  6. If the structure is the target, make semantic/contract/state/source-of-truth/failure-recovery/operational authority unique per subject. If there are multiple writers/readers, a coordination contract is required. For details of consumer operations, refer to Boundary; for conditional guarantees, refer to Contract.
  7. Connect undecided options to the Selection Gate, and do not call them adopted targets. Keep ADR current/superseded/rejected and proposed/approved/frozen separate.
  8. If migration is the target, define from/to, dependency order, compatibility, backfill, old/new reads and writes, conflict/reconciliation, observation period, termination/abort conditions, point of no return, recovery owner, and the deadline, usage observation, and deletion conditions of the temporary path. Do not assume that external success has been canceled by local rollback.
  9. Connect value→quality scenario→finding→option→target→transition→validation using existing IDs for the applicable stages, and exclude non-applicable stages with reasons.

Hard Gates

  • Do not create maximization of all qualities, unmeasured values, or AI-based approval of investment ranking, public contracts, or cutover.
  • Dual writers during migration must have a period, conflict, reconciliation, deletion conditions, and an owner. If the judgment of recovery or the point of no return is unknown, stop dependent operations.
  • Do not add fictitious targets, migrations, or empty specialized packages to a request that is only about quality comparison.

Completion

If judgment, structure, and verification are consistent and there is no undecided adoption, it is coherent; if undecided items can be isolated conditionally, it is conditional; known defects make it incomplete; if judgment is impossible due to important unverified items, it is indeterminate. A design plan is planned and is not runtime success.