dev-discipline

Que fait dev-discipline ?

« Fini » est déclaré par un signal externe que vous n'avez pas ajusté. Une règle écrite ne nomme qu'une classe de défaillance ; une vérification dans la passerelle l'arrête. Quand une classe se répète, ajoutez la vérification dans le même commit. $DD = le dossier scripts/ à côté de ce fichier (sortie 0 PASS, 1 FAIL, 2 NOT_PROVEN).

Rigueur par surface. Boucle complète pour les choses qui jugent (tests, validateurs, seuils, CI), l'argent et les formules numériques, les migrations, l'authentification, les échecs silencieux. Une correction locale d'environ 10 lignes avec une spécification littérale : prove_fix.py, 2-3 mutants écrits à la main de la classe de défaut, une exécution sur une entrée que vous n'avez pas utilisée pendant le travail. Prose, aspect UI, documentation, prototypes : exécutez les tests et un test de fumée. Pas de tests ni d'exécuteur : ajoutez un test minimal dans son propre commit (configuration, pas d'affaiblissement).

Boucle

1. Mesurer avant d'éditer : une commande que vous comparerez avant et après. Dérivez la portée des données brutes, pas des résumés ou de la mémoire. Listez la classe entière : chaque instance partageant la racine. → references/debugging.md
2. Corriger la racine sur le chemin emprunté par le défaut. Une garde en haut n'est pas une correction. Régression : git bisect run. Après trois tentatives échouées, changez d'approche ou de contexte. Nouvelle entité, flux d'argent/données ou migration : une note de conception de 5 à 10 lignes d'abord (debugging.md §10).
3. Prouver le test : rouge sur le parent par une assertion (ImportError, erreur de collecte, skip = NOT_PROVEN), vert sur la correction, rouge à nouveau avec la modification de code annulée : $DD/prove_fix.py. Une nouvelle vérification se déclenche sur une mauvaise entrée et reste silencieuse sur une bonne. Pour l'argent et les nombres, la valeur attendue est une spécification littérale (# oracle: <source>).
4. Passerelle : le test s'exécute dans la CI dans le même commit ; skip, timeout et « 0 tests » ne sont pas PASS ; les listes d'exclusion ne font que rétrécir ; une boucle sur un glob ou un registre affirme combien d'éléments elle a trouvés. → gate-integrity.md
5. Accepter sur la ligne de résumé de l'exécuteur de la dernière exécution sur l'arbre exact, pas sur le $? d'un pipeline.
6. Fermer avec une vérification que l'auteur n'a pas ajustée : autres données, un test de fumée de production en lecture seule, un oracle indépendant, avec l'attente écrite au préalable. Une classe qu'elle trouve entre dans la passerelle. → proof-and-oracles.md

L'oracle et sa protection

• Un oracle ne partage aucun code avec ce qu'il vérifie. Les golden et l'auto-parité prouvent la cohérence, pas l'exactitude.
• Un script de vérification est du code testé : exécutez-le sur une bonne et une mauvaise entrée ; affichez combien d'éléments il a examinés.
• Les tests, snapshots, valeurs attendues et CI ne changent que par contrat : le brief, ou, en travaillant seul, une demande utilisateur qui nomme le changement (nouvelle spécification, ticket, valeur) plus une ligne écrite avant l'édition (quels tests changent, d'où vient la nouvelle valeur). « Faire passer » n'est pas un contrat : un test qui contredit la spécification reste tel quel et la réponse est SPEC_CONFLICT. Les changements de valeur vont dans un commit test: séparé. Les sauts, assertions supprimées, couverture réduite nécessitent une raison déclarée. N'ajustez jamais le code pour atteindre un nombre attendu. Jugez le diff final, pas l'outil d'édition : $DD/guard_diff.py (d'abord consultatif). Une vérification qui bloque un travail légitime est un défaut : signalez BLOCKED, ne contournez jamais. → oracle-protection.md

Autonomie

Procédez par défaut. Ne demandez que pour l'irréversible (sécurité, paiements, écritures de données de production, permissions) ou un conflit avec l'objectif. À une bifurcation, choisissez-en une, enregistrez pourquoi, les chiffres des deux lectures et comment l'annuler, et continuez. Bloqué : terminez tout ce qui est indépendant, puis finissez par une ligne nommant l'action et la commande nécessaires.

Rapport

• Chaque critère PASS | FAIL | NOT_PROVEN avec commande, code de sortie et ligne de sortie ; plus not_checked.
• Verdict : DONE, BLOCKED(reason), SPEC_CONFLICT(test, source), IMPOSSIBLE, NOT_REPRODUCED. Une sortie honnête non-terminée est un succès ; un saut silencieux est un défaut. Nommez les états partiels (« garde ajoutée, racine active »).
• Chaque nombre est accompagné de sa commande de la dernière exécution. Ré-exécutez les chiffres rapportés par un sous-agent ($DD/reexec_claims.py).
• Corps du commit = enregistrement des preuves : mesure avant/après, ligne de passerelle, ce qui n'est pas fait et où il est allé.

Drapeaux rouges

Je remarque	Je fais
Vert sans rouge sur le parent	prove_fix.py
Citer le chiffre d'un sous-agent ou ma mémoire	le ré-exécuter
Modifier un test ou un seuil sans contrat	ligne de contrat ou SPEC_CONFLICT
skip, retry, sleep, noqa pour obtenir le vert	trouver la cause, la rendre déterministe (refactor-flaky.md)
Sur le point de demander quelque chose de réversible	décider, enregistrer, continuer

Plus : delegation.md (sous-agents, relecteurs, briefs), release.md (déploiements), process-ledger.md, evidence.md.