fixage du parcourt boostrap jusqaua la config du domain

[Dubrelh]

Description

Cette PR corrige le flux d’onboarding et la configuration du domaine dans l’UI Web. Après bootstrap, le compte owner est désormais connecté automatiquement. Si l’utilisateur n’a pas encore activé la MFA, il est redirigé vers une page d’activation MFA avant de pouvoir accéder à /setup-domain. La page de configuration de domaine affiche maintenant correctement l’état MFA et bloque l’enregistrement tant que la MFA n’est pas activée.

Type de changement

• Correction de bug
• Nouvelle fonctionnalité
• Refactoring (aucun changement de comportement)
• Documentation
• Autre

Package(s) concerné(s)

• api
• web
• shared
• infra / workflows

Comment ça a été testé ?

• npm run --workspace @hullbay/web typecheck via WSL
• Vérification manuelle du flux :
  • bootstrap owner
  • redirection automatique vers login
  • activation MFA via page dédiée
  • accès à /setup-domain après activation MFA
  • blocage de la configuration de domaine tant que la MFA n’est pas activée

Checklist avant de demander une revue

• J'ai testé mes changements localement
• npm run typecheck passe sans erreur
• npm run test passe sans erreur
• J'ai mis à jour la documentation si nécessaire
• Aucun secret ou donnée sensible n'est inclus dans cette PR

Notes complémentaires

Ajout d’une nouvelle page ActivateMfaPage pour centraliser l’enrôlement et la confirmation MFA.

Closes #33

[bright77777]

Avant de l'approuver, peux-tu appliquer les corrections et améliorations listées ci‑dessous ?

1. Secret exposé — packagesapi.env

• Le fichier packagesapi.env contient des secrets (JWT_SECRET, MFA_ENCRYPTION_KEY). Ne laisse pas de clés réelles dans le dépôt.
  Actions demandées :
  • Retire immédiatement packagesapi.env du commit (git rm --cached si utile).
  • Ajoute packagesapi.env à .gitignore.
  • Ajoute à la place un packagesapi.env.example avec des placeholders (EXAMPLE_JWT_SECRET=replace_me).
  • Si ces clés ont été publiées publiquement, considère-les compromises et rotate-les (JWT_SECRET, MFA_ENCRYPTION_KEY).

2. Réactivité des boutons / état des mutations (React Query)

• Dans packages/web/src/pages/SettingsPage.tsx, SetupDomainPage.tsx (et partout où utilisé) tu relies sur isPending / status === "pending". Avec React Query v4 il faut utiliser isLoading / status === "loading(les valeurs"pending"/isPending` ne sont pas standard et risquent d'empêcher le disabling/feedback correct).
  Actions demandées :
  • Remplace les checks isPending / "pending" par isLoading ou status === "loading".
  • Vérifie que tous les boutons passent bien en disabled/isLoading pendant l'appel réseau.
  • Ajoute un test manuel rapide (ou unit) qui simule une mutation longue pour valider l'UI.

3. Déconnexion sur erreur réseau (App.tsx / DomainGate)

• DomainGate fait if (meError) { auth.clear(); navigate("/login") }. Ça va déconnecter l'utilisateur sur toute erreur (même une 500 ou coupure réseau).
  Actions demandées :
  • Ne clear/auth que pour des erreurs d'authentification explicites (401/403) ou pour un code d'erreur API structuré.
  • Si l'API ne renvoie pas le statut HTTP dans useMe, modifie api.me() pour rejeter avec un objet d'erreur structuré (ex: { status: 401, code: 'unauthorized' }) afin que DomainGate puisse réagir correctement.
  • Évite le logout automatique sur erreurs transitoires.

4. Vérification d'erreur MFA côté client (SetupDomainPage)

• Le code onError teste le message d'erreur texte : message.includes("mfa"). Le matching textuel est fragile.
  Actions demandées :
  • Faire remonter depuis l'API un code d'erreur structuré (ex: { code: "mfa_required" }) ou vérifier le status HTTP.
  • Adapter le front pour utiliser ce code/status au lieu du texte.

5. Choses mineures/UX & housekeeping

• Large changement de package-lock.json : si ce n'est pas intentionnel, sépare la mise à jour des dépendances dans un PR dédié.
• Regex de validation de domaine : la regex utilise des constructions avancées (lookbehind). Privilégie une validation plus robuste ou centralisée et ajoute des tests unitaires pour les cas limites.
• Redirections via window.location.href/assign (après changement de domaine) sont correctes si tu veux forcer un reload complet — indique le en commentaire si c'est intentionnel.

6. CI / tests

• Lance npm run test/CI et joins le résultat ou corrige les tests qui échouent avant merger.

Si tu veux je peux :

• préparer le commit qui retire packagesapi.env, ajoute .env.example et met à jour .gitignore,
• et te proposer un patch concret pour remplacer isPending/"pending" par isLoading/"loading" dans les fichiers touchés.

[Dubrelh]

D'accord je m'y met...

[bright77777]

packagesapi.env — Remplacer le commit par un .env.example (sans valeurs secrètes) ; supprimer le fichier sensible du repo et ajouter une entrée .gitignore. Si les secrets ont été poussés publiquement, planifier une rotation.
packages/web/src/App.tsx — Adjust DomainGate to explicitly allow these paths: ['/login','/bootstrap','/activate-mfa','/setup-domain'] as exceptions (or compute via a white-list). Cela évite boucles et autorise onboarding/public pages avant auth.
packages/web/src/pages/SetupDomainPage.tsx — Remplacer la détection d'erreur par inspection du status code : si error.status === 401/403 => toast spécifique "MFA non activée" + navigate('/activate-mfa'). Si le client API n'expose pas status, faire en sorte que req() renvoie un objet erreur standardisé.
packages/web/src/lib/useMe.tsx — Revoir refetchOnWindowFocus / refetchOnMount si les coûts réseau sont importants ; envisager staleTime raisonnable (p.ex. 5s-30s) plutôt que always.
packages/web/src/{SetupDomainPage.tsx,SettingsPage.tsx} — Factoriser la regex de validation du domaine dans un util exporté (ex: packages/web/src/lib/validation.ts) et réutiliser pour éviter duplication et erreurs futures.