État du projet et liens entre composants au 6 novembre 2026

Périmètre et preuves

Ce document décrit le point de retour beta-2026-11-06, créé après fusion des six PR ouvertes, avant les changements envisagés pour une V1 sans invitation. Ce n'est ni l'annonce d'une bêta publique ni une certification de mise en production.

Trois niveaux restent distincts :

• Source figée : fichiers au tag et commits du manifeste.
• Observation live du 6 novembre : contrôles anonymes HTTPS et inventaire Docker en lecture seule.
• Historique / intention : décisions et anciens guides, qui ne prouvent pas un déploiement.

Aucun compte, collection, secret, migration ou paramètre serveur n'a été modifié pour ce relevé. Les données personnelles et configurations privées sont exclues. Ce n'est pas un audit exhaustif du cluster Kubernetes.

Inventaire immuable

Les 14 dépôts non vides ont un tag et une prerelease du même nom. agent-sandbox est vide. Les branches main de snag-data et snag-gitops ont été conservées.

Repository	Role	Branch	Commit
snag-data	Collect, normalize, match, publish catalogue/prices	main	d16bfe972818e9f110fca7cb43bdc5470c88a0a2
agent-workflows	Shared engineering workflows	staging	b3b4903a8996a8ecb1fc100ad1dcde55aa06abcd
design	Design handoff, themes, Penpot	staging	cb7bf188fa2dd5ca1e6e797a9478705fbb218953
admin-frontend	Staff console, authorized SQL, catalogue/media	staging	1f8803de98b13df94b2b7dad160205fd2ad9c9a2
snag-gitops	Kubernetes, image overlays, ArgoCD	main	3692d654a49b06ef5ca0573fcec4d524f084d0de
tcg-collector-backend	API, identity, catalogue, pricing, collection, scan	staging	ea4580781516cc7c370ac94aefef7d9b71f53d9b
documentation	VitePress guides and change tracking	staging	5bc276b82d77c14450c4628168c5e235135201ff
poc-tcg-collector	Mobile React Native / Expo	staging	42189afcba12923df4e0d1966f0827dfbb0de717
tg-bridge-ts	TypeScript bridge tooling	staging	cbcc46487f88909553f7458aa16823a09ac92a33
tg-bridge-py	Python bridge tooling	staging	694b813b73b7b87cb338b11ae52ab5ceed315010
snag-landing	Public landing site	staging	fbf8247fe0a765cf445a019334be9e280af953d7
test	Test repository; runtime not audited	staging	17c6f0271026bfeed28875cc463345f03c2f42fd
routines	Auxiliary automations; runtime not audited	staging	e5eb124c2a8877e95056038ff8d4f8ec19fa62de
tg-bridge-go	Go bridge tooling	staging	11a1bbe7c04e208553725bddfd0fccde2a92e8ce

Manifeste JSON · Release Documentation.

Cette page est postérieure au tag : elle l'explique sans le déplacer. Le commit Documentation du manifeste désigne donc l'état avant l'ajout de cette page.

Carte des liaisons

App iOS/Android -> HTTPS /api -> API Fastify
                                  -> PostgreSQL : comptes, sessions, catalogue, collection
                                  -> Redis : cache des prix
                                  -> reconnaissance / embeddings
                                  -> catalogue-media : validation et accès aux images
App -> navigateur système -> fournisseur OAuth annoncé par l'API
                             -> callback HTTPS backend -> retour Snag
                             -> finalisation de session

Admin -> fonctions SQL autorisées / PostgreSQL
      -> S3 : médias
      -> service de test scan
      -> API : certaines références publiques
      -> documentation, GitHub et observabilité

Sources -> snag-data -> bronze/raw -> silver -> gold
                                           -> publication PostgreSQL / médias
GitHub -> tests/builds -> registre -> snag-gitops -> ArgoCD
Production Docker : chemin distinct encore observé

Cette carte décrit les responsabilités et transports, sans garantir que chaque job/source soit activé. Elle ne prouve pas une migration intégrale de Docker vers Kubernetes.

Application et autorité backend

Le mobile utilise le backend HTTPS partagé, y compris dans l'émulateur. backendConfig.ts définit /api, les routes de scan et /api/catalogue-media.

Le backend décide des règles métier : identité, admission, quotas, catalogue, classement, prix et mutations de collection. Les états d'interface, navigation, formulaires, caches et transport sécurisé de session restent locaux. Cette règle ne signifie pas que toute logique historique du client a déjà été migrée.

Invitation, sessions et connexion

