Fix/depth comfort probe 2 - #340
Merged
Merged
Conversation
Reprise telle quelle de `test/sondes-adversariales-constats` (commit 13a3b0e) comme point de départ mesuré. Elle est VERTE 6/6 sur `origin/develop` : ce n'est pas un test rouge à faire passer, c'est un test de *caractérisation* qui fige le comportement actuel, défaut compris (`expect(rhythm, 0)` sur la séance normale sous le seuil). Chiffres relevés sur `origin/develop`, avec comfort=mid / best=throat : - normal sr=0.50 : rhythm=0/300 hold=300/300 - normal sr=0.80 : rhythm=300/300 hold=300/300 - égalité sr=0.70 : rhythm=16/300 (5.3 %, ≈ 1/14 = la loterie de surcharge) - Encore sr=0.50 : rhythm=300/300 hold=300/300 - Encore sr=0.80 : rhythm=300/300 hold=300/300 - Utilise-moi 0.50 : rhythm=300/300 hold=300/300 Commité avant tout correctif pour que le diff suivant montre exactement quel `expect` bascule, et pourquoi.
Réapplication sur le code d'aujourd'hui de l'intention de 411feba (`origin/feat/depth-comfort-probe`, 101 commits de retard) : la profondeur rythmée vise **un cran au-dessus du comfort, borné par le `best` prouvé**. Les deux fonctions ciblées sont identiques à ce qu'elles étaient au merge-base (39cbcaa) — vérifié : `git diff 39cbcaa..origin/develop` est vide sur les deux fichiers. Le raisonnement d'origine tient donc tel quel. Deux écarts assumés par rapport à 411feba : - garde `max(comfort, …)` dans `capabilityCapFor` : un profil persisté où `best < comfort` verrait sinon la « sonde » RABAISSER le cap. Le `best` est monotone en mémoire, mais il est persisté séparément du `comfort` et rechargeable depuis un import — le cas n'est pas impossible. - `maxDepthIndexForProfile` formulé en `best.round() > rounded ? rounded+1 : rounded` (équivalent au `min` d'origine sur des entiers, non abaissant par construction). Le clamp lit `comfort` en double (le decay produit des crans fractionnaires), d'où le `min(comfort + 1, best)` conservé là — le consommateur arrondit, et `comfort=2.7 / best=3.0` doit donner throat, pas full.
Deux `expect` figeaient le défaut ; ils expriment maintenant la règle voulue. Ajout des cas qui bornent le correctif — c'est là que se joue « est-ce trop généreux ? » : un cran seulement (comfort=head/best=throat reste borné à mid, 0/300), no-op strict quand best == comfort (0/300), pas d'abaissement quand best < comfort, et le tableau unitaire de `maxDepthIndexForProfile`. Non-régression des tenues : deux invariants insensibles à la dérive RNG (les compteurs bruts ne sont PAS comparables step à step — déplacer un step rythmé fait diverger toute la séquence en aval) : la tranche throat sort toujours en tenue, et `full` reste fermé sans `fullHold` acquise. Discrimination vérifiée sur un worktree détaché sur origin/develop : - avec le correctif : 11/11 verts - sur origin/develop : 2 rouges (rhythm 0 au lieu de 300 ; maxDepthIndex 2 au lieu de 3), les 9 autres verts — ce sont les non-régressions.
Les sondes de profondeur existantes injectent un profil figé dans le générateur : elles prouvent que la tranche throat redevient visible, pas que le `comfort` remonte. Ce harnais referme le circuit — profil persisté relu par le générateur, séance rejouée dans le vrai `CapabilityTracker`, rapport repassé par le vrai `CapabilityService.commit`. Mesuré sur la branche : comfort=mid/best=throat remonte à throat à la 2ᵉ séance (5 bases de graines), une chute de deux crans en 3, un tap-out coûte un cran et la profondeur proposée redescend avec lui. Les 4 tests sont rouges sur origin/develop, où le comfort ne bouge pas de 20 séances.
La relecture adverse l'a relevé : la reformulation n'est pas équivalente au `min` d'origine, et l'écart tombe exactement sur le cas que l'autre fichier du correctif protège explicitement (`best < comfort`, écrit tel quel par l'import de profil). Sans cette note, un refactor qui « revient à la forme littérale » réintroduit la régression.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.