claims-no-vinculados

Revisar claims no vinculados

Lee convenciones compartidas y publicación antes de escribir.

knowledge_remember guarda un claim sin una página de asunto cuando ningún nombre en él coincide exactamente con una página. El mantenimiento programado ejecuta entonces knowledge_relink, que solo vincula claims cuya página fuente registrada es una página de entidad o cuyo texto nombra exactamente una página. El resto permanecen sin vincular y son invisibles desde las páginas que les conciernen. Esta habilidad maneja ese residuo con criterio. Trabaja en este orden: enlazar, luego duplicados y claims reemplazados, luego prosa de página.

1. Enumerar el residuo

Llama a knowledge_status para el alcance previsto y a knowledge_ontology para la huella digital actual. Ejecuta knowledge_relink sin dryRun primero para que cada claim recordado que pueda enlazar esté enlazado. Luego lista el residuo con knowledge_relink dryRun: true, include: "all" y limit: 10, siguiendo nextCursor: cada claim actual sin página vinculada y sin página fuente, independientemente de la herramienta que lo guardó. Cada llamada informa como máximo 10 ejemplos por resultado, así que un límite de 10 devuelve cada claim que examinó.

Lee cada claim con knowledge_record y metadataView: "full". Su subject_hint, cuando está presente, es la propia descripción de quien guardó sobre qué trata el claim y la pista más fuerte sobre su asunto. Agrupa los claims por lo que tratan (una característica, PR, hilo de decisión, persona o preferencia) antes de elegir páginas. La mayoría de los claims solo tienen sentido junto a sus vecinos: una serie de instantáneas de estado sobre un PR generalmente terminan en un claim de resultado.

2. Elegir páginas de asunto

Para cada grupo, encuentra páginas candidatas con knowledge_grep y knowledge_lookup, y lee su Estado y Cronología. Ignora páginas retiradas y páginas de fixture.

• El asunto principal es sobre lo que el claim afirma algo. Añade un asunto secundario solo cuando el claim también afirma algo sobre esa entidad, como la persona que tomó la decisión o la empresa cuyo producto fue configurado. Una mención pasajera no es un asunto. Dos o tres asuntos suelen ser suficientes.
• Una preferencia o decisión expresada por una persona pertenece a la página de esa persona. No conviertas la preferencia de una persona en una política de proyecto o empresa.
• Coincide la identidad basándote en evidencia, no en nombres similares. Cuando un claim nombra algo que podría ser una página existente (por ejemplo, un nombre de producto que podría ser un servicio diferente), confírmalo a partir de evidencia como configuración, una URL o los propios alias de la página. Si sigue siendo incierto, deja el claim sin vincular e infórmalo.

Vincula con knowledge_annotate entities, pasando la lista completa (reemplaza la existente) y la revisión y hash actuales del claim. El texto de la afirmación, la evidencia y el ciclo de vida permanecen sin cambios.

3. Crear páginas faltantes

Vincular cada claim a la página existente más cercana puede enterrar un asunto real en la Cronología de una página amplia. Crea una página cuando:

• un asunto discreto (una característica, proyecto, herramienta o PR sustancial) tiene aproximadamente cinco o más claims, o tiene su propio diseño, prueba e historial de resultados; o
• una persona u organización es autora, propietaria o decidió algo en los claims, no tiene página y tiene evidencia de identidad (por ejemplo, el autor del PR mostrado por gh pr view).

No crees una página para una única mención o una corrección puntual que cubra una entrada de Cronología. Usa knowledge_save_page con el type de la ontología, alias y la evidencia de identidad como source. Las páginas de persona usan identity.status: partial a menos que la identidad esté completamente establecida. Escribe un Estado breve que cite los claims y una Cronología fechada. Luego vincula los claims a la nueva página, manteniendo sus asuntos existentes como secundarios, y vincula la nueva página desde su página principal.

4. Retirar duplicados y claims reemplazados

• Duplicado: dos claims afirman el mismo hecho, decisión o preferencia sobre el mismo evento. Conserva el que tenga recuerdo aprobado por el propietario, si no, el anterior, si no, el que tenga atribución más completa. Copia cualquier evidencia que le falte al superviviente con knowledge_annotate addEvidence, luego retira el otro con knowledge_withdraw con una razón que nombre el ID del superviviente.
• Reemplazado: un claim posterior corrige explícitamente al anterior (por ejemplo, un asistente corrigiendo su propio informe), decide una pregunta que el claim anterior dejó abierta, o informa el estado final del mismo elemento específico (mismo PR, commit o decisión). Retira el claim anterior con una razón que nombre el claim reemplazante. No uses knowledge_correct aquí: publica una nueva copia del reemplazo, lo que crea otro duplicado.
• Ninguno: instantáneas de diferentes momentos (CI rojo en un head, una fusión después) son historia, no errores. Consérvalas. La contradicción por sí sola no justifica una retirada. Cuando no estés seguro, conserva ambos e informa el par.

