This website requires JavaScript.
Explore
Help
Sign In
michel
/
oto-enterprise-os-dtp
Watch
1
Star
0
Fork
0
You've already forked oto-enterprise-os-dtp
Code
Issues
Pull Requests
Actions
Packages
Projects
Releases
Wiki
Activity
Files
6a40bfcccecde3f6b65fed8d8d3bfc4078e1f00f
oto-enterprise-os-dtp
/
05_activity_log
T
History
Claude Code DTP Worker
6a40bfccce
[DTP-Worker] Sprint 8 · buffer L75 · Domaine QA/Audit 5D (2e surface) : la TABLE « Verdict courant » de l'audit de conformité énumérait À LA MAIN ses 4 open items (control → dimension → propriétaire) sans AUCUN gate d'IDENTITÉ. Le bloc audit_5d existant gate « 17 contrôles / 5 dimensions » (×2 docs) ET la ventilation du verdict « 13 PASS · 0 FAIL · 4 à confirmer » (recomputée d'audit_report.totals) mais PAS l'identité des 4 contrôles ouverts ni leur (dimension, propriétaire) — surface data-derived distincte du MÊME README. Cette table dérive d'audit_report.json.open_items[] (byte-gaté par check_artifacts : chaque item = {control, dimension, owner, detail} recalculé en rejouant les contrôles sur les hand-off amont). Le bloc de VENTILATION ne recompute que le COMPTE (« 4 à confirmer ») : un ÉCHANGE d'open item (ex. D2.3 → D3.1) laisse le compte à 4 — le compteur reste AVEUGLE — pendant que l'artefact dit autre chose ; idem une dimension mal étiquetée (D1.3 rangé sous D2) ou un propriétaire réattribué — « vert trompeur » qu'aucune suite tests/ (qui teste des FONCTIONS, pas la prose) n'attrape → nouveau bloc dans check_readme_claims recomputant l'ensemble {control:(dimension, propriétaire)} depuis audit_report.open_items (zéro duplication du modèle de l'auditeur
#6
) et exigeant que la table README l'énumère EXACTEMENT. Contrôle par ENSEMBLE (absent ET en trop mordus, pas seulement présence), puis (dimension, propriétaire) PAR LIGNE. Même patron que l'énumération des confirmations DevOps ou la carte de renormalisation par archétype 4Big. Cohérence croisée en bonus : l'ensemble des control == MANIFEST.open_items (le manifeste qui résume le rapport) — mord un manifeste désynchronisé de son rapport. Un claim absent échoue AUSSI (4 morsures vérifiées : échange D2.3→D3.1 capté là où le compte reste 4 · dimension D1.3→D2 captée · propriétaire D1.1 Direction→Compta capté · ligne D1.2 supprimée = sous-ensemble capté ; restauré = green : [D1.1,D1.2,D1.3,D2.3] control→dimension→propriétaire == audit_report.open_items). État courant : aucun open item périmé (anti-invention
#6
, rien à réécrire) — le défaut est la surface ungated. ci/README.md (table + détail) mis à jour · 7 gates re-verts.
...
Co-Authored-By: Claude Opus 4.8 (1M context) <
noreply@anthropic.com
>
2026-07-31 14:39:58 +00:00
..
2026-07-30.md
[DTP-Worker] Sprint 8 · buffer · Gate reproductibilité artefacts (ci/check_artifacts.sh) + fix dérive run_sheet demo 18→21
2026-07-30 23:38:15 +00:00
2026-07-31.md
[DTP-Worker] Sprint 8 · buffer L75 · Domaine QA/Audit 5D (2e surface) : la TABLE « Verdict courant » de l'audit de conformité énumérait À LA MAIN ses 4 open items (control → dimension → propriétaire) sans AUCUN gate d'IDENTITÉ. Le bloc audit_5d existant gate « 17 contrôles / 5 dimensions » (×2 docs) ET la ventilation du verdict « 13 PASS · 0 FAIL · 4 à confirmer » (recomputée d'audit_report.totals) mais PAS l'identité des 4 contrôles ouverts ni leur (dimension, propriétaire) — surface data-derived distincte du MÊME README. Cette table dérive d'audit_report.json.open_items[] (byte-gaté par check_artifacts : chaque item = {control, dimension, owner, detail} recalculé en rejouant les contrôles sur les hand-off amont). Le bloc de VENTILATION ne recompute que le COMPTE (« 4 à confirmer ») : un ÉCHANGE d'open item (ex. D2.3 → D3.1) laisse le compte à 4 — le compteur reste AVEUGLE — pendant que l'artefact dit autre chose ; idem une dimension mal étiquetée (D1.3 rangé sous D2) ou un propriétaire réattribué — « vert trompeur » qu'aucune suite tests/ (qui teste des FONCTIONS, pas la prose) n'attrape → nouveau bloc dans check_readme_claims recomputant l'ensemble {control:(dimension, propriétaire)} depuis audit_report.open_items (zéro duplication du modèle de l'auditeur
#6
) et exigeant que la table README l'énumère EXACTEMENT. Contrôle par ENSEMBLE (absent ET en trop mordus, pas seulement présence), puis (dimension, propriétaire) PAR LIGNE. Même patron que l'énumération des confirmations DevOps ou la carte de renormalisation par archétype 4Big. Cohérence croisée en bonus : l'ensemble des control == MANIFEST.open_items (le manifeste qui résume le rapport) — mord un manifeste désynchronisé de son rapport. Un claim absent échoue AUSSI (4 morsures vérifiées : échange D2.3→D3.1 capté là où le compte reste 4 · dimension D1.3→D2 captée · propriétaire D1.1 Direction→Compta capté · ligne D1.2 supprimée = sous-ensemble capté ; restauré = green : [D1.1,D1.2,D1.3,D2.3] control→dimension→propriétaire == audit_report.open_items). État courant : aucun open item périmé (anti-invention
#6
, rien à réécrire) — le défaut est la surface ungated. ci/README.md (table + détail) mis à jour · 7 gates re-verts.
2026-07-31 14:39:58 +00:00