メモリ修正

矛盾を追加せず、レコードを修正する

PATCH /v1/memories/{memory_id}で既存のメモリを変更します。MemoryUpdateRequestの全フィールドは任意で、content、path、metadata、source、provenance、memory_type、status、expires_at、scope、team_idを含みます。これにより修正は同じmemory referenceに結び付き、サーバーのversioning pathで処理されます。

PATCH /v1/memories/<memory-id>
X-API-Key: <your-assigned-api-key>
Content-Type: application/json

{
  "content": "The corrected deployment decision was verified on 2026-09-02.",
  "provenance": {
    "correction": "owner-confirmed"
  },
  "merge_provenance": true,
  "detect_conflicts": true
}

Versionとconflictの制御もrequestの一部です

更新contractにはmerge_metadata、merge_provenance、detect_conflictsが含まれ、いずれもデフォルトでtrueです。さらにsupersession_reasonも指定できます。永続化pathはmemory versionを増分し、公開memory contractにstatus、superseded_by、conflictの証拠を保持します。現在の結果は返されたimplementation dataから読み取り、OpenAPI responseは型付けされていないままであることに注意してください。

• 修正後も既存の証拠を残す必要がある場合は、metadataとprovenanceをmergeします。
• 同時編集や競合するversionが重要な場合は、detect_conflictsを有効に保ちます。
• 修正で以前のversionを意図的に置き換える場合は、supersession_reasonを使います。

修正後のscopeを検証する

修正後はscopeを限定したreadを実行し、返されたversion、status、provenance、conflictの各フィールドを確認します。取得は引き続き認証済みscopeとmemory status filterに従うため、PATCHが成功しただけでは、意図したscopeの結果が見えるようになった証明にはなりません。

GET /v1/memories/search?query=corrected%20deployment%20decision&scope=memory-os&status=active&limit=5
X-API-Key: <your-assigned-api-key>