5. Actualizar la prosa de la página

Vincular hace que los claims sean accesibles desde sus páginas; no cambia lo que dice una página. Edita una página solo cuando los claims cambien su estado duradero: una decisión, una preferencia, un cambio implementado o lanzado, una nueva capacidad, una pregunta abierta resuelta, o texto de página que los claims posteriores muestren que es incorrecto.

• Colapsa una serie de instantáneas de progreso en su resultado. Las instantáneas (ejecuciones de CI, PR abiertos, commits locales) son como máximo entradas de Cronología fechadas, nunca Estado.
• Verifica el estado mutable en vivo antes de escribirlo como actual (por ejemplo, gh pr view para el estado de fusión) y di cuándo lo verificaste. Una fusión no es un despliegue, y un despliegue no es prueba de que una Puerta de enlace determinada ejecute el código.
• Cuando un diseño o página de decisión contradice una decisión posterior, añade una enmienda fechada junto al texto original en lugar de reescribirlo. Marca las preguntas abiertas respondidas como resueltas y conserva la pregunta original.
• Cita cada oración añadida con enlaces [[claim-id|etiqueta]] a los claims.

Usa knowledge_edit_body para ediciones de sección. Calcula los desplazamientos UTF-16 a partir de una lectura completa nueva, y relee la revisión y el hash antes de cada edición: otras sesiones editan páginas ocupadas concurrentemente. Prefiere insertar texto sobre reemplazarlo. Reemplaza una sección de Estado completa solo cuando todo ella esté desactualizada, y conserva los enlaces a claims que ya tenía.

6. Verificar e informar

Ejecuta knowledge_verify con expectedEntities para cada claim vinculado y expectedLinks para cada página nueva o editada. Enumera el residuo de nuevo: pueden haber llegado nuevos claims recordados mientras trabajabas. Manéjalos de la misma manera o infórmalos.

Informa el número de claims examinados y vinculados, páginas creadas, claims retirados (con el claim superviviente o reemplazante para cada uno), páginas editadas y claims que quedan sin vincular con la razón para cada uno. Cuando se ejecute sin supervisión, nunca pidas una decisión: deja sin tocar las identidades inciertas, los duplicados inciertos y las páginas que solo crearías basándote en una suposición, y enuméralos en el informe para que los revise una persona.

Ejecutarse como la revisión programada

El mantenimiento de Conocimiento pone en cola esta revisión después de su paso de reenlace nocturno cuando todavía hay claims recordados privados sin vincular (maintenance.reviewJobId). La ejecución es sin supervisión:

• Primero llama a knowledge_status. Si el alcance no es private o las escrituras están deshabilitadas, responde con AUTOMATION_FAILED en su propia primera línea y la razón: el trabajador ha perdido el acceso del propietario y debe ser configurado de nuevo.
• Trabaja a través de los pasos 1 a 6. Verifica el residuo de nuevo antes de detenerte, ya que los claims guardados durante la ejecución son parte del mismo backlog.
• Si no hay nada que hacer, responde NO_REPLY. De lo contrario, responde con el informe del paso 6.

Configuración de la revisión programada

La revisión necesita acceso privado del propietario, que solo tiene una sesión descendiente de la conversación directa del propietario. Configúrala desde esa conversación:

1. Genera un trabajador mantenido: sessions_spawn con runtime: "subagent", cleanup: "keep" y context: "isolated", cuya tarea es llamar a knowledge_status e informar el alcance. Continúa solo si informa private con escrituras habilitadas. Conserva la clave de sesión devuelta.

2. Crea la automatización vinculada a ese trabajador. Necesita una programación, así que asígnale una fecha única dentro de años; el mantenimiento lo ejecuta bajo demanda.

   openclaw automations add --agent <agente> --name knowledge-unlinked-claims-review \
     --session "session:<clave-sesión-trabajador>" --at <fecha-años-adelante> --keep-after-run \
     --model <proveedor/modelo> --no-deliver --timeout-seconds 3600 \
     --message "Sigue la habilidad knowledge-unlinked-claims como la revisión programada."
   

   El trabajo registra la cuenta de inferencia con la que fue creado. Elige un modelo que use esa cuenta (un proveedor con un perfil de autenticación); de lo contrario, cada ejecución falla antes de que se llame al modelo.

3. Establece plugins.entries.knowledge.config.maintenance.reviewJobId al ID del trabajo.

4. Pruébalo: openclaw automations run <id-trabajo> --wait debe terminar con el trabajador informando el alcance privado, y maintenance_status informa el resultado de la revisión después del siguiente paso.

Deshabilita la automatización para pausar la revisión. Restablecer o eliminar la conversación del propietario de la que provino el trabajador revoca su acceso; configura la revisión de nuevo.