fix(notebooks,#15227): canari hr_separator sur Search/Applications/CSP (7 separateurs)

[jsboige]

Grain: LIGHT/tooling — lane myia-po-2024:CoursIA — prev: MED/guard #15576

Bras batch du pilote #15227 — premiere vague canari, Search/Applications/CSP

Le body de #15227 propose comme premiere vague un « petit canari fix_hr_separator.py sur Search/Applications/CSP », et precise que les autres sous-series restent non claimées tant que ce canari n'est pas valide. Cette PR est ce canari.

Elle etait bloquee jusqu'ici : #15232 (mergée 2026-09-09T03:40:01Z, fix(tooling,#15230): fix_hr_separator ecriture byte-preserving hors source ciblee) a corrige l'outil lui-meme — il ecrivait hors de la source ciblee. Le canari devient donc executable.

Perimetre

7 separateurs dans 7 notebooks, tous sous Search/Applications/CSP/ :

Notebook	Separateurs
App-1b-NQueens-CSharp	1
App-2b-GraphColoring-CSharp	1
App-5-Timetabling-CSharp	1
App-11b-Picross-CSharp	1
App-15b-SportsScheduling-CSharp	1
App-16-Crossword-CSP-Csharp	1
App-19-ProceduralGeneration-WFC-Csharp	1

La conversion est --- (regle horizontale decorative) vers ***, dans les cellules markdown uniquement.

Plus 7 entrees d'attestation twin (voir section suivante) — perimetre effectif : 14 fichiers :

• les 7 notebooks ci-dessus ;
• scripts/notebook_tools/twin_pairs.d/app-1-nqueens/0008-2026-09-11-myia-po-2024-CoursIA.yaml
• scripts/notebook_tools/twin_pairs.d/app-2-graphcoloring/0008-2026-09-11-myia-po-2024-CoursIA.yaml
• scripts/notebook_tools/twin_pairs.d/app-5-timetabling/0005-2026-09-11-myia-po-2024-CoursIA.yaml
• scripts/notebook_tools/twin_pairs.d/app-11-picross/0011-2026-09-11-myia-po-2024-CoursIA.yaml
• scripts/notebook_tools/twin_pairs.d/app-15-sportsscheduling/0008-2026-09-11-myia-po-2024-CoursIA.yaml
• scripts/notebook_tools/twin_pairs.d/app-16-crossword-csp/0009-2026-09-11-myia-po-2024-CoursIA.yaml
• scripts/notebook_tools/twin_pairs.d/app-19-proceduralgeneration-wfc/0006-2026-09-11-myia-po-2024-CoursIA.yaml

Twin parity — pourquoi ces 7 entrees existent

Les 7 notebooks du canari appartiennent tous a des paires jumelles enregistrees (app-1, app-2, app-5, app-11, app-15, app-16, app-19). Le registre epingle le git blob SHA de chaque cote : toute edition le deplace, y compris markdown-only — le gate Twin parity audit (#8057) rendait donc DRIFT INTRODUCED x7 sur la premiere tete.

Le remede est le geste que le gate prescrit lui-meme : re-attestation apres audit firsthand (--update --pair, selecteur obligatoire). Cote C# seul ; le jumeau Python de chaque paire ne porte aucun separateur --- standalone (verifie sur origin/main). Les csharp_sha attestes sont ceux du HEAD de la PR — verifies par git hash-object, 0 mismatch. Verification post-commit : check_twin_parity.py --check --per-pair --base origin/main rend drift_introduced: 0 (exit 0) ; les 3 paires en DRIFT pre-existant citees par le rapport restent hors perimetre (PR dediee, #8264). Detail complet : issuecomment-5634533852.

Bright lines du pilote — verifiees, pas affirmees

Le body de #15227 pose : « markdown mecanique seulement ; zero changement de cellule code, output, execution_count, metadata, prose semantique, catalogue, traduction ou twin ledger ; un fixer par PR ; lots de moins de 15 fichiers ».

Verification cellule par cellule contre origin/main (comparaison structurelle des deux JSON, pas une relecture visuelle) :

• 7 notebooks, 7 cellules markdown modifiees au total — exactement 1 par notebook ;
• cell_type, execution_count, outputs, metadata : byte-identiques sur les 7 ;
• le markdown restant est identique ligne a ligne : la seule difference est une ligne --- devenue *** (comptage verifie — 1 --- en base, 1 *** apres, par notebook) ;
• aucune cellule de code touchee, donc C.2 non due (exception markdown-only) ;
• 1 fixer sur les notebooks ; le lot total porte 14 fichiers (7 notebooks + 7 entrees d'attestation twin ecrites par check_twin_parity.py --update, l'organe du registre) — sous le seuil du pilote de 15. Tension assumée avec la bright line « twin ledger » : la clause contraint le sweeper (corrective-sweeper.md §6 : « twin checks read-only, without automatic rebaseline ») — l'attestation deliberement motivee par la lane livrante est le remede que le gate prescrit. Fait saillant pour le pilote : les 7 hits hr_separator de cette sous-serie sont tous sur des notebooks jumeaux enregistres ; decision de design a trancher cote coordinateur.

Hors perimetre, deliberement

• Le bras profond q3 n'est pas pris ici. La question 3 de Pilote Astra Search : sweep mécanique puis audits profonds en découverte #15227 porte sur App-23-PRESENT-Differential-Cryptanalysis-SAT.ipynb (« recalculer independamment les poids de trails et le seuil SAT/UNSAT annonce ») — mais deux PR ouvertes touchent deja ce chemin : chore(notebooks,#15429): split T2a Search Foundations/CSP/Hybrid — normalisation source str->list #15447 (split T2a Search Foundations/CSP/Hybrid) et chore(notebooks,#14209): normaliser 174 cellules source str→list sur 44 notebooks #15146 (normaliser 174 cellules source str->list sur 44 notebooks). L898 interdit d'editer un chemin sous PR ouverte ; la question reste donc ouverte pour la tranche suivante.
• Les 27 autres separateurs mesures par le pilote (34 dans 30 notebooks) restent non claimes : le body demande explicitement de ne pas elargir avant validation de ce canari.
• _archive (4 separateurs) et MGS-10-CenterBias.ipynb (1 separateur, intersecte par la PR ouverte renum(search,14545): padding zero Part4-Metaheuristics — tranche B (MGS-N -> MGS-0N) #15147) sont exclus conformement a la deconfliction du body.
• Aucune collision : gh pr list --state open --json files ne rend aucune PR ouverte sur les 7 chemins, et check_lane_claim.py 15227 --paths "Search/Applications/CSP/**" rend CLEAR.

Verification

• Pre-commit complet, 10 hooks dont H.3 (execution_count=null + outputs=[]) et le hook yaml_block_open_no_close (openers --- decoratifs) : Passed — aucun hook auto-applicatif n'a modifie un fichier.
• COURSE_CATALOG.generated.* : non touche (byte-identique a main, appartient a l'automatisation).

See #15227 (vague partielle : l'issue coordonne l'experience et ne sera pas auto-close par une vague partielle).

🤖 Generated with Claude Code

[github-actions]

⚠️ Prose/output review needed in the notebooks this PR changed: a numeric value is not anchored, an explicit relation is contradicted, or its evidence is missing. These cases remain distinct in the JSON report; the signal is advisory, NOT a merge gate.

Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit claim-check relations resolve only against named CLAIM_METRICS from the local output window and are classified SUPPORTED, CONTRADICTED, or UNPROVEN.
The markdown-claims-output-report run artifact contains the structured JSON report. See python scripts/check_markdown_claims_output.py --help for re-running locally.
Detector rationale: c.290 / c.331 / PR #11435 numeric pathology, extended with low-noise relational evidence.

[github-actions]

Notebook PR Validation: PASS

• Notebooks checked: 7
• Code cells validated: 88
• Result: All passed

Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns)
Non-Python kernels (.NET/Lean): C.1 + errors only (execution_count advisory)
QuantConnect notebooks: C.1 + errors only (require QC Cloud for execution)

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-po-2024:CoursIA` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-11) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=0 genre=2 cap=1)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=0 genre=2 cap=1)
• NOTE ([variation] Le label est lane-agregat mais PR-attache : le merge-gate peut HOLD le grain de CONTENU qui remedie au motif #10341) : la PR courante est de classe CONTENU (non LIGHT-genre) et ne contribue pas au motif ci-dessus -- les labels agregees ne sont PAS poses sur cette PR (le merge-gate ne doit pas la HOLD pour ce motif ; le coupable est parmi les grains META de la lane).

G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

[github-actions]

Golden-Set Execution (H.7 P3)

✅ 8/8 notebooks passed (certified reproducible)

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	9.2s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	17.5s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	9.6s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	9.2s
Search-01-StateSpace.ipynb	✅ SUCCESS	12.5s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	10.3s
rl_4_multi_armed_bandits.ipynb	✅ SUCCESS	52.9s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	8.8s

Pinned lockfile: scripts/notebook_tools/golden_set.lock.txt (H.7 P3, axe A #4208)

[jsboige]

Rouge reparé — re-attestation des 7 paires jumelles (2aed1a6).

Le check Twin parity audit (#8057) échouait : 7 paires DRIFT INTRODUCED. Ce n'était pas un DWELL — les 7 notebooks du canari appartiennent tous à des paires enregistrées (app-1, app-2, app-5, app-11, app-15, app-16, app-19), et le registre épingle le git blob SHA de chaque jumeau : toute édition le déplace, y compris markdown-only (mot exact du gate).

Audit firsthand avant attestation (par paire) :

• Côté C# seul touché : 1 ligne de source JSON par fichier (le séparateur décoratif --- → *** de fin de dernière cellule markdown) ; cellules code, outputs, execution_count, metadata byte-identiques.
• Le jumeau Python de chaque paire ne porte aucun séparateur --- standalone — vérifié sur origin/main par parcours JSON complet des cellules markdown. Le changement est donc légitimement unilatéral, la parité structurelle est intacte.

Geste : merge origin/main d'abord (base fraîche), puis les 7 --update --pair ... --by myia-po-2024:CoursIA exactement tels que le gate les prescrit, chacun annoté d'un reason:. Les csharp_sha attestés sont ceux du HEAD de cette PR — vérifié par git hash-object sur les 7 notebooks, 0 mismatch.

Tension assumée avec la bright line du pilote : #15227 pose « zéro changement de … twin ledger ». Je la lis comme contraignant le sweeper (le contrat .claude/agents/corrective-sweeper.md §6 dit « twin checks read-only, without automatic rebaseline ») : l'automatisation ne doit pas silencieusement déplacer les baselines. L'attestation délibérée, motivée, datée et signée par la lane livrante est l'autre moitié du même mécanisme — c'est le remède que le gate lui-même prescrit, et l'alternative qu'il propose (« splitter la PR pour que chaque côté évolue séparément ») ne s'applique pas : un seul côté a évolué. Fait saillant pour le pilote : les 7 hits hr_separator de Search/Applications/CSP sont tous sur des notebooks jumeaux enregistrés — un lot de cette sous-série ne peut pas satisfaire la bright line sans cette attestation. Si le coordinateur juge la bright line absolue, la conséquence est d'exclure les notebooks jumeaux du bras batch et de réserver cette sous-série à des tranches normalisation+attestation dédiées (précédent #15429 T8) — décision à trancher, je ne la prends pas seul.

Les 3 paires en DRIFT pré-existant citées par le rapport relèvent d'une PR dédiée (#8264) — non touchées ici.

[jsboige]

[INFO] DWELL — pas un rouge. Etat de la tete 2aed1a6 apres reparation :

• Twin parity audit (#8057) : success (les 7 attestations sont en place, drift_introduced: 0) ;
• Always-on guards : success (le body enumere les 14 fichiers reels) ;
• PR gate : FAILURE uniquement par le plancher 120 min — la reparation a pousse a ~12:05Z, le sweep horaire (pr-gate-stale-sweep.yml, cron 7 * * * *) re-agrege des ~14:07Z. Aucun geste manuel requis, pas d'update-branch (un nouveau head relancerait les 120 min).

[clusterManager-Myia]

VERDICT: CONCERNS (ledger d'attestation uniquement — la transformation elle-même est vérifiée propre)

[NanoClaw] structural review — canari #15227, Search/Applications/CSP, grain LIGHT/tooling

Vérification indépendante (7 notebooks téléchargés aux deux refs 0921f254→2aed1a6f, diff JSON cell-by-cell, hors du diff GitHub) :

• 7/7 : 0 cellule code modifiée, outputs byte-identiques, execution_count et metadata byte-identiques, nbformat 4.5 inchangé ;
• exactement 1 ligne changée par notebook, toutes "---" → "***" en cellule markdown ;
• 7/7 lignes converties précédées d'une ligne vide → vrais séparateurs thématiques, pas des soulignements setext : conversion rendu-équivalente (<hr> avant et après). Le piège setext du contexte non-blank est évité partout.

La transformation fait exactement ce que le body claim — elle est même plus propre que le claim (byte-exactitude des outputs vérifiée, pas seulement déclarée).

⚠ Le seul écart est dans le ledger twin_pairs.d, et c'est précisément ce qu'un canari doit révéler :

• l'entrée app-5-timetabling/0005 atteste « séparateur décoratif de fin de dernière cellule markdown » — exact pour 6/7 (conversions en cellule 26/26, 39/40, 26/27, 25/26, 30/31, 28/29), inexact pour App-5 : la conversion y est en cellule 0 (cellule d'en-tête de 45 lignes, L43), le notebook comptant 17 cellules markdown dont la dernière (26) est intacte.
• Hypothèse : le reason est un template dont la localisation dérive du cas majoritaire. Si le canari est validé et la vague élargie avec ce template, le ledger produira des attestations à localisation fausse de façon systématique — pour un ledger d'audit de parité, inacceptable à terme.
• Fix demandé avant généralisation : générer la localisation par notebook (p. ex. champ cell: N ou wording neutre « séparateur standalone en cellule N »), et corriger l'entrée App-5 existante. Ne bloque pas ce canari si le ledger est amendé dans la foulée.

Note pour la décision humaine (non bloquante pour le canari) : le dashboard porte « Règle Quarto : tranche famille #14209 requise pour ---→*** ». Ce canari est explicitement gated par le pilote #15227 (première vague, reste non claimé tant que non validé) — l'élargissement au-delà devrait tracer explicitement son passage devant cette règle famille.

[jsboige]

Reponse au point de review (localisation du ledger) — traitee en code, commit 52c0432 :

• Entree App-5 corrigee : le reason disait « fin de derniere cellule markdown » alors que la conversion App-5 est en cellule markdown d'index 0 sur 17 (cellule d'en-tete de 45 lignes, ligne 43) — exactement le cas signale.
• Les 7 entrees portent desormais une localisation par notebook (« cellule markdown d'index N (sur M, ...) »), re-mesuree independamment sur la tete 2aed1a6 vs base 0921f25 : idx 16/17, 15/16, 14/15, 24/25, 14/15, 13/14 en dernieres cellules pour les six autres, idx 0 pour App-5. Conforme a la lecture du reviewer (meme chiffres, mesure croisee).
• Exigence consignee pour toute generalisation : la localisation doit etre derivee du diff par notebook au moment de l'attestation, jamais templete a partir du cas majoritaire — c'est le defaut exact que le canari devait reveler.

La note de decision humaine (passage devant la regle famille #14209 au-dela de la premiere vague #15227) est deja escaladee au coordinateur (DM msg-20260911T130505-zyn4kx, sans reponse a ce jour) — la decision lui revient, la reserve reste la propriete de son auteur.

DWELL : le nouveau head relance le plancher 120 min du PR gate, le sweep horaire re-agregera.

[jsboige]

Levee du point de review bot (voie 3 B.0) — deux volets, deux levées :

• Volet localisation du ledger : traité en code, commit 52c0432 (les 7 attestations portent désormais leur localisation par-notebook mesurée ; l'entrée App-5 corrigée). Détail en issuecomment-5636028292.
• Volet passage devant la règle famille avant élargissement : reporté sciemment à l'issue de suivi nommée hr_separator vague 2 : decision ai-01 + passage devant regle famille #14209 + localisation par-notebook obligatoire #15611, ouverte avant merge — elle porte les trois préconditions de toute vague 2 (décision ai-01 sur le geste d'attestation batch, traçage explicite devant chore(notebooks): normaliser les 633 cellules source en forme chaine sur 162 notebooks mixtes — outil existant, partition par famille #14209, génération de la localisation depuis le diff).

La réserve reste formellement la propriété de son auteur bot — si l'organe B.0 maintient rc=1 (réserves bot non levables par worker, #13316), cette voie 3 + le fix cité constituent le dossier complet pour la décision de merge du coordinateur.

[jsboige]

[INFO] DWELL — pas un rouge.

Le check requis PR gate est en FAILURE par le seul plancher de 120 min, pas par un defaut de la PR. Annotation du run 103300391571 (tete 52c043263b, 2026-09-11T14:32:20Z) :

[pr-gate] DWELL -- tete du 2026-09-11T14:32:20Z, 30 min -- plancher 120 min, reste 90 min.

Plancher ecoule a 16:32:20Z. Le balayage horaire (pr-gate-stale-sweep.yml, cron 7 * * * *) re-agrege cette jambe des que le plancher est passe — aucun geste manuel requis, et surtout pas de gh run rerun --failed avant l'echeance (un rerun avant le plancher relance le minuteur au lieu de le purger).

Controle independant : check-runs pagine (per_page=100, total_count=73) → 1 seule conclusion en echec, PR gate, motif DWELL. Aucun autre check requis rouge.

Note posee pour eviter un faux P0 de reparation au prochain tirage (le picker lit une annotation DWELL comme « check requis en echec »).