migrate-mem

メモリの移行

目的

すでに開発済みのプロジェクトに、読みやすく信頼できるメモリの基盤を整えます。重点は、古いファイルの移動やあらゆる成果物の変換ではなく、プロジェクトを理解し、有用な StrictDoc ドキュメントを初期化することです。

調査の深さ、ドキュメントの構成、保存先の重複、ユーザーへの確認が必要な質問については、状況に応じて判断してください。すべての初期化で、固定の棚卸し項目、必須の分類レポート、承認手順が必要なわけではありません。

現状のプロジェクトを理解する

• プロジェクトの指示、README、主要モジュール、エントリーポイント、設定、既存のドキュメント、関連する開発履歴を調べます。目的、アーキテクチャ、慣例、現在の状態、未完了の作業を理解できるまで、根拠をたどってください。
• 既存の Magic Context メモリや claude-mem の記録から、コードだけでは分からない決定や経験を把握できることがあります。それらがなくても、StrictDoc の初期化は可能です。
• 特定のメモ名、計画用ディレクトリ、以前の開発手法を前提とせず、有用な情報源を文脈に沿って読みます。生成された出力や網羅的な記録に、主要なコードや決定と同じだけの注意を払う必要はほとんどありません。
• 定められた方針、実際に確認された実装、過去の経験、未解決の質問を区別します。新しい根拠から変更が分かることはありますが、それだけで現在のルールが決まるわけではありません。

有用なメモリの基盤を構築する

同梱の save-mem スキルでは、メモリの保守と StrictDoc の仕組みについて説明しています。その assets/docs-skeleton/ は出発点として利用できます。スキルレジストリまたは隣接する ../save-mem/ ディレクトリから見つけてください。ホームディレクトリ内の固定パスにあるとは限りません。

一般的な場所	有用な内容
docs/project_memory/decisions.sdoc	現在のルールと決定、その適用範囲や理由、廃止された旧ルール
docs/project_memory/journal.sdoc	日付入りのプロジェクトの基準状況、重要な経験、進捗、未解決の質問
docs/handbook/	維持する価値のある参考資料：アーキテクチャ、使い方、仕様、運用ガイド
docs/strictdoc_config.py	StrictDoc のプロジェクト設定

• 既存の構成に合わせて、このレイアウトを調整してください。ドキュメントやひな形がないのは、一般的な初期状態です。既存の docs ディレクトリがあるからといって、上書きしてよいわけではありません。
• プロジェクトを理解できるだけの知識を整理して残します。モジュールごと、または過去の作業ごとにドキュメントを作るより、少量でも役立つ基準情報を優先してください。
• 現在の StrictDoc 規範を信頼できる情報源として維持し、過去の記録やレポートと区別できるようにします。Active、Proposed、Deprecated、Superseded などのステータスを使うと、プロジェクトの進化に伴うこの区別を保ちやすくなります。
• 情報源が食い違う場合や、意図されたルールが不明な場合は、重要な論点を明示します。根拠のない理由を作ったり、推測した方針を確定事項として示したりしないでください。確定済みの決定が実際に変更されている場合は、別途ドキュメント作成の指示を待たず、現在の規範を維持してユーザーに簡潔に伝えてください。通常のメモリや説明の整理については、より柔軟に対応できます。
• 同じ事実や決定を Magic Context に保存してもかまいません。記憶しやすさと耐障害性が高まるように重複を選んでください。事実ごとに保存先を一つだけにすることも、すべてを複製することも目的ではありません。

読みやすさを向上させながら、プロジェクトを維持する

• 既存のソース資料や実用的なドキュメントを、引き続き役立つ状態に保ちます。すべてを自動的に移動、アーカイブ、削除、再フォーマットするのではなく、追加または統合します。重要な再構成については、ユーザーと相談します。
• 後続の実行では、基準となる内容を作り直すのではなく、既存のノードや参照を基に作業します。プロジェクトの履歴保持やバージョン管理の規約に従います。
• 文章を作成または改訂する前に、共有プロジェクトの文体（事実や条件を損なわず、言い回し、リスト、簡潔な表を用いる）を確認するため、readable-docs を読み込みます。この方針は、メモリや docs/ 以外にも適用されます。
• 必要に応じて、結論をソースファイル、コミット、またはメモリの参照先に結び付けます。元のドキュメントは、新しいハンドブックにそのまま複製するのではなく、根拠資料として残すことができます。
• AGENTS.md の起動時や保存時の案内は、後続のエージェントがメモリを見つけるのに役立ちます。必要に応じて、関係のないプロジェクト指示を維持しながら、合意した意図に沿うように調整します。

実際のプロジェクトで結果を確認する

• 利用可能な StrictDoc のインストール環境またはプロジェクト環境を使用します。変更を加える前に既存の設定と文法を確認し、特定のバージョン、環境マネージャー、プラグインのインストールを前提としないようにします。
• .sdoc や設定の変更は、docs のルートで strictdoc export . を実行して検証し、リスト、表、注記が読みやすく表示されているか、出力を十分に確認します。
• 新しい読者が、現在適用される内容、その理由、これまでの経緯、未確定の点を理解できるか検討します。エクスポートに成功しただけでは、内容が正しいとは限りません。
• 確立できた有用なメモリ、未解決の疑問、実際の検証状況を簡潔に報告します。連携機能の不足や未検証のランタイムに関する主張は、完了したと捏造する理由にせず、明示的な未解決事項として残すことができます。