---
issueRef: "#212"
version: 6
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
updatedAt: 1786786870793
---
2026-08-15 Main triage + implementation + QA.
- Symptome confirme par lecture code: frontend web invoque `load_layout`, mais `crates/web-server/src/lib.rs` ne route pas cette commande et tombe sur `UNKNOWN_COMMAND`.
- Cadrage Architect: fixer l'adapter web `/api/invoke` en alignement avec Tauri; idealement couvrir tout le sous-ensemble layout (`load_layout`, `mutate_layout`, `list_layouts`, `create_layout`, `rename_layout`, `delete_layout`, `set_active_layout`) + tests de non-regression.
- Cadrage UX: ne jamais exposer `unknown command: load_layout`; en cas d'echec de restauration, message utilisateur `Impossible de restaurer l’espace de travail de ce projet.` avec fallback vers un layout par defaut/non bloquant.
- Git: branche de travail `fix/212-web-load-layout-unknown-command`, creee depuis `develop` local `cf2f0dc`, rien pousse.
- DevBackend: web-server route maintenant toute la famille layout dans `/api/invoke`; tests ajoutes `authorized_layout_invokes_match_tauri_contracts` et `web_invoke_routes_layout_commands`; `cargo test -p web-server layout` OK. Suite complete `cargo test -p web-server` non verte dans cet environnement a cause d'echecs WS/PTY non lies au ticket.
- DevFrontend: `useLayout` ne propage plus l'erreur brute; message utilisateur controle + fallback `singleLeafTree()`; test UI cible ajoute et vert; `npm run typecheck` OK.
- QA: VERT pour #212. Commandes vertes: `cargo test -p web-server authorized_layout_invokes_match_tauri_contracts -- --nocapture`, `cargo test -p web-server web_invoke_routes_layout_commands -- --nocapture`, `npm --prefix frontend test -- LayoutGrid.test.tsx`. Aucun echec bloquant sur le perimetre du ticket.
- Prochaine etape: commit Git puis decision de merge local vers `develop`.