xu-jin-cs/dsh-skills

ArchMap: Agente de Mapeo de Arquitectura

Agente nativo de terminal, sin interfaz web. Con llamada de cero parámetros, deriva automáticamente a los modos full/lite. También admite modos explícitos como análisis de impacto incremental, sincronización y análisis de impacto por diff.

Instalación y Dependencias

Antes del primer uso, ejecute pip3 install -r requirements.txt en el directorio raíz de este skill (consulte README.md). sentence-transformers es una dependencia opcional; si falta, la identificación vectorial retrocede automáticamente a la vectorización hash local, la funcionalidad está disponible con una precisión ligeramente reducida.

Forma de Invocación

/archmap <ruta-del-proyecto>                        # Derivación automática de cero parámetros (recomendado)
/archmap <ruta-del-proyecto> full | lite [nota]      # Modo forzado como respaldo
/archmap <ruta-del-proyecto> <texto-de-requisito>
/archmap <ruta-del-proyecto> sync
/archmap <ruta-del-proyecto> diff [nota-de-cambio]

Ejemplos:

/archmap /Users/xujin/projects/my-app
/archmap /Users/xujin/projects/my-app Nuevo sistema de puntos de usuario, que involucra la interfaz de inicio de sesión y la tabla de roles
/archmap /Users/xujin/projects/my-app sync

Enrutamiento de Modos (Derivación Automática de Cero Parámetros, Nuevo desde 2026-08-12)

La llamada de cero parámetros /archmap <ruta-del-proyecto> se deriva automáticamente según la existencia o no de una línea base, sin interruptor de conmutación manual:

• Sin línea base (archmap/full_index.json no existe) → Ejecuta automáticamente la inicialización completa full
• Con línea base → Ejecuta automáticamente el incremento mínimo lite (iteración diaria por defecto, consulte el modo G)
• Respaldo manual para escenarios especiales: palabras explícitas full / lite para forzar la especificación (después de una gran reestructuración, use full para regenerar el mapa completo, no es necesario eliminar el directorio de la línea base)

Lista de Modos

Modo A: Análisis Completo (Solo Ruta del Proyecto)

Cuando la ruta es el directorio raíz del proyecto:

1. Ejecuta un escaneo completo del código fuente
2. Divide los módulos por directorio de negocio, analiza con Workers multi-hilo
3. Agrega activos en la entidad principal, marca API/almacenamiento compartido, genera caché de vectores
4. Genera diagramas de texto Mermaid e informes Markdown 01~09
5. Escribe atómicamente los resultados en <ruta-del-proyecto>/archmap/
6. Muestra las rutas de los artefactos y un resumen

Rutas de los artefactos:

<ruta-del-proyecto>/archmap/
├── full_index.json          # Línea base completa de la arquitectura
├── vector_cache.json        # Caché de vectores de módulos
├── 01_ResumenEjecutivo.md
├── 02_DiagramaArquitectura.md              # Texto Mermaid
├── 03_DiagramaFlujoDatos.md
├── 04_DiagramaSecuencia.md
├── 05_InventarioActivosModulo.md
├── 06_InventarioActivosAPI.md
├── 07_InventarioActivosAlmacenamiento.md
├── 08_MatrizDependencias.md
└── 09_InformeValidacionGranularidad.md

Modo B: Análisis de Impacto Incremental (Ruta del Proyecto + Texto de Requisito)

Ingrese la ruta del proyecto correspondiente a la línea base existente y adjunte el texto del requisito. Este modo primero sincroniza los cambios reales en el código fuente antes de hacer coincidir el requisito. Por lo tanto, llamar a /archmap <ruta> <requisito> activa la integración de revisión:

