komilovsg/f-mode

F-mode — mode filtrage d'abord

Principe : les données brutes n'entrent jamais dans le contexte ; seul le résultat le fait. Déplacez la logique vers les données (un pipeline shell, un script court, un sous-agent) et ramenez un résumé compact. Chaque token d'un dump de log que vous lisez est un token que vous ne pouvez pas consacrer au raisonnement — et un contexte long et bruité empire le raisonnement, pas seulement le coût.

1. Filtrer et agréger avant de lire

Au lieu de	Faire
cat app.log	grep -c ERROR app.log; `grep -E 'ERROR
lire un JSON de 5 Mo	`jq '.items
SELECT * FROM orders	SELECT status, count(*) FROM orders GROUP BY 1
git log	git log --oneline -20, git log --format=%s origin/main..HEAD
parcourir un fichier	grep -n 'def handle' file.py, puis lire avec offset/limit

2. Le filtrage ne doit jamais cacher les échecs

Une vue tronquée qui semble verte est pire que pas de vue du tout.

• Conservez le code de sortie : set -o pipefail, ou cmd > out.txt 2>&1; echo "exit=$?"; tail -20 out.txt. Envoyer directement vers tail perd le code de sortie de la commande.
• Ajoutez des marqueurs d'échec en plus de tail : grep -cE 'FAIL|ERROR|Traceback|panic' out.txt.
• Affichez les comptages avec dénominateurs : passed 41/42, jamais seulement « OK ».

pytest -q --tb=short > /tmp/t.out 2>&1; echo "exit=$?"
grep -cE 'FAILED|ERROR' /tmp/t.out; tail -15 /tmp/t.out

3. Beaucoup de vérifications similaires → un script, un tableau

Dix points d'accès, vingt fichiers, trente lignes à valider : écrivez un script qui boucle et affiche un tableau compact (name | status | detail) plus les totaux. Pas dix appels d'outils avec dix sorties complètes.

for u in / /api/health /api/items; do
  printf "%-14s %s\n" "$u" "$(curl -s -o /dev/null -w '%{http_code}' "localhost:8000$u")"
done

4. Vérifiez le résumé pour le sens, pas pour la forme

Une sortie d'apparence valide peut encore être fausse. Comparez avec une valeur attendue ou un total de cohérence : les comptes s'additionnent à la taille de l'entrée, une ligne connue est présente, le nombre de fichiers correspond à ls | wc -l. Si un résumé ne peut pas être recoupé, dites-le.

5. Tests

Mode silencieux, tracebacks courts, fin de la section des échecs :

• pytest -q --tb=short
• vitest run --reporter=dot, jest --silent
• go test ./... 2>&1 | grep -E '^(FAIL|ok|---)'
• cargo test -q

6. Contrôles navigateur

Évaluez un script qui retourne un JSON compact ({title, errors: n, buttons: n, overflowX: bool}) au lieu de captures DOM complètes. Prenez une capture DOM uniquement lorsque la structure DOM elle-même est la question. Des captures d'écran pour les contrôles visuels, pas pour lire du texte.

7. Investigation large → sous-agent

Grandes recherches, forensics de logs, dumps de base de données : déléguez à un sous-agent qui retourne des conclusions avec des références file:line. Son résultat reste une affirmation — vérifiez les points clés avant d'agir dessus.

8. Secrets et données personnelles

N'imprimez jamais de secrets ou de données personnelles réelles dans les résumés ou les diagnostics. Masquez (postgres://***) ou comptez-les (emails trouvés : 12). Masquez les chaînes de connexion et les clés à l'intérieur des messages d'exception capturés aussi.

9. Lecture de fichiers

• grep -n d'abord, puis lisez seulement la plage pertinente avec offset/limit.
• Le code source que vous êtes sur le point de modifier est lu en entier — des lectures partielles entraînent des modifications cassées.
• Ne relisez pas un fichier immédiatement après l'avoir modifié pour « vérifier » ; l'outil d'édition signale déjà les échecs.

10. Règle d'arrêt

La même correction a échoué deux fois → arrêtez. Trouvez la cause racine à partir de la ligne d'erreur exacte, ou demandez. Pas de troisième tentative aveugle.

11. Hygiène du contexte

• Nettoyez le contexte entre les tâches non liées ; compactez les longues sessions.
• Désactivez les plugins, compétences et serveurs MCP que vous n'utilisez pas dans ce projet : chacun coûte des tokens d'invite dans chaque requête.
• Jugez les économies par les chiffres d'utilisation réels (par exemple /cost), pas par des pourcentages annoncés.