[sowibrr]

Closes #175 · Suivi : #166 · Proposition : #182

Ce qui a été fait

• contracts/missions.yaml décrit le parcours complet d'une mission :
  • annonce : créer (seule ou depuis sa demande publiée, demandeId), modifier, publier, fermer, inviter ;
  • propositions : proposer, retenir, retirer, envoyer le devis par jalons, accepter le devis (il vaut contrat) ;
  • suivi : démarrer (le délai commence là), livrer, accepter (automatiquement après 72 h), demander une retouche (dans la limite du devis), déclarer un paiement, demander une prolongation ;
  • fin : annuler (d'un commun accord, ou seul dans deux cas précis), ouvrir et trancher un désaccord (modérateur), laisser un avis.
• Les règles écrites dans le contrat :
  • qui voit quoi : 404 pour les autres ; un développeur ne voit que sa propre proposition ;
  • les limites contre les abus (429) ;
  • les montants en entiers avec leur devise ISO 4217 ;
  • le paiement déclaré dans la v1 ;
  • un champ version sur chaque action ;
  • la liste des codes 409 ;
  • les données personnelles.
• Le champ moi donne le rôle de la personne qui lit et les actions qu'elle peut faire, pour afficher les bons boutons. L'API revérifie toujours.
• Le front :
  • les types sont générés (missions.ts, ajouté au script api:types) ;
  • les maquettes MSW couvrent la liste, la création, la publication et les propositions ;
  • elles sont enregistrées dans handlers.ts.

Comment c'est vérifié

• tests : apps/web 172 sur 172 (dont 4 nouveaux dans mocks/missions.test.ts), build réussi, types générés à jour.
• contrat : npx @redocly/cli@1.34.5 lint --config contracts/redocly.yaml contracts/missions.yaml est valide.

Décisions et alternatives écartées

• Des actions par des routes avec un verbe (/publier, /livrer) plutôt qu'un PATCH sur le statut : c'est la règle des conventions (§1), et chaque transition a ses propres droits.
• Les limites par jour répondent 429, et non 409 limite_atteinte comme le disait Missions · M2 : publier une mission #176 : c'est la règle des conventions (§6).
• La mission est une ressource à part, liée à une demande par demandeId : une mission peut aussi naître sans demande, et le module demandes ne change pas.

Pistes d'amélioration

• 🔴 Risque : la PR fait environ 1 150 lignes sans les fichiers générés (le contrat seul en fait environ 880), au-delà des 400 recommandées. Je peux la découper en deux PR (l'annonce et les propositions, puis le suivi et la fin) si la revue le demande.
• 🟡 À améliorer ensuite : l'acceptation automatique doit rester idempotente, même si deux instances de l'API tournent en même temps. Ce sera testé dans Missions · M4 : démarrer, livrer, accepter, payer #178.
• 🟡 Fichiers partagés : apps/web/package.json (le script api:types) et src/mocks/handlers.ts, avec 3 lignes ajoutées.
• ❓ Question ouverte : le délai d'acceptation automatique (72 h) et les cas d'annulation par une seule partie (7 jours) sont à valider dans la proposition docs: proposition 0004, hackathons et missions freelance (#167) #182.

Outils d'IA utilisés : Claude Code (Claude Opus 5.5) pour la rédaction du contrat, des maquettes et des tests.

🤖 Generated with Claude Code