better-review 0.3.0 → 0.5.0

package/README.md

@@ -35,7 +35,22 @@ navigateur). Le jeton est généré au premier lancement et conservé dans `BR_D
 redémarrer le serveur ne déconnecte pas. Le cookie est lié à l'hôte : `127.0.0.1` et `localhost` sont deux
 sessions distinctes.
 
-Puis « Repos suivis » : ajouter des repos (`owner/repo`) ou des orgs / comptes. L'inbox ne montre que cette liste.
+Puis « Repos suivis » : ajouter des repos (`owner/repo`) ou des orgs / comptes. L'accueil ne montre que cette liste.
+
+## Accueil : tableau des PR
+
+Toutes les PR ouvertes des repos suivis, en colonnes par avancement : Brouillon · En attente de review · En review
+(commentaires, changements demandés) · Approuvée (CI ou threads ouverts) · Prête à merger (approuvée, CI ok, aucun
+thread ouvert) · Merge queue · Mergée (dernières 24 h). Pas de glisser-déposer : la colonne découle de l'état GitHub.
+
+Badges de relation (review demandée, à re-relire, retours à traiter, ma PR, je participe, stagnante, sans reviewer) et
+filtres par groupe : Reviewer, Auteur, Lead ; plus « Non lues » et « Non vues à 100 % ». Le tableau se recharge au
+retour sur la page ou dans l'onglet (au-delà de 30 s), toutes les 5 min, dès qu'un changement GitHub est détecté
+(sondage toutes les 60 s) et sur « Actualiser ».
+
+Données chargées au plus juste : champs du tableau pour toutes les PR ; CI et threads en plus pour les PR approuvées
+(pour séparer « Approuvée » de « Prête à merger ») ; taille, fichiers vus, réponses attendues et dernière activité
+seulement pour les PR qui me concernent. Recherche GitHub limitée à 1000 résultats par repo / org suivi.
 
 ## Configuration
 
@@ -59,6 +74,11 @@ Commenter : clic sur un numéro de ligne (« + » au survol), côté ancien code
 nouveau code pour une ligne ajoutée, `Maj+clic` pour une plage ; bouton « Commenter » dans l'en-tête d'un fichier
 pour le fichier entier. Chaque commentaire part seul ou dans la review en attente.
 
+Réactions emoji (celles de GitHub) sous chaque commentaire, review et la description : clic sur une réaction pour
+ajouter / retirer la mienne, « ☺ » pour en choisir une autre. Les conversations résolues sont repliées (« Afficher N
+messages ») et s'ouvrent quand on y navigue. La CI de l'en-tête met les échecs en avant (détail au clic) et est sondée
+toutes les 15 s tant que des checks tournent.
+
 ## Naviguer dans les fichiers
 
 Le panneau de gauche (360 px, masquable avec `f`) propose trois vues. **La vue choisie fixe l'ordre des fichiers** :
@@ -71,10 +91,14 @@ sans changer l'ordre).
 | Arbre | Dossiers repliables (sous-dossiers avant fichiers, A→Z ou Taille) avec changements, fichiers vus, threads      |
 | Liens | Fichiers en ordre de lecture « base d'abord », nombre d'imports / d'utilisateurs, graphe plein écran           |
 
-Les liens sont calculés côté serveur sur le contenu complet des fichiers au head de la PR : AST TypeScript pour
-TS/JS (y compris `.js` → `.ts`, `require`, `import()`), règles dédiées pour Python, CSS/SCSS/Less, Go, Java/Kotlin,
-C/C++, Rust, Ruby, Vue/Svelte. Les mentions (nom de fichier en CamelCase, ou nom avec extension, ou chemin) couvrent
-la doc et les autres langages. Les alias `tsconfig` `paths` autres que `@/`, `~/`, `#` ne sont pas résolus.
+**Langages pris en charge** : TypeScript / JavaScript, HTML, CSS / SCSS / Sass / Less, Markdown, JSON et texte brut
+(`.txt`). Seuls les fichiers de ces langages sont analysés et colorés ; les autres s'affichent en texte simple et
+peuvent seulement être la cible d'un lien. Les liens sont calculés côté serveur sur le contenu complet des fichiers au
+head de la PR : AST TypeScript pour TS/JS (y compris `.js` → `.ts`, `require`, `import()`) ; `<script src>` et
+`<link href>` pour HTML (URL relatives, ou `/…` depuis le dossier de la page) ; `@import` / `@use` / `@forward` pour les
+feuilles de style (partiels `_x.scss`, `index`, chemins de chargement) ; les mentions (nom de fichier en CamelCase, ou
+nom avec extension, ou chemin) valent pour tous ces langages. Les alias `tsconfig` `paths` autres que `@/`, `~/`, `#`
+ne sont pas résolus.
 
 **Ordre « base d'abord »** (vue Liens) : ordre topologique, chaque fichier après ceux qu'il importe ou mentionne, les
 plus utilisés en premier, les cycles départagés de la même façon et les fichiers sans lien à la fin. On relit la PR de
@@ -83,12 +107,11 @@ ses fondations vers ce qui les assemble.
 **Voisinage** (onglet du panneau de droite, 520 px, quelle que soit la vue de gauche) : graphe du fichier courant, ce
 qu'il utilise → fichier → ce qui l'utilise, avec tous ses voisins ; clic sur un voisin pour l'ouvrir.
 
