Blomios
8e481aed69
Versionne l'état runtime IdeA produit pendant le sprint #13 : store de tickets (dont les nouveaux #55 à #67), compteur et index, notes de mémoire projet des lots F0 à F5, et journal des tâches de fond. Séparé du code applicatif conformément à la convention du dépôt (cf.ad1f225,a244f32) : métadonnée d'orchestration last-writer-wins, sans impact sur le build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.3 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| idea-distribution-strategy-desktop-vs-docker | memory note idea-distribution-strategy-desktop-vs-docker |
|
Stratégie de distribution IdeA validée utilisateur (2026-07-16, suite #13) : DEUX offres au-dessus du MÊME cœur backend (pas de fork métier).
Offre 1 — Full desktop : binaire Tauri app-tauri actuel. AppImage Linux (existe, inchangée). Windows explicitement REPORTÉ (garder la portabilité à l'esprit, ne rien introduire de non-portable ; PTY = ConPTY à retester le jour venu). L'AppImage reste desktop PUR — elle ne bundle pas les assets web.
Offre 2 — Serveur/client : image Docker, bâtie sur un binaire serveur HEADLESS idea-serve SANS dépendance Tauri/WebKit (pas de dockerisation du binaire Tauri qui traînerait GTK/WebKit pour rien). Cadré faisable en hexagonal par Architect.
Point pivot technique : server.rs vit dans crates/app-tauri et réutilise indirectement la présentation Tauri via crate::state::AppState, crate::dto::*, crate::events::DomainEventDto, crate::pty::PtyChunk, crate::mcp_endpoint::*, ResumeContext. Le protocole HTTP/WS lui est déjà autonome. Le vrai travail = découpler les DTO (→ crate partagé presentation-dto/backend-api) puis extraire crates/web-server (sur BackendCore, pas AppState) puis le bin idea-serve.
Tickets : #65 (headless, high, L1 DTO→L2 web-server→L3 idea-serve), #66 (Docker, medium, L4 build web http→L5 Dockerfile volumes /data+/workspace→L6 agents CLI conteneur), #64 (folder browser web, dependsOn #66 pour /workspace), #67 (lock inter-process app-data-dir, low).
Topologie de branches (décision utilisateur) : chantier packaging sur feature/server-client-packaging (créée depuis c246875, tête de feature/ticket13-pty-websocket). PAS de merge dans develop tant que l'utilisateur n'a pas validé lui-même la NON-RÉGRESSION desktop-only. Flux final : feature/server-client-packaging → feature/ticket13-pty-websocket → develop. Git rebase la branche packaging si #13 avance.
Invariants : desktop AppImage ne perd RIEN ; aucun import Tauri dans le bin headless ; même cœur/use cases/stores ; contrat HTTP/WS inchangé sauf lot versionné. Voir frontend-uses-npm-not-pnpm, appimage-build-no-strip-relr-dyn-fix.