• GET /api/auth/beta/status contrôle l'entrée.
• POST /api/auth/beta/validate vérifie sans réserver ni consommer le code.
• Admission et authentification sont distinctes. Le parcours bêta prévoit invitation puis inscription email ou Apple. L'inscription directe bêta évite le code email initial ; la récupération de mot de passe reste séparée.
• L'admission est persistante au niveau du compte. Une reconnexion au même compte admis restaure l'accès après réinstallation sans réutiliser un code à usage unique.
• Les admissions historiques, isBeta et les droits illimités de l'équipe sont distincts. isBeta active les scans illimités, mais la réciproque est fausse.
• Les métadonnées email de distribution admin ne constituent pas une preuve de correspondance avec l'identité Apple.
• Le relevé opérateur du 4 novembre avait constaté l'absence des colonnes destinataire dans la table live d'invitations. Le schéma n'a pas été réaudité aujourd'hui : ne pas supposer la migration appliquée.

Sources : contrat backend, garde mobile, émission des invitations.

OAuth et callbacks

Le backend annonce les fournisseurs via /api/auth/oauth/providers, crée le flux, échange les codes et vérifie les jetons. Secrets et configuration fournisseur restent serveur. Un compte Apple/Google ne reçoit pas automatiquement un mot de passe Snag ; la connexion email classique est conservée.

Le callback fournisseur HTTPS est distinct du lien de retour vers l'app. Les chemins documentés sont /auth/oauth/google/callback (GET) et /auth/oauth/apple/callback (POST). Le proxy doit les router exactement, indépendamment du préfixe /api des appels mobiles. Les URI enregistrées, l'origine et la validité des secrets doivent être contrôlées dans l'inventaire opérateur protégé.

OAuth au tag · Apple / EAS · TestFlight.

Certaines introductions OAuth parlent encore de leur PR initiale comme non déployée : elles ne mesurent pas l'état actuel. L'annonce du fournisseur Apple ne prouve pas une connexion de bout en bout réussie.

Scan et collection

La table URL mobile figée contient /scan-lab (défaut), /scan, /scan-frame et /scan-sealed-lab. Une route présente ne signifie pas que le mode est proposé dans chaque build. Les modes historiques compat et tormknd ne sont plus résolus par cette table pour les captures normales.

Caméra/galerie, préparation prévue et envoi précèdent l'identification backend. Les candidats, identifiants, métadonnées et visuels retournés alimentent l'affichage. Les ajouts utilisent des commandes authentifiées. Le bulk est un état de travail avant validation, pas une preuve de sauvegarde serveur.

Une collection peut contenir plusieurs achats du même produit à des prix différents. L'agrégation visuelle ne doit pas effacer les achats distincts. Prix d'achat et cours actuel sont séparés. Suppression de compte et effacement du cache ne sont pas des opérations de rollback logiciel. Voir suppression de compte.

Catalogue, identifiants et assets

Les identifiants catalogue relient scan, collection, prix et médias. Ne pas identifier une variante One Piece par son seul numéro imprimé ni remplacer l'identifiant par le nom affiché.

Pour les scellés, ancien tag/nom et chemin source restent conservés ; nouveau label et sous-titre sont fournis par le backend. Les modèles de familles et exceptions du référentiel pilotent les noms. L'exemple Mini Tin ne justifie pas un remplacement global sans contrôle. Les Mini Tins réservées restent hors modification sans arbitrage explicite.

Les sources et leur provenance sont déposées en bronze/raw, puis traitées vers silver/gold. Dépôt S3, publication gold, association de média et serving public sont quatre étapes distinctes à vérifier. Une image présente dans le stockage ne prouve pas que l'app la reçoit.

Le fruit P est le logo du bloc Promos One Piece ; le bandeau PROMOS est celui de la série. Leurs tailles et variantes clair/sombre sont distinctes. Les marges transparentes nécessitent un cadrage adapté. Les corrections au tag ne prouvent pas que ce build est installé sur chaque iPhone.

Sources : route média, inventaire data, sécurité API/assets.

Prix et caches

Le cache Redis des prix est conservé. Les caches mobiles sont des copies de réponses serveur, pas une autre autorité de valorisation. Image et prix ont des chargements indépendants. Un prix absent ne devient pas zéro ; une requête en cours ne signifie pas « cote absente ».

Le retour sur des lignes déjà consultées doit réutiliser les ressources disponibles sans réinitialisation visuelle inutile. Cela ne garantit ni cache illimité ni catalogue intégralement hors ligne. Expiration, erreurs et rafraîchissement restent nécessaires.

L'évolution du portefeuille sur 24 h nécessite un historique suffisant sur les positions concernées. Une fonctionnalité fusionnée ne prouve pas une couverture réelle complète des cartes, scellés et gradées.

Redis · priceCache.ts.

Admin et pipeline de données

