20 août 2026 — Migration physique v1.1 CANDIDAT fermée

<aside> ✅

CON-18 est maintenant physiquement aligné sur le candidat v1.1 et reste en sommeil contrôlé. Cette migration ne prouve aucun build VR et ne modifie pas le Golden Template.

</aside>

<aside> 🛸

18 août 2026 — rattachement USS Frequencies créé. CON-18 est désormais surveillé comme VSR-44 — MOTEUR MÉTAVERS / VR — XR, 3D, accessibilité & expériences immersives dans le PMO USS, sans créer de nouvelle maison projet ni de scheduler GPT parallèle.

PMO USS : parent VSR-44 item 3169667096 ; SSR-44.1 3169685747 ; SSR-44.2 3169633172 ; SSR-44.3 3169670005 ; SSR-44.4 3169702094 ; SSR-44.5 3169669745 ; SSR-44.6 3169661402.

Flightplan : FP-MOTEUR-METAVERSE-560 item 3169668647, puis 561 3169667412, 562 3169667485, 563 3169654188, 564 3169686794, 565 3169670631, 566 3169668474.

État initial : sommeil contrôlé, score VSR de référence 37,5 % selon gates A–F ; 44.1, 44.2 et 44.6 documentés ; 44.3→44.5 bloqués tant qu’il n’existe ni source/runtime reproductible, ni droits/QA suffisants, ni pilote réel.

Planification GPT : aucune Task GPT supplémentaire. Le scheduler unique USS Frequencies découvre automatiquement VSR-44 dans le PMO/Flightplan et ne l’exécute qu’en présence d’un delta ou d’une condition de réveil. Sans signal : METAVERSE_NO_CHANGE et silence.

</aside>

<aside> 🌙

18 août 2026 — cycle Moteur Métavers / VR poussé jusqu’au palier prouvable puis remis en sommeil contrôlé. La branche conversationnelle d’absorption / réconciliation est fermée à 100 % : doctrine V1→V5 absorbée dans CON-18, collision projet évitée, routage canonique confirmé et anomalie Airtable réconciliée. Le PMO CON-18 contient désormais 6 éléments Fait, 10 Bloqués, 0 En cours : cela représente 37,5 % des éléments PMO fermés, et non 37,5 % d’un produit VR terminé.

Réconciliation DATA-016 : les 93 lignes de METAVERSE-001-01 sont un corpus de ressourcerie / migration Umbrella 3D et assistance : 79 UMB-3D tous À qualifier, 8 sources À vérifier, 3 licences À vérifier, 3 revues de provenance À faire. Aucune de ces lignes ne constitue à elle seule un livrable ou build CON-18 prouvé. CON-18-DATA-016 est fermé.

ENG-015 : le scaffold V5 est conservé comme doctrine / architecture, mais reste bloqué faute de source canonique, dépôt, build, runtime et tests reproductibles. Aucun faux source V5 n’est reconstruit pour artificiellement fermer ce gate.

Restes explicites au réveil : récupérer un source/repo V5 réel ou décider une reconstruction V6 ; récupérer au moins un vrai livrable VR/3D des jeunes ; identifier auteur, droits et licences ; tester un .glb sur copie ; obtenir/tester un build VR privé ; puis seulement cadrer la vertical slice accessible et une éventuelle publication.

Conditions de réveil : réception d’un source/build réel, nouveau pointeur fiable vers un livrable, équipe/cohorte + encadrement technique confirmés, ou décision explicite de reconstruire V6 depuis la spécification. Le pourcentage global Frequencies n’est pas modifié par ce cycle.

</aside>

<aside> ⚠️

18 août 2026 — anomalie Airtable détectée et actionnée. Le readback live contredit l’ancien état documentaire « tables métier à 0 ligne » : METAVERSE-001-01 contient actuellement 79 Assets 3D & XR + 8 Sources + 3 Licences + 3 Validations & revues = 93 enregistrements. Une action PMO dédiée a été créée : CON-18-DATA-016. Objectif : séparer le corpus Umbrella / ressourcerie des livrables réellement propres à CON-18, qualifier provenance/licence et ne promouvoir que les preuves validées. Pas de nouvel import avant cette réconciliation.

</aside>

<aside> 🧠

18 août 2026 — absorption de la conversation “Moteur Métavers / VR” dans CON-18, sans création d’un projet bis. L’audit croisé Notion / Drive / Monday confirme que la maison canonique existe déjà et que la fédération CON-18 est le bon propriétaire. Le lot Modèle 3D/Metavers-VR de PROJ-ETU-000, les briefs Factory XR et les occurrences TGS restent des contributeurs / consommateurs, pas des propriétaires concurrents.

Delta réellement apporté par la conversation : une architecture d’authoring XR progressive V1→V5 : registre d’assets et scènes, profils d’accessibilité, export metaverse-spec.v1, Undo/Redo, persistance locale, validation licences/accessibilité, éditeur de transforms, runtime hints, QA confort VR, plugins d’export, snapshots, batch ops, taxonomie et placeholders de collaboration.

