zexuanw958-svg/travel-plan-viz

Visualisation de voyage

Transformez un voyage en page HTML mono-fichier : carte interactive, chronologie quotidienne, rappels avant départ. La logique mécanique utilise le moteur intégré (assets/map.js, assets/reminders.js), l'esthétique est confiée à l'étape de design (frontend-design / huashu-design, ou directives intégrées par défaut).

Première étape : déterminer le mode

• L'utilisateur donne uniquement une destination + nombre de jours (ex. "Hong Kong 4 jours 3 nuits") → Mode A (planification de zéro).
• L'utilisateur a déjà un itinéraire (texte ou ancien fichier HTML) → Mode B (analyse et génération à partir d'un plan existant).

Mode A : planification de zéro

1. Lire references/research-guide.md, rechercher la destination en ligne.
2. Proposer dans la conversation un plan quotidien détaillé en markdown (matin/midi/soir, attractions, transport, hébergement).
3. Itérer avec l'utilisateur jusqu'à confirmation explicite.
4. Passer à "Recherche et complétion + génération".

Mode B : plan existant

1. Analyser l'itinéraire fourni (s'il s'agit d'un ancien HTML, en extraire les données structurées).
2. Suggérer des améliorations (valeur ajoutée de l'Agent, sans insister) : examiner rapidement le plan selon les dimensions d'amélioration (informations pratiques avant le départ, gestion météo, réservations à l'avance, transport point à point, rythme et marges, incontournables locaux, pertinence des quartiers d'hébergement, etc.) et proposer au maximum 3–4 suggestions concrètes et facultatives dans la conversation. Principes :
   • Ne relever que les lacunes réelles ; si le plan est complet, dire simplement "C'est complet", ne pas inventer, ne pas faire la morale, ne pas réorganiser le voyage à la place de l'utilisateur.
   • Une phrase pour le problème + une phrase pour l'orientation, rester concis ; les suggestions sont données oralement par défaut, le fichier HTML final reste propre (l'utilisateur peut demander à les ajouter).
   • C'est ce qui nous distingue du "simple prompt vers HTML" : faire appel au jugement de l'Agent, mais avec mesure.
3. Passer à "Recherche et complétion + génération" (la génération n'est pas bloquée par les suggestions ; c'est à l'utilisateur de décider lesquelles adopter).

Recherche et complétion + génération

1. Suivre references/research-guide.md pour compléter en ligne : coordonnées, URL d'images réelles, notes, avis, horaires d'ouverture/jours de fermeture, prix d'entrée indicatifs, éléments nécessitant une réservation avec leadDays ; informations pratiques avant le départ (météo/typhon/tenue/paiement/App/moment de réservation des billets), transport point à point (mode/prix/durée), activités saisonnières, plats à commander + prix indicatif pour chaque repas ; pour les vols, proposer 3-5 vols alternatifs ; pour les hôtels, recommander par quartier + gamme de prix ; préparer une clause de non-responsabilité et des astuces pour tout le séjour. L'organisation doit refléter la logique météo/saisonnière (activités extérieures le matin ou en fin d'après-midi). Ne pas rechercher les prix en temps réel.
2. Organiser les données selon la structure trip définie dans assets/page-contract.md.
3. Générer le HTML stylisé en utilisant l'étape de design : en priorité, faire appel à un skill de design professionnel — frontend-design ou huashu-design (Design de Huashu) ; si aucun des deux n'est installé, suivre les directives esthétiques intégrées de references/design-guidelines.md. Dans tous les cas, respecter strictement les blocs et contraintes de assets/page-contract.md :
   • Intégrer le contenu de assets/map.js, assets/reminders.js dans le HTML (garantir un fichier unique).
   • Utiliser computeReminders + renderChecklistHTML pour la liste de vérification en haut de page.
   • Afficher le bloc d'informations pratiques avant le départ ; pour les vols, afficher les vols alternatifs (ceux déjà réservés en surbrillance) ; pour les hôtels, afficher par quartier + gamme de prix, et la clause de non-responsabilité bien visible à proximité.
   • Les cartes de la chronologie doivent afficher les champs optionnels comme horaires d'ouverture/prix d'entrée/transport/activités saisonnières ; afficher les repas quotidiens (plats à commander + prix), les astuces du jour et du séjour complet, et les options alternatives pour une journée (le cas échéant).
   • La carte utilise initTravelMap, avec les CSS/JS du CDN Leaflet.
   • Les éléments needsBooking dans la chronologie reçoivent reminderBadgeHTML(leadDays).
   • Chaque voyage utilise une palette de couleurs différente.
4. Enregistrer sous <NomDuVoyage>-voyage.html dans le répertoire de travail.
5. Informer l'utilisateur : il pourra ensuite fournir ce fichier HTML et dire "déplace l'activité X du jour 3 au jour 4", et la modification sera effectuée sur la structure existante.

Ne pas faire

Prix des billets en temps réel / prix des vols, réservation d'offres, interface multilingue, backend. L'ensemble reste un fichier statique unique.