Les panneaux d'édition étaient modaux et la colonne de gauche tronquait
tout ce qu'elle portait. Sept corrections, mesurées sur data/exemple.json.
Panneaux
- Le voile qui recouvrait la page disparaît : la frise reste manipulable
pendant l'édition, et cliquer une autre barre y bascule la sélection.
Il rendait aussi le raccourci flèches inatteignable, le focus partant
dans le champ « Nom » sans qu'on puisse cliquer ailleurs pour en sortir.
- Un clic dans une zone inerte referme le panneau : ce que rendait le
voile, sans le calque qui figeait la frise.
- Les paramètres d'un projet quittent le <dialog> modal pour le même
panneau qu'une phase, avec la même édition au fil de la saisie.
« Nouveau projet » crée donc le projet aussitôt, comme le fait déjà
l'ajout d'une phase : plus aucune création ne passe par un formulaire.
Colonne des projets
- Le nom ne disposait que de 56 px sur 250, et « client » s'affichait
« c. ». Les commandes passent en surimpression au survol, les tags
cèdent en bloc derrière un compteur, et le nom cède en dernier.
- La colonne se redimensionne, largeur conservée dans localStorage.
- L'œil disparaît : il faisait doublon avec l'entrée « Masquer » du menu.
Un « + » le remplace, l'ajout d'une phase étant l'action la plus
fréquente, et le nom du projet devient cliquable — il portait déjà un
curseur « main » sans aucune action derrière.
- Plus de commande « Ajouter un jalon » : un jalon est une phase dont on
coche la case, pas un autre objet.
Frise
- Le nom d'une phase reste accroché au bord visible quand sa barre
s'enfonce sous la colonne.
- Cliquer un nom de phase hors écran ramène la frise sur elle.
- La barre cumulative d'un projet s'affiche aussi quand il est déplié,
amincie pour ne pas se faire passer pour une barre de phase.
Arbitrages consignés dans docs/decisions.md, sections 8 et 17 à 21.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Les tags s'affichent en pastilles colorées dans la colonne des libellés, et une
barre de filtres apparaît sous la barre d'outils dès qu'un tag existe. Cliquer un
tag — dans cette barre ou directement sur la pastille d'un projet — restreint la
frise ; recliquer le retire.
Le filtre est conjonctif : un projet doit porter tous les tags cochés. Cocher un
tag de plus resserre donc toujours la sélection, sans jamais faire se repeupler
la frise. Un message dédié prend la place de la frise quand plus rien ne passe le
filtre, sans quoi elle laisserait croire que les projets ont disparu.
Le filtre est un état de vue, jamais enregistré, au même titre que la fenêtre
temporelle. Il ne fait pas le même travail que le masquage par l'œil, qui reste
enregistré : le filtre retire le projet de la vue entière, l'œil garde son
libellé grisé et n'ôte que les barres.
Deux ajustements de confort : créer un projet sous filtre actif préremplit ses
tags avec ceux du filtre, sinon le nouveau venu naîtrait invisible ; et un tag
que plus aucun projet ne porte est retiré du filtre, sinon il masquerait tout.
Le dialogue d'un projet gagne un champ de saisie et propose en un clic les tags
déjà employés ailleurs, seul garde-fou contre la dérive orthographique.
Dans la colonne des libellés, les pastilles rognent le nom du projet mais lui
laissent quatre caractères, et s'effacent à leur tour plutôt que de repousser
l'œil et le menu hors de la colonne.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un projet porte désormais une liste d'étiquettes libres, destinées à filtrer la
frise. Il n'y a pas de référentiel à tenir : les tags disponibles sont ceux que
portent les projets.
normaliserTags() nettoie la liste à l'enregistrement — espaces réduits, vides
écartés, doublons fusionnés à la casse près, tri alphabétique pour qu'une
ressaisie dans un autre ordre ne produise aucun diff. Les accents, eux, comptent :
« éditeur » et « editeur » restent deux tags distincts, contrairement aux
identifiants qui doivent tenir dans une URL.
Un tag trop long est tronqué plutôt que refusé : sa longueur est cosmétique, et
bloquer le chargement d'un planning entier pour un libellé bavard serait
disproportionné. La validation ne vérifie donc que le type — un tag mal typé
serait un tag qu'on croit poser et qui ne filtre rien.
teinteTag() dérive une teinte HSL du nom par hachage : la couleur d'un tag n'est
ni stockée ni saisie, et reste la même partout où il apparaît.
Le format passe en version 3. Un fichier en version 2 se charge sans rien
demander, ses projets recevant une liste vide, et il est réécrit en version 3 à
la première sauvegarde. Le bump empêche une version antérieure de l'outil
d'effacer silencieusement les tags en réécrivant le fichier.
Dix tests couvrent la normalisation, la comparaison, la teinte et le filtre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Une frise chronologique unique où plusieurs projets s'empilent en couloirs
pliables, pour voir d'un coup d'œil où en est chacun et comment ils se situent
les uns par rapport aux autres. Ce n'est pas un outil de suivi quotidien : une
phase se compte en semaines, et il n'y a ni sous-tâches, ni tickets, ni
dépendances entre phases.
- Manipulation directe des barres (glisser, redimensionner), accrochées au lundi
- Couloirs pliables : plié, un projet devient une barre segmentée par phase
- Planning de référence figeable, avec barre fantôme et calcul de dérive
- En-tête à trois bandes : année, mois, numéro de semaine ISO 8601
- Frise qui s'élargit au défilement, pour planifier dans un futur encore vide
- Micro-serveur Python (bibliothèque standard) exposant GET/PUT sur /api/data,
avec sauvegarde horodatée avant chaque écriture
- Zéro build : modules ES natifs, aucune dépendance à installer
50 tests unitaires sur la logique métier (node --test, sans dépendance).
Vérifié dans Chromium et Firefox.
Les arbitrages de conception et surtout leurs raisons sont consignés dans
docs/decisions.md — notamment l'abandon des dépendances entre phases, de la
File System Access API, du SVG et des niveaux de zoom.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
