Audit — navigation, entry points et decouvrabilite du dashboard

Etat du depot : branche claude/peaceful-maxwell-xf9lrf, 11 septembre 2026, fusionnee sur origin/main apres le merge de BoostEcom/boostecom.app#1030 (feat(app-shell): unify org/store/account navigation into one cockpit launcher, src/config/cockpit-nav.ts).

Perimetre : src/app/(dashboard) — le cockpit authentifie. Pas le site marketing (deja garde par nav-coverage.test.ts), pas l'admin plateforme (deja garde par admin-routes.ts + son propre registre).

Methode : lecture du code de navigation existant, puis derivation programmatique des liens entrants reels vers chaque page.tsx du dashboard (grep de tout href/push/redirect litteral ou en template, normalise et compare a chaque route). Chiffres verifies a la main pour chaque route citee ci-dessous.

Une session concurrente a resolu la majeure partie de cet audit pendant qu'il tournait

Cet audit et le travail qu'il a produit ont ete faits en parallele d'une autre session, qui a livre src/config/cockpit-nav.ts — un registre unique, gardee par src/test/cockpit-surfaces-are-reachable.test.ts, qui derive les vraies routes du disque et couvre la quasi-totalite des trous que cette page listait initialement : ~/agents, ~/memory, ~/deals, ~/disputes, ~/sponsor-placements, les six pages /account/*, et en plus les six Systems, Insights et le Studio d'une boutique (que cet audit n'avait pas couverts). Le meme commentaire mensonger sur sub-header-nav.tsx ("stay 404 by design") a ete corrige des les deux cotes.

Cette version du document a ete reecrite APRES avoir lu ce travail, pour ne garder que ce qu'il ne couvre pas et eviter de documenter deux fois la meme chose sous deux noms differents. Le detail complet de cette premiere passe (six cartes-liens, une porte "Agents" dans l'Overview, AccountMarketplaceNav) a ete retire de la PR qui accompagne cette page une fois le chevauchement identifie ; seul ce qui reste unique a cette PR a ete garde. Voir "Ce qui reste dans cette PR" en bas de page.

Ce qui reste un vrai probleme, non resolu par le nouveau registre

Le registre cockpit-nav.ts ajoute des portes. Il ne verifie pas la validite des donnees derriere chaque route, et c'est exactement la ou un probleme plus profond se cache sur trois surfaces :

P1 — Trois surfaces se disent scopees a l'organisation et ne le sont pas

/[orgSlug]/~/deals, /[orgSlug]/~/disputes et /[orgSlug]/~/sponsor-placements verifient l'appartenance a l'organisation de l'URL (garde correcte), mais la requete qui remplit chaque page filtre uniquement par l'utilisateur connecte (sellerId/buyerId, ou sponsorEmail = user.email) — jamais par l'organisation elle-meme. Ni DealThread ni SponsorPlacement n'ont de colonne orgId. Deux organisations differentes du meme utilisateur affichent donc EXACTEMENT la meme liste sous ces trois routes.

Avant le registre, c'etait un risque theorique caché dans le code. Depuis le registre, c'est un fait en production : un membre clique desormais sur "Deals", "Disputes" ou "Sponsor placements" depuis le panneau gauche du cockpit et voit une liste sans rapport garanti avec l'organisation qu'il regarde. Le lien rend le bug plus visible, pas plus correct.

Suivi : backlog/marketplace/0589 (deals/disputes) et backlog/marketplace/0591 (sponsor-placements, qui devrait vivre sous /account/ plutot que [orgSlug]/~/ — meme mouvement que les six pages account deja resolues).

P3 — Deux mecanismes de bookmark paralleles, desormais groupes mais pas clarifies

/account/saved (SavedListing, un listing marketplace a vendre) et /account/watchlist (bst_watchlist, un item de catalogue statique) resolvent la meme intention ("retrouver ca plus tard") sur deux modeles de donnees distincts. Le registre les groupe deja sous une section "Following" commune du launcher de compte, ce qui rend l'existence des deux visibles l'une depuis l'autre.

Un audit distinct, mene le meme jour sur le modele metier plutot que la navigation (docs/audits/2026-09-11-modele-metier.md), a trouve la meme incoherence par un autre chemin, avec un plan de fusion de modele de donnees que cet audit-ci ne proposait pas : backlog/marketplace/0597. L'item bookmark de cet audit (0590) a donc ete ferme comme doublon au profit de 0597, qui porte desormais la note sur le groupement du launcher. 0589 (deals/disputes) reste distinct et ouvert.

Ce qui reste dans cette PR

Un seul changement de code, qui n'est PAS couvert par le nouveau registre par choix deliberé de celui-ci : le registre documente explicitement que les pages settings/connectors, settings/rules et settings/skills d'une boutique ne doivent PAS recevoir de porte dans le launcher general (une deuxieme porte pour la meme piece), et laisse la question ouverte dans backlog/design-system/0596.

Cette PR ferme cet item : trois cartes-liens ajoutees a settings-manager.tsx (la page /settings d'une boutique elle-meme), meme forme visuelle et meme emplacement que celle qui menait deja a settings/privacy. Aucun composant duplique — les cartes pointent vers les routes existantes, qui montent deja ConnectorsManager / RulesManager / SkillsManager. src/test/cockpit-surfaces-are-reachable.test.ts est mis a jour pour dire la vraie raison ("linked from its own parent settings page") plutot que "flagged for its owning pillar".

Deux items de backlog restent ouverts a cette PR (0589, 0591) pour ce qui depasse un correctif de navigation : un changement de logique metier (scope des requetes par organisation). Le troisieme constat de cet audit (0590, bookmarks dupliques) a fusionne dans marketplace/0597, ouvert par un audit concurrent avec un plan de correction plus complet.

Aucune route deplacee, aucune garde d'acces changee, aucune nouvelle feature creee, et aucun doublon de navigation laisse en place a cote du registre deja livre.