blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
aec4293750270a7ad17218278ba82e097eb88ba7
IdeA/.ideai/memory/ui-rework-sprint-tickets-21-22-23-scoping.md
Blomios ffc458e477 docs(memory): notes projet du sprint UI rework et des tickets #7/#14/#16/#17/#18/#25/#28 
Capitalise les notes durables produites pendant le sprint UI rework et les
tickets livrés depuis. Commit séparé du code : `.ideai/memory/` est le store
durable versionné, il ne doit jamais être mélangé aux commits de feature.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-08 08:38:16 +02:00

5.2 KiB
Raw Blame History

name, description, metadata
name description metadata
ui-rework-sprint-tickets-21-22-23-scoping memory note ui-rework-sprint-tickets-21-22-23-scoping
type
project

Cadrage hexagonal des 3 derniers tickets du sprint « UI rework » (order 1), fait 2026-07-07 par Architect. Les 4 premiers (#16/#17/#18/#19) sont livrés/mergés sur develop — cf. ui-rework-sprint-scoping-contracts. Ne pas re-cadrer ; produire.

État de départ vérifié

  • Vues (context/work/tickets/agents/templates/skills/permissions/memory/git) = composants React rendus via menu View, pilotés par openPanel: useState<PanelId|null> (ProjectsView.tsx:127). UNE seule vue à la fois dans un FloatingWindow modal centré (ProjectsView.tsx:497).
  • FloatingWindow = overlay MODAL (fixed inset-0, backdrop, focus-trap, z-50), non déplaçable/non redimensionnable, purement présentationnel.
  • LayoutTree terminaux (cellules/LeafView, layout.json via ProjectStore) = domaine DISTINCT ; ne pas confondre avec le placement des vues.
  • TicketListQuery (ports/index.ts:717) N'A PAS de sort/order. Pagination RÉELLE (useTicketSearch + loadMore, TicketsPanel.tsx:225 charge 100 puis +100).

#21 tri tickets (low) — NON frontend-pur : B + F

Le tri est une préoccupation de QUERY, symétrique du filtrage déjà backend-driven (TicketGateway.list→ticket_list). Comme la liste est paginée, trier client ne trie que les pages chargées → FAUX. Refuser le « frontend-pur ».

  • B : étendre TicketListQuery/ticket_list avec sort?:{field:"number"|"priority"|"status"|"title"; direction:"asc"|"desc"}. ORDRE TOTAL déterministe obligatoire (tie-break par number croissant, sinon curseur casse). priority/status = ordre sémantique enum explicite, pas alpha. Défaut absent = comportement actuel (champ optionnel, rétro-compat). Companion recommandé non imposé : solder la dette basse curseur offset non opaque/stable (cf. ui-rework-sprint-scoping-contracts) — peut rester ticket séparé.
  • F : contrôle « Trier par… » dans TicketFacetsBar (partagé TicketsPanel + TicketPicker #18). useTicketSearch relaie sort dans la query, sort dans la queryKey (reset pagination). Ne pas toucher le traitement OPAQUE du curseur (G3-bis). Groupement-par-sprint reste client ; tri s'applique intra-groupe.
  • Dépend #16/#18 (livrés). Indépendant de #22/#23.

#22 Anchor/docking views (medium) — frontend-pur V1 ; persistance = B optionnel différé

NE PAS réutiliser FloatingWindow (overlay modal) ni LayoutTree terminaux. NOUVELLE primitive de docking chrome-level, en-flux (pas overlay).

  • Frontière : docking = état présentation chrome-level machine-local, distinct du domaine LayoutTree (réservé cellules PTY). Jamais dans LayoutGrid/LeafView (G5).
  • Généraliser openPanel:PanelId|null en modèle de placement : ViewPlacement = "closed"|"floating"|{dock:"left"|"right"} par PanelId — conçu EXTENSIBLE pour #23 (ajoutera "detached"). Invariant : une vue = exactement un slot. V1 reco : 1 vue ancrée par côté, largeur redimensionnable.
  • F : shared/ui/DockRegion (colonne verticale resizable gauche/droite du ), header titre + bascule flottant↔ancré. ProjectsView remplace openPanel par le placement. Réutilise composants de vue existants tels quels.
  • B optionnel différé : persistance restore-au-redémarrage = préférence UI machine-local → store global settings.json/workspace.json (archi §9.2 via ProjectStore), PAS layout.json projet. V1 éphémère (useState) ; persistance = follow-up ticket dédié.
  • Autonome. FOURNIT le modèle de placement dont #23 dépend.

#23 views en fenêtres système (medium) — impact backend Rust + composition root

Cas spécialisé du chantier L10 multi-fenêtre (Tauri v2 WebviewWindow, protocole detach, archi §13.3). Avantage vs detach onglet-terminal : vues gateway/read-model-driven, PAS liées à un Channel PTY → nouvelle WebviewWindow ré-instancie le DI et re-souscrit aux gateways, AUCUN transfert d'état lourd.

  • B (app-tauri) : command open_view_window({panel,projectId}) créant une WebviewWindow sur entrée dédiée (URL param ?panel=&project=), lifecycle (focus/close/registre anti-doublon), events cycle de vie (fermeture OS → re-bascule placement). Composition root (di.tsx) : supporter un shell « panneau seul » (mêmes adapters/gateways).
  • F : nouveau port WindowGateway.openViewWindow(panel,projectId) (+ closeViewWindow) avec adapter Tauri + mock (jamais invoke direct). Entrée panel-only lisant panel/project depuis URL. Menu View : action « Ouvrir dans une nouvelle fenêtre ».
  • Articulation #22 FIGÉE : ViewPlacement = "closed"|"floating"|{dock:"left"|"right"}|"detached". Une vue = soit ancrée soit flottante soit détachée, jamais deux (même invariant un-seul-slot). #23 = ajoute "detached" + plomberie Tauri.
  • DÉPEND du modèle de placement de #22.

Ordre & dépendances

  • #21 en parallèle, autonome (petit B+F, le plus rapide, chaîne tickets uniquement).
  • #22 AVANT #23 : #22 pose ViewPlacement que #23 étend. #23 d'abord = réinventer puis retravailler.
  • Frontières : #21 seul à toucher domaine tickets (query sort) ; #22 présentation pure (docking ≠ LayoutTree) ; #23 seul à toucher app-tauri/composition root + nouveau port WindowGateway.