tencentmusic/modus

modus-reinit

Se utiliza al revisar exhaustivamente el texto existente. Comparte la Guía de Evidencia, el Marco de Generación y el Contrato de Publicación; este documento solo describe las diferencias de reinit.

Primero, inventariar, luego probar los cambios

Lee completamente el texto existente y los hashes, clasificando los objetivos como unchanged, anchor-only, implementation-change, scope-change, content-repair, posiblemente retirados o texto manual. Las identidades estables y las definiciones principales se reutilizan por defecto; los movimientos de rutas de código fuente/símbolos solo corrigen anclajes, los cambios en el diseño del texto no son cambios de Scope.

content-repair incluye: párrafos de plantilla genérica que reemplazan escenarios reales, anclajes representativos que reemplazan hechos, copia entre módulos, semántica poco clara de completado/fallo, relaciones complejas que carecen de diagramas que ayuden significativamente a la comprensión. El texto que realmente satisface la tarea del lector y cuyos hechos no han cambiado permanece como unchanged y se omite la escritura.

Ejecución

1. Construir sincrónicamente la evidencia de esta ronda en un solo repositorio y obtener el contexto reinit-diff; si falla, volver inmediatamente al código fuente actual. Expandir según el Contrato de Paquete de Máquina, sin leer directamente los archivos internos del bundle, y sin agotar el cursor.
2. Según el Modelado de Scope, juzgar en el orden "identidad estable → responsabilidad de entrada/objeto → cambio semántico → cambio estructural → cambio de archivo", escribiendo el alcance, el handle, el hash de lectura, el evidence/status exacto de Domain/Module, la cobertura del Domain, el resultado y los candidatos a diagrama en una tarjeta de ejecución única con schemaVersion: 2. Confirmar solo una vez las nuevas adiciones, divisiones, fusiones, movimientos, renombres o retiros ya probados. Por defecto en serie; cuando el usuario lo autorice explícitamente y existan múltiples Dominios afectados que no se superpongan, cargar Redacción en Paralelo por Dominio y usar el Contrato de Delegado de Worker de Dominio; el autor raíz continúa en exclusiva con la tarjeta de ejecución y los artefactos compartidos.
3. Para cada cambio o módulo de content-repair, usar un selector preciso para solicitar el contexto module-authoring, cotejar el doble resumen y el requestedScope; las solicitudes amplias que cubren múltiples módulos independientes de todo el dominio no son válidas. Las solicitudes precisas que no dependen entre sí pueden ser concurrentes; luego resumir y deduplicar las rutas de código fuente/símbolos del Domain actual, y luego releer en lotes. Si la solicitud falla, da resultado vacío o parcial, volver al cuerpo del método actual, configuración, SQL y pruebas para complementar la evidencia; no usar nombres de clase, firmas de interfaz o anclajes de primera línea de archivo como si el contenido estuviera restaurado. No escanear repetidamente el mismo enlace para diferentes temas, ni escribir concurrentemente el mismo texto. Redemostrar según Cierre de Escenario; revisar en la definición principal original, sin agregar changelog, y sin reescribir ni redibujar en lote debido a cambios de plantilla.
4. Leer por lotes de Domain completo el alcance afectado en el orden "definición principal de seis temas → escenario de Module → ruta de Domain". Migrar las rutas de código fuente y números de línea a los pocos anchors.locations en el frontmatter de cada documento generado; eliminar del cuerpo del texto las rutas de código fuente completas, path#L y las listas de evidencia. El objetivo de la reparación es restaurar la tarea completa, la semántica de los campos, las ramas clave, el estado y la recuperación de errores, no hacer que el archivo vuelva a tener un título, anclaje o extensión similar. Una vez cerrada la evidencia, reevaluar los candidatos según Expresión Visual con Texto e Imágenes y actualizar el único diagrama principal; la tabla de navegación no sustituye a los diagramas explicativos. La coverage-audit a nivel de Domain debe reutilizar el alcance candidate/capability/source path/symbol de este dominio, no puede usar modus/knowledge/**; sin coincidencia, resultado vacío o parcial solo desencadena complemento de evidencia o brecha explícita. Registrar los resultados válidos como cobertura de Domain; después de completar la relectura de los tres tipos de lectores, el autor raíz lee los archivos reales y los marca como reviewed. Solo cuando hay cambios en la dirección entre dominios, propiedad, estado, condición, finalización o recuperación, se actualiza la visión general raíz; Team Standard y los negocios existentes están protegidos por bytes originales por defecto; para nuevos Domain, usar modus knowledge seed-business --domain <slug> --json para crear el índice faltante.
5. Los cambios estructurales primero escriben el nuevo destino y pasan por la relectura semántica; reparar los enlaces de entrada del texto generado y la navegación, luego eliminar los archivos generados antiguos según el hash de lectura. No deducir retiro directamente de la desaparición de símbolos, resultados parciales o brechas de cobertura.
6. Después de la relectura semántica global, ejecutar modus knowledge verify --publication --json, publicar mediante CAS y releer. La publicación debe cotejar la tarjeta de ejecución schemaVersion: 2, el cuerpo del texto sin rutas de código fuente, anclajes estructurados, evidencia por Module, cobertura de Domain y decisión visual; clean sigue sin ser prueba de calidad del texto. Continuar revisando cuando haya muchos textos cortos de la misma longitud, sin escenarios reales, solo tablas de navegación, temas de estado sin transiciones o evidencia que solo cae en la primera línea del archivo. No eliminar la tarjeta de ejecución prematuramente, ni reconstruir una tarjeta más pequeña "todo revisado" basada en la salida después de perderla. Solo después de que todos los objetivos confirmados hayan alcanzado el estado final y la relectura semántica, la publicación real y la relectura posterior a la publicación estén aprobadas, se limpia la tarjeta de ejecución; las verificaciones mecánicas comunes no pueden sustituir a la publicación. Informar de manera real sobre lo unchanged, revisado, eliminado, conflictos y brechas.