Un prompt peut-il remplacer Zencal ?

Construis un système de réservation où un type de rendez-vous peut exiger un paiement avant d’être confirmé.

Calendrier : connecte un Google Calendar via OAuth avec des tokens de rafraîchissement chiffrés. Disponibilité à partir des heures de travail moins les événements occupés, avec des marges, un préavis minimum et un horizon de réservation. Toute l’arithmétique en UTC, rendue dans le fuseau horaire du visiteur avec le fuseau nommé à l’écran.

Types de rendez-vous : nom, durée, lieu, marges, questions posées à la réservation, et un prix optionnel avec une devise.

Le flux de réservation payante, qui est l’intérêt de ce projet. Une réservation passe par des états explicites et chaque transition doit être gérée :

1. **Bloqué** — créé quand le visiteur choisit un créneau et procède au checkout, avec une expiration à quelques minutes. Un créneau bloqué est indisponible pour tous les autres. Crée-le dans une transaction avec une contrainte d’unicité sur le type de rendez-vous et l’heure de début, pour que deux visiteurs simultanés ne puissent pas tous les deux le bloquer ; le perdant apprend que le créneau vient de partir et se voit proposer le suivant.
2. **En attente de paiement** — une session Stripe Checkout créée côté serveur contre la réservation bloquée, avec l’identifiant de réservation dans les métadonnées et une clé d’idempotence.
3. **Confirmé** — sur `checkout.session.completed`, vérifié par signature et contrôlé pour un traitement préalable, la réservation est confirmée, l’événement calendrier créé, et les emails de confirmation envoyés. Ne confirme jamais sur la redirection de succès ; le visiteur peut fermer l’onglet et la redirection peut ne jamais se déclencher.
4. **Expiré** — une tâche planifiée libère les blocages passé leur expiration. Avant de libérer, revérifie Stripe pour une session complétée contre cette réservation, parce qu’un webhook peut arriver en retard et libérer un créneau payé est le pire résultat du système.

Gère aussi : un paiement complété pour une réservation déjà expirée et libérée — rembourse automatiquement et envoie au visiteur un email d’explication plutôt que de garder l’argent silencieusement ; et `checkout.session.expired`, qui libère le blocage immédiatement plutôt que d’attendre le minuteur.

Écris un test pour chacun de ces six chemins. C’est toute la raison d’être de cette fiche et c’est là qu’un système maison de réservation-avec-paiement tourne mal.

Remboursements et annulation : une politique d’annulation par type de rendez-vous (une fenêtre dans laquelle un remboursement est automatique), un lien d’annulation signé dans l’email de confirmation ne nécessitant aucun compte, et des remboursements émis via Stripe avec l’événement calendrier supprimé et le créneau rendu à la disponibilité.

Les types de rendez-vous non payants utilisent le même flux de réservation sans les états de paiement, pour qu’il n’y ait qu’un seul chemin de code plutôt que deux.

Construis aussi : des emails de rappel à un intervalle configurable avec l’envoi enregistré pour qu’un redémarrage ne puisse pas envoyer en double, une liste de réservations admin montrant l’état et le statut de paiement, et un journal d’audit de chaque transition d’état.

Hors périmètre : les calendriers Microsoft et Apple, le round-robin d’équipe, les formulaires de routage, l’intégration CRM, et tout déploiement hébergé multi-tenant.