Macroplan Pro

Outil local de macroplanification / Gantt pour du développement logiciel. On décrit un plan en YAML (équipe, features, sprints) et l'outil auto-remplit un calendrier semaines × features en fonction de la capacité de l'équipe, des priorités et des dépendances — avec des marqueurs de progression, des vues par feature ou par développeur, des sprints, des commentaires et un historique de versions.

Le produit tourne 100 % en local (aucun backend). Le plan est un fichier YAML versionnable dans git ; les versions nommées sont aussi stockées localement (IndexedDB).

Démarrer

pnpm install
pnpm dev            # http://localhost:5173
pnpm test           # suite Vitest
pnpm build          # build de production (dist/)

Concepts

• Auto-scheduling déterministe : chaque feuille de feature est placée sur le développeur au rôle compatible qui la termine le plus tôt, en respectant les priorités, les dépendances (tri topologique), la hiérarchie parent/enfant, la charge (%), les absences et les week-ends. Deux devs → travail en parallèle ; un seul dev → sérialisation. Override manuel via pin.
• Baseline figée : la fin de dév prévue sert de repère immuable (progress.plannedEnd). La fin de dév réelle (progress.end) occupe la capacité du dev jusqu'à sa date — un dépassement bloque donc la feature suivante — et tout glissement au-delà de la baseline apparaît en « retard prévu » (△) puis « livré en retard » (▲) sans déplacer le repère.
• Source de vérité = le document, pas le texte. Deux surfaces d'édition écrivent le même PlanDoc via applyDocEdit : l'UI structurée type Notion (vue « Structure » : formulaires + tables + arbre de features avec drag & drop) et l'éditeur texte YAML (vue « Texte »/« Source »). Elles restent synchronisées et le calendrier se recalcule en direct.

Barres du calendrier

Chaque feature est une barre à bord de départ plat et de hauteur constante. La fin est marquée par deux formes dont les bords prennent la couleur de la feature :

Marqueur	Sens
cercle creux	Fin prévue (baseline)
cercle plein noir	Fin atteinte (livrée à temps)
triangle creux	Retard prévu (prévision > baseline, non livré)
triangle plein noir	Livré en retard

La couleur du corps de barre vient du champ color (ou du risque par défaut). La case « Cacher les week-ends » (activée par défaut) retire complètement les samedis/dimanches de la timeline — ce ne sont pas des jours travaillés. Les sprints sont numérotés à partir de 0. En vue par développeur, les absences de chaque membre apparaissent en bandes hachurées.

Format du plan (YAML)

version: 1
title: Mon projet
start: 2026-06-01
end: 2026-08-31

sprint:
  lengthWeeks: 2 # 1 à 4
  anchor: 2026-06-01 # début du sprint 1 (défaut : start)

members:
  - id: bruno # id slug stable (référencé ailleurs)
    name: Bruno T.
    role: backend # backend | frontend | fullstack | tech-lead | eng-manager | design | qa | product
    load: 1 # 0..1 (0.8 = 80 %)
    absences:
      - { from: 2026-07-20, to: 2026-07-31 }

features:
  - id: auth
    name: Authentification
    estimate: 8 # jours-hommes (JH)
    priority: p0 # p0..p3
    risk: green # green | orange | red  (affiché : maîtrisé/faible/élevé)
    color: blue # couleur de barre : nom de base ou hex "#rrggbb" (défaut = risque)
    role: backend # compétence requise (owner déduit sinon)
  - id: oauth
    name: OAuth
    parent: auth # hiérarchie = liste plate + pointeur parent
    dependsOn: [payments] # prédécesseurs : ne démarre pas avant leur fin (ex. front ← back)
    estimate: 5
    owner: bruno # override d'owner
    pin: { assignee: bruno, start: 2026-06-15 } # qui + début (« à partir de »)
    progress: # overrides de fin de développement (baseline + réel)
      plannedEnd: 2026-06-26 # fin de dév prévue (baseline gelée)
      end: 2026-07-05 # fin de dév réelle/prévue — occupe la capacité (retard si > plannedEnd)

sprints: # métadonnées optionnelles par sprint (index dès 0)
  - { id: s3, index: 2, description: "Durcissement" }

comments: # une seule liste, cible discriminée
  - { id: c1, on: { kind: feature, feature: auth }, author: amel, body: "..." }
  - { id: c2, on: { kind: sprint, sprint: s3 }, body: "Démo" }
  - { id: c3, on: { kind: date, date: 2026-07-14 }, body: "Séminaire" }

Architecture

src/
  model/        types (PlanDoc), render-types, date math (UTC-noon), constantes
  format/       schema Zod, parse (YAML→doc), serialize (doc→YAML)
  schedule/     moteur greedy déterministe (capacity.ts, schedule.ts)
  derive/       tree, lanes (packing), build-render-model
  store/        Zustand (source de vérité, applyDocEdit alimente les 2 éditeurs)
  calendar/     rendu grille + barres au jour près + marqueurs + now-line
  editor/       éditeur texte (overlay shiki + complétion)
  structured/   UI structurée type Notion (Projet/Équipe/Features/Commentaires)
  panels/       SprintDetail, CommentsPanel, VersionHistory (diff)
  persistence/  IndexedDB (working doc + snapshots nommés)
  export/       YAML + PNG

Tout le cœur (parse, schedule, derive) est pur et couvert par des tests Vitest.

Prochaines étapes possibles

• Équilibrage de charge dans le scheduler (répartir sur les devs sous-utilisés).
• Intégration git réelle (isomorphic-git) pour l'historique.
• Multi-plans / import-export de fichiers .yaml.
• UI structurée : réordonnancement par drag & drop plus riche (re-parentage), édition inline des re-estimations QA.