dsh-switchman 1.11.5 → 1.11.7

package/README.fr.md

@@ -12,30 +12,27 @@
 
 À force de travailler avec DSH, on finit par se heurter à deux problèmes : la session s'alourdit à mesure que la conversation s'étire — l'historique gonfle le contexte à des centaines de milliers de tokens, le modèle commence à oublier, à ralentir, à coûter cher, et le /compact manuel avale des détails à chaque compression ; et le modèle principal fait tout lui-même — retrouver un fichier, lancer un test, recouper des données, il mâche tout cela seul, lentement et à grands frais, alors que l'essentiel de ce travail gagnerait à être confié à un modèle bien moins cher.
 
-dsh-switchman est un plugin pour [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) (DSH). Une fois installé, le modèle principal passe de « tout faire lui-même » au rôle de répartiteur : mesurer le niveau d'eau, choisir le couloir, distribuer les tâches, contrôler le résultat. Ce n'est pas un nouveau modèle — c'est une doctrine d'orchestration accrochée à DSH, accompagnée d'une page de réglages. Concrètement, il fait huit choses :
+dsh-switchman est un plugin pour [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) (DSH). Une fois installé, le modèle principal continue de travailler lui-même — simplement avec plus de discernement : il choisit ses combats, confie les menus travaux à des couloirs bon marché et laisse le routage par intention faire atterrir l'urgent ou le difficile sur le bon modèle, se réservant ce qui mérite vraiment d'être fait en personne ; il rejette le superflu pour ne garder que l'essentiel — l'historique digéré se replie en résumés compacts pendant que le niveau d'eau mesure chaque dépense, et le contexte voyage toujours léger ; et quand la charge dépasse une seule paire de mains, il fait venir des coéquipiers permanents qui se partagent le travail sur un tableau commun pendant qu'il se réserve le dispatch et la réception. Ce n'est pas un nouveau modèle — c'est une doctrine d'orchestration accrochée à DSH, accompagnée d'une page de réglages. Concrètement, il fait neuf choses :
 
