PD-299 — Rapport de confrontation (Étape 5 — Pré-Gate 5)¶

Ce rapport est produit par l'orchestrateur Claude avant la Gate 5 (Review plan). Il confronte la spécification (step 1), les tests (step 2), le plan (step 4) et les code contracts (step 4) pour identifier convergences, divergences et zones d'ombre.

1. Sources confrontées¶

2. Convergences¶

2.1 Invariants structurants¶

• INV-299-01 à INV-299-18 : couverture intégrale constatée dans les 4 documents. Chaque invariant est mappé à au moins un mécanisme (plan §3), un contrat (contracts), un ou plusieurs tests (tests §2) et une observation contractuelle (spec §7).
• FSM Gate 8 fermée (§5.4) : scope Gate 8 explicite, 6 états, transitions terminales sans sortie. Convergence totale spec ↔ tests (TC-NOM-19/20/21, TC-ERR-14) ↔ plan (§2.8, §9.3) ↔ contracts (gov-gate-zerotest).
• Distinction FSM Gate 8 / gardes workflow : les enchaînements 6c→6c.bis→7 et Gate 5 plan→spec sont explicitement hors FSM (spec §5.4), convergent dans le plan (§2.7, §2.10) et les contracts.

2.2 Modèle de données et bornes¶

• D-299-01 à D-299-22 : formats, regex et contraintes reprises sans contradiction entre spec, plan et contracts. Les tests se réfèrent explicitement aux IDs de données dans leurs GIVEN/THEN.
• Bornes numériques (§5.2) : 45 tests, coverage 80%, cap score 6.0, tolérance 0 cross-module, tolérance 0 extensions non ratifiées — valeurs strictement identiques dans les 4 documents.
• A8 legal : 3 textes (ARB-7, ARB-8, RGPD-90J) × 2 approbations (PO + LEGAL) : structure et obligations de traçabilité convergent (D-299-21 ↔ F-299-11 ↔ gov-legal contract ↔ TC-NOM-18 / TC-ERR-12).

2.3 Gate 8 zéro test (B2)¶

• Règle déterministe test_coverage = 6.0 exact + transition CHECKING → NON_CONFORME forcée, même si moyenne ≥ 7 : convergence spec (INV-299-12/13, F-299-08) ↔ tests (TC-NOM-11/12, TC-ERR-08, TC-NR-03) ↔ plan (§2.8) ↔ contract (gov-gate-zerotest).
• Application uniquement sur project_code ∈ {app, backend} ; no-op sur ia-governance : converge ERR-299-13 ↔ TC-ERR-13 ↔ plan §2.8 ↔ contract.
• Conservation de raw_test_coverage distinct pour auditabilité : plan §2.8 + contract cohérents.

2.4 Autres mécanismes B1 / B3 / B6¶

• 6c.bis (B1) : exit code 2 + motif + liste chemins manquants + correlation_id D-299-22 : cohérent entre tests (TC-NOM-09/10, TC-ERR-09), plan (§2.7) et contract (gov-6cbis).
• Injection companion (B3) : sections ## 4. Invariants et ## Arbitrages — Vérification formelle post-step 1 comme sources canoniques, bloc inséré en portion cacheable, traçabilité source_story_id : convergent spec ↔ plan ↔ contract ↔ tests.
• detect-plan-extensions (B6) : exit 1 pour UNRATIFIED, exit 2 pour kind invalide, enum strict {endpoint, header, timeout}, status ∈ {RATIFIED, UNRATIFIED} : convergent sur le schéma D-299-20 et le comportement de blocage.

2.5 Cross-module¶

• Le plan (§2ter) et les contracts désignent ProofDetailScreen comme point d'intégration cross-module, et OwnershipGuard comme mécanisme de protection — cohérent avec la clarification Q-299-05 de la spec (§10.2) et INV-299-03.

3. Divergences¶

⚠️ Les conflits ne doivent JAMAIS être lissés. Chaque divergence est rendue visible.

DIV-01 : Regex du header Authorization (un espace vs plusieurs)¶

