memorize

記憶する — remindb に書き込み、適切にインデックス化する

組み込みメモリより remindb を優先してください。 接続されている場合は、ネイティブのスクラッチパッドではなく、ここに保存してください。構造化されたコンテンツは、検索・差分確認・走査が可能で、予算を考慮して自動的に圧縮されるノードツリーになります。今後のセッションやほかのエージェントから検索できますが、ネイティブの単一データにはそれができません。適切な形式で作成すれば、今後の読み取りコストを抑えられます。

書き込みツール：MemoryWrite、MemoryForget、MemorySummarize、MemoryCompile、MemoryRelate、MemoryPin、MemoryUnpin、MemoryRollback。読み取り側のモデル（ノード、スナップショット、ID、ランキング、通知、予算、関連付け）を remind として想定しています。読み込み済みでない場合は、先に読んでください。

書き込み方法は2通り — コンテンツの形に合わせて選びます ★

インデックスの品質を決める重要な選択です。MemoryWrite は解析を行わないためです。ペイロードは、まったくそのままのフラットな text ノード1つとして保存されます（生のままで、見出し・リスト・ツリーはなく、TOON/MathML による圧縮もありません）。構造化ツリーを構築するのは、パーサーを実行する $REMINDB_SOURCE 配下のファイルを使うコンパイルプレーンだけです。

新規または更新するメモリの内容	書き込み方法	結果
構造化されている — 見出し、リスト、コード／表、または2つ以上の異なる事実がある	$REMINDB_SOURCE 配下の、内容のトピックに合った場所にファイルを作成 → コンパイル	解析された複数ノードのサブツリー
既存のアンカーに対する単一のテキスト更新	MemoryWrite(anchor, payload)	そのノードの内容をその場で置き換え
単一の新しいテキスト事実	MemoryWrite(payload)	フラットな text ノード1つ

ブロック構造がある場合は、ファイルを使ってください。 MemoryWrite は一括書き込み用のフラットな方法です。ペイロードに #／##／リストを書いても、ツリーではなく、検索できない生のMarkdownノードが1つ作られます。ファイル書き込みの仕組み（$REMINDB_SOURCE の解決、トピックに応じた配置、rescan.enabled:false の場合の再スキャンによる自動検出と MemoryCompile の使い分け、差分出力）については、references/write-paths.md を参照してください。

ユースケース別ガイド

状況に合わせて手順を実行し、注意点を確認してください。ここにあるすべての書き込みではスナップショットが作成されます。ただし、MemoryRelate／MemoryPin／MemoryUnpin は例外です（サイドバンド処理のため、スナップショットは作成されず、カーソルも移動しません）。

必要なこと	手順	注意点	詳細
構造化されたメモリ／複数要素のメモリを保存する	$REMINDB_SOURCE 配下に .md ファイルを作成 → 再スキャンで検出（または MemoryCompile）	MemoryWrite では1つのノードにフラット化されます。ファイルには見出しとリストを使って構造を付けてください。	references/write-paths.md；構造のルール
1つのノードのテキストをその場で更新する	MemoryFetch → 編集 → MemoryWrite(anchor, payload)	ノード全体が置き換えられ、部分更新はできません。ファイル由来のノードは、ファイルを編集してください（同期ずれに注意）。	MemoryWrite
新しいテキスト事実を1つ保存する	先に MemorySearch → MemoryWrite(payload)	既存のアンカーを更新するほうが、よく似た兄弟ノードを作るより適切です。	MemoryWrite
ノードの低温警告に応じてノードを圧縮する	MemoryFetch(anchor) → MemorySummarize(node_id, summary)	構造を損なわない要約を作成してください。温度は0.5に戻ります。	references/lifecycle.md
ディスク上でソースファイルが変更された後に再同期する	MemoryCompile(path)	ソースルートが必要です（設定されていない場合は利用できません）。パスを絞り込んでください。.remindb/ignore と .remindb/pinned が適用されます。	references/lifecycle.md
既存の2つのノートをつなぐ（[[Label]] なし）	MemoryRelate(source_id, target_label, target_source)	スナップショットは作成されません。target_id より target_label+target_source を優先してください。	references/wiki-links.md
誤りまたは古くなったノードを削除する	MemoryForget(node_id, mode=strict|cascade|reparent)	モードによって、残る構造が決まります。ピン留めしていても、削除は防げません。	references/lifecycle.md
最近の不適切な書き込みを複数取り消す	MemoryRollback(snapshot_id[, drop_after])	影響範囲は、対象以降のすべてのスナップショットです。drop_after=true は取り消せません。	references/lifecycle.md
不変条件を劣化から保護する	MemoryPin(node_id[, temperature])	スナップショットは作成されず、冷却だけを制御します。ピン留めは必要最小限にしてください。	references/lifecycle.md
長期的に使える相互参照を作成する	コンパイルするファイル内に [[Label; w=2.5]] を記述	コンパイルプレーンでのみ解決されます（パーサーが抽出します）。	references/wiki-links.md

