# Décisions d'architecture Choix actés et leur pourquoi. But : éviter aux futurs agents de relitiger ce qui est déjà tranché. Format léger (date — décision — pourquoi). ## 2026-06-29 — Extension Firefox plutôt que CLI Première piste : un CLI (Bun) qui fetch l'ICS et auto-soumet le formulaire. Abandonnée au profit d'une **extension Firefox**. **Pourquoi :** - La revue manuelle avant envoi est le vrai besoin (descriptions à enrichir, formulaire modéré) → pré-remplir + envoyer soi-même bat l'auto-submit. - L'extension réutilise la **session du navigateur** pour Nextcloud → aucun mot de passe à stocker. - Pas de gestion des tokens CSRF : le formulaire les porte lui-même. ## 2026-06-29 — v1 = page autonome de l'extension Plutôt que d'injecter des boutons dans le calendrier Nextcloud (SPA Vue, DOM fragile, casse à chaque mise à jour), la v1 est une **page propre** à l'extension. L'injection dans le calendrier reste un *bonus* ultérieur. ## 2026-06-29 — Statut dans le tag CATEGORIES (CalDAV) L'intention (*ignoré* / *soumis*) est écrite dans l'événement Nextcloud, pas dans un stockage local. **Pourquoi :** partagé entre bénévoles, durable, visible dans le calendrier. Un `state.json` local serait privé à une machine et invisible des autres. Le statut *publié* n'est pas un tag : il est **dérivé** de l'agenda public de la mairie (match titre + date), ce qui donne aussi le lien direct. ## 2026-06-29 — Image ajoutée manuellement Un content script ne peut pas remplir un `` (sécurité navigateur). L'extension facilite le geste (affiche l'image à glisser) mais ne l'automatise pas. L'affiche vient souvent de la newsletter Brevo, hors calendrier. ## 2026-06-30 — Parseur iCalendar (T1) : contrat `Event` figé + ical.js vendoré Le flux brut est transformé en `Event[]` par une fonction pure `parserEvenements(flux, aujourdhui)` (`extension/evenements.js`), via **ical.js v2.2.1 vendoré** (approche 3 du brainstorm : pas de build, dépendance en `.js`). **Contrat `Event` figé** (ne pas rouvrir sans accord) : `{ uid, titre, description, lieu, debut: Date, fin: Date, categories: string[], journeeEntiere: boolean }`. Champs texte coercés en `""` si absents (l'aval suppose des chaînes). Le défaut « café » du lieu est appliqué **en aval**, pas ici. **Décisions tranchées :** - **`uid` seul, pas de `href`/`ETag`.** Le transport actuel (`?export`) renvoie un ICS concaténé sans `href`/`ETag` par événement. L'`UID` est la clé stable ; T2 résoudra l'adressage CalDAV par UID au moment du PUT. Le contrat n'est pas alourdi. - **`journeeEntiere` dès T1** (drapeau porté, comportement « heure exigée » différé à T3). - **Cas limites traités « au plus simple », différés à T3** : pas d'expansion RRULE (récurrents pris au DTSTART maître + filtre futur → un récurrent au maître **passé** disparaît, **trou assumé et documenté**), exceptions d'occurrence (`RECURRENCE-ID`) ignorées, journées entières au minuit local. - **Tri & message « 0 événement futur » hors parseur** : le parseur renvoie les événements **dans l'ordre du flux**, non triés (responsabilité de la liste). ## 2026-06-29 — Pré-remplissage par content script, pas par URL Gravity Forms n'accepte `?input_X=` que si chaque champ est configuré « population dynamique » côté mairie (improbable). On remplit donc le **DOM par id** (ids confirmés dans `RECHERCHE.md`).