name: canonical-source-guard description: > 正本候補が2つ並立したら STOP を強制。 統合は別 Permit で行う。spec/wall.rs vs composition/ を典型例として明記。 inputs: - 新規作成しようとしているファイル - 既存の正本候補リスト(STATUS.md から) outputs: - 競合判定結果 rules: - 競合あり → STOP - 統合は必ず別 Permit - 推測で統合方法を決めない - STATUS.md が 48h 以上古い場合は先に更新
canonical-source-guard
目的
正本(canonical source)の二重化を防ぐ。 新しい Store / Model を作る前に、既存正本との競合をチェックする。
適用条件
以下のいずれかを作ろうとしたとき:
- 新規
*Store/*Model/*Repository - 新規 mod.rs
- 「正本っぽい」データ構造
以下のいずれかを変更しようとしたとき(拡張):
- 既存正本に「正本的責務」を追加する変更
- 正本に近い責務の切り出し
- 例:
spec/wall.rsに CompositionStore 相当を足す
事前チェック
STATUS.md の鮮度確認
STATUS.md 最終更新日が 48h 超 → STOP
→ 先に STATUS.md を更新してから再開
実行手順
1. 新規作成/変更対象を明記
- ファイル: <path>
- 責務: <A/B/C/D/E/F 層>
- 内容: <何を保持するか>
- 変更種別: 新規作成 / 責務追加 / 責務切り出し
2. 既存正本候補を列挙(STATUS.md 参照)
| ファイル | 責務 | 現状 |
|---|---|---|
| ... | ... | 正本/便宜/ドラフト |
3. 競合判定
- 同じ責務の正本候補が既に存在するか?
- 役割が重複するか?
- 既存正本の責務が拡張されるか?
判定結果
競合なし
→ 続行可(ただし Permit 必須)
競合あり
→ STOP
STOP 出力テンプレ
## STOP: canonical-source-guard
### Reason(1行)
競合検出: <新規/変更ファイル> vs <既存ファイル>
### 責務
<重複している責務>
### What I tried
- ...
### What I need from Human(最大3問 A/B/C)
A) ...
B) ...
### Next action
- [ ] 統合 Permit を取得するまで実装禁止
典型例(今回の事故)
競合検出: composition/mod.rs vs spec/wall.rs
責務: C 層(壁構成)
問題: どちらが正本か未決定
解決: 統合 Permit で以下を決める
- spec/wall.rs を E 専用に再定義?
- composition/ を C 正本に昇格?
- 両方維持して役割分担を明確化?
STOP 後のフロー
STOP → 競合を docs に記録 → 統合 Permit 依頼 →
→ Codex + Human レビュー → 統合方針決定 →
→ 統合 Implementation Permit → 実装
次に使う Skill
- codex-review-request(統合方針のレビュー依頼)