# MOLT — frontend prêt à intégrer

Le projet part de zéro : aucun token déployé, aucune donnée de marché, un backend en pré-lancement et aucune règle de vote publique définitive. Le site ne fabrique aucun de ces éléments. La sculpture est une animation décorative ; elle ne représente pas une donnée on-chain.

## Lancer et livrer

Node 22+ recommandé. Depuis ce dossier :

```sh
npm ci
npm run check
python3 -m http.server 8770 --bind 127.0.0.1 --directory dist
```

Ouvrir http://127.0.0.1:8770/. Publier **uniquement `dist/`**, jamais `node_modules/` ni les tests. Les fichiers compilés sont fournis ; aucune compilation côté visiteur. La prévisualisation historique à la racine fonctionne aussi.

- `docs.html` : documentation publique du concept, du cycle et des fonctionnalités prévues.
- `index.html` : landing immersive, présentation courte du concept, état réel du service et exploration visuelle.
- `src/app.js` : interface, Wallet Standard, actualisation, soumission de vote.
- `src/data.js` : validation des réponses, horloge, client HTTP, message de vote canonique.
- `src/visual.js` : animation chargée séparément. Une panne WebGL ne bloque pas les données.
- `config.json` : configuration publique, aucun secret.
- `API.md` : endpoints implémentés, administration SSH et limites du mode de répétition.
- `_headers` : en-têtes pour hébergeurs compatibles (à transposer sur Nginx/autres).

`npm run build` doit être exécuté après une modification des sources. Les dépendances sont verrouillées ; Three.js et Wallet Standard sont servis localement. Le fond lumineux est dessiné localement sur canvas, sans vidéo distante. Les polices Google restent distantes, avec polices de secours.

## Brancher le service

En production, `GET /config.json` est servi par le backend : `/api/v1` est connecté, mais le réseau et le mint restent nuls avant lancement. Le fichier local reste une configuration d’aperçu statique. Ne pas ouvrir les votes en modifiant seulement ce fichier ; voir `API.md` pour la répétition isolée et les prérequis de lancement.

Les lectures ont un délai maximal de 10 secondes. Rafraîchissement toutes les 15 secondes, recul jusqu'à 60 secondes en cas d'échec, arrêt en arrière-plan. Données périmées ou erreur : votes bloqués. La sélection d'un candidat ne remplace pas l'identité courante. Les pourcentages sont calculés à partir des totaux validés ; zéro vote donne « — ». Le compte à rebours se base sur l'heure serveur et une horloge monotone locale.

Wallet Standard découvre les wallets installés. Connexion et déconnexion fonctionnent indépendamment du backend. Le navigateur intégré peut ne disposer d'aucune extension. Le vote utilise un message signé explicite, sans transaction ni transfert ; seuls les wallets renvoyant les octets demandés sont acceptés. La confirmation signifie acceptation par le **serveur**, pas une transaction on-chain.

## Ce qui reste nécessaire avant production

1. Créer le token et décider du modèle de métadonnées/autorités de mise à jour.
2. Définir les règles publiques et raccorder un snapshot vérifié des holders au moteur de vote existant.
3. Définir l'éligibilité des holders, le poids des votes, le snapshot des balances, la gestion des doublons et des égalités. Aucune règle financière n'est arbitrairement choisie dans ce frontend.
4. Construire la collecte des tendances, la modération, la génération de branding et le job de finalisation des rounds. Les changements d'urgence nécessitent des règles explicites et un journal d'audit.
5. Valider sur devnet le parcours complet avec un wallet réel, puis configurer HTTPS, les en-têtes, supervision, limitation des requêtes et sauvegardes.

Les tests unitaires portent sur validation, incohérences, expiration, contenu signé et erreurs HTTP. Ils utilisent des fixtures isolées qui ne sont pas distribuées. Aucun vote réel ni connexion à un wallet personnel n'a été effectué pendant cette préparation. Ce livrable est une base d'intégration, pas un service crypto lancé en production.

Références techniques : [Wallet Standard](https://github.com/wallet-standard/wallet-standard), [signature et vérification de messages Solana](https://solana.com/docs/frontend/messages-and-auth).


## Privy

Le bouton utilise maintenant `@privy-io/react-auth` avec l’app publique `cmw628yn601bv0gjvj6uojvmv`. `src/privy.jsx` monte un composant React isolé : modal Privy, session, choix du wallet et déconnexion. Le reste du site demeure en HTML/CSS/JS. Les wallets Solana sont exposés via `useStandardWallets` pour conserver le protocole de signature du vote. Une connexion email peut créer un wallet Solana intégré selon la configuration du fournisseur.

Le secret d’app n’est ni nécessaire ni inclus. Configurer les origines locales et le domaine de production dans les domaines autorisés du tableau de bord Privy. HTTPS est nécessaire en production. Les méthodes email/wallet doivent être activées dans l’application. La CSP fournie autorise les services de connexion Privy et leurs iframes ; vérifier les flux sur l’hébergeur cible. Ne pas utiliser une session client comme preuve d’éligibilité : le serveur vérifie les signatures ; les règles publiques et les snapshots on-chain restent à définir et à raccorder.

Vérification réalisée : initialisation de l’app réelle et ouverture de la fenêtre Privy. Aucun email envoyé, compte créé, wallet personnel connecté ou message signé pendant le test. Le parcours authentifié (création du wallet, changement de compte, déconnexion) reste à valider avec un compte de test autorisé.

L’audit npm signale des vulnérabilités transitives dans la chaîne de dépendances du SDK (notamment Zod, WalletConnect et leurs dépendances). Les correctifs compatibles automatiques ont été appliqués ; ne pas considérer le lancement public comme validé sans résolution/revue de cet audit. Aucun downgrade majeur automatique du SDK n’a été appliqué.

Références : https://docs.privy.io/basics/react/setup et https://docs.privy.io/security/implementation-guide/content-security-policy