[sowibrr]

Closes #176 (les écrans, après l'API de #186) · Suivi : #166

⚠️ Design provisoire. Ces écrans montrent le parcours avec les composants actuels du design system et un style simple. Ils seront repris avec le design system : ne pas les juger sur leur apparence. Chaque écran porte la mention « Écran provisoire ».
⚠️ Pas encore accessibles par l'adresse du site : les routes manquent (voir plus bas).

Ce qui a été fait

Trois écrans dans apps/web/src/features/missions/, sur l'API fusionnée dans #186 :

• MissionsPage : les missions ouvertes aux propositions (lisible sans connexion), et « Les miennes » pour une personne connectée ; budget, client, compétences, nombre de propositions, « Voir plus » par curseur.
• NouvelleMissionPage : « Publier une mission » enregistre un brouillon que personne ne voit. Le budget est saisi en montant lisible (« 450 000 ») et envoyé en unité mineure avec sa devise ; les compétences (« Vue, ux design ») sont rangées (vue, ux-design, sans doublon, dix au plus) ; chaque champ refusé par l'API est signalé à côté de lui, tous ensemble.
• MissionPage : l'annonce et les actions de la personne, tirées de moi.actions (publier un brouillon, fermer une mission ouverte). L'API revérifie tout. Une mission inconnue ou privée dit « introuvable » sans préciser laquelle. Le texte du client est affiché comme du texte, jamais comme du HTML.
• Le client d'API typé connaît le contrat des missions (api/client.ts), les textes sont en français et en anglais, et la maquette MSW gère aussi « fermer ».

Comment c'est vérifié

• tests : 18 nouveaux (missions.test.ts) : montants et devises (franc CFA sans décimales, euro à deux), compétences, la liste (vide, en panne), le formulaire (bouton éteint, corps envoyé, budget invalide sans requête, erreurs par champ), la page (actions du client, publication, 409, 404, texte jamais interprété comme du HTML). Suite complète 194 sur 195 ; npm run build (vérification des types) réussi ; types générés à jour.
• testé à la main dans le navigateur contre l'API locale (profil demo), avec des routes ajoutées temporairement et non commitées : brouillon créé, publié, « 450 000 F CFA » affiché, la mission apparaît dans la liste avec ses compétences rangées. En chemin : un jeton d'espacement inexistant (--space-5) donnait un bouton sans marge ; corrigé, et je me suis assuré que tous les jetons CSS utilisés existent.

Décisions et alternatives écartées

• Pas de routes dans cette PR : apps/web/src/router.ts et App.vue appartiennent à @Amar233-ui (CODEOWNERS, docs/equipe.md). Je lui ouvre une demande pour trois routes et un lien de menu, plutôt que de modifier son fichier.
• Une seule page de détail pour le client et les visiteurs : l'API décide de ce que chacun voit et de ses actions, l'écran ne les devine pas.
• Montants saisis lisibles, convertis par la devise (Intl), plutôt qu'un champ en centimes que personne ne comprendrait.

Pistes d'amélioration

• 🔴 Les routes /missions, /missions/nouvelle, /missions/:id : sans elles, ces écrans ne sont pas atteignables. /missions et /missions/:id sont publiques, /missions/nouvelle demande la connexion.
• 🟡 Répondre à une mission (« Proposer mes services ») arrive avec Missions · M3 : candidater, choisir, fixer le devis #177 : l'écran le dit pour l'instant.
• 🟡 Le test reseau.test.ts › venu d'un besoin… est instable (cause et correction décrites dans feat: publier sa demande, avec l'événement DemandePubliee et des questions guidées (#158) #188) : si la CI échoue dessus, relancer le job.
• ❓ Question ouverte : faut-il un lien « Missions » dans le menu ? C'est le fichier d'Amar.

Outils d'IA utilisés : Claude Code (Claude Sonnet 5.5) pour le code, les tests et la vérification dans le navigateur.

🤖 Generated with Claude Code