• Source A — Spécification (D-299-07, §5.1) : authorization_header pattern ^Bearer [ ]+[!-~]+$ (le quantificateur [ ]+ autorise explicitement un ou plusieurs espaces ASCII entre Bearer et le token).
• Source B — Plan (§2.3 F-299-03, §7.1) : émission avec un seul espace ASCII, regex de sortie ^Bearer [!-~]+$ (aucun quantificateur). Le plan reconnaît explicitement être « plus strict que D-299-07 » (§7.1, ligne « Interopérabilité RFC 6750 »).
• Source C — Code contracts (module sharing-api) : invariant « produit 'Bearer ' avec un SEUL espace ASCII (RFC 6750 strict, cohérent avec D-299-07) » — la mention « cohérent avec D-299-07 » est factuellement incorrecte puisque D-299-07 admet N espaces.
• Source D — Tests (TC-NEG-02, TC-ERR-04) : rejette explicitement "Bearer abc def" (deux espaces) — aligné plan/contract, pas avec la lecture littérale de D-299-07.
• Impact : un header reçu avec 2 espaces serait valide selon la spec et rejeté par l'implémentation. Si la spec reste inchangée, un pentester/auditeur peut contester le rejet comme non conforme. Décision à ratifier en Gate 5 : soit corriger la spec (D-299-07 = ^Bearer [!-~]+$), soit assouplir l'implémentation.

DIV-02 : Borne inférieure du bloc companion (0 byte vs 1 byte)¶

• Source A — Spécification (§5.2) : companion_context_addition default=2, min=0, max=2 KiB — la borne min=0 KiB autorise explicitement un bloc vide.
• Source B — Spécification (§5.1 D-299-19) : Markdown UTF-8 ... 1..2048 bytes additionnels — borne min=1 byte.
• Source C — Plan (DEC-03, §2.9) : tranche pour [1, 2048] bytes (choisit §5.1 contre §5.2).
• Source D — Code contracts : [1, 2048] bytes + invariant « ne pas accepter un bloc companion vide (0 byte) ».
• Source E — Tests (TC-NOM-13, TC-NEG-04) : vérifient ≤ 2 KiB et > 2 KiB rejeté mais ne testent aucun cas à 0 byte (ni acceptation ni rejet).
• Impact : incohérence interne à la spec (§5.1 vs §5.2) résolue unilatéralement par DEC-03. La ratification Gate 5 doit acter la correction de §5.2 vers min=1 byte (ou équivalent sous-KiB).

DIV-03 : Récursivité du glob *.{test,spec}.{ts,tsx}¶

• Source A — Spécification (§3 « Zéro test », D-299-14) : count(*.{test,spec}.{ts,tsx}) — aucune mention explicite de récursivité ni de racine.
• Source B — Plan (DEC-01, §2.8) : décide récursivité explicite via find src -type f \( -name '*.test.ts' -o ... \).
• Source C — Code contracts (gov-gate-zerotest) : « glob récursif documenté » imposé par invariant, forbiden « glob non récursif ».
• Source D — Tests (TC-NEG-09) : vérifie que foo.spec.tsx sous src/sharing/__tests__/ donne test_file_count=1, confirmant l'implémentation récursive.
• Impact : la spec ne précise pas le comportement. Sans ratification Gate 5, un auditeur strict pourrait interpréter le glob comme non récursif (glob POSIX simple = pas de **), ce qui invaliderait toute la chaîne. Décision à ratifier.

DIV-04 : Échelle du comptage « module livré » vs « projet cible »¶

• Source A — Spécification (§3 « Zéro test ») : test_file_count == 0 sur le module livré.
• Source B — Spécification (INV-299-12) : « Gate 8, si projet ∈ {app, backend} et test_file_count == 0 » — ambivalent sur l'échelle (projet ou module).
• Source C — Plan (DEC-02, §2.8) : tranche pour niveau projet cible (ProbatioVault-app/src, ProbatioVault-backend/src). Le « module livré » n'est utilisé que pour la couverture fonctionnelle PD-298.
• Source D — Code contracts : « test_file_count est calculé via find sur <project_root>/src » → niveau projet.
• Impact : deux interprétations métier distinctes. Si une story livre un module de 0 test mais le projet a 100+ tests, l'interprétation « module » bloque Gate 8 tandis que l'interprétation « projet » ne la bloque pas. Décision structurante à ratifier.

DIV-05 : ratification_ref sur items RATIFIED (obligatoire ou optionnel)¶

