architecture-map

Files (1)

• SKILL.md

SKILL.md (first lines)

# architecture-map — ce que la tâche a changé dans le système

Un diff de fichiers dit ce qui a bougé. Il ne dit pas si un composant est apparu,
si une frontière de confiance s'est déplacée, ou si un service parle maintenant
directement à une base qu'il atteignait par une file. C'est cette question-là,
et elle se pose au moment où le code est fini et pas encore relu.

Tu écris **un fichier JSON**. Tu ne rends rien, tu ne valides rien, tu n'ouvres
pas de shell : le pipeline autour de toi exécute `validate`, `deliver` et
`compare`, et te renvoie les diagnostics si le modèle est refusé.

## À lire, dans cet ordre

1. `<archify_root>/SKILL.md` — le contrat d'écriture. C'est lui qui fait foi ;
   ce fichier-ci ne dit que le métier.
2. `<archify_root>/schemas/architecture.schema.json` et `common.schema.json`.
3. **Le modèle de référence**, fourni dans le prompt. C'est ton point de départ,
   pas un exemple.

Ne lis ni les sources du renderer, ni les validateurs, ni les tests. Un
diagnostic qui te renvoie dans l'implémentation nomme le fichier à ouvrir.

## La règle qui prime sur toutes les autres

**Conserve chaque `id`.** Le comparateur apparie les composants par leur `id` et
par rien d'autre. Un composant qui existe toujours sous un nouvel identifiant
ressort comme un composant supprimé et un autre ajouté : ce n'est pas un delta,
c'est du bruit déguisé en constat.

- un composant qui existe encore garde son `id`, même si son libellé, son type,
  son sous-titre, sa position ou ses sources changent ;
- un composant réellement disparu est retiré ;
- un composant réellement nouveau reçoit un `id` dans le style de ses voisins ;
- les `id` des connexions et des frontières suivent la même règle.

Un contrôle mécanique vérifie ça après toi. Sous le seuil, le delta est déclaré
non fiable et n'est pas affiché — le travail est perdu, pas masqué.

## Ne change que ce que la tâche a changé

Redessiner la mise en page, harmoniser des noms, « améliorer » un composant que
la tâche n'a pas touché : tout cela ressort dans le delta, et chacun de ces
constats est faux. Si le changement est invisible à cette altitude — un
refactoring interne à un seul composant — alors la bonne réponse est le modèle
de référence rendu inchangé.

## Ne déduis jamais une causalité d'un nom

Les arêtes d'import fournies dans le prompt sont mesurées : ce sont de vraies
arêtes dans le source. Un import n'est **pas** un appel à l'exécution — un module
importé une fois au démarrage et un module appelé à chaque requête sont
identiques dans cette table. Un fichier nommé `payment_service.py` prouve un nom,
pas un service.

Quand la preuve n'établit pas une relation, ouvre les fichiers et établis-la, ou
laisse la relation de côté. Une flèche fausse et assurée est pire qu'une flèche
absente, parce que l'absence, elle, se voit.

## Sources

Quand tu peux nommer les fichiers qu'un composant *est*, attache-les :

```json
{ "id": "api", "type": "backend", "label": "Build API",
  "sources": [{ "path": "apps/backend/provider_api.py", "label": "app FastAPI" }] }
```

Chemins **relatifs au dépôt**, sur des fichiers qui existent. N'écris pas
`meta.repository` toi-même : le pipeline épingle l'URL et la révision après toi,
et retire toute source qu'il ne peut pas vérifier contre un vrai blob à ce commit.

## Sortie

Le JSON complet, à l'emplacement que le prompt indique. Un seul objet JSON,
commençant par `{`. Rien d'autre : pas de résumé dans le fichier, pas de bloc de
code, pas de commentaire.

From krovomi/WorkPilot-AI, AGPL-3.0.

More from krovomi/WorkPilot-AI