-**Monorepos** : chaque dossier contenant un manifeste (`package.json`, `pyproject.toml`, `setup.py`, `go.mod`,
-`Cargo.toml`, `pom.xml`, `build.gradle`, `composer.json`) est un package ; à partir de deux, l'ordre devient
+**Monorepos** : chaque dossier contenant un `package.json` est un package ; à partir de deux, l'ordre devient
 hiérarchique : packages du plus utilisé au plus dépendant (dépendances déclarées entre packages du workspace, y
 compris via un package non modifié, + imports entre fichiers), puis la base d'abord dans chaque package. Les imports
-par nom de package (`@acme/shared`, `@acme/shared/x`, crates Rust) sont résolus vers le point d'entrée du package
-(`exports` / `main` / `types` de `package.json`, sources `src/` correspondantes, `src/index.*`, `src/lib.rs`). La
+par nom de package (`@acme/shared`, `@acme/shared/x`) sont résolus vers le point d'entrée du package
+(`exports` / `main` / `types` de `package.json`, sources `src/` correspondantes, `src/index.*`). La
 vue Liens groupe les fichiers par package et le graphe plein écran les encadre ; il affiche aussi les autres packages du
 monorepo et les dépendances entre packages (option « Autres packages du monorepo ») : en couleur uniquement les
 packages qui contiennent des fichiers modifiés (et les liens entre eux), le reste en gris. Le graphe de voisinage
@@ -101,22 +124,35 @@ La description de la PR s'ouvre dans l'onglet « Description » du panneau de dr
 ## Architecture
 
 ```
-apps/cli        paquet npm `better-review` : serveur + packages du workspace groupés par esbuild, front compilé dans dist/web
-apps/server     Node + Hono + tRPC v11 : proxy GitHub (GraphQL, diffs REST), SQLite, polling → subscriptions SSE
-apps/web        Vite + React + Mantine, TanStack Router / Query, diff virtualisé, coloration Shiki en Web Worker
-packages/shared schémas zod, parseur de diff unifié (empreinte de hunk partagée serveur / navigateur)
+apps/cli                paquet npm `better-review` : serveur + packages du workspace groupés par esbuild, front dans dist/web
+apps/server             Node + Hono + tRPC v11 : proxy GitHub (GraphQL, diffs REST), SQLite, polling → subscriptions SSE
+apps/web                Vite + React + Mantine, TanStack Router / Query, diff virtualisé, coloration Shiki en Web Worker
+packages/shared         schémas zod, parseur de diff unifié (empreinte de hunk partagée serveur / navigateur)
+packages/language       briques communes aux langages : registre, chemins, index des fichiers, contrats d'analyse / coloration
+packages/lang-typescript TS / JS : imports (AST TypeScript), écosystème npm (package.json), grammaires Shiki
+packages/lang-html      HTML : `<script src>`, `<link href>`, grammaire Shiki
+packages/lang-css       CSS / SCSS / Sass / Less : `@import` / `@use` / `@forward` (résolution façon Sass), grammaires Shiki
+packages/lang-markdown  Markdown : mentions, grammaire Shiki
+packages/lang-json      JSON / JSONC : mentions, grammaires Shiki
+packages/lang-text      texte brut : mentions
 ```
 
+Chaque package de langage expose une partie `./analysis` (serveur : `LanguageAnalyzer`, et `Ecosystem` pour les
+manifestes) et une partie `./highlight` (navigateur : `LanguageHighlighter`, grammaires chargées à la demande). Ajouter
+un langage : créer `packages/lang-<nom>` sur ce modèle, puis l'enregistrer dans `apps/server/src/languages.ts` et
+`apps/web/src/highlight/languages.ts` (seuls points d'enregistrement).
+
 - Les diffs sont demandés entre deux SHA (immuables) et mis en cache définitivement.
 - La coloration syntaxique porte sur le fichier entier (blobs désignés par les lignes `index` du diff, mis en cache
   définitivement) : un commentaire ou une chaîne ouvert hors d'un hunk est coloré correctement. Fichier trop gros ou
   indisponible : seules les lignes du diff sont colorées.
 - Un commentaire, une réponse ou un nouveau thread s'affiche dès la réponse de GitHub ; la PR est rechargée ensuite en
   arrière-plan.
-- L'inbox fait une recherche « ids seulement » par section puis charge chaque PR une seule fois
-  (≈ 1 point de quota GraphQL par PR).
-- Une PR ouverte est surveillée toutes les 30 s, l'inbox toutes les 2 min ; un changement côté GitHub
-  rafraîchit l'écran sans rechargement.
+- Le tableau d'accueil fait des recherches « ids seulement » en parallèle puis charge les PR par lots de 25, avec trois
+  niveaux de détail (voir plus haut) : ≈ 5 points de quota GraphQL et ~7 s pour ~440 PR ouvertes.
+- Une PR ouverte est surveillée toutes les 30 s, le tableau toutes les 60 s (empreinte légère) ; un changement côté
+  GitHub rafraîchit l'écran sans rechargement.
+- « Vu » / hunk vu : affichage optimiste, protégé contre un rechargement de la PR parti avant l'écriture.
 
 ## Développement