consolidación-de-reclamaciones-de-conocimiento

Revisión de consolidación de reclamaciones

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

Las reclamaciones se acumulan más rápido de lo que se curan las páginas. knowledge_remember guarda una reclamación sin una página de tema cuando ningún nombre en ella coincide exactamente con una página, y el mantenimiento programado knowledge_relink enlaza solo reclamaciones cuya página de origen es una página entidad o cuyo texto nombra exactamente una página. Las reclamaciones enlazadas también se amontonan: una página central (hub) acumula instantáneas de estado, duplicados y reclamaciones que pertenecen a un tema más específico. Esta revisión ejecuta un procedimiento sobre un ámbito elegido. Trabaja en este orden: elige el ámbito, enlaza, luego duplicados, reclamaciones reemplazadas y series de instantáneas, luego prosa de la página.

1. Elegir el ámbito y enumerarlo

Llama a knowledge_status para el ámbito previsto y knowledge_ontology para la huella digital actual. Luego enumera exactamente un conjunto inicial:

• Residuo no vinculado (el valor predeterminado, y el único ámbito de las ejecuciones del escriba). Ejecuta knowledge_relink sin dryRun primero para que cada reclamación recordada que pueda enlazar sea enlazada. Luego lista el residuo con knowledge_relink dryRun: true, include: "all" y limit: 10, siguiendo nextCursor: cada reclamación actual sin página enlazada y sin página de origen, sin importar qué herramienta la guardó. Cada llamada informa como máximo 10 ejemplos por resultado, por lo que un límite de 10 devuelve cada reclamación que examinó.
• Una página, para una página central o una página que excede su presupuesto de tamaño. Lista sus reclamaciones actuales con knowledge_connections id, direction: "claims", view: "full" y includeCards: true, siguiendo nextOffset con los mismos filtros. Reinicia cuando snapshot cambie. En un hub, agrupa primero desde las tarjetas y trabaja un grupo a la vez; no leas cada reclamación completa de antemano.
• Un tema, opcionalmente desde una fecha. Cuando el tema tiene una página, lista sus reclamaciones con knowledge_timeline entity, timeField: "recorded_at" y since, siguiendo nextOffset. También busca reclamaciones archivadas en otro lugar o no vinculadas con knowledge_grep kind: "claim", los nombres distintivos del tema (un número de PR, un SHA de commit, un nombre de funcionalidad) y el mismo since/timeField. Conserva solo las reclamaciones que realmente tratan sobre el tema.

Indica el ámbito en el informe. Lee cada reclamación que cambiarás con knowledge_record y metadataView: "full". Su subject_hint, cuando esté presente, es la descripción del propio guardador sobre de qué trata la reclamación y la pista más fuerte sobre su tema. Agrupa las reclamaciones por de qué tratan (una funcionalidad, PR, commit, hilo de decisión, persona o preferencia) antes de elegir páginas. La mayoría de las reclamaciones tienen sentido solo junto a sus vecinas: una serie de instantáneas de estado sobre un PR generalmente termina en una reclamación de resultado.

2. Elegir páginas de tema

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

• El tema principal es sobre lo que la reclamación afirma algo; enuméralo primero en entities. Agrega un tema secundario solo cuando la reclamación también afirme 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 tema. Dos o tres temas suelen ser suficientes.
• El tema principal es la página más específica sobre la que trata la reclamación: una reclamación sobre un PR pertenece a la página de ese PR, no solo al proyecto al que pertenece el PR. La página más amplia sigue siendo un tema solo cuando la reclamación dice algo sobre ella, como una decisión a nivel de proyecto, política o lanzamiento.
• 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.
• Empareja la identidad con evidencia, no con nombres similares. Cuando una reclamación nombre algo que podría ser una página existente (por ejemplo un nombre de producto que podría ser un servicio diferente), confírmalo con evidencia como configuración, una URL o los propios alias de la página. Si sigue siendo incierto, deja la reclamación donde está e informa.