1. Lee vector_cache.json, full_index.json, module_hashes.json en <ruta-del-proyecto>/archmap/
2. Compara el código fuente actual con las huellas dactilares de contenido del módulo (SHA256) de la última sincronización, identificando módulos modificados/nuevos
3. Solo re-analiza los módulos modificados y los fusiona de nuevo en la línea base, los módulos no modificados reutilizan directamente los datos de la línea base
4. Vectoriza el texto del requisito y lo compara con los vectores de módulos más recientes usando similitud de coseno
5. Distingue entre módulos de alta y baja confianza, recorre recursivamente las dependencias upstream/downstream
6. Solo inicia Workers para los módulos nuevos/modificados alcanzados por el requisito; los módulos de dependencia existentes reutilizan directamente los datos de la línea base, sin invocar LLM
7. Realiza una localización precisa dentro del módulo para los módulos alcanzados: identifica archivos, funciones/clases, rutas de interfaz, y el mapeo ruta→archivo, ordenados por relevancia con las palabras clave del requisito
8. Refuerzo de Recall (recall_engine): Sobre la base de la coincidencia de vectores, utiliza dos tipos de señales deterministas para expandir el conjunto afectado, sin estar sujeto al umbral del vector——① Cierre de oferta-demanda de rutas (rutas a las que se hace referencia en los módulos afectados → módulo donde se definen, y módulos que hacen referencia a las rutas definidas) ② Coincidencia forzada de palabras clave de requisito en rutas (palabras del requisito con expansión CN→EN, que alcanzan directamente las rutas definidas del módulo). Cada módulo en la salida tiene su match_sources anotado con la fuente de alcance (vector/keyword/route_closure/route_keyword)
9. Fusiona y actualiza la línea base, genera el archivo de impacto precise_analysis.json + los metadatos de predicción precise_meta.json (texto del requisito, fuente de alcance, huella dactilar hash de la línea base)
10. Muestra los módulos, API, almacenamiento y lista de archivos afectados para guiar el desarrollo preciso

Nota: La sincronización de revisión solo se activa cuando hay "línea base existente + nuevo requisito"; el primer análisis completo de un proyecto nuevo no ejecuta la sincronización.

Artefactos: Actualiza full_index.json, vector_cache.json en el directorio de la línea base, y agrega precise_analysis.json:

[
  {
    "module_id": "src_users",
    "module_path": "src/users/",
    "files": [
      {
        "file_path": "api.py",
        "functions": ["list_users", "get_user"],
        "classes": [],
        "routes": ["/api/users", "/api/users/<id>"],
        "relevance": 0.6
      }
    ],
    "route_to_files": {
      "/api/users": ["api.py"],
      "/api/users/<id>": ["api.py"]
    },
    "keyword_matches": ["api.py"]
  }
]

Modo C: Actualización por Sincronización (Ruta del Proyecto + sync)

Después de que el proyecto haya completado el análisis completo y haya entrado en desarrollo continuo, el nuevo código debe fusionarse de nuevo en la línea base existente, en lugar de re-ejecutar el análisis completo.

Invocación:

/archmap <ruta-del-proyecto> sync
/archmap <ruta-del-proyecto> sincronizar

Flujo de ejecución:

1. Lee full_index.json, vector_cache.json, module_hashes.json en <ruta-del-proyecto>/archmap/
2. Compara el código fuente actual con las huellas dactilares de contenido del módulo (SHA256) de la última sincronización
3. Solo re-analiza los módulos nuevos/modificados, los módulos no modificados ya analizados reutilizan directamente los datos de la línea base, sin invocar LLM
4. Elimina los módulos borrados y sus vectores de la línea base
5. Regenera los diagramas Mermaid y los informes Markdown 01~09
6. Actualiza atómicamente full_index.json, vector_cache.json, module_hashes.json y los archivos de informe
7. Validación de Recall (recall_engine): Si dentro de la línea base existe un archivo de predicción del análisis de impacto anterior (precise_analysis.json + precise_meta.json), compara automáticamente los módulos predichos con los módulos realmente cambiados en esta iteración:
   • Hay cambios → Produce recall_report.json (tasa de aciertos, módulos no reportados y su atribución: route_keyword_miss / closure_miss / vector_miss), agrega a recall_history.jsonl, luego consume el archivo de predicción
   • Sin cambios → Conserva la predicción, para validar en la próxima sincronización después de que se complete el desarrollo
   • La huella dactilar hash de la línea base no coincide (la predicción pertenece a un ciclo de desarrollo anterior ya finalizado) → Descarta la predicción obsoleta, no valida

