Conformité relue et limites de réalisation

Objet

Ce document définit la vue descendante TEC / VER vers les preuves de réalisation dans les dépôts produit. Il ne crée aucune prescription : les sources normatives restent les chapitres techniques et la matrice générée.

État de suivi

Les prescriptions et obligations publiées sont suivies lorsqu’une preuve de réalisation a été inspectée. L’absence de ligne ne vaut ni conformité ni non-conformité : elle signifie que la réalisation n’a pas encore été évaluée dans ce registre.

Les références de réalisation seront ajoutées au fil des traductions techniques. Une référence vers un ADR, un test, une procédure ou du code est informative : elle prouve un état observé sans devenir la source de la prescription.

Séquençage à reprendre dans le plan d’action et d’implémentation

Cette vue reprend DEC-0060 et DEC-0061 ; elle ne crée pas de tickets, de calendrier ni de preuve de réalisation. Les responsables et jalons précis sont à affecter dans le plan.

Ces reports ne suppriment pas les preuves obligatoires à un jalon déjà prescrit et ne reportent pas la sûreté des reprises de jobs ou des effets obligatoires.

Exception DEC-0248 : convertQuotation requiert réalisation et qualification du contrat commun dès le Lot 0, registre propriétaire Sales, selon TEC-INT-006 et le contrat Sales. VER-OPS-015 et VER-FCT-026 sont des prérequis de livraison ciblée ; la passe générale reste différée pour les autres commandes. Paramètres de clé, empreinte et conservation à qualifier ; aucune activation ni recette produit acquise.

Format cible

Écarts observés pour TEC-ARC-003

• La frontière in-process Referential/PublicApi et les DTO publics existent.
• ReferentialLookup utilise encore une interface, une implémentation et un binding sans seconde implémentation documentée ; leur simplification doit être instruite lors de la prochaine évolution substantielle.
• ReferentialEntityExists résout encore ReferentialLookup via le conteneur au lieu d’une injection explicite.
• NeighborModelBoundaryTest refuse actuellement tous les modèles Eloquent voisins ; cette protection conservatrice doit évoluer pour autoriser uniquement les modèles marqués par TEC-ARC-004. PhpModuleDependencyGateTest refuse les dépendances absentes du manifeste.
• composer check exécute Pint, PHPStan/Larastan et PHPUnit, mais les preuves relues ne refusent pas encore tous les namespaces internes hors PublicApi, le service locator, les types ORM exposés ou les cycles, et ne couvrent donc qu’une partie de VER-FCT-006.

État de TEC-ARC-004

• phpstan.neon.dist exécute actuellement PHPStan au niveau 5 avec baseline, contre le niveau 8 global et le niveau 9 sans baseline prescrits sur les frontières.
• Le dépôt ne contient pas encore l’attribut CrossModuleReadable, de fournisseur public de Builder<PublishedModel>, d’allowlist d’opérations de lecture ou de règle interdisant les mutations et échappatoires de VER-FCT-009.
• L’implémentation stricte existante bloque donc aussi le nouveau cas conforme et ne démontre pas les jointures, agrégations, having et paginations intermodules autorisées.

État de TEC-DAT-002

La revue du dépôt elena confirme la convention machine-lisible prescrite : ReferentialImportOrchestrator est déclaré sous le chemin attendu, porte le marqueur et l’attribut requis, et son graphe archivé est recalculé contre le code réel. Les scénarios de mutation du contrôle de graphe couvrent notamment les marqueurs et attributs absents, les participants ou ordres invalides, les orchestrateurs imbriqués et les cycles de précédence.

La preuve PostgreSQL jetable npm run e2e:pgsql a été rejouée le 2026-09-02 sur dev : 117 tests et 787 assertions passent, puis le projet isolé elena-e2e-976 est retiré. Elle exerce le rollback atomique de l’effet Referential et du verdict DWT, la reprise idempotente, le graphe d’orchestration et la gouvernance des FK interschémas. Les commits 7af11ce5, b2e4ee15 et 7d28d2b7 sont tous ancêtres de origin/dev ; le reçu versionné docs/architecture/receipts/ELENA-906.json identifie les critères VER-FCT-007 et VER-FCT-008 et ne déclare aucun écart.

État de TEC-DAT-006

• Les migrations et le générateur de module observés suivent déjà une pratique up() sans down() obligatoire ; ModuleStubGenerationTest vérifie explicitement cette convention.
• DisposableDatabaseGuard protège les tests contre l’utilisation d’une base non déclarée jetable. Cette preuve ne constitue pas encore la porte générale exigée avant toute reconstruction destructive de préproduction.
• Le provisioning PostgreSQL est versionné dans database/schema/01-provision-core.sql et deploy/postgres/bootstrap.sql, mais ces scripts créent aussi des objets susceptibles d’être présents dans un dump natif PostgreSQL ; ils devront être partitionnés sans chevauchement avant la baseline.
• Aucun schema dump Laravel de baseline, manifeste de régime, preuve d’activation irréversible ni test complet de VER-FCT-013 n’a été trouvé lors de la revue. La réalisation est donc partielle.

États autorisés : non-évalué, conforme, partiel, non-conforme, non-applicable.

Règles

• Toute ligne référence une TEC et une VER existantes.
• conforme exige une preuve exécutable ou relue et une date ISO.
• Un écart ne modifie pas silencieusement le CDC : il entraîne soit un correctif produit, soit une décision modifiant la prescription.
• Les preuves sensibles ou credentials ne sont jamais copiés dans le CDC.