maybe-im-smart — garder l'objectif, chercher ailleurs une pratique existante
Le résultat est une action — l'acteur, la première étape de la semaine, comment savoir si ça a marché. Pas une idée.
Critère : une fois chargé, décider de poursuivre
Se charge uniquement lorsqu'un déclencheur de la description est activé. Après le chargement, passer la première porte : la prochaine étape doit être hors de vue — difficile ne compte pas, seul l'absence de candidat compte. Puis la deuxième porte : ce qui manque — seule la première catégorie passe par cette procédure :
| Ce qui manque | Où aller | Limite |
|---|---|---|
| Action manquante (quoi faire) | Cette procédure | Seule cette catégorie a besoin de chercher ailleurs une pratique |
| Fait manquant (ce que c'est) | Chercher | Demander à l'utilisateur ce que l'IA peut chercher lui fait perdre du temps |
| Contrainte manquante (ce qui ne doit pas bouger) | Demander, et demander précisément | Demander seulement "ce qui ne doit pas bouger" ; demander "comment faire" redonne l'espace d'action |
Plusieurs autres cas n'ont pas leur place ici. La prochaine étape connue et simplement indésirable = un problème d'exécution. Un deadlock au sens technique (threads qui s'attendent mutuellement, boucles d'appels d'outils, tempêtes de tentatives) = un bug à corriger, pas l'échange "l'utilisateur demande à l'IA, l'IA redemande à l'utilisateur" ; cet échange relève de la catégorie "≥3 tours de questions-réponses". Un brainstorming sans point de blocage = demander des idées. Peaufiner et expliquer = aucun domaine de récupération vers lequel basculer.
L'autre moitié est l'audit, qui saute le jugement et l'annonce ci-dessus. Pour juger une correspondance inter-domaines existante pour sa cohérence structurelle (avant qu'elle n'entre dans une chaîne de raisonnement, ou avant que son mécanisme ne soit ramené dans le domaine A), lire directement references/audit.md ; structure uniquement, pas savoir si l'analogie est vraie.
Auto-vérification : pas besoin d'attendre que l'utilisateur parle
Les signaux d'événement externe sont comptables à partir de l'historique. Les signaux ci-dessous sont uniquement du côté de l'IA et seul l'IA peut les admettre :
- L'action substantielle de la réponse actuelle de l'IA est de faire choisir l'utilisateur parmi des candidats (demander un choix, pas un fait)
- Parmi les candidats que l'IA s'apprête à proposer, pas un seul n'est quelque chose que l'utilisateur n'a pas proposé
Si l'un ou l'autre est vrai, cela compte comme bloqué, et les deux portes "prochaine étape hors de vue" et "ce qui manque est une action" n'ont plus besoin d'être remplies.
Quand le jugement est positif, annoncer le déclencheur pour que l'utilisateur puisse le rejeter ou le déclasser sur le moment :
<cet élément de preuve> — lancer un tour avec maybe-im-smart, en trois étapes : décomposition, récupération, atterrissage (
references/probe.md).
Copier <cet élément de preuve> textuellement depuis l'entrée correspondante dans description, ou depuis la phrase que l'IA a admise ; ne pas le reformuler en un résumé.
Si ce n'est pas le cas, ne rien dire.
1. Classifier le type de tâche
| Type | Forme du point de blocage | Exemple |
|---|---|---|
| Détection | Doit découvrir si quelque chose existe ou non ; oublis ou faux positifs | Revue encore manquante |
| Blocage | Doit empêcher quelque chose de se produire | Le même incident se reproduit |
| Allocation | Ressources limitées réparties entre plusieurs besoins | Conflits de planning, répartition budgétaire |
| Coordination | Les actions de plusieurs parties doivent rester cohérentes | Distorsion de passage de relais, consensus inter-équipes |
| Timing | L'ordre ou le rythme se dérègle | Inversion de dépendances, retard de retour d'info |
| Continuité | Le système ne doit pas s'effondrer sous la perturbation | Capacité saturée, départs clés |
| Décision | Doit conclure alors que l'information est incomplète | Approuver ou non avec des preuves insuffisantes |
Si aucun ne convient, inventer un nom. Ce tableau sert uniquement à faire émerger "quelle forme de problème est-ce".
2. Décomposition : quatre colonnes
| Colonne | Ce qu'elle demande | Exemple (défauts manqués dans une revue de code) |
|---|---|---|
garder ce qui doit être gardé | Qu'est-ce qui le fait fonctionner maintenant ? Le déplacer et tout s'effondre | Un jugement indépendant avant la fusion |
bloquer ce qui doit être bloqué | Quel échec se produit ? | Il y a un jugement mais il n'en fait pas office |
bloqué là où c'est bloqué | Une phrase "veut X, mais manque Y" | Augmenter le taux de détection, mais ajouter des personnes le fait baisser |
contraintes ce qui ne doit pas bouger | Écrire la contrainte réellement touchée | Impossible d'ajouter du personnel ; impossible de prolonger le calendrier |
Au-delà des quatre colonnes, conserver le tableau d'opérations du domaine A ops_A — nom : entrée → sortie, objets sous leurs vrais noms. La porte d'atterrissage l'utilise pour sujet (dans le domaine A ?) et action (une ancienne action renommée ?).
Échec de la décomposition = le point de blocage n'est pas encore localisé ; revenir en arrière et le localiser. Si bloqué ne peut pas être écrit comme "veut X, mais manque Y", ne pas aller plus loin.
3. Reformulation sans indice
Poser deux questions de manière répétée jusqu'à ce que les deux échouent : ce nom suggère-t-il l'utilisation ? Peut-il être décomposé davantage ? Méthode, critères et exemples : première étape de references/probe.md.
Produire :
- une reformulation neutre (≤40 caractères, ne contenant aucun terme spécifique au domaine d'origine)
- 3 à 5 termes de recherche (noms ou verbes neutres)
Un terme du domaine d'origine dans les termes de recherche signifie que l'étape n'est pas terminée. Lister ces termes dans domain_terms ; l'outil bloque par correspondance de sous-chaîne.
4. Récupération (2a génération de directions → 2b vérification sur des sources primaires → 2c remplissage des lacunes)
Scanner d'abord le domaine d'origine, puis le quitter. Première chose en 2a.
"Source" ici ne signifie pas "un autre domaine". Une source a deux granularités :
| Ce qui est changé | La source est | Mécanisme |
|---|---|---|
| Changement de branche | Une autre branche dans le domaine A | Remplace la prémisse de la ligne principale, pas un mapping |
| Changement inter-domaines | Un autre domaine | Mapping structurel φ : A→B |
Deux types d'"autre branche", tous deux comptant : une écartée par les pairs (faite avant, abandonnée ensuite) ; une jamais utilisée comme méthode du tout — quelque chose qui existe déjà dans le domaine d'origine (un champ obligatoire dans un standard de documentation, une structure d'index existante, une solution de contournement grossière utilisée par une autre équipe), seulement personne ne l'a appliqué à ce problème. La seconde n'est pas une invention : elle doit exister déjà dans le domaine d'origine ; seule sa position change.
b_domain enregistre la source réelle : pour un changement de branche, le nom du domaine A plus le nom de la branche ; pour un changement inter-domaines, ce domaine. Seule une source spécifique nommable compte.
"Le domaine d'origine est épuisé" est indécidable ; ne pas le juger. Vérifier deux tableaux, un enregistrement chacun :
| Ce qui est scanné | Comment scanner | Ce qu'il faut enregistrer |
|---|---|---|
| Prémisse partagée | Voir "comment briser une prémisse" ci-dessous, cinq étapes | Une prémisse + une pratique qui rejette la prémisse, ou "aucune pratique de ce type dans le domaine d'origine" |
| Branche non empruntée | Demander pour les deux types. ① La pratique autrefois dominante du domaine d'origine est maintenant abandonnée — a-t-elle été réfutée, ou simplement démodée ? ② Pourquoi quelque chose qui existe déjà dans le domaine d'origine n'a-t-il jamais été utilisé comme méthode ? | Nom de la branche + pourquoi elle n'a pas été empruntée ; si aucune, écrire "aucune branche de ce type dans le domaine d'origine" |
Comment briser une prémisse — le scan pour le tableau "prémisse partagée". Cinq étapes, aucune sautée :
- Mettre les chemins échoués côte à côte ; écrire leur prémisse partagée comme une phrase qui peut être niée — si elle ne peut pas l'être, la prémisse n'est pas encore énoncée.
- La décomposer en clauses qui peuvent être niées individuellement.
- Pour chaque clause : existe-t-il une pratique du domaine d'origine qui ne la prend pas comme prémisse ? Si oui, la remplir ; cette clause est scannée.
- La clause répondant "non" partout est la direction pour quitter.
- Utiliser la négation de cette clause comme termes de recherche. Pas un nom de discipline — un nom de discipline ne renvoie que des articles de mots-clés de cette discipline, et la recherche boucle directement au début.
confidence ne compte pas lors de la rupture des prémisses.
Ce n'est que lorsque les deux tableaux répondent "aucun" que quitter est autorisé. "Vide" signifie aucune pratique contre-exemple, pas aucun mot. Une ligne disant "aucune pratique de ce type dans le domaine d'origine" compte aussi comme vide.
Un changement de branche n'est pas simplement repenser. Un critère : la nouvelle branche ne prend pas la prémisse partagée des chemins échoués. Plus d'effort, plus de détails, réglage des paramètres sous la même prémisse ne font que prolonger la ligne principale. Impossible de la nommer : la branche n'est pas encore trouvée.
Les deux tableaux scannent les endroits où la ligne principale n'est pas allée, pas la ligne principale elle-même. Les problèmes ouverts reçoivent le même traitement : éviter les clichés du domaine d'origine, pas le domaine d'origine.
Les entrées du domaine d'origine vont dans recall sur un pied d'égalité avec les entrées inter-domaines : structure indique "quelle branche du domaine d'origine, et laquelle est prise maintenant". Quitter est admis par les deux sorties de l'étape trois : zéro terme du domaine A dans restated (non vérifié par l'outil — le compter) et aucun terme de domain_terms dans terms (bloqué par l'outil). L'outil ne vérifie pas les deux tableaux.
Les trois sous-étapes appartiennent toutes à l'étape deux et s'exécutent dans l'ordre en un seul tour. Ne pas les fusionner en une seule requête — fusionnées, 2c devient une continuation de 2a.
| Étape | Action | Sortie | Format strict | Ce qu'elle peut prouver |
|---|---|---|---|---|
| 2a génération de directions | Depuis la mémoire paramétrique : où pourrait se trouver une pratique (branches non empruntées du domaine d'origine d'abord) | Une direction + "ce qui pourrait être là" | origin: "recall", confidence, lentille operator ; 3-6 entrées, ≥2 lentilles ; status toujours unverified | Seulement "vu cette zone", pas que la pratique existe là |
| 2b vérification sur des sources primaires | Vérifier chaque entrée contre une source primaire externe : cette pratique existe-t-elle là ? | verified / refuted / unverified (vérifié mais indécidable reste unverified) | verified doit porter une provenance ; refuted doit porter une correction | Transforme des suppositions en faits citables |
| 2c remplissage des lacunes | Changer les termes de recherche et chercher à nouveau, pour des directions que 2a n'a jamais envisagées | Nouvelles sources | origin: "search" et status par entrée ; chaque résultat enregistre query | Au-delà de la frontière des données d'entraînement |
2c renvoyant la même pratique que 2a (même domaine, même pratique) = l'étape n'a pas quitté ; c'est une continuation, pas un remplissage de lacunes. Une autre pratique dans le même domaine compte — mais "autre" doit aller dans structure, sinon on ne peut pas la distinguer de l'entrée 2a dans l'enregistrement, et l'outil ne peut pas non plus juger la duplication. L'outil ne vérifie pas cela ; le compter.
Pour les invites et l'ordre, voir references/probe.md. Ne pas calculer la précision du rappel : 2a donne des directions, pas des propositions.
Les quatre lentilles de cadrage (utilisées pour la génération de directions 2a, revérifiées par rapport aux candidats à la porte d'atterrissage)
En 2a, étiqueter chaque direction avec une lentille ; 3-6 entrées couvrent ≥2. Quatre entrées d'une lentille sont quatre copies d'une seule analogie, justes et fausses ensemble — vérifier la divergence en 2a, pas à la porte d'atterrissage à la fin.
La lentille demande "où", pas "jusqu'où". La réponse peut être une autre branche du domaine d'origine ou un autre domaine.
| Lentille de cadrage | Demander avec |
|---|---|
function (fonction) | Dans quel domaine ce verbe (détection / mise en tampon / limitation de débit / calibrage) est-il un composant standard ? |
conflict (conflit) | Qui traite "veut X et en même temps pas X" comme quotidien ? |
scale (échelle) | Comment les domaines un cran en dessous (une occurrence unique) et un cran au-dessus (une organisation, un écosystème) font-ils la même chose ? |
failure (échec) | Quel domaine possède une archive d'incidents écrite traitant ce type d'échec ? |
5. Rétro-traduction : atterrir comme des actions du domaine A
Rétro-traduire chaque pratique du côté source ; abandonner ce qui ne peut pas être rétro-traduit.
Écrire why en premier ; si on ne peut pas l'écrire, abandonner l'entrée. Pas ajouté après les autres colonnes — à ce moment-là, la conservation est déjà décidée, et ce qui est écrit est une justification trouvée pour elle. why est la porte d'admission : le côté A cite les mots exacts de decompose.stuck ; le côté B indique ce qui fait le travail dans ce domaine. Côté B seulement ("ce domaine fonctionne bien ainsi") tourne en rond ; côté A seulement reformule le point de blocage ; les deux qui ne correspondent pas = impossible à rétro-traduire.
Pour evidence, choisir : la provenance de la pratique source, ou inferred. Marquer inferred est autorisé ; écrire une inférence comme provenance ne l'est pas. Cela régit le fait (la pratique existe là) ; why régit la correspondance (même endroit que le point de blocage du domaine A ?).
L'outil vérifie seulement que why est non vide ; il ne peut pas dire s'il a été écrit en premier ou ajouté après. Mou, comme l'auto-vérification de 2c : bloque ce qui est manifestement non fait.
6. Les deux portes et les commandes
python3 scripts/maybe_smart.py --recall decompose.json # porte d'enregistrement
python3 scripts/maybe_smart.py --check cands.json decompose.json # porte d'atterrissage
python3 scripts/maybe_smart.py analogy.json # audit (optionnel)
--quiet est un commutateur de sortie, pas un emplacement de mode : par défaut, le rapport complet est imprimé ; avec, seulement la ligne de résultat (PASS / FAIL ; --check traite une paire et imprime une seule ligne). Codes de sortie : 0 succès / 1 blocage / 2 erreur d'entrée.
Porte d'enregistrement : task_type non vide et les quatre colonnes présentes ; restated ≤40 caractères ; terms ≥3 sans terme de domain_terms (si domain_terms n'est pas listé, cette porte ne peut pas être vérifiée et est considérée comme non passée) ; chaque entrée de rappel a un b_domain non vide ; ≥3 entrées de rappel ; même source, même pratique ne se répète pas (deux pratiques différentes sous une même branche comptent comme deux) ; status ne prend que verified / refuted / unverified ; verified porte source, refuted porte correction ; au moins 1 entrée avec origin comme search et un query enregistré.
Porte d'atterrissage, sept vérifications :
- Six champs non vides :
operator/action/subject/first_step/observable/why - ≥2 lentilles de cadrage ;
operatorne peut prendre que les littéraux chinois 功能 / 矛盾 / 尺度 / 失败 (fonction / conflit / échelle / échec) ; toute autre valeur est non conforme - ... (contenu tronqué pour la traduction)