Corrección de memoria

Corrija el registro; no añada una contradicción

Una corrección cambia la memoria existente mediante PATCH /v1/memories/{memory_id}. MemoryUpdateRequest hace opcionales todos los campos e incluye content, path, metadata, source, provenance, memory_type, status, expires_at, scope y team_id. Esto mantiene la corrección vinculada a la misma referencia de memoria y permite al servidor aplicar su ruta de versionado.

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
}

Los controles de versiones y conflictos forman parte de la solicitud

El contrato de actualización incluye merge_metadata, merge_provenance y detect_conflicts, todos con valor predeterminado true, además de supersession_reason. La ruta de persistencia incrementa la versión de la memoria y conserva la evidencia de status/superseded_by/conflict en el contrato público; lea los datos de implementación devueltos como el resultado actual, mientras que la respuesta de OpenAPI permanece sin tipar.

• Fusionar metadata y provenance cuando la corrección debe retener pruebas existentes.
• Mantenga detect_conflicts habilitado cuando las ediciones simultáneas o versiones competidoras importan.
• Utilice supersession_reason cuando la corrección sustituya intencionadamente a una versión anterior.

Verifique el scope corregido

Después de una corrección, haga una lectura con scope e inspeccione los campos devueltos de versión, status, provenance y conflicto. La recuperación sigue los filtros autenticados de scope y status de memoria; un PATCH correcto por sí solo no demuestra que el resultado con el scope previsto sea visible.

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