Artefactos: El contenido de la carpeta de la línea base se actualiza por completo, la estructura es consistente con el Modo A, pero solo consume el costo de análisis de los módulos modificados. Cuando hay predicciones pendientes de validación, se agregan recall_report.json y recall_history.jsonl.

<ruta-del-proyecto>/archmap/
├── full_index.json          # Módulos nuevos/modificados fusionados
├── vector_cache.json        # Solo se recalculan los vectores de los módulos modificados
├── module_hashes.json       # Huellas dactilares de contenido del módulo más recientes
├── 01_ResumenEjecutivo.md
├── 02_DiagramaArquitectura.md
├── 03_DiagramaFlujoDatos.md
├── 04_DiagramaSecuencia.md
├── 05_InventarioActivosModulo.md
├── 06_InventarioActivosAPI.md
├── 07_InventarioActivosAlmacenamiento.md
├── 08_MatrizDependencias.md
└── 09_InformeValidacionGranularidad.md

Ritmo de uso típico:

1. Primera vez: /archmap /ruta/al/proyecto
2. Desarrolle una nueva función y modifique el código fuente
3. Sincronización de revisión: /archmap /ruta/al/proyecto sync
4. Localice el impacto: /archmap /ruta/al/proyecto Nueva función de puntos

Modo D: Sondear Reglas Subyacentes de ETL (Disparo Automático)

Para proyectos con directorios de características ETL (existe tongue_diagnosis/etl / etl_config / etl/core), durante el análisis completo y la actualización de sincronización, se generan automáticamente 7 productos de mantenimiento de cambios ETL, escritos en <ruta-del-proyecto>/archmap/etl_rules/:

#	Producto	Contenido
①	IndiceGeneralReglasETL.md	Árbol de directorios de 7 capas (Preprocesamiento/Limpieza→Fragmentación de Chunks→Escritura Vectorizada→Conciliación de Consistencia→Almacenamiento Aislado→Reintento de Excepción→Orquestación ETL) + Código único de regla (ETL-CHUNK-01, etc.) + Etiquetas de palabras clave + Índice de búsqueda rápida + Flujo de uso de 7 pasos
②	details/ETL-{codigo}.md (1 por regla)	7 capítulos uniformes: Identificación básica de la regla / Lógica de ejecución subyacente completa / Localización precisa del código fuente / Restricciones de entrada y salida / Reglas de dependencia asociadas / Registro de cambios históricos / Estándar de verificación de pruebas
③	etl_rule_mapping.json	Tabla de mapeo de reglas ETL a código y configuración (legible por máquina)
④	DiagramaDependenciasReglasETL.md	Diagrama de dependencias Mermaid + Lista de impacto textual + Clasificación de impacto (Alto/Medio/Bajo)
⑤	TablaLineaBaseParametrosGlobalesETL.md	Valores de línea base de todos los parámetros de reglas + Origen del archivo de configuración
⑥	ListaEvaluacionRiesgoCambiosReglasETL.md	Nivel de riesgo/descripción/prueba de regresión + Acciones previas al cambio para todas las reglas
⑦	etl_rule_search_index.json	Índice de búsqueda de máquina (entradas de reglas + índice rápido de palabras clave → código de regla)
⑧	InformeAlineacionContratoConfiguracionETL.md + config_contract_report.json	Detección de deriva del contrato de configuración-código (alineación periódica): existencia real de claves yaml + característica de cadena read/use grep → aligned (conectado)/ unused (configuración muerta)/ stale (residuo de código)/ missing_from_yaml (inconsistencia de contrato) + sugerencia de manejo

Puntos clave:

