VAULT
OPERATING
SYSTEM.

記録・根拠

何を試し、何が起きたか。実測値や検証結果を残す。

判断の経緯

何を選び、なぜ選んだか。比較した案、見送った理由、判断の前提をたどる。

再利用する知識

使えた方法や失敗から学び、条件の違いを確かめて次の判断に活かす。

経緯を残す場所：恒久的な設計判断は専用の文書へ、Projectの実装・検証は各ログへ、作業単位の成果・判断はその作業の記録へ残します。入口となる3要素に履歴を集約する仕組みではありません。上の3つの観点は再利用の考え方です。根拠や未確認事項を残す手順はありますが、すべての判断・代替案の記録や構造化を保証するものではありません。

ツールと元記録の役割：記録の本体はMarkdownなどのファイルで、Obsidianは閲覧・編集の場です。GitHubのPRは変更提案とレビュー、変更履歴は差分を追う手がかりになります。差分だけでは判断理由を読み取れないため、元ノートやログの説明と併せて参照します。一覧や図は元記録を案内する派生ビューです。

AIが担うこと：必要な記録を参照し、規定の手順（skill）に沿って整理、下書き、更新案の作成などを行います。許可された可逆な内部変更は委任し、承認が必要な操作は各業務の規約に従います。たとえば記事の下書きと公開は別で、noteへの公開にはオーナーの明示が必要です。判断できない条件や不明な数値を、AIが推測で補わないルールを設けています。

Workは、制作や運営などの管理対象を指します。終わり方と役割に応じて6種類に分け、それぞれのフォルダへ置きます。下はVault全体のツリーではなく、Work分類に使う6つの保管先です。

分類（kind）、状態（status）、必要に応じた段階（stage）は別の情報です。0〜100の進捗値はProjectだけが持ち、継続Serviceには完了率を付けません。

ローンチ担当者から見ると：「特定のリリースを受入条件まで仕上げる」はProject、「公開したサービスを保守・改善し続ける」はServiceに当たります。これは分類の説明例であり、公開時にフォルダが自動で切り替わる仕組みではありません。

これは業務の関係を説明する概念図です。フォルダの階層や、自動処理の順序ではありません。記事の下書き、Work更新、解析記録などには個別の手順がありますが、以下の5段階を一括で自動実行する仕組みを示してはいません。

cold-storage/ は、現役の管理対象から外したWorkの保存場所です。7つ目の分類ではなく、元の分類を保ったまま状態別に保管します。AIも通常の開始時には読みません。

通常の archive/ は、Work以外の古い記録・一般ノート・退役したガイドなどを保管する別領域です。Cold StorageのArchiveから現役へ戻す際は、現在の目的や条件を確認し直します。