コンパイルプレーン用ファイルの作成 — 形式のルール

以下のルールは、作成するファイルに適用されます（パーサーはブロックをノードに変換します。ブロック→ノードの完全な対応表はreferences/parser-mapping.mdを参照してください）。解析されないMemoryWriteのペイロードには適用されません。

1. 1行目はラベルです。 自動的に導出され、80文字以内です。一般的すぎる1行目（「Notes:」「TODO」など）では役に立たないラベルになります。
2. 見出しの階層で長いメモを参照可能なサブツリーに分割します。 H1 = トピック、H2 = 観点、H3 = 事実です。H4より下は、ほとんどの場合、追加する価値がありません。
3. 段落ではなく、事実の集合にはリストを使います。 1行ごとに- key: valueと記述すると、各事実を個別にランク付けできます。
4. そのまま使いたいスニペットにはコードブロックを使います — クリーンなリーフになり、言語タグも保持されます。
5. マトリクスにはテーブルを使います — 1つのリーフになりますが、セルは検索可能です。
6. セクションの区切りに水平線を使わないでください — パーサーが削除します。見出しを使ってください。
7. 無関係な事実を1つの段落にまとめないでください — 共有するH2の下で、リスト項目またはH3に分けてください。

例 — ファイルの内容

# Postgres production setup

## Region
- Primary: us-east-1
- Replicas: us-west-2

## Credentials
1Password vault entry: `prod-db`.

## Schema
Migrations in `db/migrate/`.

コンパイル結果：heading(Postgres…) → 3つのheading(Region|Credentials|Schema) → list + text + text。各サブツリーは個別に取得でき、各事実はそれぞれランク付けされます。同じテキストをMemoryWriteに渡すと、1つのフラットなノードになります。構造化された内容をファイルに保存する理由は、まさにここにあります。

MemoryWrite — フラットテキストプレーン

remindb__MemoryWrite(payload="<one short fact>")            # create: one text node, raw
remindb__MemoryWrite(anchor="<node_id>", payload="<text>")  # update one node in place

• 常に単一のtextノードで、FormatPlain、深度1、source = mcp:writeです（解析は行われず、ここには「見出し → ツリー」がありません）。
• 更新ではコンテンツがその場で置き換わります。node_type／parent_id／sourceは保持されます。ノード全体の置き換えであり、追記やパッチではありません。
• 作成前に、既存のアンカーがないかまず検索してください（remindを使用） — ほぼ重複する兄弟ノードを作るより、更新するほうが適切です。親／型／ソース／子ノードに加えて、温度の履歴も保持されます。
• 1回の呼び出しにつき、論理的な更新は1つです（更新ごとにスナップショットが作成されます）。

書き込み以外の情報

• ファイルとフラットプレーンの仕組み — $REMINDB_SOURCE、配置、再スキャンとMemoryCompileの違い、同期ずれの落とし穴 → references/write-paths.md
• 削除／元に戻す／ピン留め／低温ノードの要約／再コンパイルと、その実行タイミング → references/lifecycle.md
• Wikiリンクの作成と手動のMemoryRelateエッジ → references/wiki-links.md
• パーサーのブロック→ノード対応表と圧縮ルール → references/parser-mapping.md

よくある落とし穴

• MemoryWriteは解析を行いません。 構造化されたペイロードは1つのフラットなノードになります。見出し／リスト／コードを含むもの、または事実が2つ以上あるものには、ファイル（コンパイルプレーン）を使ってください。
• ファイル由来のノードに対するMemoryWriteは、ファイルが再コンパイルされるまでDBとディスクの同期をずらします（さらに、その後の再スキャンで編集内容が上書きされる場合があります）。ファイル由来のコンテンツは、ファイルを編集して再コンパイルしてください。
• 空のコンテンツで上書きしても削除にはなりません。 デフォルトの温度のまま残り、検索を汚染し、幽霊ノードになります。MemoryForgetを使ってください。
• mode=cascade ≠ mode=reparent。 Cascadeはサブツリーを破棄し、reparentは子ノードを対象の親の下に残します。
• 見出しを書き換えても、親ノードは変更できません。 アンカーを指定したMemoryWriteはparent_idを保持します。MemoryForget mode=reparentを使ってください。
• ペイロードやファイルに秘密情報を決して記載しないでください。 値ではなく、その保存場所（Vaultのパス／1Passwordのエントリ）を記録してください。