Enlaza con knowledge_annotate entities, pasando la lista completa (reemplaza la existente) y la revisión y hash actuales de la reclamación. El texto de la aserción, la evidencia y el ciclo de vida permanecen sin cambios. Enlaza una reclamación antes de supercederla: las reclamaciones supercedidas no pueden ser reenlazadas.

3. Crear páginas faltantes y reenlazar a ellas

Enlazar cada reclamación a la página existente más cercana puede enterrar un tema real en una página amplia. Crea una página cuando:

• un tema discreto (una funcionalidad, proyecto, herramienta o PR sustancial) tiene aproximadamente cinco o más reclamaciones, o tiene su propio diseño, prueba e historial de resultados; o
• una persona u organización es autora, propietaria o decidió algo en las reclamaciones, 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 sola mención o una corrección puntual que cubra una reclamación con fecha. Usa knowledge_save_page con el tipo de ontología type, 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 corto que cite las reclamaciones; su Línea de Tiempo se deriva de ellas. Enlaza la nueva página desde su página padre.

Luego reenlaza las reclamaciones del grupo, incluidas las instantáneas que el paso 4 supercederá. La nueva página se convierte en el tema principal de cada reclamación. Mantén la página amplia en la que se archivaron las reclamaciones (a menudo el hub desde el que comenzó esta revisión) solo para reclamaciones que digan algo sobre ella, según la regla del paso 2; elimínala del resto. Mantén otros temas secundarios existentes que aún califiquen. Por debajo del umbral, deja las reclamaciones en sus páginas actuales.

4. Retirar duplicados, reclamaciones reemplazadas y series de instantáneas

• Duplicado: dos reclamaciones afirman el mismo hecho, decisión o preferencia sobre el mismo evento. Conserva la que tenga recuperación aprobada por el propietario, si no la más antigua, si no la que tenga la atribución más completa. Copia cualquier evidencia que falte al superviviente con knowledge_annotate addEvidence, luego knowledge_withdraw la otra con una razón que nombre el ID del superviviente.
• Reemplazada: una reclamación posterior corrige explícitamente la anterior (por ejemplo un asistente corrigiendo su propio informe) o decide una cuestión que la reclamación anterior dejó abierta. Supercede la reclamación anterior por la posterior con knowledge_supersede, con una razón que diga qué la reemplazó. No uses knowledge_correct aquí: publica una nueva copia del reemplazo, lo que crea otro duplicado.
• Serie de instantáneas: varias instantáneas de estado sobre un elemento específico (el mismo PR, commit o hilo de decisión: CI rojo en un head, revisión solicitada, CI verde) seguidas de una reclamación de resultado sobre el mismo elemento (fusionado, cerrado, revertido, lanzado, decidido, abandonado). Supercede cada instantánea en la serie por el resultado en una sola llamada knowledge_supersede (hasta 25 reclamaciones). Todos estos deben cumplirse, según el texto de las reclamaciones y sus fechas:
  • cada instantánea y el resultado nombran el mismo elemento específico, no meramente el mismo proyecto;
  • el resultado está fechado después de cada instantánea que supercede y establece un estado final, no otro intermedio;
  • el resultado y las instantáneas comparten una página de tema (enlázalos primero, paso 3); la herramienta rechaza reclamaciones sin una página común. Una instantánea fechada después del resultado, o una sobre un head diferente o un elemento diferente, permanece.
• Ninguno: las instantáneas de diferentes momentos que ningún resultado posterior reemplaza (CI rojo, luego CI verde, sin fusión todavía) son historia, no errores. Consérvalas. La contradicción por sí sola no justifica un retiro o una supersesión. Cuando no estés seguro, conserva ambas e informa el par.

knowledge_supersede mantiene el texto, la evidencia, la procedencia y la historia de cada reclamación supercedida, registra superseded_by y la razón en ella, y deja la reclamación supercedente sin cambios. Las lecturas predeterminadas dejan de mostrar reclamaciones supercedidas; las lecturas históricas (historical: true, lifecycle: "all") y knowledge_history todavía lo hacen. Si una supersesión fue incorrecta, llámala de nuevo con undo: true, la misma reclamación by y los límites de su recibo items.

