Reproducible Development Router

実装詳細が変わっても、同じproblem、requirement、contract、model整合性、quality constraint、public boundaryを満たす変更を生成・判定する。

このrouterを使う基準は行数や抽象的な「規模」ではない。二つ以上の専門成果物を統合する必要がある、または実装・reviewを複数の成果物へend-to-endでtraceする必要がある場合に使う。単一成果物なら対応する専門Skillだけを使う。

Modes

```
design
```
: Implementation Specと未解決gateを作る。read-only。
```
implementation
```
: Implementation Spec内で変更し、独立検証する。変更権限が必要で、高impactな未承認判断には依存しない。
```
review
```
: 既存code / diffを要件と専門成果物へ照合する。read-only。
```
reproduction-test
```
: fresh contextの複数runを比較する。live workspaceは変更しない。

Outcome Contract

modeに応じた一つの主成果物を返す。

```
design
```
:
```
Implementation Spec
```
```
implementation
```
:
```
Verified Change
```
```
review
```
:
```
Review Result
```
```
reproduction-test
```
:
```
Reproduction Report
```

主成果物には、必要な範囲だけ次を統合する。

Problem Frame、Context Packet、AI restatement
Requirement Catalog、rejection criteria、end-to-end traceability
applicableなArchitecture / Completeness / Contract / Boundary package
Change Safety、Platform Context、platform別validation
independent verification、human approval、canonical
```
decision
```

Function packageを要約するときも、stable ID、Evidence、applicability、authority、coverage、subject verdictを失わない。schemaを全文複製するのではなく、losslessなpackageを参照可能な形で保持する。

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

を読む。

routing、Function package、mode別成果物、統合traceでは
```
skills/mino-reproducible-development/references/integrated-workflow.md
```
を読む。
filesystem、process、shell、toolchain、test実行、複数platform対応を扱うときだけ
```
skills/mino-core/references/platform-compatibility.md
```
を読む。
Skill更新またはreproduction-testでは
```
skills/mino-core/references/benchmark.md
```
を読む。
domain discovery、code design、existing changeは対応するmino-core referenceを必要時だけ読む。

専門Skillは

$mino-architecture-quality-strategy

、

$mino-domain-model-completeness

、

$mino-design-by-contract

、

$mino-interface-implementation-separation

から必要なものだけを依存順に呼ぶ。

各callへ

routing_context.origin: integrated

、

requested_by: router

、

requested_artifact

、

return_to: router

を渡し、専門Skillに再routingさせない。

router schema、Function package、platform matrix、benchmarkはsuite operationalizationまたはrepository policyとして扱う。

Default Routing

Request	Route
Problem Frame / Context Packetだけ	`$mino-problem-framing` へhand offし、routerを継続しない
統合依頼だがproblem、meaning、change boundaryが曖昧	Coreでframingし、必要なら `blocked` またはProblem Frameを返す
concept、state、failureの欠落	discovery as needed → completeness
pre / post / invariant、retry / duplicate / idempotency	contract。意味が未確定ならcompletenessを先行
技術漏出、caller分岐、long script	completeness / contract as needed → boundary
複数module、system-wide data authority、quality trade-off	architecture → completeness / contract / boundary as needed
legacyのend-to-end実装	Core → relevant Functions → change safety → implementation → verification
diffの要件適合review	Core → relevant Functions → independent verification。変更しない
private mechanical rename	このrouterを使わない

Workflow

mode、decision scope、変更権限、可逆性、host / target platformを確認し、Evidence状態とdecision maturityを記録する。
Coreでproblem、premise、meaning、Context Packet、AI restatementを記録する。
Requirement Catalogとtest-first rejection criteriaを作る。
```
run_if
```
を明示して必要な専門Skillだけを依存順に実行する。
専門成果物をImplementation Specまたはmode別主成果物へ統合し、canonical ownerが重複していないか確認する。
```
mode == implementation && mutation_authorized
```
の場合だけ、小さな可逆stepで実装する。
実装者の説明と独立して、test、analysis、traceability、failure、change scenarioをrequired platformごとに検証する。
artifact readiness、subject verdict、engineering status、release status、human acceptanceを分けて返す。
reproduction-testではfresh contextのrunを同じgateで比較する。

Platform Compatibility

共通problem、requirement、contract、test oracleを維持し、shellやphysical pathだけをplatform adapterへ分ける。
Windows、Linux、macOSのうち複数がrequiredなら、各platformの実行結果を独立Evidenceとして保持する。
一部を実行できない場合は
```
unexecuted_validation
```
と
```
platform_validation.parity_result: incomplete
```
を返し、required platform全体をverifiedとしない。

Hard Gates

以下のいずれかに該当する場合はimplementationまたはrelease判定へ進まず、現在modeで安全に返せるartifactと不足事項を返す。

単一成果物の依頼をrouterへ過剰routingしている。
Coreの往復trace、Requirement Catalog、rejection criteriaがないまま専門Skillまたは実装へ進んでいる。
Function schemaを埋めただけで、目的・要件・Evidenceから固有判断への因果を検証していない。
```
reversibility: unknown
```
または未解決Selection Gateに依存する実装を進めている。
Function packageから
```
run_if
```
、stable ID、Evidence、applicability、condition別authority、coverage、subject verdictを落としている。
domain discoveryがapplicableなのに、termのactor / purpose / rule / Evidence、canonical term / context / translation / relationship ID、reference integrity、relationshipごとのfailure semantics、unknownの確認方法・影響をfree textや改名fieldへ圧縮している。
上流Skillに未作成の後続IDを作らせている。
peer / router間で再routingまたはping-pongが起きている。
mode外mutation、無承認の公開契約・data meaning・不可逆変更を行っている。
design planと実行成功、artifact readinessと対象systemの良否、engineeringとreleaseを混同している。

Completion

Core、Requirement Catalog、必要な専門成果物、Verificationのgate結果がある。
各専門Skillの
```
run_if
```
と固有packageが同じ成果物内で解決し、固有hard gateをrouterの要約が迂回していない。
applicableなChange Safety、Platform Context / Validation、causal chain、Selection Gateが最終成果物へlosslessに残る。
applicableなdomain discoveryのterm、ambiguous meaning、translation、relationship参照がcanonical fieldのまま解決し、reference integrityがpassする。
modeごとの主成果物が一つあり、Problem Frame、Evidence付きpremise / unknown、AI restatementと、全requirementのpurpose、model、contract、boundary、change、testへの必要範囲のtraceを保持する。
invalid state、failure、retry、migration、代表変更の必要経路を検証する。
required platformごとのtest / build / analysis結果とcontract parity判定がある。
mode外の書換え、scope外cleanup、将来用abstractionを行わない。
未実行検証、unknown、contradiction、residual risk、human approvalを隠さない。
現在modeのstatus、次phaseの可否、release statusを分ける。

mino-reproducible-development

NPX Install

Tags

SKILL.md Content