• Alineación periódica (deriva del contrato de configuración): Después de cambiar la configuración/el punto de consumo del código, ejecute /archmap <ruta-del-proyecto> sync. El informe ⑧ actualiza automáticamente el estado de cada campo (la existencia del campo ≠ efectividad: unused/stale necesita ser conectado o limpiado según la sugerencia de manejo). Ejemplos de deriva de línea base existente: El peso RRF no es efectivo (rag_engine._rrf_fuse weights hardcodeado a 1.0), la configuración max_ctx_tokens no está conectada, reconcile.enabled/batch_size es configuración muerta, embedding.yaml batch_size no se consume.
• El número de línea de localización del código fuente se resuelve en tiempo de ejecución mediante grep por nombre de función/cadena de característica. Después de cambiar el código, /archmap <ruta-del-proyecto> sync actualiza todos los números de línea y productos.
• Clasificación de profundidad de análisis P0/P1/P2 (Fase 2, 2026-08-12): risk_level alto → Análisis profundo P0 (número de línea+configuración+contrato), medio → Análisis estándar P1 (número de línea), bajo → Análisis ligero P2 (solo verificación de existencia de archivo, número de línea salta el análisis y no se cuenta en el alcance unresolved). Los encabezados de documentos detallados/directorio de índices generales/mapping JSON/search_index JSON llevan la marca priority. El resumen contiene estadísticas priority_counts y parse_depth. Una sola regla puede anular la derivación escribiendo explícitamente el campo priority en etl_rule_registry.py.
• Convención de relleno (debe ejecutarse después de modificar reglas/pasos/configuración ETL): /archmap <ruta-del-proyecto> sync rellena automáticamente tres aspectos：① Números de línea (análisis en tiempo real con grep)；② Línea base de parámetros (lee etl.yaml/embedding.yaml/chunking.yaml en tiempo de ejecución, los parámetros de reglas correspondientes en ③⑤⑦ se actualizan automáticamente al valor actual del archivo de configuración)；③ Cambios a nivel semántico (cambio de nombre de regla/cambio de comportamiento/ajuste de nivel de riesgo) después de agregar registros history en etl_rule_registry.py y volver a ejecutar sync para regenerar. No ejecutar sync provoca deriva entre la documentación y el código/la configuración.
• Punto de entrada de búsqueda: Lea etl_rules/etl_rule_search_index.json (máquina) o la tabla de palabras clave del directorio de índices general (humano).
• Los documentos detallados contienen una sección de estándar de verificación de pruebas. Después de modificar una regla, regrese al caso de uso correspondiente.
• El mecanismo de anulación del registro de reglas ETL personalizadas se encuentra en la sección "Configuración a nivel de proyecto" de README.md.

Modo E: Activos de Entrada de Diseño de Pruebas (Test Design Input Assets)

Los diagramas de arquitectura, diagramas de flujo de datos, diagramas de secuencia, inventarios de activos y matrices de dependencias producidos por el análisis completo de ArchMap se pueden usar directamente como entrada para test-case-designer, impulsando el diseño de pruebas de tres elementos "nodo + rama + método".

Productos Consumibles por el Diseño de Pruebas

Archivo de Producto	Propósito del Diseño de Pruebas	Contenido Extraído
02_DiagramaArquitectura.md	Identificar las capas del sistema y los límites de los módulos	Nodos de capa (Trigger/Definition/Persistence/Engine/Validation)
03_DiagramaFlujoDatos.md	Identificar flujos de datos de extremo a extremo	Nodos de flujo de datos, entrada, salida, punto de persistencia
04_DiagramaSecuencia.md	Identificar orden de llamada y relaciones de concurrencia/espera	Secuencia de llamada, límites síncronos/asíncronos, puntos de retorno de excepción
05_InventarioActivosModulo.md	Identificar módulos funcionales y responsabilidades	Nombre del módulo, funciones principales, descripción de responsabilidad
06_InventarioActivosAPI.md	Identificar nodos de prueba de interfaz	Ruta, método, parámetros, estructura de retorno, código de error
07_InventarioActivosAlmacenamiento.md	Identificar puntos de prueba de persistencia de datos	Tipo de almacenamiento, campos, restricciones, ciclo de vida
08_MatrizDependencias.md	Identificar el impacto de los cambios y el alcance de la regresión	Relaciones de llamada entre módulos, API/almacenamiento compartido
precise_analysis.json	Localizar con precisión el alcance de la prueba para requisitos incrementales	Módulos modificados, archivos involucrados, funciones/rutas, relevancia

