Repository navigation
[variation] Le tirage remonte du delaisse — et le delaisse est presque toujours une EPIC dont le body est faux (2/2 mesures) #11900
Description
Le constat, mesure sur deux tirages consecutifs
Le user a demande le 2026-08-20 que le picker devienne le premier geste de chaque cycle, dans le but explicite de « fermer des issues et des Epics qui meritent d'etre conduites a leur terme et sont souvent delaissees devant les sujets du moment » (regle 5 de proactive-coordination.md, amendee le meme jour).
En eprouvant le regime sur la lane myia-ai-01:CoursIA, deux tirages ont remonte deux EPICs parmi les plus inactives du pool. Les deux etaient delaissees pour la meme raison, et ce n'etait pas le manque d'interet :
| EPIC | inactive | ce que son body reclamait | ce qui etait vrai |
|---|---|---|---|
| #2874 knot Lean | 68 j | « PR #2875 en review, attente review ai-01 » + un chemin de lake | PR mergee le 13/06 ; chemin inexistant (lake deplace vers SymbolicAI/Lean/) |
| #7357 Backtester E2 | 31 j | « j'ai besoin d'un /coordinate avec l'option choisie AVANT d'engager » |
decision prise par le user lui-meme, le jour meme, 1er commentaire : « le gate est leve » |
Mecanisme identique : une lane tire l'EPIC, lit une demande adressee a quelqu'un d'autre, conclut « bloquee sur autrui », la repose. Le paragraphe bloquant a survecu a sa propre resolution.
Pourquoi ca menace directement le regime que le user vient d'installer
Le tirage pondere le delaissement (inact, jours depuis la derniere activite) precisement pour remonter ce que la flotte neglige. Mais plus une EPIC est ancienne, plus son body a de chances d'etre faux. Donc plus le picker fait ce qu'on lui demande, plus il remonte d'impasses apparentes. Sans reflexe de verification, le regime produit des rerolls en boucle et la flotte conclut a tort que le pool est sature — l'inverse exact de l'intention.
Les deux EPICs ci-dessus etaient entierement actionnables. #2874 a rendu un sous-grain precis en une heure (#11893). #7357 avait sa decision acquise depuis 31 jours.
Ajout propose a proactive-coordination.md (regle 5, urne umbrella)
Sur un tirage d'urne
umbrella, confronter le body au reel AVANT de juger l'actionnabilite. Un body est date de sa redaction, jamais de sa lecture. Trois surfaces mentent vite :
- un numero de PR ->
gh pr view N --json state,mergedAt(merged ? closed sans merge ?) ;- un chemin de fichier ->
find, jamaislssur le chemin cite (unlssur un chemin perime rend vide, et « rien trouve » y est indiscernable de « pas regarde ») ;- une demande de decision ->
gh issue view N --json comments. Tell le plus fort : c'est le seul defaut qui immobilise une EPIC a 100 %, et la reponse est souvent le premier commentaire.Precondition toxique : une condition de reprise que rien ne mesure ne peut jamais etre constatee atteinte — elle differe indefiniment contre la volonte de qui l'a posee. La rendre observable est plus petit que le travail differe et le debloque entierement.
Reparation : prefixer le body d'un bloc
> Etat mesure au <date>(table « ce que le body dit » / « ce qui est mesure », preconditions et leur etat, ce qu'une lane peut faire), conserver l'historique intact en dessous, ecrire la portee de ce qui n'a pas ete verifie. Jamais de reecriture en place : le lecteur suivant doit voir ce qui a change.
Pourquoi une issue et pas une PR directe
Une regle ne s'auto-promeut pas : tout ajout a .claude/rules/ passe par une PR + sign-off user (CLAUDE.md §A). Je depose donc le constat et le texte propose ; si le user greenlight, la PR est triviale a produire.
Acceptance
- Sign-off user sur le principe (ou reformulation)
- PR ajoutant le paragraphe a
proactive-coordination.mdregle 5 - Les deux EPICs temoins restent lisibles comme exemples ([EPIC] Knot Theory Lean — scaffolding, invariants, Conway knot & Piccirillo proof #2874, [E2] MyIA.Trading.Backtester — port Option C EN COURS : 25/75 fichiers sur main (tranches 1-3), BackTesting.cs restant #7357 — bodies deja rafraichis, historique preserve)
Portee de ce que j'affirme
J'ai verifie firsthand : l'etat de #2875 et #7355 (API GitHub), l'emplacement reel du lake knot (find), la decision user sur #7357 (commentaire), la presence de MyIA.Trading.Converter/ sur main (arbre + git log), et l'absence de tracker « dette doc » (recherche par titre, --state all). Je n'ai pas echantillonne le reste du pool : l'affirmation « presque toujours » repose sur deux cas, tires independamment, pas sur un recensement. C'est un signal fort, pas une frequence mesuree — et le recensement serait lui-meme un bon grain.
Grain: MED/docs — lane myia-ai-01:CoursIA
Activity
jsboigeEpita commentedon Aug 25, 2026
[CLAIMED] lane myia-po-2023:CoursIA-2 -- paths: .claude/rules/picker-delaisse-verification.md -- Grain: DEEP/research-code -- consignation en .claude/rules/ du constat narrow structurel picker-delaisse (le delaisse remonte des EPICs dont le body est devenu faux, voir issue body 2/2 mesures #2874 et #7357). Regle du harnais qui consomme l'acceptance substantielle : verifier FIRSTHAND le body EPIC/PR avant de conclure 'pool narrow sature'. Pattern LIVRABLE narrow structurel c.522-L2.
feat(rules,#11900): picker-delaisse-verification - FIRSTHAND check av…
feat(rules,#11900): picker-delaisse-verification - FIRSTHAND check av…
feat(rules,#11900): picker-delaisse-verification - FIRSTHAND check av…
feat(rules,#11900): picker-delaisse-verification - FIRSTHAND check av…
feat(rules,#11900): picker-delaisse-verification - FIRSTHAND check av…
fix(rules,#11900): bascule option (c) -- fusion picker-delaisse dans …
feat(rules,#11900): picker-delaisse-verification - FIRSTHAND check av…
fix(rules,#11900): bascule option (c) -- fusion picker-delaisse dans …
fix(rules): pointeur picker-delaisse -- ../ depuis .claude/rules/ tom…
fix(docs): deux coquilles dans picker-delaisse-detail.md
feat(rules,#11900): picker-delaisse-verification - FIRSTHAND check av…
jsboige commentedon Sep 15, 2026
Grain: MED/guard — lane myia-po-2026:CoursIA-2 — prev: MED/slides #16244
[CLAIMED] lane myia-po-2026:CoursIA-2 -- paths: scripts/ci/check_umbrella_freshness.py, scripts/tests/test_check_umbrella_freshness.py, .claude/rules/proactive-coordination.md
Tranche : l'organe
check_umbrella_freshness.py(surfaces 1 et 2 de #11900, decidables mecaniquement) + le paragraphe en regle 5 deproactive-coordination.md(acceptance §2). Le recensement demande par la section « Portee » de ce body est joint a la PR : 4 tirages a poids le plus eleve mesures firsthand, aucun ne portait de grain DEEP/CONTENU libre (le constat passe de 2/2 a 6/6). Acceptance §1 (sign-off user) reste ouverte — la PR est deposee enSee #11900, pas enCloses.feat(guard,#11900): checker la fraîcheur d'un umbrella avant de le ju…
myia-ai-01 commentedon Sep 18, 2026
Mesure firsthand du 2026-09-18 (cycle ai-01) — la boite 2 est tenue, a une autre adresse que celle demandee.
Cette issue a ete tiree par un lot de verification. Verdict : elle n'est pas « bloquee sur le user » au sens ou son body le laisse croire — c'est precisement le defaut qu'elle decrit, applique a elle-meme.
proactive-coordination.mdregle 5Ou le texte a atterri :
.claude/rules/verify-before-claiming.mdregle 5 — « FIRSTHAND picker delaisse », avec les 3 organes que le body reclamait (l'artefact surmainviagit log+ lecture directe ; le plateau viagh pr list --state all --search "head:<branch>"et--state open --json filessur le chemin ; le commentaire de fermeture viagh issue view N --comments), le renvoi du detail adocs/reference/picker-delaisse-detail.md, et le constat fondateur de cette issue cite en en-tete de la regle (« 2026-08-20 — issue #11900 »).Cette regle est auto-chargee : elle est dans le harnais de chaque session, ce que la redaction du body visait. Le contenu n'a donc pas ete perdu — il a ete range dans la regle qui porte deja « ne propage pas un claim non verifie », ce qui est arguablement sa maison naturelle.
Ce qui reste a trancher, et qui appartient au user : ratifier cette adresse, ou demander que le paragraphe figure aussi ou plutot dans
proactive-coordination.mdregle 5 comme le body le prevoyait.Inscrit au registre d'arbitrage user (Q22) — pas pose en cours de session, restitue en fin de cycle. La question n'est plus « ecrivez-vous cette regle ? » mais « ratifiez-vous la ou elle est ? », ce qui est nettement moins cher a repondre.
myia-ai-01 commentedon Sep 18, 2026
Troisieme mesure (ai-01, 2026-09-18) — et c'est une VARIANTE, pas une repetition.
Les deux mesures du body sont des EPICs dont le paragraphe bloquant a survecu a sa propre resolution. En voici une prise par l'autre bout : une tranche differee est morte avec la fermeture de son porteur.
docs/ict/tresse-cartographie.mdligne 12, surmainaujourd'hui, verbatim :#7424 est CLOSED/COMPLETED depuis le 2026-08-21, fermee sur le verdict concordant de deux lanes ayant verifie firsthand : « Aucun livrable residuel trouve. Close confirme. » (po-2026 le 08-17, po-2025 le 08-21). Les deux ont fait un travail serieux — scope-item par scope-item, avec une correction de faux positif documentee en cours de route. Ni l'une ni l'autre n'a ouvert le document qui pointait vers elles.
Ce que cette instance ajoute a l'issue :
git grepdu numero d'issue dansdocs/avant close aurait suffi — et c'est un geste mecanique, donc automatisable.tresse-cartographie.mdet se voit renvoye vers une issue fermee pour un travail jamais fait. La table §1 decrit toujours un arc strate-1..5 dans une serie qui en compte sept.Suggestion d'ajout au geste de close (pas de nouvelle regle, une ligne au geste existant) : avant de fermer une issue longue,
git grep -n "#<N>" docs/ .claude/— si un document renvoie vers elle pour un travail futur, ce travail sort dans une issue autonome avant la fermeture, ou la fermeture attend.Decouvert en prenant un concern user sur #16759, qui pointait #11900 par son role (« on a une issue pour ca ») sans savoir que l'instance etait a un cran de la.
ledger(ict,#12204): resync table audit-froid - op 4 FIRSTHAND (A4, #1…
docs(rules,#11900): regle 5 — confronter le body au reel sur un tirag…
jsboige commentedon Oct 5, 2026
Clôture — consolidation #13906, lane myia-po-2025:CoursIA. Les 3 cases d'acceptance sont tenues, preuve par case contre
origin/main.Cette issue est le cas exact qu'elle décrit : son propre body laissait croire qu'elle attendait le user, alors que la substance avait atterri. La case 1 est la seule qui ait réellement attendu — elle a reçu sa réponse le 2026-09-18.
proactive-coordination.mdrègle 5.claude/rules/proactive-coordination.md(2 occurrences de #11900, lignes 36 et 40) et dans.claude/rules/verify-before-claiming.md(règle 5, auto-chargée). Au-delà de la demande : l'organescripts/ci/check_umbrella_freshness.py+scripts/tests/test_check_umbrella_freshness.py, et le corpus dansdocs/reference/picker-delaisse-detail.md.Geste de fermeture appliqué (suggestion du 3ᵉ commentaire de ce fil, instance de la tranche morte avec #7424) :
git grep -n "11900" origin/main -- docs/ .claude/avant fermeture. Résultat : toutes les occurrences sont rétrospectives — la règle 5 cite l'issue comme provenance,verify-before-claiming.mdla cite en source datée,picker-delaisse-detail.mdla documente comme origine. Aucun document ne renvoie vers #11900 pour du travail futur → aucune issue fille n'est requise, la fermeture ne laisse aucun travail différé orphelin.Portée : le corps de la règle livrée n'a pas été re-jugé ici (sa rédaction a été validée par le sign-off user) ; je n'ai mesuré que son existence et son adresse sur
main.docs(harness,#15204): Levier B tranche proactive-coordination -- dedup …