5. Actualizar la prosa de la página

Enlazar hace que las reclamaciones sean accesibles desde sus páginas; no cambia lo que una página dice. Edita una página solo cuando las reclamaciones 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 reclamaciones posteriores muestren que es incorrecto.

• Colapsa una serie de instantáneas de progreso en su resultado. Las instantáneas (ejecuciones de CI, PRs abiertos, commits locales) son como mucho reclamaciones de eventos con fecha, 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 específica ejecute el código.
• Cuando un diseño o página de decisión contradiga una decisión posterior, agrega una enmienda con fecha junto al texto original en lugar de reescribirlo. Marca las preguntas abiertas respondidas como resueltas y conserva la pregunta original.
• Cita cada oración agregada con enlaces [[claim-id|label]] a las reclamaciones.
• Los cuerpos de página tienen un presupuesto de tamaño (presupuestos de página). Una edición con state: "rejected" no guardó nada, pero las reclamaciones enlazadas ya contienen los hechos. Mueve una sección a la página de su tema con knowledge_extract_section (creando la página según el paso 3 cuando sea necesario), relee y vuelve a intentarlo. Nunca acortes otra prosa para hacer espacio. La extracción convierte el destino en el primer tema de las reclamaciones que la sección cita y mantiene sus temas existentes, incluida la página de la que extrajiste. Aplica el paso 2 a cada una de esas reclamaciones y elimina la página de origen con knowledge_annotate entities donde la reclamación no diga nada sobre ella.

Usa knowledge_edit_body para ediciones de sección. Calcula los desplazamientos UTF-16 desde una lectura completa fresca, 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 esté desactualizado, y conserva los enlaces de reclamación que ya tenía.

6. Verificar e informar

Ejecuta knowledge_verify con expectedEntities para cada reclamación enlazada y expectedLinks para cada página nueva o editada. Enumera el ámbito nuevamente: nuevas reclamaciones pueden haber llegado mientras trabajabas. Manéjalas de la misma manera o infórmalas.

Informa el ámbito, el número de reclamaciones examinadas, enlazadas y reenlazadas, páginas creadas, reclamaciones supercedidas (con la reclamación supercedente para cada serie), reclamaciones retiradas (con la reclamación superviviente para cada una), páginas editadas, y reclamaciones dejadas sin cambios que consideraste, con la razón para cada una. Al ejecutarse sin supervisión, nunca pidas una decisión y nunca adivines: deja identidades inciertas, duplicados inciertos, series de instantáneas cuyo resultado no es seguro, y páginas que solo crearías basándote en una suposición, sin tocar, y enuméralos en el informe para una persona.

Ejecuciones del escriba

El escriba Consolidación de Conocimiento ejecuta esta revisión sin supervisión sobre el residuo no vinculado, según el horario de su prompt. Su prompt verifica el acceso y configura su automatización; esta sección es solo el trabajo de una ejecución.

• Ejecuta el paso 1 para el residuo no vinculado. Cuando el residuo está vacío, informa cero reclamaciones examinadas y continúa con las Líneas de Tiempo escritas a continuación.
• De lo contrario, trabaja a través de los pasos 2 a 6, y verifica el residuo nuevamente antes de detenerse, ya que las reclamaciones guardadas durante la ejecución son parte del mismo backlog.
• Luego retira hasta 10 secciones escritas de ## Timeline, empezando por la más grande (retirar una Línea de Tiempo escrita). Encuéntralas con knowledge_grep para Timeline y confirma el encabezado en el cuerpo de la página. Cuenta las secciones retiradas y las páginas que aún llevan una.
• No hagas preguntas. Proporciona el informe del paso 6; la línea de estado de cierre cuenta las reclamaciones examinadas, enlazadas, supercedidas, retiradas y dejadas, luego las Líneas de Tiempo retiradas y dejadas.