• Source A — Spécification (D-299-20) : schéma {kind, key, status, ratification_ref?} — le ? indique une clé optionnelle.
• Source B — Plan (DEC-04, §2.10) : tout item RATIFIED sans ratification_ref est reclassé en UNRATIFIED_MISSING_PROOF et bloque Gate 5.
• Source C — Code contracts (gov-check-extensions) : invariant « un item avec status=RATIFIED mais ratification_ref vide/absent => reclassé en UNRATIFIED_MISSING_PROOF ».
• Source D — Tests : aucun test ne couvre explicitement le cas RATIFIED + ratification_ref absent (TC-NOM-17 teste uniquement RATIFIED global sans variation du champ).
• Impact : DEC-04 durcit le schéma spec. Sans ratification, un plan pourrait légitimement produire {status: "RATIFIED"} sans ratification_ref et se voir bloqué — contradiction avec la spec littérale. Gap de couverture de test additionnel.

DIV-06 : Codes d'erreur DEC-05 — extension spec auto-récursive¶

• Source A — Spécification (§6 Cas d'erreur) : table des ERR-299-* limitée à 15 entrées, sans définition de codes applicatifs normalisés.
• Source B — Plan (DEC-05, §6.1) : introduit 13 codes d'erreur fermés (SHARE_OWNERSHIP_MISMATCH, SHARE_AUTH_INVALID, SHARE_OFFLINE, etc.) constitués en union TypeScript littérale.
• Source C — Code contracts (module sharing-telemetry) : SharingErrorCode défini comme « union littérale fermée des codes listés dans PD-299-plan.md §6.1 ».
• Source D — Plan §9.1 (auto-constat) : le plan reconnaît lui-même que « DEC-05 codes d'erreur fermés : extension spec non ratifiée (au sens B6 du flux !) ». Le plan signale un méta-risque : detect-plan-extensions pourrait flagger sa propre sortie comme extension plan→spec.
• Impact : soit les codes DEC-05 sont des « constantes applicatives hors portée detect-plan-extensions » (à documenter formellement dans le contract gov-check-extensions), soit ils doivent être ratifiés PO en Gate 5 comme extensions explicites. Risque de boucle logique si non tranché.

DIV-07 : Unicité PO vs LEGAL (approvers et jira_comment_id)¶

• Source A — Spécification (D-299-21, INV-299-09) : exige approvals.PO et approvals.LEGAL avec {approver_id, approved_at, jira_comment_id} — aucune exigence d'unicité entre les deux rôles.
• Source B — Plan (DEC-08, §2.11) : impose approver_id_PO != approver_id_LEGAL ET jira_comment_id_PO != jira_comment_id_LEGAL.
• Source C — Code contracts (gov-legal) : invariant « approver_id_PO != approver_id_LEGAL ET jira_comment_id_PO != jira_comment_id_LEGAL ».
• Source D — Tests : TC-NOM-18 et TC-ERR-12 ne testent pas explicitement le cas approver_id_PO == approver_id_LEGAL (alors qu'il serait rejeté par l'implémentation).
• Impact : DEC-08 matérialise Art. II CONSTITUTIONAL (séparation des pouvoirs) mais ajoute une contrainte absente de la spec. Cas limite légitime possible (un approbateur dual-role) bloqué par design — à ratifier. Gap de couverture de test additionnel.

DIV-08 : Vérification effective de jira_comment_id via API Atlassian¶

• Source A — Spécification (D-299-21) : jira_comment_id non vide (commentaire Jira traçable Atlassian) — exige la traçabilité mais pas une vérification API live.
• Source B — Plan (§2.11) : exige GET /rest/api/3/issue/<story>/comment/<id> avec rejet sur 404.
• Source C — Code contracts (gov-legal) : invariant « existence effective vérifiée via GET /rest/api/3/issue//comment/ ; 404 => FAIL ».
• Source D — Tests (TC-NOM-18) : mentionne « Atlassian 200 » en observable mais TC-ERR-12 ne distingue pas le cas jira_comment_id inexistant en API du cas champ manquant.
• Impact : le plan ajoute une dépendance externe runtime (disponibilité API Atlassian) qui n'est pas spécifiée. H-T-11 / H-299-05 reconnaissent le risque. Impact sur la disponibilité de la validation A8 en cas de panne Jira.

DIV-09 : Normalisation Unicode NFKC pour approver_id¶

• Source A — Spécification (D-299-21) : aucune mention de NFKC, homoglyphes ou normalisation Unicode.
• Source B — Plan (§7.1 ligne homoglyphe, §2.11) : impose normalisation NFKC avant comparaison d'unicité.
• Source C — Code contracts (gov-legal) : invariant « normalisés Unicode NFKC avant comparaison d'unicité (anti-homoglyphe basique) ».
• Source D — Tests : aucun test dédié à la normalisation NFKC (TC-NEG-* ne couvre pas les homoglyphes).
• Impact : extension sécurité légitime mais non spécifiée. Si approver_id contient des caractères composés (accents décomposés), le comportement n'est pas testé. Gap de couverture de test adversarial.

DIV-10 : Terminologie « non-répudiation » vs traceability_only¶

• Source A — Spécification (D-299-21) : « non-répudiation minimale via trace Atlassian ».
• Source B — Plan (DEC-09, §2.11) : sortie JSON assurance_level=traceability_only, jamais non-repudiation.
• Source C — Code contracts (gov-legal) : forbidden « Rapporter assurance_level='non-repudiation' dans la sortie JSON ».
• Source D — Tests : TC-NOM-18 ne vérifie pas le champ assurance_level dans le verdict JSON.
• Impact : correction terminologique du plan pour éviter une sur-promesse juridique. Convergence interne plan/contract mais divergence avec le vocabulaire spec et non couverte par un test. Risque d'interprétation auditeur divergente.

DIV-11 : Quantité de cross_module_point_path attendus dans le diff¶

• Source A — Plan (§2ter) : 3 chemins attendus (ProofDetailScreen.tsx, OwnershipGuard.tsx, index.ts).
• Source B — Tests (TC-NOM-09) : GIVEN « Plan contenant 2 cross_module_point_path valides ».
• Impact : divergence quantitative entre plan et tests. TC-NOM-09 teste un scenario à 2 chemins alors que le plan en produit 3. Soit le test doit être mis à jour (contradictions sur la couverture), soit la liste plan doit être réduite. À résoudre avant step 6a.

DIV-12 : netinfo_is_connected === null traité comme false¶

• Source A — Spécification (D-299-12, ERR-299-07, INV-299-07) : condition != true bloque. Ambigu sur null (mais null != true est vrai, donc blocage attendu).
• Source B — Plan (§2.6 F-299-06) : explicite « null est traité comme false (fail-closed) ».
• Source C — Code contracts (sharing-ui) : invariant « useNetworkGuard traite netinfo_is_connected === null comme false ».
• Source D — Tests (TC-ERR-07) : netinfo_is_connected=null → action bloquée.
• Impact : convergence sur le comportement mais l'invariant spec != true est plus large que « null treated as false ». Cohérent par construction (tout != true bloque), donc divergence faible mais méritant clarification (que se passe-t-il pour undefined ?). Gap mineur.

DIV-13 : Coverage threshold granularité (global vs par fichier)¶

• Source A — Spécification (INV-299-02) : « La couverture src/sharing/ DOIT être >= 80% ».
• Source B — Tests (TC-NOM-02) : coverage mesurée >= 80% AND <= 100% — sans préciser quelle métrique.
• Source C — Code contracts (sharing-tests) : coverageThreshold: global: { statements: 80, branches: 80, functions: 80, lines: 80 } — 4 métriques distinctes chacune à 80%.
• Source D — Plan (§2.1) : reprend les 4 seuils à 80%.
• Impact : le plan/contract imposent 4 seuils simultanés (Jest bloque si UNE seule est < 80%), alors que la spec et les tests parlent d'UNE couverture. Interprétation la plus stricte retenue — à ratifier car impact sur le faisabilité (seuil 80% par branche est plus exigeant).

4. Zones d'ombre¶

ZO-01 : Tests E2E Detox « in scope » ou « out of scope »¶

Le plan §11 indique : « Flux CTA Partager bout en bout via Detox... Out of scope uniquement si Detox indisponible en CI — auquel cas scénario reporté dans un ticket PD-299-E2E, sinon in scope. » Ni la spec ni les tests ne mentionnent Detox. Sans statut clair de Detox dans la CI ProbatioVault-app, l'ambiguïté persiste : le scope E2E est-il engagé pour PD-299 ou reporté ?

ZO-02 : Récursivité invariant INV-299-18 — transitions non listées¶

INV-299-18 impose le rejet des transitions non listées. Or les états terminaux (GO, RESERVE, ESCALADE) listent explicitement toutes les transitions sortantes comme INTERDITE. Le contract gov-gate-zerotest formule « Toute transition hors table est rejetée ». Mais l'implémentation concrète (code de la FSM) doit distinguer « transition interdite explicite » vs « transition absente de la table ». Cas de test non couvert : demander PENDING → ESCALADE (INTERDITE explicite) vs une transition inexistante (ex. PENDING → UNKNOWN).

ZO-03 : Verrouillage du re-gate concurrentiel¶

Le plan §9.2 admet : « L'implémentation suppose un seul processus Gate 8 par story à un instant donné (verrouillage implicite via .gov-local.json). » Ni verrouillage explicite (lock-file, flock), ni test concurrent. Si deux orchestrateurs exécutent Gate 8 sur la même story simultanément (ex. Ringbearer + session locale), le comportement est indéterminé. Non couvert par tests ni contracts.

ZO-04 : Idempotence du rapport plan-extensions.yaml¶

Le plan §9.2 mentionne que detect-plan-extensions « chaque run recrée le rapport » sans historisation. Si Gate 5 est exécutée 3 fois (v1, v2, v3), les 3 rapports écrasent le même fichier ? Le plan cite l'artefact data/specs-index/<project>/epics/<domain>/<story>/plan-extensions.yaml (unique) alors que les verdicts de gate sont versionnés (verdict-step5-v1.yaml, -v2.yaml, etc.). Règle de versioning à clarifier.

ZO-05 : Comportement en cas d'absence de section endpoints/headers/timeouts dans le plan¶

• Plan §2.10 / Contract gov-check-extensions : « absence de section = 0 item extrait, pas d'erreur » (no-op silencieux).
• Plan §9.3 piège identifié : « un plan sans cette section produit un no-op silencieux → extract-cross-module-points.py doit rejeter les plans dépourvus de section avec un code d'erreur explicite » (concernant 6c.bis, pas detect-plan-extensions).
• Contradiction interne au plan : extract-cross-module-points.py doit rejeter l'absence de section (6c.bis), mais detect-plan-extensions doit accepter silencieusement l'absence de section (phase 4). Les deux sont des extracteurs de sections Markdown, leur comportement devrait être uniforme ou explicitement justifié comme asymétrique.

ZO-06 : Case sensitivity pour les comparaisons d'endpoints/headers¶

Le contract gov-check-extensions précise : « comparaison par clé normalisée (case-insensitive pour les headers HTTP, case-sensitive pour les endpoints) ». Ni la spec ni les tests ne précisent ce point. Cas limite : un plan listant /api/share vs spec listant /API/Share serait considéré comme extension, alors qu'ils désignent probablement la même ressource (selon le framework HTTP). Pas de test couvrant cette normalisation.

ZO-07 : Artefact de migration SharingError dans le code app existant¶

Le plan §2.4 mentionne : « tous les sites d'appel existants qui passaient {recipientEmail, ip, userAgent, ...} doivent être corrigés en parallèle (A4 exige zéro leak). » Ni inventaire des call-sites existants, ni stratégie de migration (big-bang ou progressif), ni test de non-régression sur la migration. Gap de planification.

ZO-08 : Q-299-01 référence épique non renseignée¶

La spec (§10.2 Q-299-01) et le plan (§13) documentent « Référence épique : valeur métier non renseignée ». Cette question est ouverte depuis step 0 et non résolue. Impact traçabilité Epic incomplète pour la clôture Jira (transition 31 → Done).

ZO-09 : Q-299-05 nom de composant cible A2 (ProofDetailScreen vs ProofScreen)¶

La spec (§10.2 Q-299-05) laisse ouvert le choix du composant cible. Le plan (§2ter, §2.2) et le contract (sharing-ui files) tranchent pour ProofDetailScreen.tsx. Q-299-05 est implicitement résolue par le plan sans ratification PO explicite. À formaliser en Gate 5.

ZO-10 : Q-299-06 initialisation de l'allowlist metadata¶

La spec (§10.2 Q-299-06) demande si l'allowlist doit rester vide {} ou contenir des clés explicites à l'initialisation. Le plan (§2.4) et le contract (sharing-telemetry) tranchent pour z.strictObject({}) (allowlist vide). Implicite — à confirmer en Gate 5.

ZO-11 : Couverture test du cap score sur branche else de INV-299-12¶

Les tests couvrent test_file_count == 0 (TC-NOM-11, TC-ERR-08) et test_file_count == 1 (TC-NEG-09). Pas de test couvrant explicitement la branche else : project_code == 'app', test_file_count > 0, raw score 5.5 → vérifier que le cap 6.0 n'est pas appliqué et que le verdict suit uniquement le scoring arithmétique. Important pour éviter une sur-application involontaire.

ZO-12 : Gate 8 récursive sur PD-299 elle-même¶

Le plan §9.4 soulève : « Gate 8 sur la story PD-299 elle-même : en mode gouvernance, test_file_count est calculé sur ProbatioVault-ia-governance (= ia-governance → hors scope INV-299-12), donc la règle B2 ne s'applique pas à PD-299 côté gov — à contrôler pour éviter un faux positif récursif. » Mais PD-299 livre aussi du code app (modules sharing-). Comment Gate 8 arbitre-t-elle quand une story livre *plusieurs projets** ? project_code dans la spec est scalaire (D-299-02) — un seul projet par story. Pas de stratégie claire pour les stories multi-projet (qui est justement le cas de PD-299). Gap conceptuel structurant.

5. Recommandation¶

• Procéder — convergence confirmée, aucun conflit bloquant
• Rework nécessaire — divergences à résoudre avant de continuer
• Escalade — décision humaine requise sur un point structurant

Justification de la recommandation¶

12 divergences et 12 zones d'ombre sont relevées. La majorité des divergences (DIV-01 à DIV-10) résulte des décisions techniques de résolution (DEC-01 à DEC-10) prises par le plan pour résoudre des ambiguïtés spec. Ces décisions sont documentées explicitement (ce qui est une bonne pratique) mais constituent formellement des extensions plan→spec non ratifiées — et donc candidates à blocage par le propre mécanisme B6 de cette story (phase 4 de /gov-check-plan, detect-plan-extensions).

Points de rework critique (à traiter avant Gate 5)¶

1. DIV-06 (méta-risque auto-récursif) : statut des codes DEC-05 vis-à-vis de detect-plan-extensions — soit exclusion explicite, soit ratification PO formelle.
2. DIV-11 (quantité cross_module_path) : plan dit 3, tests disent 2. Aligner TC-NOM-09 ou le plan §2ter.
3. DIV-12 (Gate 8 multi-projet) / ZO-12 : PD-299 livre app + ia-governance, la spec ne couvre pas ce cas. Gap conceptuel à trancher avant step 6b.
4. DIV-04 (scope module vs projet) : interprétation structurante, rate 8 cascade sur plusieurs invariants.
5. DIV-05, DIV-07, DIV-09 : extensions de schéma/contraintes (ratification_ref obligatoire, unicité PO/LEGAL, NFKC) non ratifiées et non couvertes par tests. Gaps de test à compléter en parallèle de la ratification.

Points de rework documentaire (à traiter en Gate 5 au plus tard)¶

1. DIV-01 / DIV-03 / DIV-02 : corriger la spec (§5.1 / §5.2 / D-299-07) pour lever les contradictions internes et aligner avec le plan.
2. DIV-08 / DIV-10 : formaliser dans la spec la dépendance API Atlassian runtime et l'usage traceability_only.
3. ZO-08, ZO-09, ZO-10 : ratifier explicitement les questions ouvertes Q-299-01/05/06.

Points de test à compléter¶

1. DIV-05, DIV-07, DIV-09, ZO-06, ZO-11 : ajouter 5 cas de test (TC-ERR supplémentaires) couvrant RATIFIED sans ratification_ref, unicité PO/LEGAL, homoglyphes/NFKC, case sensitivity endpoints, et branche else du cap score.

Points informatifs (pas bloquants)¶

• DIV-12 (netinfo null), ZO-01 (Detox), ZO-02 / ZO-03 / ZO-04 : à documenter mais pas bloquants pour Gate 5.

Conclusion orchestrateur : la convergence structurelle est forte (18 invariants mappés, FSM alignée, couverture de test dense) mais la dette d'ambiguïté spec/plan est substantielle. Le plan l'a rendue visible via les DEC-, ce qui facilite l'arbitrage PMO, mais **tous les DEC- doivent être formellement ratifiés** en Gate 5 pour éviter une contestation en Gate 8. Les DIV-06 et DIV-11/DIV-12 sont les plus critiques (auto-récursivité et multi-projet).