L'admin a ses propres autorisations opérateur. Plusieurs fonctions utilisent directement du SQL contrôlé, d'autres S3, le service de test scan ou l'API de référence publique. Ce n'est pas simplement un client de toutes les routes privées mobiles.

snag-data collecte, normalise et rapproche les identifiants avant publication. Provenance et décisions experts doivent survivre aux publications. Les PR #19 et #20 ajoutent les textes des cartes et un benchmark expérimental d'amélioration d'images. Leur fusion n'a lancé ni publication gold ni remplacement d'illustrations.

Admin données · Admin sécurité · Pipeline data.

CI, builds et déploiements

Expo/EAS produit les builds natifs. Le eas.json figé contient simulator, development, preview, production et apk. Une release GitHub n'est pas un build EAS, une soumission Apple ou une installation TestFlight.

Le flux GitOps prévu est GitHub Actions sur runners cluster, build, registre, modification d'overlay, synchronisation ArgoCD. Les workflows au tag prévalent sur les anciens paragraphes : backend et admin ne lancent plus leur workflow release sur push main ; staging reste actif. snag-data construit depuis main et vise son overlay staging.

Les six PR fusionnées sont admin #124, GitOps #21, data #19/#20, design #3 et agent-workflows #1. Le conflit documentaire data conserve les deux sections. Les changements data réunis ont passé Ruff et 919 tests, 7 ignorés, puis une seconde validation après résolution. Tests admin CI verts ; syntaxe Python/JavaScript design vérifiée, sans exécution Penpot.

Les builds d'image échouaient sur le runner faute de rootlesskit. Aucun déploiement manuel n'a été lancé pour les tags, mais les merges peuvent déclencher l'automatisation existante. Un tag ne prouve pas sa réussite.

CI/GitOps.

Observations live du 6 novembre

Lecture seule, sans authentification :

• /api/auth/beta/status : HTTP 200, required=true, admitted=false.
• /api/auth/oauth/providers : HTTP 200, apple seulement. Ce n'est pas une validation du secret Apple ou du retour dans l'app.
• /api/health : HTTP 401. Cela ne prouve pas une panne de l'API.

Inventaire Docker ciblé sur le VPS Snag :

• API : image skns-api:beta-0542cea, en cours d'exécution.
• Admin : image snag-catalogue-admin:open-beta-0084aff, déclarée healthy.
• PostgreSQL, Redis, vision et trois services d'embeddings présents avec contrôles healthy.
• Nginx, Caddy, Grafana, Loki et Alloy présents.
• Proxy privé admin déclaré unhealthy ; aucun redémarrage ni diagnostic approfondi effectué ici.
• Services de développement séparés également présents, à ne pas confondre avec la production.

Le code tagué et les images déployées diffèrent. Un nom d'image ne garantit pas son digest. Runtime Kubernetes, digests, sauvegardes actuelles et versions TestFlight n'ont pas été audités. Chemins privés et secrets restent hors du dépôt.

Retour arrière

1. Choisir entre le code du tag et la version réellement déployée. Lire le manifeste.

2. Préserver les modifications locales ; sauvegarder données/configurations avant une opération risquée.

3. Récupérer les tags nécessaires, sans déplacer les tags publiés ni forcer les branches partagées.

4. Vérifier schéma, migrations appliquées, assets externes et compatibilité API/mobile.

5. Reconstruire/déployer par le processus approuvé ; conserver l'image précédente.

6. Tester connexion email/Apple, refresh, catalogue, images, prix et collection avec un compte dédié, puis le statut du gate.

7. Consigner SHA, digest, build mobile, date et résultats. Ne pas supprimer les collections.

   git fetch origin tag beta-2026-11-06 git switch --detach beta-2026-11-06

Pour travailler depuis ce point :

git switch -c restore/beta-2026-11-06 beta-2026-11-06

Git ne sauvegarde pas la BDD, les secrets, les assets externes ou les binaires distribués. Un rollback de code ne renverse pas les migrations.

Transition V1 et limites des anciens guides

La V1 sans invitation est une intention, pas un changement effectué ici. Le retrait documenté est BETA_GATE_ENABLED=false côté serveur puis recréation autorisée de l'API et contrôle de required=false, inscription email et Apple. Ne pas effacer les admissions ou les tables. Quotas et droits illimités restent une décision séparée.

Les pages architecture de mai, anciens fan-outs scan et introductions OAuth décrivent des étapes historiques. Pour ce checkpoint, suivre le code au tag et les observations datées. « Présent dans le code », « fusionné », « construit », « déployé » et « testé sur appareil » sont différents.

Suivi des changements · Index par dépôt · Préparation production.

Les anciens effectifs du catalogue et nombres de blocages naming ne sont pas réaffirmés comme actuels.