Formato Estándar de Entrada de Diseño de Pruebas

Después de leer los productos anteriores, test-case-designer debe reducir la información a la siguiente estructura estándar (como un producto intermedio de diseño para ser enviado a revisión junto con execution-list.json, no como un archivo de producto de archmap—los productos del motor archmap son solo 01~09):

## Inventario de Nodos de Prueba (Node Inventory)

| ID de Nodo | Nombre de Nodo | Módulo | Función/Propósito | Entrada | Salida | Persistencia |
|------------|----------------|--------|-------------------|---------|--------|--------------|
| N-001 | create_workflow_endpoint | webui.py | Crear un nuevo flujo de trabajo a través de la Web UI | {name, mode} | flow.yml / SKILL.md / directorio | Árbol de directorio recién creado |
| N-002 | validate_flow_structure | workflow.py | Validar la estructura legal de flow.yml | flow_data | Lista de errores o lista vacía | Ninguna |
| N-003 | gate_a_check | engine.py | Verificación de admisión antes de la ejecución | agent, state | passed/errors/log | engine_state.json |

## Lista de Cierres de Ramas (Branch Closure)

| Nodo Fuente | Condición de Rama | Rama Verdadera | Rama Falsa | Entrada Inválida | Inconsistencia de Estado |
|-------------|-------------------|----------------|------------|------------------|--------------------------|
| N-001 | name está vacío | Continuar creando | Retornar 400 | Extremadamente largo/caracteres especiales | Directorio padre no establecido |
| N-003 | upstream está todo completado | Entrar en Gate B | bloqueado | Nodo desconocido | Hash del entregable alterado |

## Mapeo de Métodos de Prueba (Method Mapping)

| Nodo | Valor Límite (BV) | Clase de Equivalencia (EC) | Lógica de Requisito (DL) | Escenario (SC) | Excepción (EX) | Compatibilidad (CP) | Seguridad de Interfaz (IS) |
|------|--------------------|----------------------------|--------------------------|----------------|----------------|----------------------|----------------------------|
| N-001 | Límite de longitud de nombre | Nombre válido/inválido | Crear→Generar→Retornar | Flujo de creación normal | Directorio padre faltante | — | Path traversal/caracteres especiales |
| N-003 | Límite de max_retry | Upstream completado/no completado | Gate A→Ejecutar→Gate B | Progreso normal | Hash no coincide | Con/sin jsonschema | — |

Forma de Consumo en Escenarios Incrementales

Cuando el PM presenta un nuevo requisito:

1. Llame a /archmap <ruta-del-proyecto> "texto-del-requisito" para generar/actualizar precise_analysis.json.
2. test-case-designer lee primero los módulos modificados y los archivos involucrados de precise_analysis.json.
3. Solo extrae nodos de prueba para los módulos modificados y sus dependencias directas, evitando un rediseño completo.
4. Marca los casos de prueba con baseline_affected: true en execution-list.json para una regresión precisa.

Contrato de Interfaz con test-case-designer

test-case-designer tiene capacidad de análisis autónomo. Después de iniciarse, procesa de acuerdo con la siguiente lógica:

1. Descubrimiento autónomo de resultados de análisis existentes: Verifica si <ruta-del-proyecto>/archmap/ existe y contiene 02_DiagramaArquitectura.md y 03_DiagramaFlujoDatos.md válidos.
   • Si existen: Lee directamente los productos 02~08 + precise_analysis.json (escenario incremental) como entrada de diseño de pruebas, evitando análisis repetidos.
   • Si no existen o están desactualizados: Llama por sí mismo a /archmap <ruta-del-proyecto> (completo) o /archmap <ruta-del-proyecto> "texto-del-requisito" (incremental) para generar resultados de análisis, y luego los lee y usa. El PM no necesita llamar a archmap por separado antes de la prueba.