Garde-fou de preuve : ces versions sont des prototypes de code conversationnels / scaffolds frontend. Elles ne prouvent encore ni build exécutable, ni runtime WebXR/Unity/Unreal, ni tests, ni dépôt technique canonique, ni collaboration temps réel, ni mesure LUFS réelle. La V4 n’a pas été matérialisée : la conversation est passée de V3 à V5 ; ne pas inventer une V4 rétroactive sauf besoin explicite de traçabilité de version.

Routage canonique : Notion conserve cette doctrine et le relais ; Monday porte l’action de récupération/persistance/validation du scaffold V5 via CON-18-ENG-015 ; Drive conserve déjà les sources, briefs et futurs livrables ; Airtable reste inchangé tant qu’aucune donnée métier XR structurée et prouvée n’est produite. Aucune nouvelle base Airtable ni nouveau projet Métavers ne sont créés par défaut. Le sous-run transverse VSR-44 — MOTEUR MÉTAVERS / VR est désormais l’unique branche USS de veille/réveil de CON-18, sans créer de second propriétaire métier ni de scheduler parallèle.

Condition de réveil technique additionnelle : récupération du source V5 depuis son support conversationnel, dépôt dans une autorité technique validée ou dans 00_Cadrage-Documentation comme snapshot de preuve, puis build/test minimal. Ce delta ne modifie pas artificiellement le pourcentage global Frequencies ni l’état métier de CON-18.

</aside>

<aside> 🔥

RELAIS — BRASSART / CONCEPTION MÉTAVERS — 16 août 2026 — préactivation pédagogique, cœur CON-18 maintenu en sommeil contrôlé. L’échange Brassart apporte un besoin suffisamment concret pour enrichir le design, mais ne prouve encore ni équipe affectée, ni moteur, ni build, ni calendrier de production. La maison projet reste CON-18 ; aucun projet Métavers bis n’est créé.

Principe produit confirmé : l’expérience doit être pensée dès le noyau pour voyants, personnes malvoyantes et personnes non-voyantes, avec équivalents multimodaux plutôt qu’une couche d’accessibilité ajoutée après coup : audio spatial et repères auditifs, narration/rejeu, haptique, contrastes et lisibilité, confort VR, interactions simples et alternatives lorsque possible.

Première Training Room — « Feu de camp / Golden Hour » : espace d’initiation très orienté gameplay, destiné aussi bien aux jeunes qu’aux personnes âgées découvrant la VR. Le joueur apprend progressivement déplacement, orientation, saisie et interaction dans un camp calme. La fin du parcours est matérialisée par une action diégétique : prendre une bûche et la déposer dans le feu pour empêcher son extinction ; cette action déclenche la transition vers le monde suivant. Au premier passage, l’indication finale n’arrive qu’après apprentissage ; un joueur déjà formé doit pouvoir aller directement à la bûche et au feu.

Garde-fou technique — réinstallation : un simple booléen local Tutoriel terminé permet le skip aux lancements suivants mais est normalement perdu lors d’une désinstallation. Pour conserver ce choix après désinstallation/réinstallation, il faudra décider d’un mécanisme persistant hors installation locale — compte/cloud, sauvegarde plateforme ou équivalent — et traiter consentement/données/synchronisation. Ne pas promettre cette persistance tant que l’architecture n’est pas choisie.

Espaces de destination déjà proposés : Réminiscence = lieu perdu hors de la causalité / science-fiction ; Chroniques Sombres = salle d’archives inquiétante ; Plage sonore = espace assis de détente et d’écoute d’ambiances, envisagé notamment pour EHPAD/maisons de retraite. Pour ce dernier usage, prévoir séances courtes, mode assis, confort/mal des transports, hygiène du matériel, accompagnement humain et formulation non médicale tant qu’aucune évaluation clinique n’existe.

Serious game / handicap : explorer des jeux accessibles ou construits autour du handicap, mais privilégier la co-conception avec les personnes concernées et les mécaniques inclusives à une simulation simpliste prétendant reproduire « ce que vit » une personne aveugle ou handicapée. La sensibilisation doit montrer des choix de design, des obstacles et des stratégies, pas fabriquer une empathie de façade.

Références : les jeux Naughty Dog cités dans la conversation servent de piste pour l’accessibilité ; avant intégration au cahier externe, vérifier précisément les fonctions et le titre de référence (The Last of Us Part I / The Last of Us Part II Remastered). Les références VR d’onboarding et seniors devront également être sourcées avant publication.

Condition de réveil complet de CON-18 : validation institutionnelle Brassart, équipe/encadrement désignés, brief V0 accepté ou livraison réelle. D’ici là, cette branche reste une préactivation de conception, sans changement artificiel de pourcentage global.

</aside>

<aside> 🌙

Maison projet numérique — Réalité virtuelle / Metaverse (CON-18). Le projet est en sommeil contrôlé : vision, documentation, PMO, Drive, cadastre et ressourcerie sont structurés. Les livrables binaires réels des jeunes restent à retrouver ; leur réception constitue un déclencheur de réveil.

</aside>

1 — Identité & état