save-mem

メモリを保存する

目的

次のエージェントと人間の読者が、現在適用されること、その理由、プロジェクトがここに至った経緯を理解するのに役立つメモリを残します。会話を再現するのではなく、有用な知識を保持します。何をどこに保存するかは判断してください。以下は指針であり、保存の手順や、保存のたびにすべて実行するチェックリストではありません。

ストアを組み合わせて使う

ストア	有用な機能
StrictDoc docs/	現在のルールや決定、その根拠、プロジェクトの履歴、仕様、運用手順を読みやすく記録できます
Magic Context ctx_memory	セッションをまたいで利用できる、永続的な事実、ルール、決定、教訓、コンテキストを保存できます
Magic Context ctx_search / ctx_expand	既存の知識を検索し、その背景にある議論を確認できます
Magic Context ctx_note	後で対応するためのリマインダーやフォローアップを記録できます
claude-mem	インストールされ、記録が有効な場合、アクティビティを記録し、観察事項を検索できます

• 同じ知識をStrictDocとMagic Contextの両方に保存しても問題なく、多くの場合に役立ちます。データベースの記録には、ドキュメントへの参照だけでなく、実質的な知識を含めることができます。
• 今後の作業に役立つ重複や詳細の程度を選んでください。すべてのメモリに対応するドキュメントを用意する必要も、すべてのドキュメントをデータベースに複製する必要もありません。
• 既存のメモリや関連するソースファイルを確認すれば、意図しない重複や古くなった主張を避けやすくなります。ctx_memoryは書き込み、更新、統合、アーカイブに対応しています。適切な操作を選んでください。パスやUIDは相互参照に役立ちますが、保存の前提条件ではありません。
• ツールが利用できなくても、ほかのストアを活用できます。保存または確認できていない重要な知識があれば、明確にしてください。
• プロジェクトの語彙とドメインモデルもメモリの一部です。それらを変更するには、domain-modelingスキルを使います（用語、用語集の項目、変更を元に戻しにくい決定を見直します）。その成果は、このプロジェクト独自のレイヤーに反映してください。用語集はStrictDocのハンドブック（または、プロジェクトですでに使われている場合はCONTEXT.md）に、変更を元に戻しにくい決定は、別の並行した決定ツリーではなく、project_memory/decisions.sdocのノードに記録します。

現在の事実と履歴を区別する

記録が食い違う場合、現在のプロジェクト規範の正本はStrictDocです。 Magic Contextやclaude-memに過去の記録や矛盾する記録が含まれているのは問題ありません。有用な情報が重複していても、履歴に関するすべての記述が同じ権威を持つわけではありません。

• 現在のルールとその適用範囲を簡単に識別できるようにしてください。同梱の文法では、決定にActive、Proposed、Deprecated、Supersededを使用します。日付入りのジャーナルエントリーには、方針ではなく経験を記録します。
• 有効な規範は更新できますが、履歴ノードは消去しません。 ユーザーが決定を変更した場合、または会話と証拠から確定済みの変更が明らかな場合は、必要に応じて後継の決定を追加し、古いノードにSupersededを設定して、その旨をユーザーに簡潔に伝えます。推測、一時的な実験、あらゆるタスクを理由に正史を変更しないでください。通常の説明用ドキュメントや規範ではないメモリは、より柔軟に改訂できます。
• 重要な決定変更は、その経緯が分かるようにしてください。ジャーナルのメモ、改訂のコンテキスト、後継の決定などで、以前のアプローチで重要だった点を残せます。あらゆる編集で新しいノードを必須とするのではなく、目的に合った最小限の形式を選んでください。プロジェクト固有の履歴保持ルールがあれば、それに従ってください。
• 分かっている場合は、その理由を記録します。根拠、制約、代替案、ユーザーの意図などが該当します。理由が不明な場合は、作り上げるより不明と明記してください。
• 受け入れ済みの決定、観察された動作、保留中の作業、未検証の主張を区別してください。実装が動作していても、意図されたルールとは異なる場合があります。
• 有用な場合は、古くなっていることが分かっているデータベース上の主張を整合させ、関連する記録をリンクしてください。保存のたびにすべてのストアを監査する必要はありません。

人が読みやすい文章

メモリの文章を作成または改訂する前に、プロジェクト共通の文体を確認するため readable-docs を読み込んでください。このルールはメモリだけでなく、人が読むすべての技術記録に適用されます。特に指定がなければ中国語を使い、事実や条件を損なわずに、簡潔な文章、リスト、コンパクトな表でまとめます。

• 履歴では、ツールごとの作業日誌ではなく、結果、根拠、教訓、未解決の疑問を残してください。役立つ場合は、元の詳細へのリンクを付けます。
• 読みやすい最新のガイダンスをまとめます。文体を整えるためだけに書き換えるのではなく、元の根拠と歴史上の節目を残してください。

StrictDoc の実践的な参考情報

• 同梱されている構成は、docs/ 内の1つのプロジェクトを想定しています。内容は strictdoc_config.py、project_memory/{decisions,journal}.sdoc、handbook/ です。空のディレクトリを前提とせず、既存プロジェクトの構成に合わせてください。

• このスキルに対する相対パス assets/docs-skeleton/ に、出発点となる構成があります。既存のドキュメントや設定を上書きせず、不足しているものを追加してください。すでに開発が進んでいるプロジェクトのオンボーディングには migrate-mem を使用します。

• 意思決定の文法では、UID、STATUS、TITLE、STATEMENT、任意の RATIONALE、および関連付けをサポートしています。プレーンなジャーナルの [TEXT] ノードは、STATUS などの意思決定フィールドを自動的にはサポートしません。

• 後継の意思決定が役立つ場合は、以下の関連付けを使って古い UID を示すことができます。古い意思決定には Superseded を設定してください。逆向きの関連付けは SupersededBy です。

  RELATIONS:
  - TYPE: Parent
    VALUE: DEC-TOPIC-001
    ROLE: Supersedes
  

• Markdown のレンダリングを有効にするには、OPTIONS: の後にインデントした MARKUP: Markdown を記述します。セクションには [[SECTION]] / [[/SECTION]] を使います。安定した UID は [DOCUMENT] ヘッダーではなく、コンテンツノードに設定してください。フィールドを追加する際は、プロジェクトで実際に使われている文法を確認します。

• .sdoc、文法、または設定を変更した場合は、docs ルートから strictdoc export . を実行して検証します。利用可能な実行ファイルまたはプロジェクト環境を使用し、特定の環境マネージャーや固定バージョンを前提にしないでください。検証ツールがない場合やエクスポートに失敗した場合は、その事実を正直に報告し、ドキュメントの更新を完了とする前に解決してください。

• 保存またはエクスポートするコンテンツにシークレットを含めないでください。通常はシークレットの保管場所の名前や参照先だけで十分です。バージョン管理と履歴ノードの保持に関するプロジェクト既存のルールを守ってください。