2. Lee 02_DiagramaArquitectura.md + 03_DiagramaFlujoDatos.md + 04_DiagramaSecuencia.md, identifica nodos de prueba a nivel de sistema.
3. Lee 05_InventarioActivosModulo.md + 06_InventarioActivosAPI.md + 07_InventarioActivosAlmacenamiento.md, identifica nodos de prueba a nivel de módulo.
4. Lee 08_MatrizDependencias.md, identifica dependencias entre nodos y el impacto.
5. Genera la lista reducida de nodos/ramas/métodos como producto intermedio de diseño (es decir, regla 32 Paso 1.8 "Lista de Nodos y Ramas de Prueba"), para enviar a revisión junto con execution-list.json.

Modo F: Análisis de Impacto por Diff (Ruta del Proyecto + diff, Nuevo desde 2026-08-12)

Análisis de impacto de diferencias después de una actualización de versión, proporcionando entrada de diff autorizada para pruebas incrementales de caja blanca y otros procesos posteriores. Independiente de git (disponible para proyectos sin repositorio), cero invocaciones a LLM, completado en segundos.

Momento de ejecución (punto de control fijo): Debe ejecutarse una vez después de completar la adición/modificación de funciones y antes de la fase de revisión. El cambio actual (hora+contenido de modificación+intervalo de línea+cierre de impacto) se registra automáticamente en el historial de cambios como material de entrada para la revisión. Después de la aceptación, use sync para actualizar la línea base y rellenar los documentos de análisis 01~09—el registro de diff, el historial de cambios y los documentos de análisis constituyen un todo.

Invocación:

/archmap <ruta-del-proyecto> diff
/archmap <ruta-del-proyecto> diff Agregar validación de parámetros ilegales a la función de cambio de velocidad de video

Flujo de ejecución:

1. Lee la instantánea de línea del directorio de la línea base file_line_hashes.json (se escribe automáticamente durante full/sync; si la primera diff no tiene instantánea, la inicializa y sugiere que la próxima ronda se puede comparar)
2. Compara archivo por archivo con difflib el hash de línea actual con la instantánea → genera intervalos de línea de cambio precisos para los archivos modificados (basado en 1, fusionando intervalos adyacentes). Los archivos no modificados solo se comparan con hash, sin ningún reanálisis
3. El grafo de dependencias (incluye archivos del directorio raíz, no depende de la granularidad del escaneo de módulos) tiene tres tipos de aristas: import de Python (AST), import/require de JS/TS/Vue (regex + resolución de alias), aristas de oferta-demanda de rutas entre lenguajes (definición de ruta × referencia literal, bidireccional); el caché se almacena en file_imports.json + file_routes.json, solo se re-analizan los archivos modificados o con caché faltante; los archivos nuevos o eliminados son cambios estructurales, se re-analizan completamente una vez para evitar aristas faltantes. A partir de v2, la instantánea cubre .py/.ts/.tsx/.js/.jsx/.vue/.sql/.yaml/.yml, las instantáneas v1 se migran automáticamente
4. Desde el archivo de negocio modificado, BFS a lo largo de las aristas de importación inversa → cierre de impacto (archivos modificados + todas las partes dependientes transitivas); los archivos de prueba solo actúan como sumideros, no se propagan
5. Selección de pruebas: seleccionados = archivos de prueba dentro del cierre ∪ archivos de prueba modificados; marca untested_changes (archivos de negocio modificados sin ninguna prueba dentro del cierre)
6. Si existe coverage-tiers.json en la raíz del proyecto, marca cada archivo modificado con su tier según la coincidencia de prefijo más largo
7. Produce <ruta-del-proyecto>/archmap/diff_impact.json; la instantánea de línea no se actualiza en el modo diff (garantiza la estabilidad del resultado de comparación repetida dentro del mismo período de trabajo), se actualiza con la próxima full/sync
8. Cuando hay cambios, se deja huella automáticamente: Agrega a diff_history.jsonl (legible por máquina, con nota) y re-renderiza 10_HistorialCambios.md (hora+contenido de modificación+intervalo de archivo modificado+cierre+selección de prueba); la ejecución sin cambios no registra nada