-**1. Niveau d'eau du contexte : les longues sessions ne débordent jamais.** Chaque tour compte en direct les tokens de la session et les confronte à trois lignes d'eau qui durcissent par paliers : 80k (soft, réglable) rappelle qu'« il est temps de déléguer » ; 95k (hard) resserre le budget de lecture par appel et pousse à conclure ; 150k (force) déclenche la remise automatique — le document de remise est écrit (le journal de session à ajout seul constitue la sauvegarde complète), le contexte compacté, la session réveillée pour continuer, et la tâche ne s'interrompt jamais. Les subagents d'arrière-plan encore en course à cet instant ne sont pas perdus pour autant : leurs id, descriptions de tâche et chemins de rapport sont consignés dans le document de remise, et la session relancée sait où récupérer les rapports au lieu de redéspatcher en double. Chaque subagent dispatché embarque son propre plafond strict ; une fois atteint, il écrit son résumé HANDOFF et se retire. Quand l'intervention automatique ne vous convient pas, reprenez la main à tout moment : `/ctx-pause` arrête toutes les actions de niveau (la mesure continue, la ligne d'eau en direct de la fin passe en paused — il n'agit plus, c'est tout), `/ctx-resume` rétablit à tout moment — après un redémarrage de DSH, l'intervention revient aussi d'elle-même, un lâcher-prise temporaire, pas une extinction définitive ; `/ctx-handover` n'attend pas que le niveau touche le plafond et déclenche à la demande la même remise : écrire le document de remise, compacter le contexte, réveiller la session pour continuer (la session est d'abord conduite jusqu'à la limite d'inactivité, le résultat peut donc prendre quelques minutes).
+**1. Trim automatique du contexte : la session s'allonge, le coût reste plat.** Un `/compact` manuel vous fait attendre, perd du détail et transperce le cache de prompt du fournisseur. Le moteur de trim automatise tout cela : les pans digérés de la conversation sont repliés en résumés déterministes compacts aux limites d'inactivité (un side model les rédige ; sous pression d'urgence, le repli est mécanique, sans appel de modèle), et chaque requête sortante est reconstruite depuis l'état de repli — les blocs de résumé tiennent lieu des pans repliés, la queue vivante est conservée au mot près. Le journal de session stocké n'est jamais réécrit, et rien ne touche le flux en pleine diffusion. Les replis ne font qu'ajouter et la reconstruction est déterministe : le préfixe sérialisé reste identique à l'octet près entre deux replis et le cache du fournisseur continue de toucher ; toute défaillance interne retombe en fail-open vers le passage transparent — jamais une requête cassée. Trois niveaux entièrement automatiques (barrière de croissance / pression / urgence), plus un mode advisory où le modèle replie lui-même — la mécanique est détaillée plus bas dans « Trim automatique du contexte ».
 
-**2. Six pools de dispatch : le bon modèle pour chaque tâche.** Un pool léger (economy, les petites tâches en série), un pool mécanique (mechanical, les réécritures sur gabarit), un pool principal (main, le code au quotidien), un pool haute difficulté (hard, raisonnement corsé et refontes à grande échelle), un pool multimodal (vision, lire les images) et un pool de relecture (review, vérification indépendante). Dans la page de réglages, vous cochez les candidats, les classez par priorité (avec tiers S/A/B/C en option) et épinglez un effort de raisonnement pour chaque route — le menu déroulant des niveaux reflète ce que ce modèle supporte réellement, pas trois niveaux génériques. Chaque prompt du modèle principal embarque une table de recommandations `[SWITCHMAN:POOLS]`, et le dispatch suit cette table. Le mode d'exécution a trois états : off / advice / enforce (enforce = tout modèle hors pool est refusé sans appel).
+**2. Niveau d'eau du contexte : les longues sessions ne débordent jamais.** Chaque tour compte en direct les tokens de la session et les confronte à trois lignes d'eau qui durcissent par paliers : 80k (soft, réglable) rappelle qu'« il est temps de déléguer » ; 100k (hard) resserre le budget de lecture par appel et pousse à conclure ; 200k (force) déclenche la remise automatique — le document de remise est écrit (le journal de session à ajout seul constitue la sauvegarde complète), le contexte compacté, la session réveillée pour continuer, et la tâche ne s'interrompt jamais. Les subagents d'arrière-plan encore en course à cet instant ne sont pas perdus pour autant : leurs id, descriptions de tâche et chemins de rapport sont consignés dans le document de remise, et la session relancée sait où récupérer les rapports au lieu de redéspatcher en double ; chaque subagent dispatché embarque en outre son propre plafond strict : une fois atteint, il écrit son résumé HANDOFF et se retire. Le niveau d'eau lit la vue après trim — ce que le modèle voit réellement —, si bien qu'une session très repliée n'est plus coincée sur les lignes hautes. Quand l'automatique ne vous convient pas : `/ctx-pause` arrête toutes les actions (la mesure continue), `/ctx-resume` rétablit à tout moment — et après un redémarrage, tout revient tout seul ; `/ctx-handover` déclenche à la demande la même remise, sans attendre le plafond.
 
-**3. Mode Agent Teams : passer du solo à la direction d'une équipe.** Désactivé par défaut — juste après l'installation, on reste sur le dispatch subagent léger. Deux interrupteurs indépendants dans la page de réglages :
+**3. Routage par intention : le message arrive, le modèle prend sa place.** Une fois « Automatique (routage par intention) » choisi pour la session, chaque message utilisateur est d'abord typé par un petit modèle classifieur, qui le fait atterrir sur le meilleur candidat — chaque candidat porte une note de capacité d'une ligne qui guide le choix. La décision est verrouillée pour le tour : si la confiance manque ou que la fenêtre de cache est encore ouverte, le modèle courant reste en place (son cache de prompt continue de rapporter) ; on ne bascule que lorsque la confiance est suffisante ou que le modèle courant ne fait pas partie des candidats. Le basculement se fait en silence à la couche d'appel — aucun bruit de « modèle changé » dans la session — pendant qu'une pastille au-dessus du champ de saisie affiche la route et la confiance en direct. Comme classifieur, les petits modèles de décision comme les modèles de conversation génériques conviennent ; candidats, seuils et fenêtre de cache sont toujours à une page de réglages.
 
-- **Mode équipe d'agents** — l'activer injecte la doctrine d'équipe (délégation par défaut + vérification par paliers + discipline du tableau de tâches partagé) et active automatiquement les Agent Teams de DSH : le modèle principal peut recruter des coéquipiers permanents (`spawn_teammate`), confier du travail au tableau de tâches partagé (`team_task_*`) et échanger des messages avec eux. Le moment de constituer une équipe obéit à une discipline explicite : sous-tâches indépendantes parallélisables, gros lots autoportants, contexte principal déjà bien chargé, besoin de séparer les rôles ; les enquêtes ponctuelles restent du ressort du subagent. Refermer l'interrupteur ne laisse aucun résidu des clauses d'équipe, et ne retire jamais les outils d'équipe aux sessions déjà en cours.
-- **Synchronisation de la liste blanche des modèles de subagents** — DSH tient une liste d'autorisation « modèles qu'un agent peut choisir pour ses subagents » : une route cochée dans un pool mais jamais autorisée se voit refuser le dispatch quand le modèle principal la désigne nommément (en mode équipe, elle est marquée d'un ⚠). Activez cet interrupteur et l'union des six pools est d'un coup écrite dans cette liste — switchman reste l'unique source de vérité, fini la double configuration. La liste blanche s'applique par instantané à chaque nouvelle session : la synchronisation ne concerne que les sessions ouvertes ensuite.
+**4. Agent Teams : passer du solo à la direction d'une équipe.** Désactivé par défaut — juste après l'installation, on reste sur le dispatch subagent léger ; l'équipe arrive quand vous la voulez. Deux interrupteurs indépendants dans la page de réglages : **Agent Teams** injecte la doctrine d'équipe (déléguer par défaut + vérification par paliers + discipline du tableau partagé) et active automatiquement l'Agent Teams de DSH — le modèle principal peut faire venir des coéquipiers permanents (`spawn_teammate`), déposer du travail sur le tableau partagé (`team_task_*`) et s'écrire avec eux. Quand former une équipe suit une discipline claire : sous-tâches indépendantes parallélisables, travail volumineux et autonome, niveau d'eau élevé du contexte principal, besoin de séparer les rôles ; l'investigation ponctuelle d'un seul sujet continue de partir vers un subagent. Éteint, les clauses d'équipe disparaissent sans trace, et aucun outil n'est retiré aux sessions en cours. **Synchronisation de la whitelist des modèles de subagents** écrit l'union des six pools en bloc dans la whitelist d'autorisation de DSH — switchman devient l'unique source de vérité, sans double configuration (effective comme instantané par nouvelle session).
 
-L'en-tête de session donne un retour immédiat : un badge ⚡ « équipe autonome » et une puce ◇ indiquant le modèle réellement utilisé par la session ; pendant une remise automatique, une bannière en direct annonce « remise en cours · écriture du document de remise / compactage du contexte / réveil de la continuation ».
+**5. Six pools de dispatch : le bon modèle pour chaque tâche.** Un pool léger (economy, les petites tâches en série), un pool mécanique (mechanical, les réécritures sur gabarit), un pool principal (main, le code au quotidien), un pool haute difficulté (hard, raisonnement corsé et refontes à grande échelle), un pool multimodal (vision, lire les images) et un pool de relecture (review, vérification indépendante). Dans la page de réglages, vous cochez les candidats, les classez par priorité (avec tiers S/A/B/C en option) et épinglez un effort de raisonnement pour chaque route — le menu déroulant des niveaux reflète ce que ce modèle supporte réellement, pas trois niveaux génériques. Chaque prompt du modèle principal embarque une table de recommandations `[SWITCHMAN:POOLS]`, et le dispatch suit cette table. Le mode d'exécution a trois états : off / advice / enforce (enforce = tout modèle hors pool est refusé sans appel).
 
-**4. Préférences de langue : une question posée une fois, retenue pour toujours.** Un menu déroulant chacun pour les réponses, les commentaires de code et la documentation, avec un scope global ou par projet (`.switchman/lang.json`). Ne rien régler est permis — au premier besoin, on vous pose la question une fois dans la langue de votre interface DSH, la réponse est retenue, et chaque session suivante s'y conforme automatiquement.
+**6. Préférences de langue : une question posée une fois, retenue pour toujours.** Un menu déroulant chacun pour les réponses, les commentaires de code et la documentation, avec un scope global ou par projet (`.switchman/lang.json`). Ne rien régler est permis — au premier besoin, on vous pose la question une fois dans la langue de votre interface DSH, la réponse est retenue, et chaque session suivante s'y conforme automatiquement.
 
-**5. Langue de l'interface : le plugin parle votre langue aussi.** Tout en haut de la page de réglages, une nouvelle section « Interface » accueille un menu déroulant « Langue de l'interface » (clé de réglage `uiLocale`) : Auto (par défaut — suit la langue de l'appli DeepSeek Harness) ou n'importe quelle langue de l'interface du plugin, toujours affichée par son endonyme, jamais traduite. Elle ne bascule que l'interface du plugin lui-même — le badge d'en-tête, le panneau d'accueil et la page de réglages —, pas la langue de l'appli DSH : l'aperçu est immédiat, sans redémarrage ; l'enregistrement retient le choix ; le prochain démarrage le restaure ; tout échec retombe sur la langue de l'appli ; et tous les dictionnaires voyagent dans le bundle, sans téléchargement.
+**7. Langue de l'interface : le plugin parle votre langue aussi.** Tout en haut de la page de réglages, une nouvelle section « Interface » accueille un menu déroulant « Langue de l'interface » (clé de réglage `uiLocale`) : Auto (suit la langue de l'appli DeepSeek Harness ; chinois simplifié par défaut) ou n'importe quelle langue de l'interface du plugin, toujours affichée par son endonyme, jamais traduite. Elle ne bascule que l'interface du plugin lui-même — le badge d'en-tête, le panneau d'accueil et la page de réglages —, pas la langue de l'appli DSH : l'aperçu est immédiat, sans redémarrage ; l'enregistrement retient le choix ; le prochain démarrage le restaure ; tout échec retombe sur la langue de l'appli ; et tous les dictionnaires voyagent dans le bundle, sans téléchargement.
 
-**6. Vérification par paliers : chaque modification est contrôlée.** Au-delà de 20 lignes modifiées, passage au testeur ; au-delà de 300 lignes, ou dès que l'on touche à la logique cœur / sécurité / cohérence des données, en plus un relecteur indépendant. Le modèle du relecteur est choisi pour éviter celui de « l'agent qui a écrit le diff », autant que les pools le permettent ; quand c'est vraiment impossible, la conclusion le déclare DOWNGRADED. Dites « pas d'équipes » et il repasse aussitôt en solo.
+**8. Vérification par paliers : chaque modification est contrôlée.** Au-delà de 20 lignes modifiées, passage au testeur ; au-delà de 300 lignes, ou dès que l'on touche à la logique cœur / sécurité / cohérence des données, en plus un relecteur indépendant. Le modèle du relecteur est choisi pour éviter celui de « l'agent qui a écrit le diff », autant que les pools le permettent ; quand c'est vraiment impossible, la conclusion le déclare DOWNGRADED. Dites « pas d'équipes » et il repasse aussitôt en solo.
 
-**7. `/vision` : même un modèle purement textuel peut travailler avec des images.** Quand le modèle principal ne sait pas lire les images, DSH refuse les messages avec image dès l'entrée. Collez l'image, tapez `/vision où est l'erreur sur cette image`, et l'image est confiée à un modèle du pool multimodal pour lecture ; les conclusions reviennent dans la session courante. Un avertissement apparaît tôt au-dessus du champ de saisie — « le modèle courant ne sait pas lire les images » ; si un envoi d'image ordinaire est refusé, le brouillon est réécrit une fois en `/vision` et renvoyé tout seul, sans rien retaper ; sans pool multimodal configuré, la commande refuse et donne les indications de configuration.
+**9. `/vision` : même un modèle purement textuel peut travailler avec des images.** Quand le modèle principal ne sait pas lire les images, DSH refuse les messages avec image dès l'entrée. Collez l'image, tapez `/vision où est l'erreur sur cette image`, et l'image est confiée à un modèle du pool multimodal pour lecture ; les conclusions reviennent dans la session courante. Un avertissement apparaît tôt au-dessus du champ de saisie — « le modèle courant ne sait pas lire les images » ; si un envoi d'image ordinaire est refusé, le brouillon est réécrit une fois en `/vision` et renvoyé tout seul, sans rien retaper ; sans pool multimodal configuré, la commande refuse et donne les indications de configuration.
 
-**8. Routage par intention : le bon modèle se choisit tout seul.** La page de réglages accueille un nouveau groupe « Routage par intention » : un interrupteur général (désactivé par défaut ; l'activer exige un classifieur et au moins un candidat), la route du petit modèle classifieur (provider + model + effort facultatif — les modèles de décision type TypeSafe Jev comme les modèles de conversation génériques conviennent, et la sortie est analysée avec tolérance), un choix du type de classifieur à trois options (auto / decision / chat), une liste de candidats indépendante (chaque candidat : provider + model + effort facultatif + une note de capacité d'une ligne), la fenêtre de cache en secondes (300 par défaut, calée sur les caches de prompt des fournisseurs, environ 5 minutes), le seuil de confiance du basculement (80 par défaut), le timeout de classification (60000 ms par défaut), le nombre de messages d'historique (6 par défaut) et le budget de caractères (2400 par défaut), et un modèle de repli facultatif (avec un pin d'effort facultatif et indépendant ; sans pin, l'effort par défaut du modèle de repli sélectionné s'applique, indépendamment de celui du classifieur). Le sélecteur de modèles gagne une entrée « Auto » dans le groupe « Auto · Switchman » (le client la rend localisée — « Automatique (routage par intention) » en français) ; une fois choisie, chaque message utilisateur passe par le classifieur pour désigner le meilleur candidat, et la décision est verrouillée pour ce tour : si la confiance manque ou que la fenêtre de cache est encore ouverte, le modèle courant reste en place (son cache est réutilisé) ; on ne bascule que lorsque la confiance est suffisante ou que le modèle courant ne fait pas partie des candidats. Le basculement se fait en silence à la couche d'appel — aucun message « modèle changé » n'est inséré dans la session. Au-dessus du champ de saisie figure une pastille d'état (en routage automatique, elle montre le modèle routé courant et la confiance de la dernière décision) ; candidats et seuils restent consultables dans la page de réglages.
-
-Un seul modèle ? Ça vaut quand même l'installation — le contrôle du niveau d'eau et la vérification par paliers se moquent du nombre de modèles, et une longue session mono-modèle en profite tout autant.
+Un seul modèle ? Ça vaut quand même l'installation — le trim automatique, le contrôle du niveau d'eau et la vérification par paliers se moquent du nombre de modèles, et une longue session mono-modèle en profite tout autant. Le routage par intention ne prend son sens qu'avec plusieurs candidats de modèle ; laissez-le éteint jusqu'à ce que l'effectif s'élargisse.
 
 ## Skills incluses
 
@@ -75,7 +72,7 @@ Un seul modèle ? Ça vaut quand même l'installation — le contrôle du niveau
    - **Pools de dispatch** — six cartes sur deux rangées de trois : en haut léger / mécanique / principal ; en bas haute difficulté / multimodal / révision. Chaque carte coche les modèles candidats groupés par fournisseur ; cochez « ordre manuel » et elle devient une liste de priorités numérotée, à réordonner avec ↑ ↓ × ; chaque route peut épingler un effort de raisonnement (par défaut « suivre le couloir »). La ligne de résumé en haut se met à jour en direct ; sur la capture : « 4/6 pools configurés · 2 classés · mode advice ».
    - **Classement des capacités + mode d'exécution** — l'union des modèles cochés dans les six pools, classée par capacité, les plus forts devant (sur la capture glm-5.3 ancré S et glm-5.3-flash ancré A) ; on peut réordonner et retirer ; le mode d'exécution va de advice / enforce (enforce = tout modèle hors pool est refusé sans appel).
    - **Équipe d'agents** — les deux interrupteurs, mode équipe et synchronisation de la liste blanche, arrivent désactivés ; sur la capture ils sont activés, avec sous chacun une ligne d'état de synchronisation.
-   - **Niveau d'eau du contexte** — les trois seuils (sur la capture 80000 / 120000 / 150000), le budget de lecture par appel (3000), le comportement du palier hard (passage à débit limité / blocage), l'interrupteur de remise automatique et le plafond indépendant des subagents : tout tient dans cette zone. La ligne du bas porte les commandes : `/ctx-pause` suspend les interventions · `/ctx-resume` reprend · `/ctx-handover` écrit le document et remet immédiatement (il conduit la session jusqu'à une limite d'inactivité avant de compacter — le résultat peut prendre quelques minutes).
+   - **Niveau d'eau du contexte** — les trois seuils (sur la capture 80000 / 100000 / 200000), le budget de lecture par appel (3500), le comportement du palier hard (passage à débit limité / blocage), l'interrupteur de remise automatique et le plafond indépendant des subagents : tout tient dans cette zone. La ligne du bas porte les commandes : `/ctx-pause` suspend les interventions · `/ctx-resume` reprend · `/ctx-handover` écrit le document et remet immédiatement (il conduit la session jusqu'à une limite d'inactivité avant de compacter — le résultat peut prendre quelques minutes).
    - **Routage par intention** — l'interrupteur général, la route du petit modèle classifieur, le type de classifieur (auto / decision / chat), la liste de candidats indépendante (chacun avec sa note de capacité), la fenêtre de cache / seuil de confiance / timeout / budget d'historique et un modèle de repli facultatif. Une fois activé, le sélecteur de modèles gagne l'entrée localisée « Automatique (routage par intention) », et une pastille au-dessus du champ de saisie affiche le modèle routé et la confiance.
 
 4. **Vérifier** — un badge ⚡ « équipe autonome » apparaît dans l'en-tête de session (avec à côté une puce ◇ montrant le modèle de la session en cours) ; ou demandez simplement au modèle « quel est le titre du dernier paragraphe de ton prompt système » — la réponse doit mentionner la doctrine dsh-switchman.
@@ -92,19 +89,19 @@ bash <install-dir>/skills/db-query/scripts/setup.sh
 
 Voici l'ensemble complet des valeurs juste après une installation neuve (source faisant foi : le schéma zod de `host/config.js`).
 
-**Interface et langues** : `uiLocale` = `auto` (suit la langue de l'appli DSH) ; `langScope` = `global` ; `langConversation/Comments/Docs` = vides (une question posée une fois à la première session, puis retenue ; la langue des commentaires et de la documentation suit celle de la conversation).
+**Interface et langues** : `uiLocale` = `zh` (chinois simplifié ; `auto` suit la langue de l'appli DSH) ; `langScope` = `project` ; `langConversation` = `zh-CN`; `langComments/Docs` = vides (réglage par défaut ; si vidé, une question posée une fois à la première session, puis retenue ; la langue des commentaires et de la documentation suit celle de la conversation).
 
 **Pools de dispatch** : les six couloirs (economy/mechanical/main/hard/vision/review) démarrent sans candidats (= les modèles par défaut du système, aucune intervention) ; l'ordre manuel et l'effort épinglé sont désactivés/vides ; `dispatchEnforce` = `advice` (simple recommandation, rien n'est forcé).
 
-**Niveau d'eau du contexte** : soft `80000` / hard `95000` / force `150000` tokens ; budget de lecture par appel `3000` ; comportement en cas de dépassement `cap` (tronquer avec avertissement) ; `wmAutoHandover` = activé (à force, écriture du document de remise + compactage automatiques) ; le plafond strict des subagents = activé (150k partagées).
+**Niveau d'eau du contexte** : soft `80000` / hard `100000` / force `200000` tokens ; budget de lecture par appel `3500` ; comportement en cas de dépassement `cap` (tronquer avec avertissement) ; `wmAutoHandover` = activé (à force, écriture du document de remise + compactage automatiques) ; le plafond strict des subagents = activé (200k partagées).
 
-**Agent Teams** : `teamsMode` = désactivé ; `syncWhitelist` = désactivé (les deux interrupteurs sont indépendants l'un de l'autre).
+**Agent Teams** : `teamsMode` = activé ; `syncWhitelist` = activé (les deux interrupteurs sont indépendants l'un de l'autre).
 
-**Routage par intention** (indisponible par défaut ; il exige un classifieur + au moins un candidat + l'interrupteur général) : `intentEnabled` = désactivé (désactivé, l'entrée Auto reste cachée et les sessions déjà passées en Auto empruntent la chaîne de repli) ; route du classifieur non définie ; type de classifieur `chat` ; liste de candidats vide (les catégories préinstallées ne participent au routage qu'une fois un modèle renseigné) ; fenêtre de cache `300` s / seuil de confiance du basculement `80` / timeout de classification `60000` ms ; historique de `6` messages / `2400` caractères ; `intentContextWindow` = `200000`.
+**Routage par intention** (indisponible par défaut ; il exige un classifieur + au moins un candidat + l'interrupteur général) : `intentEnabled` = désactivé (désactivé, l'entrée Auto reste cachée et les sessions déjà passées en Auto empruntent la chaîne de repli) ; route du classifieur non définie ; type de classifieur `chat` ; liste de candidats vide (les catégories préinstallées ne participent au routage qu'une fois un modèle renseigné) ; fenêtre de cache `300` s / seuil de confiance du basculement `80` / timeout de classification `60000` ms ; historique de `6` messages / `2400` caractères ; `intentContextWindow` = `250000`.
 
-**Trim de contexte** : `trimEnabled` = activé ; `trimMode` = `auto` (entièrement automatique) ; porte de croissance `22500` + incrément `25000` tokens ; pression `65%` / urgence `95%` ; queue protégée `10` messages ; plafond de cadence des folds `30` par heure ; modèle annexe non défini (hérite du modèle de la session) — détails dans la section « Trim automatique du contexte » ci-dessous.
+**Trim de contexte** : `trimEnabled` = activé ; `trimMode` = `advisory` (rappels + outils de pliage ; le modèle de la session se plie lui-même — pour le mode entièrement automatique, `auto`) ; porte de croissance `22500` + incrément `45000` tokens ; pression `45%` / urgence `90%` ; rappels advisory `50%` / `80%` ; queue protégée `6` messages ; plafond de cadence des folds `30` par heure ; modèle annexe non défini (hérite du modèle de la session) — détails dans la section « Trim automatique du contexte » ci-dessous.
 
-**À savoir dès l'installation** : ① l'indisponibilité du routage par intention en sortie d'usine est un choix délibéré — trois étapes pour l'activer (classifieur, candidats, interrupteur) ; ② la fenêtre effective d'Auto vaut 200000 dès l'usine — le garde-fou garantit 0.8×fenêtre ≥ force (150000), si bien que la ligne de compactage cœur (160000) se situe toujours après la ligne de remise en douceur (150000) ; ③ l'effet le plus tangible dès l'usine est le trio de niveaux : 80k rappelle de déléguer / 95k resserre la lecture / 150k remet automatiquement (document + compactage) — sans aucun réglage.
+**À savoir dès l'installation** : ① l'indisponibilité du routage par intention en sortie d'usine est un choix délibéré — trois étapes pour l'activer (classifieur, candidats, interrupteur) ; ② la fenêtre effective d'Auto vaut 250000 dès l'usine — le garde-fou garantit 0.8×fenêtre ≥ force (200000), si bien que la ligne de compactage cœur (200000) se confond avec la ligne de remise en douceur (200000) ; ③ l'effet le plus tangible dès l'usine est le trio de niveaux : 80k rappelle de déléguer / 100k resserre la lecture / 200k remet automatiquement (document + compactage) — sans aucun réglage.
 
 ## Trim automatique du contexte
 
@@ -113,21 +110,25 @@ Les longues sessions restent bon marché : les plages de conversation consommée
 Niveaux d'automatisation (`trimMode`) :
 
 - **`off`** — mesure seule : l'échantillonnage de l'usage et des hits de cache tourne toujours ; pas de bannière, pas de folds.
-- **`advisory`** — le modèle de session se replie lui-même : les outils `ctx_trim_fold` et `ctx_trim_status` plus l'en-tête de protocole sont exposés.
-- **`auto`** (par défaut) — tout ce qui précède, plus des folds automatiques à la frontière d'inactivité, en trois paliers : une porte de croissance (croissance > `trimGrowthTokens` mesurée depuis le point bas après le dernier pli — l'ancre qui garde la porte armée après des plis confirmés à des points hauts de la view — ET un incrément compressible contigu ≥ `trimIncrementTokens`), un palier de pression (`trimPressurePercent` de la fenêtre de contexte) et un palier d'urgence (`trimEmergencyPercent` — un fold mécanique avec son propre refroidissement).
+- **`advisory`** (par défaut) — le modèle de session se replie lui-même : les outils `ctx_trim_fold` et `ctx_trim_status` plus l’en-tête de protocole sont exposés. Quand la pression de session atteint `trimAdvisoryPercent` de la fenêtre effective, le moteur ajoute un rappel de repli épinglé sous forme de suffixe `user/message` à la fin de la surface de session active (pas à l’en-tête system du dispatch) — répété immédiatement au passage au niveau critique et supprimé dès que la pression repasse sous la ligne. À la ligne critique, le moteur exécute lui-même un fold mécanique de secours (délai de 90 s, `trimCriticalRelief` = activé).
+- **`auto`** — tout ce qui précède, plus des folds automatiques à la frontière d'inactivité, en trois paliers : une porte de croissance (croissance > `trimGrowthTokens` mesurée depuis le point bas après le dernier pli — l'ancre qui garde la porte armée après des plis confirmés à des points hauts de la view — ET un incrément compressible contigu ≥ `trimIncrementTokens`), un palier de pression (`trimPressurePercent` de la fenêtre de contexte) et un palier d'urgence (`trimEmergencyPercent` — un fold mécanique avec son propre refroidissement).
 
 Toutes les clés vivent dans Réglages → dsh-switchman ; les valeurs par défaut viennent de `host/config.js` :
 
 | Clé | Par défaut | Signification |
 | --- | --- | --- |
 | `trimEnabled` | `true` | Interrupteur maître. Désactivé, folding et métriques s'arrêtent totalement (le listener se dégrade en simple passage). |
-| `trimMode` | `auto` | `off` mesure seule / `advisory` folds pilotés par le modèle / `auto` folds pilotés par le système. |
+| `trimMode` | `advisory` | `off` mesure seule / `advisory` folds pilotés par le modèle / `auto` folds pilotés par le système. |
 | `trimGrowthTokens` | `22500` | Porte de croissance : on plie quand la view sortante a grandi d'autant depuis le dernier fold. |
-| `trimIncrementTokens` | `25000` | Compagnon de la porte : l'incrément compressible contigu doit aussi atteindre cette taille. |
-| `trimPressurePercent` | `65` | Palier de pression : on plie quand l'usage de la view atteint ce pourcentage de la fenêtre de contexte. |
-| `trimEmergencyPercent` | `95` | Palier d'urgence : fold mécanique forcé (sans appel de modèle annexe) à ce pourcentage. |
+| `trimIncrementTokens` | `45000` | Compagnon de la porte : l'incrément compressible contigu doit aussi atteindre cette taille. |
+| `trimPressurePercent` | `45` | Palier de pression : on plie quand l'usage de la view atteint ce pourcentage de la fenêtre de contexte. |
+| `trimEmergencyPercent` | `90` | Palier d'urgence : fold mécanique forcé (sans appel de modèle annexe) à ce pourcentage. |
+| `trimAdvisoryPercent` | `50` | Ligne de rappel advisory : à ce pourcentage de la fenêtre effective, le moteur invite le modèle à replier immédiatement via `ctx_trim_fold` (mode advisory uniquement). |
+| `trimAdvisoryCriticalPercent` | `80` | Ligne critique : l'atteindre répète le rappel immédiatement, en contournant le bridage de 10 minutes à palier égal. |
 | `trimWindowTokens` | `0` | Plafond de fenêtre effectif pour le calcul des paliers : calculé sur min(fenêtre du modèle, plafond). `0` = suit `wmForceTokens`. |
-| `trimProtectedTail` | `10` | Les N derniers messages ne sont jamais repliés. |
+| `trimCriticalRelief` | `true` | Soulagement critique advisory : à la ligne critique, le moteur lui-même exécute un pliage mécanique (style urgence), avec un délai de 90 s. |
+| — | — | Les pourcentages de trim ne sont pas comparables au compteur de contexte du composer : trim divise le dernier prompt payé (max de view/wire) par la fenêtre effective (plafond inclus) ; le compteur affiche la projection du prochain prompt sur la fenêtre complète du modèle. |
+| `trimProtectedTail` | `6` | Les N derniers messages ne sont jamais repliés. |
 | `trimMaxFoldsPerHour` | `30` | Plafond de cadence des folds par heure glissante pour le modèle annexe (les folds d'urgence en sont exemptés). |
 | `trimSideModel` | non définie | Route du modèle annexe qui écrit les résumés. Vide = suivre le provider/model de la session, sans hériter de l'effort de cet appel ; les distillations ladder utilisent aussi cette route. L'effort du résumé peut être fixé séparément ; sans pin, les métadonnées du modèle déterminent le niveau de reasoning activé le plus bas ; pour un modèle limité à un interrupteur on/off, choisir off. Si le reasoning n'est pas pris en charge ou si les métadonnées sont indisponibles, aucun effort n'est envoyé et le comportement par défaut du modèle/de l'adaptateur s'applique. |
 | `trimFoldFallbackModel` | non définie | Route de relance quand le modèle annexe de résumé échoue ; un fold de pression dégrade alors en mécanique. Vide = pas de repli. Le modèle de repli du fold choisi manuellement a un pin d'effort indépendant ; sans pin, appliquer la même recommandation par métadonnées que pour le modèle de résumé, et en l'absence de métadonnées, le défaut du modèle. Choisir une route avec de la marge sur cooldowns, contrôle de risque et concurrence. |
@@ -136,7 +137,7 @@ Toutes les clés vivent dans Réglages → dsh-switchman ; les valeurs par défa
 
 **Chemins de déclenchement.** Les vérifications de paliers s'exécutent à la frontière d'inactivité et, en repli pour les hôtes où les événements d'état d'inactivité sont inaccessibles, après chaque fin de flux du modèle (limitées à une évaluation par 60 s et par session). Chaque décision — folds comme no-ops — est ajoutée comme une ligne `key=value` horodatée à `decisions.log` dans le répertoire d'état des folds (voir `trimStateDir`), donnant aux folds une piste d'audit hors ligne; le vocabulaire des lignes (`view-applied`, lignes de décision/résultat de fold, `surface-replace`, `surface-replace skipped reason=…`) est catalogué dans [docs/context-trim.md](./docs/context-trim.md).
 
-**Vérité du fil et régime stationnaire.** Les lignes de décision portent `view=<n>` et, une fois qu'une réponse est arrivée, `wire=<n>` — le prompt réel du fournisseur (entrée non cachée + lecture de cache + écriture de cache, échantillonné depuis l'événement d'usage du stream). L'estimation de la view ne compte que le tableau de messages et lit toujours moins que le fil, du surcoût fixe (mesuré ≈ 17.3k : system prompt + schémas d'outils + persona), donc les paliers de pression et d'urgence évaluent sur `max(view, wire)`, et seul `wire` est une lecture de la taille du prompt. Sur une fenêtre de 150k, la dent de scie saine fait tourner le fil à ≈ 40k juste après un fold ↔ 64–97.5k au suivant (≈27%–65% de la fenêtre), un fold par ~25k de croissance brute, le plafond étant arrimé près de 97.5k par le palier de pression plutôt que par la fenêtre. Si `view` monte sans qu'aucune ligne `surface-replace` n'apparaisse jamais, lisez les lignes d'omission (`incomplete-seqs`, `no-service`, `compaction-lock`).
+**Vérité du fil et régime stationnaire.** Les lignes de décision portent `view=<n>` et, une fois qu'une réponse est arrivée, `wire=<n>` — le prompt réel du fournisseur (entrée non cachée + lecture de cache + écriture de cache, échantillonné depuis l'événement d'usage du stream). L'estimation de la view ne compte que le tableau de messages et lit toujours moins que le fil, du surcoût fixe (mesuré ≈ 17.3k : system prompt + schémas d'outils + persona), donc les paliers de pression et d'urgence évaluent sur `max(view, wire)`, et seul `wire` est une lecture de la taille du prompt. Sur une fenêtre de 200k, la dent de scie saine fait tourner le fil à ≈ 40k juste après un fold ↔ 64–90k au suivant (≈20%–45% de la fenêtre), un fold par ~45k de croissance brute, le plafond étant arrimé près de 90k par le palier de pression plutôt que par la fenêtre. Si `view` monte sans qu'aucune ligne `surface-replace` n'apparaisse jamais, lisez les lignes d'omission (`incomplete-seqs`, `no-service`, `compaction-lock`).
 
 **Époques de compactage de l'hôte.** Les références de fold sont ancrées dans les identifiants de messages et les hachages de contenu ; quand l'hôte compacte lui-même l'historique renvoyé, tout le registre vieillit d'un coup : plus aucun bloc ne se localise, la vue retombe silencieusement sur l'historique brut (fail-open — le journal des décisions note `view-applied applied=0`), et le plugin ré-ancre sa base de croissance sur la vue post-compaction à la requête suivante. La compaction de l'hôte est donc la couche de rognage de dernier recours ; les folds du plugin font le travail fin au sein d'une époque de l'hôte. Certains dispatches remettent des tableaux de requête ou des objets d'options entièrement gelés (la boucle d'agent actuelle gèle en profondeur les requêtes assemblées) ; pour eux, `injectView` rapporte l'issue dans le journal des décisions : `nothing-to-apply` (aucun bloc de fold localisé — l'historique brut EST la vue), `in-place`/`swapped` (la vue pliée est partie avec la requête) ou `none` (un fold existait mais le dispatch gelé ne pouvait pas le transporter — l'historique brut part sur le fil). **Le remplacement de surface est le chemin d'expédition quand il est disponible** (`surfaceFold`, activé par défaut) : à la frontière sérielle `agent/turn-stopping` plus un balayage d'inactivité, le plugin ajoute l'événement de mesure shadow-price à la manière de l'hôte et UN remplacement `user/message` portant `surfaceOp {op:'replace', startSeq, endSeq}` avec des `sourceEventSeqs` couvrant chaque nœud de surface masqué — le même mécanisme que celui de la compaction de l'hôte elle-même —, de sorte qu'un fold validé rejoint le fil depuis le niveau source, dispatches gelés compris. Tant que les dispatches récents d'une session consignent `none`, le plugin traite la vue comme une simple mesure : le niveau d'eau lit à la place le total rapporté par le fournisseur (le palier force et la remise automatique continuent de fonctionner), les cycles de fold se mettent en pause au lieu de brûler des appels au résumeur, et la bannière de rognage marque la ligne avec `wire=raw` (folds not shipping; watermark reads the tally) ; les hôtes sans le mécanisme de surface (ou avec l'option désactivée) gardent exactement cet ancien comportement.
 
@@ -161,6 +162,12 @@ Toutes les clés vivent dans Réglages → dsh-switchman ; les valeurs par défa
 - Les lignes de protocole (`[SWITCHMAN:LANG|POOLS|WATERMARK|TEAMS]`) restent volontairement en anglais et stables à l'octet — ne les localisez pas.
 - `npm pack --dry-run` doit conserver la forme auditée de 60 fichiers / ~380 kB (~1,26 Mo décompressés ; `docs/` est exclu).
 
+## Téléchargements
+
+Tous les téléchargements npm depuis la première publication, en cumul — tracés à partir de l'[API officielle des téléchargements npm](https://api.npmjs.org/) et actualisés chaque jour par GitHub Actions ([script du graphique](scripts/downloads-chart.mjs)) :
+
+![Téléchargements npm cumulés pour dsh-switchman](docs/assets/downloads.svg)
+
 ## License
 
 MIT

package/README.it.md

@@ -12,30 +12,27 @@
 
 Se lavori con DSH, col passare del tempo ti imbatti in due cose: la sessione pesa sempre di più — la cronologia gonfia il contesto fino a centinaia di migliaia di token, il modello inizia a dimenticare, rallenta e costa di più, e il /compact manuale comprime perdendo dettagli nel farlo; e il modello principale fa tutto da solo — leggere un file, lanciare un test, confrontare dati: è sempre lui a masticarli, lento e costoso, quando gran parte di quel lavoro spetterebbe a un modello economico.
 
-dsh-switchman è un plugin per [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) (DSH). Una volta installato, il modello principale smette di «fare tutto da solo» e diventa un dispatcher: misura il livello dell'acqua, sceglie la corsia, assegna i task, verifica il risultato. Non è un nuovo modello: è un regolamento di orchestrazione agganciato a DSH più un'interfaccia di configurazione. In concreto fa otto cose:
+dsh-switchman è un plugin per [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) (DSH). Una volta installato, il modello principale continua a lavorare di persona — solo con più criterio: sceglie le sue battaglie, affida i lavoretti a corsie economiche e lascia che l'instradamento per intent faccia atterrare l'urgente o il difficile sul modello giusto, riservando a sé solo ciò che merita davvero un tocco personale; scarta il gonfio e distilla l'essenziale — le parti già digerite della conversazione si ripiegano in riassunti compatti mentre il livello dell'acqua misura ogni spesa, e il contesto viaggia sempre leggero; e quando il carico supera un solo paio di mani, arruola compagni permanenti che si spartiscono il lavoro su un task board condiviso, mentre lui si riserva il dispatch e la verifica. Non è un nuovo modello: è un regolamento di orchestrazione agganciato a DSH più un'interfaccia di configurazione. In concreto fa nove cose:
 
-**1. Livello dell'acqua del contesto: le sessioni lunghe non esplodono.** A ogni turno conta i token della sessione in tempo reale, e tre soglie inaspriscono a gradini: 80k (soft, regolabile) ricorda che «è ora di delegare»; 95k (hard) stringe il budget di lettura per singola chiamata e spinge verso la chiusura; 150k (force) avvia l'handover automatico — scrittura del documento di handover (il log di sessione append-only è la copia completa), contesto compattato, sessione risvegliata per continuare: il task non si interrompe. Nemmeno i subagent in background ancora in corsa al momento del passaggio si perdono: id, descrizione del task e percorso del report finiscono nel documento di handover, così la sessione ripresa sa dove raccogliere i report invece di ri-assegnare lo stesso lavoro. Ogni subagent inviato porta con sé un tetto massimo indipendente e, raggiunto il limite, esce dopo aver scritto il riepilogo HANDOFF. Se l'intervento automatico non ti torna, prendi tu il comando in qualsiasi momento: `/ctx-pause` ferma tutte le azioni della soglia (la misurazione continua, la riga del livello dell'acqua in tempo reale in coda passa a paused — smette solo di agire), `/ctx-resume` ripristina in qualsiasi momento — dopo un riavvio di DSH l'intervento torna anche da solo, un mollare la presa temporaneo, non uno spegnimento definitivo; `/ctx-handover` non aspetta che la soglia tocchi il limite e avvia su richiesta lo stesso handover: scrittura del documento di handover, compattazione del contesto, risveglio della sessione per continuare (la sessione viene prima guidata fino al confine di inattività, quindi il risultato può richiedere qualche minuto).
+**1. Trim automatico del contesto: la sessione si allunga, il costo resta piatto.** Un `/compact` manuale ti fa aspettare, perde dettagli e buca la cache di prompt del fornitore. Il motore di trim automatizza tutto questo: le parti già digerite della conversazione vengono ripiegate in riassunti deterministici e compatti ai confini di inattività (a scriverli pensa un side model; sotto pressione d'emergenza il ripiegamento è meccanico, senza chiamate al modello), e da quel momento ogni richiesta in uscita viene ricostruita dallo stato dei ripiegamenti — i blocchi di riassunto prendono il posto delle parti ripiegate, la coda viva resta parola per parola. Il log di sessione salvato non viene mai riscritto, e nulla tocca lo stream in pieno corso. I ripiegamenti sono solo append e la ricostruzione è deterministica: il prefisso serializzato resta identico al byte tra un ripiegamento e l'altro e la cache del fornitore continua a essere agganciata; ogni fallimento interno ricade in fail-open verso il passaggio trasparente — mai una richiesta malformata. Tre livelli completamente automatici (crescita / pressione / emergenza), più una modalità advisory in cui è il modello a ripiegare da solo — la meccanica è in fondo, nella sezione «Trim automatico del contesto».
 
-**2. Sei pool di dispatch: a ogni lavoro il suo modello.** Pool leggero (economy, piccoli lavori in serie), pool meccanico (mechanical, riscritture modellate), pool principale (main, coding di tutti i giorni), pool ad alta difficoltà (hard, ragionamento complesso e refactoring su larga scala), pool multimodale (vision, lettura delle immagini), pool di revisione (review, verifica indipendente). Nella pagina delle impostazioni spunti i candidati, ordini le priorità (con fasce opzionali S/A/B/C) e fichi un reasoning effort per ogni route — il menu a tendina elenca i livelli che quel modello supporta davvero, non tre livelli generici. A ogni turno il prompt del modello principale viaggia con una tabella di raccomandazioni `[SWITCHMAN:POOLS]`: si assegna il lavoro seguendo la tabella. La modalità di esecuzione ha tre stati: off / advice / enforce (enforce = i modelli fuori pool vengono rifiutati sul posto).
+**2. Livello dell'acqua del contesto: le sessioni lunghe non esplodono.** A ogni turno conta i token della sessione in tempo reale, e tre soglie inaspriscono a gradini: 80k (soft, regolabile) ricorda che «è ora di delegare»; 100k (hard) stringe il budget di lettura per singola chiamata e spinge verso la chiusura; 200k (force) avvia l'handover automatico — scrittura del documento di handover (il log di sessione append-only è la copia completa), contesto compattato, sessione risvegliata per continuare: il task non si interrompe. Nemmeno i subagent in background ancora in corsa al momento del passaggio si perdono: id, descrizione del task e percorso del report finiscono nel documento di handover, così la sessione ripresa sa dove raccogliere i report invece di ri-assegnare lo stesso lavoro; ogni subagent inviato porta inoltre con sé un tetto massimo indipendente e, raggiunto il limite, esce dopo aver scritto il riepilogo HANDOFF. Il livello legge la vista dopo il trim — ciò che il modello vede davvero —, così una sessione molto ripiegata non resta più inchiodata sulle soglie alte. Se l'automatismo non ti torna: `/ctx-pause` ferma tutte le azioni (la misurazione continua), `/ctx-resume` ripristina in qualsiasi momento — e dopo un riavvio torna anche da solo; `/ctx-handover` avvia su richiesta lo stesso handover, senza aspettare il tetto.
 
-**3. Modalità Agent Teams: dal lavoro solitario alla squadra.** Disattivata di default: appena installato si lavora con un dispatch leggero via subagent. Nella pagina delle impostazioni, due interruttori indipendenti:
+**3. Instradamento per intent: arriva il messaggio, il modello prende il suo posto.** Scegli «Auto (instradamento per intent)» per la sessione e ogni messaggio dell'utente viene prima tipizzato da un piccolo modello classificatore, che lo fa atterrare sul candidato più adatto — ogni candidato porta una nota di capacità di una riga a orientare la scelta. La decisione è bloccata per il turno: se la fiducia manca o la finestra di cache è ancora aperta, resta il modello corrente (la sua cache di prompt continua a rendere); si passa solo quando la fiducia è bastevole o il modello corrente non è tra i candidati. Il passaggio avviene in silenzio al livello di chiamata — nessun rumore di «modello cambiato» nella sessione — mentre un chip sopra la casella di input mostra in diretta rotta e fiducia. Come classificatore valgono sia i piccoli modelli di decisione sia i modelli di chat generici; candidati, soglie e finestra di cache sono sempre a una pagina di impostazioni di distanza.
 
-- **Modalità Agent Teams** — una volta attivata, inietta la dottrina di squadra (delega per default + verifica a livelli + disciplina del task board condiviso) e abilita automaticamente gli Agent Teams di DSH: il modello principale può arruolare compagni permanenti (`spawn_teammate`), assegnare lavori al task board condiviso (`team_task_*`) e scambiarsi messaggi con loro. Quando formare la squadra segue una disciplina precisa: sotto-task indipendenti parallelizzabili, lavori voluminosi e autosufficienti, livello dell'acqua del contesto principale già alto, necessità di separare i ruoli; le indagini una-tantum restano al subagent. Ri-spegnendo l'interruttore, le clausole di squadra spariscono senza residui, e gli strumenti di squadra nelle sessioni in corso non vengono ritirati.
-- **Sincronizzazione della whitelist dei modelli per i subagent** — DSH ha una whitelist di autorizzazione «Consenti agli agenti di scegliere i modelli per i subagent»: le route scelte nei pool ma non autorizzate vengono rifiutate se il modello principale le nomina esplicitamente (in modalità squadra, vengono marcate con ⚠). Con questo interruttore attivo, l'unione dei sei pool viene scritta in un colpo solo in quella whitelist — niente configurazione doppia: switchman è l'unica fonte di verità. La whitelist scatta come snapshot alla «nuova sessione»: la sincronizzazione vale solo per le sessioni aperte dopo.
+**4. Modalità Agent Teams: dal lavoro solitario alla squadra.** Disattivata di default: appena installato si lavora con un dispatch leggero via subagent. Nella pagina delle impostazioni, due interruttori indipendenti: **Modalità Agent Teams** — una volta attivata, inietta la dottrina di squadra (delega per default + verifica a livelli + disciplina del task board condiviso) e abilita automaticamente gli Agent Teams di DSH: il modello principale può arruolare compagni permanenti (`spawn_teammate`), assegnare lavori al task board condiviso (`team_task_*`) e scambiarsi messaggi con loro. Quando formare la squadra segue una disciplina precisa: sotto-task indipendenti parallelizzabili, lavori voluminosi e autosufficienti, livello dell'acqua del contesto principale già alto, necessità di separare i ruoli; le indagini una-tantum restano al subagent. Ri-spegnendo l'interruttore, le clausole di squadra spariscono senza residui, e gli strumenti di squadra nelle sessioni in corso non vengono ritirati. **Sincronizzazione della whitelist dei modelli per i subagent** — DSH ha una whitelist di autorizzazione «Consenti agli agenti di scegliere i modelli per i subagent»: le route scelte nei pool ma non autorizzate vengono rifiutate se il modello principale le nomina esplicitamente (in modalità squadra, vengono marcate con ⚠). Con questo interruttore attivo, l'unione dei sei pool viene scritta in un colpo solo in quella whitelist — niente configurazione doppia: switchman è l'unica fonte di verità. La whitelist scatta come snapshot alla «nuova sessione»: la sincronizzazione vale solo per le sessioni aperte dopo.
 
-L'intestazione della sessione dà un riscontro immediato: badge ⚡ «Squadra autonoma», ◇ modello effettivo della sessione in corso; durante un handover automatico compare un avviso in tempo reale del tipo «Handover in corso · scrittura del documento di handover / compattazione del contesto / risveglio della continuazione».
+**5. Sei pool di dispatch: a ogni lavoro il suo modello.** Pool leggero (economy, piccoli lavori in serie), pool meccanico (mechanical, riscritture modellate), pool principale (main, coding di tutti i giorni), pool ad alta difficoltà (hard, ragionamento complesso e refactoring su larga scala), pool multimodale (vision, lettura delle immagini), pool di revisione (review, verifica indipendente). Nella pagina delle impostazioni spunti i candidati, ordini le priorità (con fasce opzionali S/A/B/C) e fichi un reasoning effort per ogni route — il menu a tendina elenca i livelli che quel modello supporta davvero, non tre livelli generici. A ogni turno il prompt del modello principale viaggia con una tabella di raccomandazioni `[SWITCHMAN:POOLS]`: si assegna il lavoro seguendo la tabella. La modalità di esecuzione ha tre stati: off / advice / enforce (enforce = i modelli fuori pool vengono rifiutati sul posto).
 
-**4. Preferenze linguistiche: chiede una volta, ricorda per sempre.** Un menu a tendina per ciascuna delle tre lingue — risposte, commenti nel codice, documenti — con ambito a scelta globale o per progetto (`.switchman/lang.json`). Puoi anche non impostarlo: al primo utilizzo ti viene chiesto una volta, nella lingua dell'interfaccia DSH, e da lì in poi ogni sessione lo rispetta da sé.
+**6. Preferenze linguistiche: chiede una volta, ricorda per sempre.** Un menu a tendina per ciascuna delle tre lingue — risposte, commenti nel codice, documenti — con ambito a scelta globale o per progetto (`.switchman/lang.json`). Puoi anche non impostarlo: al primo utilizzo ti viene chiesto una volta, nella lingua dell'interfaccia DSH, e da lì in poi ogni sessione lo rispetta da sé.
 
-**5. Lingua dell'interfaccia: il plugin parla anche la tua lingua.** In cima alla pagina delle impostazioni arriva una nuova sezione «Interfaccia» con un menu a tendina «Lingua dell'interfaccia» (chiave di impostazione `uiLocale`): Automatico (predefinito — segue la lingua dell'app DeepSeek Harness) o una qualsiasi delle lingue dell'interfaccia del plugin, sempre mostrata con il suo endonimo, mai tradotta. Cambia solo l'interfaccia del plugin stesso — il badge nell'intestazione, il pannello home e la pagina delle impostazioni —, non la lingua dell'app DSH: l'anteprima è immediata, senza riavvio; il salvataggio ricorda la scelta; il prossimo avvio la ripristina; ogni errore ricade sulla lingua dell'app; e tutti i dizionari viaggiano nel bundle, nessun download.
+**7. Lingua dell'interfaccia: il plugin parla anche la tua lingua.** In cima alla pagina delle impostazioni arriva una nuova sezione «Interfaccia» con un menu a tendina «Lingua dell'interfaccia» (chiave di impostazione `uiLocale`): Automatico (segue la lingua dell'app DeepSeek Harness; cinese semplificato di fabbrica) o una qualsiasi delle lingue dell'interfaccia del plugin, sempre mostrata con il suo endonimo, mai tradotta. Cambia solo l'interfaccia del plugin stesso — il badge nell'intestazione, il pannello home e la pagina delle impostazioni —, non la lingua dell'app DSH: l'anteprima è immediata, senza riavvio; il salvataggio ricorda la scelta; il prossimo avvio la ripristina; ogni errore ricade sulla lingua dell'app; e tutti i dizionari viaggiano nel bundle, nessun download.
 
-**6. Verifica a livelli: finita la modifica, si controlla.** Le modifiche oltre 20 righe vanno a un tester per la verifica; oltre 300 righe, o quando si toccano logica centrale / sicurezza / coerenza dei dati, subentra anche un reviewer con revisione indipendente. Il modello del reviewer si sceglie ancorandolo a quello dell'«agente che ha scritto il diff», evitandolo per quanto possibile; se nel pool proprio non si riesce, la conclusione dichiara DOWNGRADED. Basta dire «non usare le squadre» e torna subito a lavorare da solo.
+**8. Verifica a livelli: finita la modifica, si controlla.** Le modifiche oltre 20 righe vanno a un tester per la verifica; oltre 300 righe, o quando si toccano logica centrale / sicurezza / coerenza dei dati, subentra anche un reviewer con revisione indipendente. Il modello del reviewer si sceglie ancorandolo a quello dell'«agente che ha scritto il diff», evitandolo per quanto possibile; se nel pool proprio non si riesce, la conclusione dichiara DOWNGRADED. Basta dire «non usare le squadre» e torna subito a lavorare da solo.
 
-**7. `/vision`: anche i modelli solo testo trattano le immagini.** Quando il modello principale non sa leggere le immagini, DSH rifiuta al varco i messaggi che le contengono. Alleghi l'immagine e digiti `/vision dov'è l'errore in questa immagine`: l'immagine viene affidata alla lettura di un modello del pool multimodale, e la conclusione torna nella sessione corrente. Sopra la casella di input compare in anticipo l'avviso «il modello corrente non supporta la lettura delle immagini»; se un invio diretto dell'immagine viene rifiutato, il messaggio viene riscritto una volta in `/vision` e reinviato da solo, senza dover rifare tutto a mano; senza pool multimodale configurato, il comando rifiuta e indica come configurarlo.
+**9. `/vision`: anche i modelli solo testo trattano le immagini.** Quando il modello principale non sa leggere le immagini, DSH rifiuta al varco i messaggi che le contengono. Alleghi l'immagine e digiti `/vision dov'è l'errore in questa immagine`: l'immagine viene affidata alla lettura di un modello del pool multimodale, e la conclusione torna nella sessione corrente. Sopra la casella di input compare in anticipo l'avviso «il modello corrente non supporta la lettura delle immagini»; se un invio diretto dell'immagine viene rifiutato, il messaggio viene riscritto una volta in `/vision` e reinviato da solo, senza dover rifare tutto a mano; senza pool multimodale configurato, il comando rifiuta e indica come configurarlo.
 
-**8. Instradamento per intent: il modello giusto si sceglie da sé.** La pagina delle impostazioni si arricchisce di un gruppo «Instradamento per intent»: un interruttore principale (spento per predefinito; per attivarlo servono un classificatore e almeno un candidato), la route del piccolo modello classificatore (provider + model + effort facoltativo — vanno bene sia i modelli decisionali tipo TypeSafe Jev sia i modelli di chat generici, e l'output viene letto con tolleranza), una scelta a tre vie del tipo di classificatore (auto / decision / chat), una lista di candidati indipendente (per ogni candidato: provider + model + effort facoltativo + una nota di capacità di una riga), la finestra di cache in secondi (300 per predefinito, allineata alle cache di prompt dei provider, circa 5 minuti), la soglia di confidenza per il cambio (80 per predefinito), il timeout di classificazione (60000 ms per predefinito), il numero di messaggi di cronologia (6 per predefinito) e il budget di caratteri (2400 per predefinito), più un modello di fallback facoltativo (con un pin di effort facoltativo e indipendente; se non fissato, si usa l'effort predefinito del modello di fallback selezionato, separato da quello del classificatore). Nel selettore dei modelli compare una voce «Auto» nel gruppo «Auto · Switchman» (il client la renderizza localizzata — «Automatico (instradamento per intent)» in italiano); una volta scelta, ogni messaggio dell'utente passa dal classificatore per eleggere il candidato migliore e la decisione resta fissata per quel turno: se la confidenza non basta o la finestra di cache è ancora aperta, resta il modello corrente (riusandone la cache); si cambia solo quando la confidenza è sufficiente o il modello corrente non è tra i candidati. Il cambio avviene in silenzio al livello di chiamata — nessun messaggio «modello cambiato» finisce nella sessione. Sopra la casella di input c'è una chip di stato (con instradamento automatico mostra il modello di instradamento corrente e la confidenza dell'ultima decisione); candidati e soglie si consultano sempre nella pagina delle impostazioni.
-
-Un solo modello? Vale comunque la pena installarlo — il controllo del livello dell'acqua e la verifica a livelli non guardano a quanti modelli hai, e ne giovancono allo stesso modo le sessioni lunghe con un modello unico.
+Un solo modello? Vale comunque la pena installarlo — trim automatico, controllo del livello dell'acqua e verifica a livelli non guardano a quanti modelli hai, e ne giovancono allo stesso modo le sessioni lunghe con un modello unico. L'instradamento per intent ha senso solo con più candidati modello: lascialo spento finché la squadra non si allarga.
 
 ## Skill incluse
 
@@ -75,7 +72,7 @@ Un solo modello? Vale comunque la pena installarlo — il controllo del livello
    - **Pool di dispatch** — sei schede su due righe da tre: in alto leggero / meccanico / principale; in basso alta difficoltà / multimodale / revisione. In ogni scheda si spuntano i candidati raggruppati per provider; spunta «ordine manuale» e diventa una lista di priorità numerata da riordinare con ↑ ↓ ×; accanto a ogni route puoi fichare il reasoning effort (predefinito «segui la corsia»). La riga di riepilogo in alto si aggiorna in tempo reale; nella schermata: «4/6 pool configurati · 2 in classifica · modalità advice».
    - **Classifica di capacità + modalità di esecuzione** — l'unione dei modelli scelti nei sei pool, ordinata per capacità con i più forti davanti (nella schermata glm-5.3 ancorato in S e glm-5.3-flash ancorato in A); si può riordinare e ridurre; la modalità di esecuzione va da advice / enforce (enforce = i modelli fuori pool vengono rifiutati sul posto).
    - **Squadra di agenti** — i due interruttori, modalità squadra e sincronizzazione della whitelist, partono spenti; nella schermata sono accesi, con sotto una riga di stato della sincronizzazione.
-   - **Livello dell'acqua del contesto** — le tre soglie (nella schermata 80000 / 120000 / 150000), il budget di lettura per singola chiamata (3000), il comportamento della soglia hard (passa con limitazione / blocca), l'interruttore dell'handover automatico e il tetto indipendente dei subagent: tutto in quest'area. Una riga di comandi in fondo: `/ctx-pause` sospende gli interventi · `/ctx-resume` li riprende · `/ctx-handover` scrive il documento e passa le consegne subito (guida la sessione fino al confine di inattività prima di compattare: il risultato può richiedere alcuni minuti).
+   - **Livello dell'acqua del contesto** — le tre soglie (nella schermata 80000 / 100000 / 200000), il budget di lettura per singola chiamata (3500), il comportamento della soglia hard (passa con limitazione / blocca), l'interruttore dell'handover automatico e il tetto indipendente dei subagent: tutto in quest'area. Una riga di comandi in fondo: `/ctx-pause` sospende gli interventi · `/ctx-resume` li riprende · `/ctx-handover` scrive il documento e passa le consegne subito (guida la sessione fino al confine di inattività prima di compattare: il risultato può richiedere alcuni minuti).
    - **Instradamento per intent** — l'interruttore principale, la route del piccolo modello classificatore, il tipo di classificatore (auto / decision / chat), la lista di candidati indipendente (ciascuno con la sua nota di capacità), finestra di cache / soglia di confidenza / timeout / budget di cronologia e un modello di fallback facoltativo. Attivandolo, il selettore dei modelli guadagna la voce localizzata «Automatico (instradamento per intent)» e sopra la casella di input compare la chip con il modello di instradamento e la confidenza.
 
 4. **Verifica** — nell'intestazione della sessione compare il badge ⚡ «Squadra autonoma» (accanto, il ◇ mostra il modello della sessione in corso); oppure chiedi direttamente al modello «qual è il titolo dell'ultima sezione del tuo system prompt?» — la risposta dovrebbe menzionare la dottrina dsh-switchman.
@@ -92,19 +89,19 @@ bash <install-dir>/skills/db-query/scripts/setup.sh
 
 Questi sono tutti i valori così come si presentano dopo una nuova installazione (fonte autorevole: lo schema zod in `host/config.js`).
 
-**Interfaccia e lingue**: `uiLocale` = `auto` (segue la lingua dell'app DSH); `langScope` = `global`; `langConversation/Comments/Docs` = vuote (una domanda fatta una volta alla prima sessione, poi ricordata; la lingua di commenti e documenti segue quella della conversazione).
+**Interfaccia e lingue**: `uiLocale` = `zh` (cinese semplificato; `auto` segue la lingua dell'app DSH); `langScope` = `project`; `langConversation` = `zh-CN`; `langComments/Docs` = vuote (impostazione predefinita; se svuotato, una domanda fatta una volta alla prima sessione, poi ricordata; la lingua di commenti e documenti segue quella della conversazione).
 
 **Pool di dispatch**: le sei corsie (economy/mechanical/main/hard/vision/review) partono senza candidati (= i modelli predefiniti del sistema, nessuna interferenza); ordine manuale ed effort fissato spenti/vuoti; `dispatchEnforce` = `advice` (solo consiglio, niente di imposto).
 
-**Livello dell'acqua del contesto**: soft `80000` / hard `95000` / force `150000` token; budget di lettura per singola chiamata `3000`; comportamento oltre budget `cap` (tronca con avviso); `wmAutoHandover` = attivo (a force, scrittura del documento di handover + compattazione automatiche); il tetto massimo dei subagent = attivo (150k condivisi).
+**Livello dell'acqua del contesto**: soft `80000` / hard `100000` / force `200000` token; budget di lettura per singola chiamata `3500`; comportamento oltre budget `cap` (tronca con avviso); `wmAutoHandover` = attivo (a force, scrittura del documento di handover + compattazione automatiche); il tetto massimo dei subagent = attivo (200k condivisi).
 
-**Agent Teams**: `teamsMode` = spento; `syncWhitelist` = spento (i due interruttori sono indipendenti tra loro).
+**Agent Teams**: `teamsMode` = acceso; `syncWhitelist` = acceso (i due interruttori sono indipendenti tra loro).
 
-**Instradamento per intent** (non disponibile per predefinito; servono classificatore + almeno un candidato + l'interruttore principale): `intentEnabled` = spento (spento, la voce Auto resta nascosta e le sessioni che l'avevano già scelta percorrono la catena di fallback); route del classificatore non impostata; tipo di classificatore `chat`; lista dei candidati vuota (le categorie preinstallate entrano nell'instradamento solo con un modello assegnato); finestra di cache `300` s / soglia di confidenza del cambio `80` / timeout di classificazione `60000` ms; cronologia di `6` messaggi / `2400` caratteri; `intentContextWindow` = `200000`.
+**Instradamento per intent** (non disponibile per predefinito; servono classificatore + almeno un candidato + l'interruttore principale): `intentEnabled` = spento (spento, la voce Auto resta nascosta e le sessioni che l'avevano già scelta percorrono la catena di fallback); route del classificatore non impostata; tipo di classificatore `chat`; lista dei candidati vuota (le categorie preinstallate entrano nell'instradamento solo con un modello assegnato); finestra di cache `300` s / soglia di confidenza del cambio `80` / timeout di classificazione `60000` ms; cronologia di `6` messaggi / `2400` caratteri; `intentContextWindow` = `250000`.
 
-**Trim del contesto**: `trimEnabled` = acceso; `trimMode` = `auto` (del tutto automatico); cancello di crescita `22500` + incremento `25000` token; pressione `65%` / emergenza `95%`; coda protetta `10` messaggi; tetto di cadenza dei fold `30` all'ora; modello secondario non impostato (eredita il modello della sessione) — dettagli nella sezione «Trim automatico del contesto» più sotto.
+**Trim del contesto**: `trimEnabled` = acceso; `trimMode` = `advisory` (avvisi + strumenti di piegatura; il modello della sessione si ripiega da solo — per la modalità del tutto automatica, `auto`); cancello di crescita `22500` + incremento `45000` token; pressione `45%` / emergenza `90%`; avvisi advisory `50%` / `80%`; coda protetta `6` messaggi; tetto di cadenza dei fold `30` all'ora; modello secondario non impostato (eredita il modello della sessione) — dettagli nella sezione «Trim automatico del contesto» più sotto.
 
-**Note di serie**: ① l'instradamento per intent non disponibile di serie è una scelta voluta — tre passi per attivarlo (classificatore, candidati, interruttore); ② la finestra effettiva di Auto vale di serie 200000 — la barriera di sicurezza garantisce 0.8×finestra ≥ force (150000), così la linea di compattazione del cuore (160000) resta sempre dopo la linea di consegna morbida (150000); ③ di serie la cosa più percettibile è il terzetto di soglie: 80k ricorda di delegare / 95k stringe la lettura / 150k consegna da sola (documento + compattazione) — senza alcuna impostazione.
+**Note di serie**: ① l'instradamento per intent non disponibile di serie è una scelta voluta — tre passi per attivarlo (classificatore, candidati, interruttore); ② la finestra effettiva di Auto vale di serie 250000 — la barriera di sicurezza garantisce 0.8×finestra ≥ force (200000), così la linea di compattazione del cuore (200000) coincide con la linea di consegna morbida (200000); ③ di serie la cosa più percettibile è il terzetto di soglie: 80k ricorda di delegare / 100k stringe la lettura / 200k consegna da sola (documento + compattazione) — senza alcuna impostazione.
 
 ## Trim automatico del contesto
 
@@ -113,21 +110,25 @@ Le sessioni lunghe restano economiche: le porzioni di conversazione già consuma
 Livelli di automazione (`trimMode`):
 
 - **`off`** — solo misura: il campionamento di uso e hit di cache continua; niente banner, niente fold.
-- **`advisory`** — il modello della sessione si ripiega da sé: vengono esposti gli strumenti `ctx_trim_fold` e `ctx_trim_status` più l'intestazione di protocollo.
-- **`auto`** (predefinito) — tutto quanto sopra più fold automatici al confine di inattività, su tre scalini: un cancello di crescita (crescita > `trimGrowthTokens` misurata dal minimo post-ripiegamento dell'ultimo fold — l'ancora che mantiene il cancello armato dopo ripiegamenti confermati su punti alti della view — E un incremento comprimibile contiguo ≥ `trimIncrementTokens`), uno scalino di pressione (`trimPressurePercent` della finestra di contesto) e uno scalino di emergenza (`trimEmergencyPercent` — un fold meccanico con il proprio raffreddamento).
+- **`advisory`** (predefinito) — il modello della sessione si ripiega da sé: vengono esposti gli strumenti `ctx_trim_fold` e `ctx_trim_status` più l’intestazione di protocollo. Quando la pressione della sessione raggiunge `trimAdvisoryPercent` della finestra effettiva, il motore aggiunge un sollecito di ripiegamento fissato come suffisso `user/message` alla fine della surface attiva della sessione (non all’intestazione system del dispatch) — ripetuto immediatamente all’escalation a critical e rimosso quando la pressione rientra sotto la linea. Alla linea critica il motore esegue da sé un fold meccanico di soccorso (cooldown di 90 s, `trimCriticalRelief` = acceso).
+- **`auto`** — tutto quanto sopra più fold automatici al confine di inattività, su tre scalini: un cancello di crescita (crescita > `trimGrowthTokens` misurata dal minimo post-ripiegamento dell'ultimo fold — l'ancora che mantiene il cancello armato dopo ripiegamenti confermati su punti alti della view — E un incremento comprimibile contiguo ≥ `trimIncrementTokens`), uno scalino di pressione (`trimPressurePercent` della finestra di contesto) e uno scalino di emergenza (`trimEmergencyPercent` — un fold meccanico con il proprio raffreddamento).
 
 Tutte le chiavi stanno in Impostazioni → dsh-switchman; i valori predefiniti vengono da `host/config.js`:
 
 | Chiave | Predefinito | Significato |
 | --- | --- | --- |
 | `trimEnabled` | `true` | Interruttore principale. Spento disattiva fold e metriche del tutto (il listener degrada a puro pass-through). |
-| `trimMode` | `auto` | `off` solo misura / `advisory` fold guidati dal modello / `auto` fold guidati dal sistema. |
+| `trimMode` | `advisory` | `off` solo misura / `advisory` fold guidati dal modello / `auto` fold guidati dal sistema. |
 | `trimGrowthTokens` | `22500` | Cancello di crescita: ripiega quando la view in uscita è cresciuta di tanto dall'ultimo fold. |
-| `trimIncrementTokens` | `25000` | Compagno del cancello: anche l'incremento comprimibile contiguo deve raggiungere questa taglia. |
-| `trimPressurePercent` | `65` | Scalino di pressione: ripiega quando l'uso della view raggiunge questa percentuale della finestra di contesto. |
-| `trimEmergencyPercent` | `95` | Scalino di emergenza: fold meccanico forzato (nessuna chiamata al modello secondario) a questa percentuale. |
+| `trimIncrementTokens` | `45000` | Compagno del cancello: anche l'incremento comprimibile contiguo deve raggiungere questa taglia. |
+| `trimPressurePercent` | `45` | Scalino di pressione: ripiega quando l'uso della view raggiunge questa percentuale della finestra di contesto. |
+| `trimEmergencyPercent` | `90` | Scalino di emergenza: fold meccanico forzato (nessuna chiamata al modello secondario) a questa percentuale. |
+| `trimAdvisoryPercent` | `50` | Linea di sollecito advisory: a questa percentuale della finestra effettiva il motore invita il modello a ripiegare subito con `ctx_trim_fold` (solo modalità advisory). |
+| `trimAdvisoryCriticalPercent` | `80` | Linea critica: al raggiungimento ripete subito il sollecito, bypassando il throttle di 10 minuti sulla stessa fascia. |
 | `trimWindowTokens` | `0` | Limite di finestra effettivo per il calcolo delle soglie: calcolato su min(finestra del modello, limite). `0` = segue `wmForceTokens`. |
-| `trimProtectedTail` | `10` | Gli ultimi N messaggi non vengono mai ripiegati. |
+| `trimCriticalRelief` | `true` | Sollievo critico advisory: alla linea critica il motore esegue autonomamente un ripiegamento meccanico (stile emergenza), con cooldown di 90 s. |
+| — | — | Le percentuali di trim non sono paragonabili al misuratore di contesto del composer: trim divide l'ultimo prompt pagato (max di view/wire) per la finestra effettiva (limite incluso); il misuratore mostra la proiezione del prossimo prompt sull'intera finestra del modello. |
+| `trimProtectedTail` | `6` | Gli ultimi N messaggi non vengono mai ripiegati. |
 | `trimMaxFoldsPerHour` | `30` | Tetto di cadenza dei fold per ora mobile per il modello secondario (quelli di emergenza ne sono esenti). |
 | `trimSideModel` | non impostata | Route del modello secondario che scrive i riassunti. Vuota = seguire il provider/model della sessione, senza ereditare l'effort della chiamata; anche le ladder distillation usano questa route. L'effort del riepilogo si può fissare separatamente; senza pin, i metadati del modello scelgono il livello reasoning abilitato più basso; per i modelli con solo interruttore on/off, scegliere off. Se reasoning non è supportato o i metadati non sono disponibili, non si invia effort e si mantiene il comportamento predefinito del modello/adattatore. |
 | `trimFoldFallbackModel` | non impostata | Route di ripiego quando il modello secondario dei riassunti fallisce; un fold di pressione degrada quindi a meccanico. Vuota = nessun fallback. Il modello di fallback del fold scelto manualmente ha un pin di effort indipendente; senza pin, usa la stessa raccomandazione basata sui metadati del modello di riepilogo e, se mancano metadati, il valore predefinito del modello. Scegli una route con margine su cooldown, risk control e concorrenza. |
@@ -136,7 +137,7 @@ Tutte le chiavi stanno in Impostazioni → dsh-switchman; i valori predefiniti v
 
 **Percorsi di attivazione.** I controlli degli scalini girano al confine di inattività e, come ripiego per gli host dove gli eventi di stato di inattività non sono raggiungibili, dopo ogni completamento del flusso del modello (limitati a una valutazione ogni 60 s per sessione). Ogni decisione — fold e no-op allo stesso modo — viene aggiunta come una riga `key=value` con timestamp a `decisions.log` nella directory dello stato dei fold (vedi `trimStateDir`), dando ai fold una traccia di audit offline; il vocabolario delle righe (`view-applied`, righe di decisione/esito dei fold, `surface-replace`, `surface-replace skipped reason=…`) è catalogato in [docs/context-trim.md](./docs/context-trim.md).
 
-**Verità del filo e stato stazionario.** Le righe di decisione portano `view=<n>` e, una volta arrivata una risposta, `wire=<n>` — il prompt reale del provider (input non in cache + lettura cache + scrittura cache, campionato dall'evento di utilizzo dello stream). La stima della view conta solo l'array di messaggi e legge sempre meno del filo, della misura dell'overhead fisso (misurato ≈ 17.3k: system prompt + schemi degli strumenti + persona), quindi gli scalini di pressione e di emergenza valutano su `max(view, wire)`, e solo `wire` è una lettura della dimensione del prompt. Su una finestra da 150k l'andamento a dente di sega sano porta il filo a ≈ 40k subito dopo un fold ↔ 64–97.5k al successivo (≈27%–65% della finestra), un fold ogni ~25k di crescita grezza, con il tetto fissato vicino a 97.5k dallo scalino di pressione anziché dalla finestra. Se `view` sale senza che compaia mai una riga `surface-replace`, leggi le righe di salto (`incomplete-seqs`, `no-service`, `compaction-lock`).
+**Verità del filo e stato stazionario.** Le righe di decisione portano `view=<n>` e, una volta arrivata una risposta, `wire=<n>` — il prompt reale del provider (input non in cache + lettura cache + scrittura cache, campionato dall'evento di utilizzo dello stream). La stima della view conta solo l'array di messaggi e legge sempre meno del filo, della misura dell'overhead fisso (misurato ≈ 17.3k: system prompt + schemi degli strumenti + persona), quindi gli scalini di pressione e di emergenza valutano su `max(view, wire)`, e solo `wire` è una lettura della dimensione del prompt. Su una finestra da 200k l'andamento a dente di sega sano porta il filo a ≈ 40k subito dopo un fold ↔ 64–90k al successivo (≈20%–45% della finestra), un fold ogni ~45k di crescita grezza, con il tetto fissato vicino a 90k dallo scalino di pressione anziché dalla finestra. Se `view` sale senza che compaia mai una riga `surface-replace`, leggi le righe di salto (`incomplete-seqs`, `no-service`, `compaction-lock`).
 
 **Epoche di compattazione dell'host.** I riferimenti dei fold sono ancorati a id dei messaggi e hash dei contenuti; quando l'host compatta esso stesso la cronologia reinviata, l'intero registro invecchia in un colpo: nessun blocco si localizza, la vista retrocede silenziosamente alla cronologia grezza (fail-open — il registro delle decisioni annota `view-applied applied=0`) e il plugin re-ancora la sua baseline di crescita sulla vista post-compattazione alla richiesta successiva. La compattazione dell'host è quindi lo strato di taglio di ultima istanza; i fold del plugin fanno il lavoro fine all'interno di un'epoca dell'host. Alcuni dispatch consegnano array di richiesta o oggetti opzioni completamente congelati (l'attuale loop d'agente congela in profondità le richieste assemblate); per essi `injectView` riporta l'esito nel registro delle decisioni: `nothing-to-apply` (nessun blocco di fold localizzato — la cronologia grezza È la vista), `in-place`/`swapped` (la vista piegata è partita con la richiesta) oppure `none` (esisteva un fold ma il dispatch congelato non poteva portarlo — sul filo va la cronologia grezza). **La sostituzione di superficie è la via di spedizione quando disponibile** (`surfaceFold`, attivo per impostazione predefinita): al confine seriale `agent/turn-stopping` più una spazzata di inattività, il plugin aggiunge l'evento di misurazione shadow-price in stile host e UNA sostituzione `user/message` che porta `surfaceOp {op:'replace', startSeq, endSeq}` con `sourceEventSeqs` che copre ogni nodo di superficie in ombra — lo stesso meccanismo usato dalla compattazione dell'host stessa — cosicché un fold confermato raggiunge il filo dal livello sorgente, dispatch congelati compresi. Finché i dispatch recenti di una sessione registrano `none`, il plugin tratta la vista come sola misurazione: il livello dell'acqua misura invece il conteggio riportato dal provider (lo scalino force e la consegna automatica continuano a funzionare), i cicli di fold si mettono in pausa invece di bruciare chiamate al riassuntore, e il banner di taglio contrassegna la riga con `wire=raw` (folds not shipping; watermark reads the tally); gli host senza il meccanismo di superficie (o con il flag spento) mantengono esattamente quel comportamento legacy.
 
@@ -161,6 +162,12 @@ Tutte le chiavi stanno in Impostazioni → dsh-switchman; i valori predefiniti v
 - Le righe di protocollo (`[SWITCHMAN:LANG|POOLS|WATERMARK|TEAMS]`) restano deliberatamente in inglese e stabili al byte — non localizzarle.
 - `npm pack --dry-run` deve restare alla forma auditata di 60 file / ~380 kB (~1,26 MB scompattati; `docs/` è escluso).
 
+## Download
+
+Tutti i download npm dalla prima pubblicazione, cumulativi — tracciati dall'[API ufficiale dei download npm](https://api.npmjs.org/) e aggiornati ogni giorno da GitHub Actions ([script del grafico](scripts/downloads-chart.mjs)):
+
+![Download npm cumulati per dsh-switchman](docs/assets/downloads.svg)
+
 ## License
 
 MIT