ArchMap 架构测绘 Agent (Agent de Cartographie Architecturale)
Agent natif en terminal, sans interface Web. Routage automatique sans paramètre vers full/lite, supporte également les modes explicites d'analyse d'impact incrémental, de synchronisation et d'impact de diff.
Installation et Dépendances
Avant la première utilisation, exécutez pip3 install -r requirements.txt dans le répertoire racine de cette compétence (voir README.md pour les détails). sentence-transformers est une dépendance optionnelle ; si elle est absente, la reconnaissance vectorielle revient automatiquement à un hachage vectoriel local, la fonctionnalité reste disponible mais la précision est légèrement réduite.
Modes de Déclenchement
/archmap <chemin_du_projet> # Routage automatique sans paramètre (recommandé)
/archmap <chemin_du_projet> full | lite [remarque] # Mode forcé de secours
/archmap <chemin_du_projet> <texte_du_besoin>
/archmap <chemin_du_projet> sync
/archmap <chemin_du_projet> diff [remarque_contenu_modification]
Exemples :
/archmap /Users/xujin/projects/my-app
/archmap /Users/xujin/projects/my-app Ajouter un système de points utilisateur, impliquant les interfaces de connexion et la table des rôles
/archmap /Users/xujin/projects/my-app sync
Routage des Modes (Routage Automatique Sans Paramètre, Nouveau le 2026-08-12)
L'appel sans paramètre /archmap <chemin_du_projet> effectue un routage entièrement automatique basé sur l'existence ou non d'une ligne de base, sans commutateur manuel :
- Pas de ligne de base (
archmap/full_index.jsoninexistant) → exécute automatiquement l'initialisation complète 'full' - Ligne de base existante → exécute automatiquement l'incrémental minimal 'lite' (itération quotidienne par défaut, voir mode G)
- Cas spéciaux de secours manuel : mots explicites
full/litepour forcer le mode (après une grande refonte,fullrégénère la carte complète, pas besoin de supprimer le répertoire de ligne de base)
Liste des Modes
Mode A : Analyse Complète (Saisie uniquement du chemin du projet)
Lorsque le chemin est le répertoire racine du projet :
- Exécute une analyse complète du code source
- Divise les modules par répertoire métier, analyse multi-thread
- Agrège les actifs du socle, marque les API/stockages partagés, génère le cache vectoriel
- Génère un diagramme texte Mermaid et les rapports Markdown 01 à 09
- Écriture atomique des résultats dans
<chemin_du_projet>/archmap/ - Affiche le chemin des artefacts et un résumé
Chemin des artefacts :
<chemin_du_projet>/archmap/
├── full_index.json # Ligne de base architecturale complète
├── vector_cache.json # Cache vectoriel des modules
├── 01_Résumé_Exécutif.md
├── 02_Diagramme_Architecture.md # Texte Mermaid
├── 03_Diagramme_Flux_Données.md
├── 04_Diagramme_Séquence.md
├── 05_Inventaire_Actifs_Modules.md
├── 06_Inventaire_Actifs_API.md
├── 07_Inventaire_Actifs_Stockage.md
├── 08_Matrice_Dépendances.md
└── 09_Rapport_Vérification_Granularité.md
Mode B : Analyse d'Impact Incrémental (Chemin du Projet + Texte du Besoin)
Saisissez le chemin du projet correspondant à la ligne de base existante, et ajoutez le texte du besoin. Ce mode, avant de faire correspondre le besoin, synchronise d'abord les modifications réelles dans le code source. Ainsi, appeler /archmap <chemin> <besoin> déclenche une intégration post-rétrospective :
- Lit
vector_cache.json,full_index.json,module_hashes.jsonsous<chemin_du_projet>/archmap/ - Compare l'empreinte du contenu des modules (SHA256) du code source actuel avec celle de la dernière synchronisation, identifie les modules changés/ajoutés
- Ne réanalyse que les modules modifiés et les fusionne dans la ligne de base, les modules inchangés réutilisent directement les données de la ligne de base
- Vectorise le texte du besoin et effectue une correspondance par similarité cosinus avec les vecteurs de module les plus récents
- Distingue les modules suspects à haute/faible confiance, parcourt récursivement les dépendances amont/aval
- Ne lance le Worker d'analyse que pour les modules nouveaux/modifiés correspondant au besoin, les modules de dépendance existants réutilisent directement les données de la ligne de base, sans appel LLM
- Effectue une localisation précise au sein du module pour les modules correspondants : identifie les fichiers concernés, les noms de fonctions/classes, les routes d'interface, le mappage route→fichier, et les trie par pertinence par rapport au mot-clé du besoin
- Renforcement du Rappel (recall_engine) : sur la base de la correspondance vectorielle, utilise deux types de signaux déterministes pour étendre l'ensemble affecté, sans contrainte de seuil vectoriel — ① fermeture offre-demande de route (routes référencées par le module affecté → module définisseur, et modules référençant la route définie) ② correspondance dure de mots-clés de route du besoin (mots du besoin avec extension CN→EN, correspondance directe avec les routes définies par le module). Produit
match_sourcesannotant la source de correspondance de chaque module (vector/keyword/route_closure/route_keyword) - Fusionne et met à jour la ligne de base, génère le fichier d'impact
precise_analysis.json+ les métadonnées de prédictionprecise_meta.json(texte du besoin, source de correspondance, empreinte de hachage de la ligne de base) - Produit les modules, API, stockages affectés, la liste des fichiers concernés, pour guider le développement de précision
Note : La synchronisation post-rétrospective ne se déclenche que lorsqu'il y a une "ligne de base existante + nouveau besoin" ; l'analyse complète initiale d'un nouveau projet n'exécute pas de synchronisation.
Artefact : mise à jour de full_index.json, vector_cache.json dans le dossier de la ligne de base, et ajout de 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"]
}
]
Mode C : Mise à Jour par Synchronisation (Chemin du Projet + sync)
Après qu'une analyse complète du projet a été réalisée et que le développement continu a commencé, le nouveau code doit être fusionné dans la ligne de base existante, plutôt que de réexécuter une analyse complète.
Déclenchement :
/archmap <chemin_du_projet> sync
/archmap <chemin_du_projet> synchronisation
Processus d'exécution :
- Lit
full_index.json,vector_cache.json,module_hashes.jsonsous<chemin_du_projet>/archmap/ - Compare l'empreinte du contenu des modules (SHA256) du code source actuel avec celle de la dernière synchronisation
- Ne réanalyse que les modules nouveaux/modifiés, les modules inchangés déjà analysés réutilisent directement les données de la ligne de base, sans appel LLM
- Supprime de la ligne de base les modules supprimés et leurs vecteurs
- Regénère les diagrammes Mermaid et les rapports Markdown 01 à 09
- Mise à jour atomique de
full_index.json,vector_cache.json,module_hashes.jsonet des fichiers de rapport - Validation du Rappel (recall_engine) : si le fichier de prédiction de l'analyse d'impact précédente (
precise_analysis.json+precise_meta.json) existe dans la ligne de base, compare automatiquement les modules prédits avec les modules effectivement modifiés cette fois-ci :- Changement → produit
recall_report.json(taux de réussite, modules non signalés et attribution : route_keyword_miss / closure_miss / vector_miss), ajouterecall_history.jsonl, puis consomme le fichier de prédiction - Pas de changement → conserve la prédiction, à valider lors de la prochaine synchronisation après développement
- Empreinte de hachage de la ligne de base incohérente (la prédiction appartient à un ancien cycle de développement terminé) → abandonne la prédiction obsolète, ne valide pas
- Changement → produit
Artefact : le contenu du dossier de la ligne de base est entièrement rafraîchi, la structure est identique à celle du mode A, mais seul le coût d'analyse du module modifié est consommé. En cas de prédiction en attente de validation, recall_report.json et recall_history.jsonl sont ajoutés.
<chemin_du_projet>/archmap/
├── full_index.json # Modules nouveaux/modifiés fusionnés
├── vector_cache.json # Seuls les vecteurs des modules modifiés sont recalculés
├── module_hashes.json # Empreintes de contenu des modules les plus récentes
├── 01_Résumé_Exécutif.md
├── 02_Diagramme_Architecture.md
├── 03_Diagramme_Flux_Données.md
├── 04_Diagramme_Séquence.md
├── 05_Inventaire_Actifs_Modules.md
├── 06_Inventaire_Actifs_API.md
├── 07_Inventaire_Actifs_Stockage.md
├── 08_Matrice_Dépendances.md
└── 09_Rapport_Vérification_Granularité.md
Rythme d'utilisation typique :
- Première fois :
/archmap /chemin/vers/projet - Développement de nouvelle fonctionnalité et modification du code source
- Synchronisation post-rétrospective :
/archmap /chemin/vers/projet sync - Localisation d'impact :
/archmap /chemin/vers/projet Ajouter une fonctionnalité de points
Mode D : Exploration des Règles Sous-Jacentes ETL (Déclenché automatiquement)
Pour les projets contenant des répertoires à caractéristiques ETL (présence de tongue_diagnosis/etl / etl_config / etl/core), lors de l'analyse complète et de la mise à jour par synchronisation, 7 artefacts de maintenance des changements ETL sont automatiquement générés dans <chemin_du_projet>/archmap/etl_rules/ :
| # | Artefact | Contenu |
|---|---|---|
| ① | Répertoire_Index_Total_Règles_ETL.md | Arbre de répertoires à 7 niveaux (Prétraitement Nettoyage → Découpage Chunk → Écriture Vectorisation → Rapprochement Cohérence → Stockage Isolation → Réessai Anomalies → Orchestration ETL) + code unique de règle (ETL-CHUNK-01 etc.) + étiquettes mots-clés + index de recherche rapide + processus d'utilisation en 7 étapes |
| ② | details/ETL-{code}.md (1 par règle) | 7 chapitres unifiés : Identifiant de base de la règle / Logique d'exécution sous-jacente complète / Localisation précise du code source / Contraintes entrée-sortie / Règles de dépendance associées / Historique des modifications / Normes de vérification des tests |
| ③ | etl_rule_mapping.json | Table de correspondance Règle ETL - Code - Configuration (lisible par machine) |
| ④ | Diagramme_Chaîne_Dépendances_Règles_ETL.md | Diagramme de dépendances Mermaid + liste d'impact textuelle + classification d'impact (Élevé/Moyen/Faible) |
| ⑤ | Tableau_Baseline_Paramètres_Globaux_ETL.md | Valeurs de base de tous les paramètres de règles + source du fichier de configuration |
| ⑥ | Liste_Évaluation_Risques_Changement_Règles_ETL.md | Niveau de risque/description/tests de régression pour toutes les règles + actions préalables au changement |
| ⑦ | etl_rule_search_index.json | Index de recherche machine (entrées de règle + index rapide mot-clé → code de règle) |
| ⑧ | Rapport_Alignement_Contrat_Configuration_ETL.md + config_contract_report.json | Détection de dérive du contrat configuration-code (alignement périodique) : existence réelle de la clé yaml + read/use grep de chaîne caractéristique → aligned (câblé)/ unused (configuration morte)/ stale (résidu de code)/ missing_from_yaml (incohérence de contrat) + suggestions de traitement |
Points clés :
- Alignement périodique (dérive du contrat de configuration) : après avoir modifié la configuration / le point de consommation de code, exécutez
/archmap <chemin_du_projet> sync; le rapport ⑧ rafraîchit automatiquement l'état de chaque champ (le champ existe ≠ il est actif : unused/stale nécessite un câblage ou un nettoyage selon les suggestions de traitement) ; exemple de dérive de ligne de base existante : les poids RRF ne sont pas effectifs (rag_engine._rrf_fusepoids codés en dur à 1.0), la configurationmax_ctx_tokensn'est pas câblée,reconcile.enabled/batch_sizeest une configuration morte,embedding.yaml batch_sizen'est pas consommé. - Les numéros de ligne de localisation du code source sont analysés à l'exécution par grep de nom de fonction / chaîne caractéristique. Après modification du code,
/archmap <chemin_du_projet> syncrafraîchit tous les numéros de ligne et artefacts. - Classification de la profondeur d'analyse P0/P1/P2 (Phase 2, 2026-08-12) : risk_level élevé → P0 analyse approfondie (numéro de ligne + configuration + contrat), moyen → P1 analyse standard (numéro de ligne), faible → P2 analyse légère (vérification uniquement de l'existence du fichier, pas d'analyse de numéro de ligne et non compté dans le périmètre unresolved) ; l'en-tête du document de détail / le répertoire d'index total / le JSON de mapping / le JSON d'index de recherche portent tous un indicateur
priority, le résumé contientpriority_countset les statistiquesparse_depth; une règle individuelle peut écraser la déduction en écrivant explicitement le champprioritydansetl_rule_registry.py. - Convention de remise à jour (doit être exécutée après avoir modifié une règle/étape/configuration ETL) :
/archmap <chemin_du_projet> syncremplit automatiquement trois aspects — ① numéros de ligne (analyse en temps réel par grep) ; ② paramètres de base (lecture à l'exécution deetl.yaml/embedding.yaml/chunking.yaml, les paramètres de règle correspondants dans ③⑤⑦ sont automatiquement rafraîchis avec les valeurs actuelles du fichier de configuration) ; ③ modifications sémantiques (changement de nom de règle/changement de comportement/ajustement du niveau de risque) après avoir ajouté un enregistrementhistorydansetl_rule_registry.pyet réexécuté sync pour régénérer. Ne pas exécuter sync entraîne une dérive entre documentation et code/configuration. - Point d'entrée de recherche : lire
etl_rules/etl_rule_search_index.json(machine) ou le tableau de mots-clés de l'index total (humain). - Le document de détail contient une section sur les normes de vérification des tests ; après avoir modifié une règle, exécutez les tests de régression correspondants.
- Le mécanisme de remplacement du registre de règles ETL personnalisé est décrit dans la section "Configuration au niveau du projet" du README.md.
Mode E : Actifs d'Entrée pour la Conception de Tests (Test Design Input Assets)
Les diagrammes d'architecture, diagrammes de flux de données, diagrammes de séquence, inventaires d'actifs et matrices de dépendances produits par l'analyse complète d'ArchMap peuvent être directement utilisés comme entrée pour test-case-designer, pilotant la conception de tests basée sur les trois éléments « nœud + branche + méthode ».
Artefacts Consommables par la Conception de Tests
| Fichier Artefact | Utilisation en Conception de Tests | Contenu Extrait |
|---|---|---|
02_Diagramme_Architecture.md | Identifier les couches système et les limites des modules | Nœuds de couche (Trigger/Definition/Persistence/Engine/Validation) |
03_Diagramme_Flux_Données.md | Identifier les flux de données de bout en bout | Nœuds de flux de données, entrées/sorties, points de persistance |
04_Diagramme_Séquence.md | Identifier l'ordre des appels et les relations de concurrence/attente | Chronologie des appels, limites synchrone/asynchrone, points de retour d'exception |
05_Inventaire_Actifs_Modules.md | Identifier les modules fonctionnels et leurs responsabilités | Nom du module, fonctions principales, description des responsabilités |
06_Inventaire_Actifs_API.md | Identifier les nœuds de test d'interface | Routes, méthodes, paramètres, structure de retour, codes d'erreur |
07_Inventaire_Actifs_Stockage.md | Identifier les points de test de persistance des données | Type de stockage, champs, contraintes, cycle de vie |
08_Matrice_Dépendances.md | Identifier l'impact des changements et le périmètre de régression | Relations d'appel entre modules, API/stockages partagés |
precise_analysis.json | Localiser précisément le périmètre de test pour les besoins incrémentaux | Modules modifiés, fichiers concernés, fonctions/routes, pertinence |
Format Standard d'Entrée pour la Conception de Tests
Après avoir lu les artefacts ci-dessus, test-case-designer doit réduire les informations à la structure standard suivante (en tant qu'artefact intermédiaire de conception soumis avec execution-list.json pour révision, n'est pas persistant en tant qu'artefact archmap — les artefacts du moteur archmap sont uniquement 01~09) :
## Liste des Nœuds de Test (Node Inventory)
| ID Nœud | Nom du Nœud | Module concerné | Fonction/Rôle | Entrée | Sortie | Persistance |
|---------|-------------|-----------------|---------------|--------|--------|-------------|
| N-001 | create_workflow_endpoint | webui.py | Créer un nouveau workflow via l'interface Web | {name, mode} | flow.yml / SKILL.md / répertoire | Nouvel arbre de répertoires |
| N-002 | validate_flow_structure | workflow.py | Valider la structure de flow.yml | flow_data | Liste d'erreurs ou liste vide | Aucune |
| N-003 | gate_a_check | engine.py | Vérification d'accès avant exécution | agent, state | passed/errors/log | engine_state.json |
## Liste des Fermetures de Branches (Branch Closure)
| Nœud source | Condition de branche | Vrai branche | Fausse branche | Entrée invalide | Incohérence d'état |
|-------------|----------------------|--------------|----------------|-----------------|---------------------|
| N-001 | name est-il vide ? | Continuer la création | Retour 400 | Trop long / caractères spéciaux | Répertoire parent non défini |
| N-003 | upstream est-il complété ? | Entrer dans Gate B | bloqué | Nœud inconnu | Hachage du livrable falsifié |
## Mappage des Méthodes de Test (Method Mapping)
| Nœud | Valeur limite (BV) | Classe d'équivalence (EC) | Logique métier (DL) | Scénario (SC) | Exception (EX) | Compatibilité (CP) | Sécurité interface (IS) |
|------|--------------------|---------------------------|----------------------|---------------|----------------|--------------------|-------------------------|
| N-001 | Limite de longueur du nom | Nom valide/invalide | Créer → Générer → Retourner | Processus de création normal | Répertoire parent manquant | — | Traversée de chemin / caractères spéciaux |
| N-003 | Limite de max_retry | Amont complété / non complété | Gate A → Exécution → Gate B | Progression normale | Hachage non correspondant | Avec / sans jsonschema | — |
Mode de Consommation en Scénario Incrémental
Lorsque le PM donne un nouveau besoin :
- Appeler
/archmap <chemin_du_projet> "texte du besoin"pour générer/mettre à jourprecise_analysis.json. test-case-designerlit en priorité les modules modifiés et les fichiers concernés dansprecise_analysis.json.- Extrayez les nœuds de test uniquement pour les modules modifiés et leurs modules de dépendance directe, évitant une reconception complète.
- Marquez les cas de test avec
baseline_affected: truedansexecution-list.jsonpour une régression précise.
Contrat d'Interface avec test-case-designer
test-case-designer possède une capacité d'analyse autonome. Après le démarrage, il suit la logique suivante :
- Découverte autonome des résultats d'analyse existants : Vérifie si
<chemin_du_projet>/archmap/existe et contient des02_Diagramme_Architecture.mdet03_Diagramme_Flux_Données.mdvalides.- S'ils existent : Lit directement les artefacts 02~08 +
precise_analysis.json(scénario incrémental) comme entrée de conception de tests, évitant une analyse redondante. - S'ils n'existent pas ou sont obsolètes : Appelle lui-même
/archmap <chemin_du_projet>(complet) ou/archmap <chemin_du_projet> "texte du besoin"(incrémental) pour générer les résultats d'analyse, puis les lit. Le PM n'a pas besoin d'appeler archmap séparément avant les tests.
- S'ils existent : Lit directement les artefacts 02~08 +
- Lit
02_Diagramme_Architecture.md+03_Diagramme_Flux_Données.md+04_Diagramme_Séquence.md, identifie les nœuds de test au niveau système. - Lit
05_Inventaire_Actifs_Modules.md+06_Inventaire_Actifs_API.md+07_Inventaire_Actifs_Stockage.md, identifie les nœuds de test au niveau module. - Lit
08_Matrice_Dépendances.md, identifie les dépendances entre nœuds et les surfaces d'impact. - Produit la liste des nœuds/branches/méthodes réduite en tant qu'artefact intermédiaire de conception (c'est-à-dire la règle 32 Étape 1.8 "Liste des nœuds et branches de test"), soumise avec
execution-list.jsonpour révision.
Mode F : Analyse d'Impact Diff (chemin du projet + diff, Nouveau le 2026-08-12)
Analyse d'impact différenciée après mise à jour de version, fournissant une entrée de diff faisant autorité pour les tests incrémentaux en boîte blanche et autres avals. Indépendant de git (utilisable pour les projets sans dépôt), zéro appel LLM, exécution en quelques secondes.
Moment d'exécution (point de contrôle fixe) : doit être exécuté une fois après l'ajout/la modification de fonctionnalité et avant la phase de rétrospective. La modification en cours (horodatage + contenu modifié + intervalle de lignes + fermeture d'impact) est automatiquement enregistrée dans l'historique des modifications, en tant que matériel d'entrée pour la rétrospective ; après validation, utilisez sync pour rafraîchir la ligne de base et remettre à jour les documents d'analyse 01~09 — l'enregistrement diff, l'historique des modifications et les documents d'analyse forment un ensemble cohérent.
Déclenchement :
/archmap <chemin_du_projet> diff
/archmap <chemin_du_projet> diff Ajouter une validation des paramètres illégaux à la fonction de changement de vitesse vidéo
Processus d'exécution :
- Lit l'instantané ligne par ligne
file_line_hashes.jsondu répertoire de base (écrit automatiquement lors de full/sync ; s'il n'y a pas d'instantané pour la première diff, initialise et indique que la comparaison pourra commencer au prochain cycle). - Compare fichier par fichier le hachage de ligne actuel avec l'instantané via difflib → produit les intervalles de lignes de changement précis pour les fichiers modifiés (base 1, fusionne les intervalles adjacents). Pour les fichiers non modifiés, seule une comparaison de hachage est effectuée, aucune réanalyse.
- Trois types d'arêtes du graphe de dépendances (y compris les fichiers du répertoire racine, indépendant de la granularité d'analyse des modules) : import Python (AST), import/require JS/TS/Vue (regex + résolution d'alias), arêtes offre-demande de route entre langues (définition de route × référence littérale, bidirectionnel) ; cache via
file_imports.json+file_routes.json, seuls les fichiers modifiés ou manquants dans le cache sont réanalysés ; l'ajout ou la suppression de fichiers constituent un changement structurel, déclenchant une réanalyse complète unique pour éviter la perte d'arêtes. La couverture de l'instantané v2 concerne.py/.ts/.tsx/.js/.jsx/.vue/.sql/.yaml/.yml, l'instantané v1 est automatiquement migré. - Partant des fichiers métier modifiés, BFS le long des arêtes d'import inversées → fermeture d'impact (fichiers modifiés + tous les dépendants transitifs) ; les fichiers de test ne servent que de points de confluence, pas de propagation.
- Sélection de test : sélectionné = fichiers de test dans la fermeture ∪ fichiers de test modifiés eux-mêmes ; marque
untested_changes(fichiers métier modifiés sans aucun test dans la fermeture). - Si
coverage-tiers.jsonexiste à la racine du projet, annote chaque fichier modifié avec son tier par correspondance de préfixe la plus longue. - Produit
<chemin_du_projet>/archmap/diff_impact.json; l'instantané ligne par ligne n'est pas mis à jour en mode diff (pour garantir la stabilité des résultats de comparaison répétés pendant la même période de travail), il est rafraîchi lors du prochain full/sync. - En cas de changement, trace automatiquement : ajoute
diff_history.jsonl(lisible par machine, avec remarque) et ré-rend10_Journal_Modifications.md(horodatage + contenu de la modification + intervalle des fichiers modifiés + fermeture + sélection de test) ; aucune exécution sans changement n'est enregistrée.
Structure de l'artefact :
{
"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": "<chemin_du_projet>/archmap/diff_history.jsonl",
"history_doc": "<chemin_du_projet>/archmap/10_Journal_Modifications.md"
}
Consommation aval : le mode incrémental de whitebox-coverage utilise diff_impact.json comme unique source de périmètre (exécution sélective + filtrage des lacunes --diff-scope + gate diff) ; le processus de rétrospective utilise 10_Journal_Modifications.md comme registre des modifications en entrée.
Mode G : Incrémental Minimal Lite (Entrée automatique lorsque zéro paramètre est appelé et qu'une ligne de base existe, ou explicite lite, Nouveau le 2026-08-12)
Mode par défaut pour les cycles de développement quotidiens. Différence avec sync : ne régénère pas les rapports complets et le grand diagramme d'architecture de 01 à 09, effectue uniquement la fermeture du changement, exécution en quelques secondes :
- Détection des changements par comparaison d'instantané ligne par ligne (même moteur que le mode F, indépendant de git)
- Ne réanalyse que les modules modifiés et les fusionne dans la ligne de base (full_index / vector_cache / module_hashes / instantané ligne par ligne / cache de graphe d'import entièrement rafraîchis)
- En cas de changement, trace automatiquement : ajoute
diff_history.jsonl+ ré-rend10_Journal_Modifications.md(peut inclure une remarque sur le contenu de la modification) - Pour les projets ETL, rafraîchit automatiquement les artefacts
etl_rules/; en cas de prédiction non validée, effectue la validation de rappel comme d'habitude. - Produit/rafraîchit
diff_impact.json(contenantdirect_dependentsrésumé des dépendances de premier niveau + fermeture transitive complète, la fermeture complète est lisible par machine sans occuper le contexte de l'Agent)
Sans changement, retourne directement « Aucun changement, mise à jour non nécessaire ». Exécutez sync ou full si les rapports 01~09 doivent refléter le code le plus récent.
Appel Sous-Jacent
Emplacement du script wrapper :
/Users/xujin/.agents/skills/archmap/archmap <chemin_du_projet> [texte du besoin]
Équivalent à :
# Complet
python3 /Users/xujin/.agents/skills/archmap/archmap /chemin/vers/projet
# Incrémental
python3 /Users/xujin/.agents/skills/archmap/archmap /chemin/vers/projet "Ajouter un système de points utilisateur"
Le moteur archmap_agent est distribué avec la compétence (dans le même répertoire que le script wrapper), aucune installation supplémentaire du moteur n'est nécessaire.
Contraintes
- Ne démarre aucun service Web.
- Ne lit ni n'écrit dans une table de tâches SQLite.
- Tout l'état est enregistré dans le dossier
archmap/sous le chemin du projet. - Ne modifie pas le code métier original de l'utilisateur, effectue uniquement une analyse statique du code source.
- Le mode complet analyse uniquement les répertoires métier, en filtrant automatiquement les répertoires test, node_modules, dist, build, etc.
- Le mode incrémental réutilise les actifs de la ligne de base existante, ne réanalyse pas les modules inchangés, réduisant considérablement la consommation de tokens.
- Les sorties sont uniquement du texte brut JSON/YAML/Markdown/Mermaid, aucune image n'est générée.