knowledge-correct

Corregir conocimiento guardado mediante herramientas de agente

Leer las convenciones compartidas y publicación antes de escribir.

Identificar el registro propietario

Usar un ID de registro/afirmación estructurado proporcionado y su revisión como objetivo principal, no solo su etiqueta de visualización. Leer knowledge_record con metadatos y evidencia; confirmar su revisión/hash actual. Una revisión referenciada que ha cambiado requiere releer y conciliar la solicitud, no actuar silenciosamente sobre una nueva aserción. Sin una referencia exacta, usar búsqueda/localización, inspeccionar candidatos y preguntar solo cuando el objetivo solicitado o la corrección sigan siendo materialmente ambiguos.

Distinguir una afirmación guardada errónea de una respuesta no respaldada, declaraciones de fuentes en conflicto y un hecho que cambió con el tiempo. La contradicción por sí sola no autoriza la supersesión; el único caso no-usuario es una declaración vigente que su propio titular reemplazó explícitamente, según la publicación. No fabricar un "hecho de guardia" almacenado cuando no existe ningún registro ni tratar una retractación como evidencia de su opuesto.

Aplicar la operación correcta

• Corrección de afirmación o relación explícita: llamar a knowledge_correct con el ID exacto, expectedRevision y expectedHash observados, motivo, UUID de vault y huella de ontología observados, y un replacement completo del mismo kind. Los campos de reemplazo usan el contrato de create-claim/create-relationship; hay un ID de solicitud externo, no una segunda solicitud de reemplazo. Preservar el contexto compatible, la atribución, las fechas exactas y la evidencia; eliminar o revisar solo lo que la corrección cambia realmente. La operación publica el reemplazo y reemplaza la afirmación anterior juntos, con enlaces en ambas direcciones.
• Retiro sin reemplazo: llamar a knowledge_withdraw con el ID exacto, revisión/hash, motivo y UUID de vault. Acepta páginas, afirmaciones y relaciones explícitas. Una arista se identifica por su propio ID, no por su par de extremos. Preserva la evidencia/historial original y no es eliminación de archivo.
• Corrección de prosa de página: usar knowledge_save_page con revisión, preservando el material original no relacionado y las fuentes. Las correcciones de página son revisiones, no identidades de entidad de reemplazo.
• Dos páginas para una entidad: llamar a knowledge_merge con la página superviviente, la duplicada, la revisión/hash actual de ambas páginas y un motivo. Mantener la página con la identidad más completa (nombre real, más conexiones) como superviviente; pasar title para renombrarla y body cuando la página combinada deba decir más que la prosa actual de la superviviente. El ID, título, alias, afirmaciones, relaciones y enlaces de la duplicada se resuelven entonces a la superviviente; nada se corrige uno por uno. Deshacer una fusión errónea con knowledge_unmerge.

Una corrección explícita del usuario puede proporcionar evidencia: retener su declaración exacta con knowledge_attach, atribuirla al usuario y hacer referencia a su localizador verificado. Usar assertion_origin: user_belief para distinguir una aserción de usuario de una declaración con fuente independiente; no afirmar verificación documental. La inferencia del agente aún necesita evidencia de premisa retenida, no una cita inventada.

Resolver un alias o identidad errónea

Usar knowledge-entities para encontrar y leer el perfil del alias, la persona establecida y sus registros conectados. Retener la identificación exacta del usuario como evidencia. Actualizar los alias compatibles y el contexto de identidad en las páginas existentes; preservar contenido no relacionado y describir la conexión con la persona establecida. Usar el ID existente de esa persona para enriquecimiento futuro. Cuando el alias ya tiene su propia página, fusionarla en la página de la persona establecida con knowledge_merge en lugar de escribir una página de puntero, retirarla o corregir sus afirmaciones una por una. Fusionar solo con evidencia de identidad (la declaración del usuario, una auto-presentación, un ID de cuenta estable compartido), nunca por similitud de nombre; knowledge_diagnostics mergeCandidates lista páginas para verificar, no páginas para fusionar. Retener la evidencia de identidad con knowledge_attach y pasarla como evidence.

Inspeccionar la prosa, afirmaciones, líneas de tiempo y relaciones afectadas dentro del alcance de la corrección. Corregir atribución errónea e identidad no resuelta donde la nueva evidencia lo respalde, usando las operaciones de página/afirmación anteriores; preservar las etiquetas de fuente, citas textuales, fechas de eventos y procedencia de la corrección. Una identidad de autor confirmada no verifica independientemente las afirmaciones factuales de ese autor.

Los cambios pasan por estas herramientas, no por ediciones manuales de Markdown, formularios de navegador, SQL o llamadas separadas de "crear luego retirar". No se aplica ningún ritual de aprobación adicional a una corrección autorizada inequívocamente por el usuario. Seguir el manejo de reintentos/conflictos de publicación; un recibo en estado aceptado/conflicto no es una reparación completada.

Inspeccionar propagación e informar honestamente

El impact.items del recibo identifica los dependientes directos/transitivos afectados conocidos en el momento de la aceptación. No los actualiza. Leer los registros afectados por ID exacto e inspeccionar su evidencia. Reparar solo los cambios respaldados dentro del alcance de la solicitud; no reemplazar ciegamente IDs de dependencia o citas de fuente con la nueva afirmación. Los registros que dependen de una afirmación inactiva se retienen del descubrimiento actual hasta que se reparen; la inspección exacta del registro/historial permanece disponible.

Buscar copias de prosa plausibles como verificación complementaria. Las búsquedas fallidas, la prosa no vinculada, los alcances ocultos y los índices incompletos impiden una promesa universal de "todas las copias corregidas". No alterar sistemas de memoria o identidad no relacionados como consecuencia automática de una corrección de Conocimiento.

Leer de nuevo el original y el reemplazo (o el objetivo retirado), verificar el ciclo de vida y la evidencia, y verificar que la búsqueda actual excluye la afirmación anterior. Responder con el ID del recibo/solicitud, los IDs de registros afectados, el motivo de la corrección/retractación y las dependencias reparadas frente a las no resueltas. Mencionar el historial retenido solo cuando sea relevante; nunca prometer borrado de originales, exportaciones o copias de seguridad.