pepate/traveldiary-skill

Carnet de Voyage

Transforme les matériaux bruts d'un voyage en un site web narratif : une carte par jour au-dessus d'une carte satellite fixe, segments de déplacement (camping-car, voiture, vélo, à pied, ferry, péniche) dessinés sur la carte, photos et vidéos épinglées à leur emplacement, points d'information ("Unterwegs" / "Along the way") avec images Wikimedia Commons, et une relecture par jour qui survole le tracé en 3D avec statistiques, profil d'altitude et les photos qui apparaissent là où elles ont été prises.

Le modèle dans template/ est un projet Vite + TypeScript + MapLibre (sans framework, sans clé API). L'utilisateur n'a jamais à toucher au code : une application web de configuration locale collecte la langue, les données du voyage, les textes du jour et les fichiers par glisser-déposer ; vous faites le reste avec les scripts de construction.

Quel mode ?

L'utilisateur dit	Mode	Aller à
"nouveau carnet de voyage", "créer un site de voyage", pas encore de projet	init	§1
"nouvelles photos / GPX / timeline / texte du journal", "ajouter le jour N", le projet existe	day	§2
"déployer", "publier", "créer le fichier unique", "mettre en ligne"	deploy	§3

Un projet est un projet traveldiary lorsqu'il contient data/trip.json et scripts/build-timeline.mjs.

1. init – créer un nouveau projet

1. Demandez (ou prenez du message) seulement deux choses : le dossier cible et si l'utilisateur préfère répondre aux questions de configuration dans l'application web (par défaut, plus convivial) ou dans le chat. Tout le reste, l'application le demande.
2. Exécutez la génération : node <skill-dir>/scripts/init.mjs <target-folder>. Cela copie template/, lance npm install, et affiche la commande suivante.
3. Démarrez l'application de configuration : npm run setup dans le projet (port 5180) et dites à l'utilisateur d'ouvrir http://localhost:5180. Utilisez preview_start avec cette URL si un volet de navigation est disponible. L'application les guide à travers : langue (de/en) → titre, sous-titre, dates, fuseau horaire, véhicules, type de sortie, couleur d'accent → une entrée par jour (date, titre, texte du journal en Markdown) → zones de dépôt pour photos, vidéos, GPX, Google Timeline. Elle écrit data/trip.json, content/tagebuch.md et les dossiers raw/. Ils peuvent la rouvrir à tout moment.
4. Lorsqu'ils reviennent ("fini", "done", ou ils collent simplement du matériel), continuez avec day.

Si l'utilisateur répond dans le chat à la place, écrivez data/trip.json vous-même (schéma dans references/data-formats.md) et le journal dans content/tagebuch.md (## Tag N – <weekday, date> – <title> / ## Day N – …).

2. day – traiter les nouveaux matériaux

Lisez references/day-workflow.md avant la première exécution dans une session ; il contient l'ordre exact, les conventions et les pièges. Version courte :

1. Inventaire de ce qui est nouveau sous raw/ (find raw -newer public/data/photos.json), et si le journal a de nouveaux jours. Si un connecteur Claude Docs et un lien de document sont disponibles, exportez le document en Markdown dans content/tagebuch.md ; sinon, l'application de configuration / l'utilisateur maintient ce fichier.
2. Structure dans data/trip.json : une entrée days[] par jour (n, date, title, tracks[] pour GPX, video pour un clip de survol, legs[] lorsqu'il n'y a pas de timeline). Renommez les fichiers GPX en YYYY-MM-DD_slug.gpx.
3. Étiquettes de timeline : exécutez npm run data:timeline, lisez la liste console des segments et donnez à chacun une étiquette humaine dans trip.json → timeline.labels (clé = heure de début locale YYYY-MM-DDTHH:MM). Corrigez les types mal détectés dans timeline.kinds (SKIING sur un e-bike → ebike, voiture d'un ami → car). Ajoutez les lieux d'arrêt à places pour que les arrêts aient des noms au lieu de "Pause".
4. Construction : npm run data (contenu → traces → timeline → pois → photos). Les serveurs publics de routage/altitude/Commons sont limités en débit ; les scripts font une pause et mettent en cache, ne les bouclez jamais.
5. Regardez les photos : construisez des planches contact des nouvelles photos (script dans la référence), lisez-les, et écrivez une courte phrase par photo dans data/captions.json. Nommez les lieux et les montagnes lorsque la position de la photo (imprimée à côté de chaque photo) les rend identifiables ; dites "groupe de l'Ortler" plutôt que de deviner un sommet. Mettez les photos floues ou accidentelles dans data/exclude.json.
6. Points d'intérêt : pour les endroits notables que l'utilisateur a traversés sans une bonne photo personnelle (un tunnel, un lac célèbre, un château), ajoutez des entrées à data/pois.json avec 2–3 phrases factuelles et un terme de recherche Commons ; npm run data:pois récupère une image librement licenciée avec attribution. Vérifiez les images sélectionnées sur une planche contact et épinglez un meilleur file si le premier résultat est médiocre (gravures, cartes).
7. Vérifiez avec npm run dev : ouvrez le nouveau jour, vérifiez les lignes, les épingles, les légendes, et jouez la relecture une fois.
8. Déployez (§3) et, si le projet est un dépôt git, faites un commit.

Gardez CLAUDE.md dans le projet à jour (c'est le document de transition pour la prochaine session).

3. deploy

trip.json → output dit ce que l'utilisateur a choisi ; les détails et les commandes exactes sont dans references/hosting.md.

• single : npm run build:single → un fichier HTML à côté du projet avec les données, photos et vidéos intégrées (les grandes vidéos propres sont laissées de côté avec une note). Note pour l'utilisateur : sur certains téléphones, un fichier ouvert depuis le système de fichiers bloque le web worker de la carte ; l'hébergement est plus fiable.
• web : npm run deploy:web → construction, génération de .htaccess + .htpasswd (Authentification de base) et téléchargement des fichiers modifiés via SSH (tar pipe, incrémental via manifeste de hachage). Nécessite .env.web (hôte, utilisateur, répertoire, logins).
• nas : npm run deploy → tar pipe vers un conteneur nginx Synology ; configuration dans nas/default.conf.

Choses à savoir

• Les photos ont besoin de l'heure EXIF + GPS (les téléphones fournissent les deux). Les vidéos obtiennent leur heure du nom de fichier (PXL_YYYYMMDD_HHMMSS) et leur position de la timeline, du GPX, d'un arrêt, ou de la photo la plus proche.
• GPX bat la timeline : les activités de la timeline qui chevauchent une trace GPX sont supprimées.
• Sans Google Timeline, les trajets sont routés entre les lieux nommés via days[].legs.
• Voyages en péniche : le type boat route le long des rivières/canaux OSM (scripts/waterway.mjs, liste blanche optionnelle timeline.waterways) et utilise les positions EXIF des photos comme points de cheminement – voir references/day-workflow.md.
• Bureau (≥ 900 px) : carte à gauche 50 %, histoire à droite 50 % avec une grande grille de photos ; la relecture affiche des cartes photo sur la droite et groupe les photos prises dans les 15 min (max. 6) sur une carte (mobile inchangé).
• Les profils d'altitude au-dessus des tunnels autoroutiers montrent le terrain au-dessus ; c'est pourquoi le gain d'altitude n'est compté que pour le vélo/la marche.
• Tout le texte de l'interface utilisateur est dans src/i18n.ts (de, en) ; ajouter une langue est un dictionnaire de plus.