Estructura del producto:

{
  "changed_files": [{"path": "ui/main_window.py", "change_type": "modified", "tier": "P2", "changed_ranges": [[169, 182]]}],
  "deleted_files": [],
  "affected_closure": {"files": ["..."], "changed": ["..."], "propagated": ["..."]},
  "test_selection": {"selected": ["tests/test_main_window.py"], "skipped": ["..."], "untested_changes": []},
  "stats": {"changed_files": 1, "changed_ranges": 1, "closure_files": 3, "tests_selected": 1, "tests_skipped": 7},
  "history_path": "<ruta-del-proyecto>/archmap/diff_history.jsonl",
  "history_doc": "<ruta-del-proyecto>/archmap/10_HistorialCambios.md"
}

Consumo posterior: El modo incremental de whitebox-coverage utiliza diff_impact.json como la única base de alcance (ejecución selectiva + filtrado de brechas --diff-scope + puerta de enlace diff_gate); el proceso de revisión utiliza 10_HistorialCambios.md como entrada de registro de cambios.

Modo G: Incremento Mínimo Lite (Automático con línea base en llamada de cero parámetros, o explícitamente lite, Nuevo desde 2026-08-12)

Modo predeterminado para iteraciones de desarrollo diarias. Diferencia con sync: No regenera los informes completos 01~09 ni los diagramas de arquitectura grandes, solo cierra el ciclo de cambios, completado en segundos:

1. Comparación de instantáneas de línea para detectar cambios (mismo motor que el modo F, independiente de git)
2. Solo re-analiza los módulos modificados y los fusiona de nuevo en la línea base (full_index / vector_cache / module_hashes / instantánea de línea / caché del grafo de importación se actualizan todos)
3. Si hay cambios, se deja huella automáticamente: Agrega a diff_history.jsonl + re-renderiza 10_HistorialCambios.md (puede llevar nota de contenido de modificación)
4. Los proyectos ETL actualizan automáticamente los productos de etl_rules/; si hay predicciones sin validar, se realiza la validación de recall como de costumbre
5. Produce/actualiza diff_impact.json (contiene direct_dependents resumen de dependencias de primer nivel + cierre de transmisión completo, la máquina lee el cierre completo sin ocupar el contexto del Agente)

Sin cambios, devuelve directamente "Sin cambios, no hay necesidad de actualizar". Para que los informes 01~09 reflejen el código más reciente, ejecute sync o full.

Invocación Subyacente

Ubicación del script envoltorio:

/Users/xujin/.agents/skills/archmap/archmap <ruta-del-proyecto> [texto-del-requisito]

Equivalente a:

# Completo
python3 /Users/xujin/.agents/skills/archmap/archmap /ruta/al/proyecto

# Incremental
python3 /Users/xujin/.agents/skills/archmap/archmap /ruta/al/proyecto "Nuevo sistema de puntos de usuario"

El paquete del motor archmap_agent ya está incluido y distribuido con el skill (en el mismo directorio que el script envoltorio), no es necesario instalar el motor por separado.

Restricciones

• No inicia ningún servicio web.
• No lee ni escribe tablas de tareas SQLite.
• Todo el estado se guarda en la carpeta archmap/ dentro de la ruta del proyecto.
• No modifica el código de negocio original del usuario, solo realiza análisis de código fuente estático.
• El modo completo solo escanea directorios de negocio, filtrando automáticamente directorios como test, node_modules, dist, build, etc.
• El modo incremental reutiliza los activos de la línea base existente, no re-analiza módulos no modificados, reduciendo significativamente el consumo de Tokens.
• Todas las salidas son texto plano en JSON/YAML/Markdown/Mermaid, no se generan imágenes.