write-persistence-scenarioslisted

# write-persistence-scenarios（永続化シナリオを先に書く） 読み終えると、業務イベントと業務シナリオから、データの形を考える前に「何が起きたため何を残すのか」を永続化シナリオとして書き、作成・更新・削除の3操作を検討済みにできる。エンティティ、テーブル、正本方式、投影はこのskillの外である。 ## 入力 根拠づけられた入力、業務イベントの一覧と関係する役割、既存の業務シナリオまたは既存の論理設計資料を、この判断規律を適用するagentが同じ文脈に保持していること。資料に無い判断は補わず、未確認として止める。 ## 判断基準 同梱の内部skill `write-bdd`の規律のうちアクターと利害関係者、業務イベント、ユビキタス言語、BDDの前提・トリガー・失敗理由を読んでから始める。 | 観察対象 | 述語 | 行動 | |---|---|---| | 作成の候補 | 業務上の事実が初めて成立する | 作成のシナリオにする | | 更新の候補 | 別の事実によって現在状態が変わる。上書きか、新しい事実の追加かが決まっている | 更新のシナリオにする。訂正・取消は新しい事実の追加であり、物理削除と混ぜない | | 削除の候補 | 保持理由が尽きて物理的に消せる条件が業務上決まっている | 削除のシナリオにする。業務上の取消・失効・終了は削除ではない | | 各操作 | シナリオあり、または業務上存在しない理由がある | `covered`か理由つきの`not-applicable`として3操作すべてを記録する | | 一つのシナリオ | 一つの業務イベントと一つの永続化上の変化を持つ | 分ける | | 残す事実 | 現在状態だけでなく、後の判断、取消、訂正、説明に必要な事実が含まれる | 含める。誰が何を説明できなくなるかで判断する | | 実現方法の語 | API、DTO、SQL、テーブル、ORMが混ざっている | 業務の言葉へ言い換える | | 確からしさ | 業務を知る人が確認した | `confirmed`。未確認のシナリオは`assumed`（根拠のある仮説）または`unknown`として渡し、仮説に依存する記録は論理モデル側で仮説と明示させる | ## 手順 1. 利用者の業務シナリオ、業務イベントの一覧、業務資料を先に読む。 2. 作成・更新・削除の各操作を`covered`（シナリオあり）または`not-applicable`（業務上の理由）として記録する。 3. 永続化シナリオを1件ずつ、`場合 / アクター / 事前状態 / 業務イベント / 条件 / 業務判断 / 業務上の結果 / 次状態 / 操作（作成・更新・削除） / 残す・変える・消せる事実 / 履歴（過去の何を残すか） / 保持（物理削除を許す条件） / 出所 / 確からしさ`で書く。 4. シナリオごとに条件マトリクスを作り、条件マトリクスJSONを標準入力で`python3 scripts/scenario_matrix.py check`へ渡す。pathはこのSKILLと同じdirectoryを基準にし、fileは介さない。stdoutにJSONを1行ずつ返し、終了codeは0が違反なし、1が違反あり（各行が`path` / `detail` / `howto`）、2が入力を読めない（空、不正JSON）。0以外なら診断に従ってシナリオを直す。単一失敗では検証対象以外の必要条件をすべて成立させる。 ## 停止条件