Correção de memória

Corrija o registro; não acrescente uma contradição

Uma correção altera a memória existente por meio de PATCH /v1/memories/{memory_id}. MemoryUpdateRequest torna todos os campos opcionais e inclui content, path, metadata, source, provenance, memory_type, status, expires_at, scope e team_id. Assim, a correção permanece associada à mesma referência de memória e o servidor pode aplicar seu caminho de versionamento.

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
}

Versionamento e controles de conflito fazem parte da requisição

O contrato de atualização inclui merge_metadata, merge_provenance e detect_conflicts, todos com valor padrão true, além de supersession_reason. O caminho de persistência incrementa a versão da memória e mantém status/superseded_by/evidências de conflito no contrato público de memória; leia os dados de implementação retornados como resultado atual, enquanto a resposta OpenAPI continua sem tipagem.

• Mescle metadados e proveniência quando a correção deve manter as evidências existentes.
• Mantenha detect_conflicts habilitado quando edições concorrentes ou versões conflitantes forem relevantes.
• Use supersession_reason quando a correção substituir intencionalmente uma versão anterior.

Verifique o escopo corrigido

Depois de uma correção, faça uma leitura com escopo e examine os campos de versão, status, proveniência e conflito retornados. A recuperação continua seguindo o escopo autenticado e os filtros de status da memória; um PATCH bem-sucedido, por si só, não prova que o resultado no escopo desejado está visível.

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