chore(tickets): synchro du store local — cycle #244 DTO permissions templates (QA verte) + #157 passage en QA après validation live v0.34.0

This commit is contained in:
2026-08-24 11:46:19 +02:00
parent 69129a95ad
commit a6a97fdd39
5 changed files with 63 additions and 18 deletions

View File

@ -1,12 +1,14 @@
---
issueRef: "#244"
version: 6
version: 7
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
updatedAt: 1787481685136
updatedAt: 1787564256353
---
2026-08-23
- Reprise du ticket après demande utilisateur explicite: il faut corriger la cause applicative avant de se contenter de réaligner les templates.
- Travail déjà fait plus tôt: réalignement manuel des templates globaux sur les defaults projet. Ce réalignement ne suffit pas comme résolution si la cause racine de non-persistance subsiste.
- Nouvelle consigne de traitement: cycle correctif complet (Architect -> Git -> DevBackend -> QA -> Git), sans UX a priori car pas de surface touchée prouvée.
- Hypothèse de départ à vérifier: la persistance/backfill des permissions template ne se déclenche pas dans un des chemins runtime actuels, ou une mise à jour de template écrase/omet encore ces champs dans un cas précis.
- Prochaine étape: cadrage Architect sur la cause probable et le plus petit correctif sûr.
2026-08-24
- Repro QA confirmée sur le ticket #244.
- Scénario minimal: ouvrir Templates, éditer un template, cocher une permission MCP (ex. `idea_ticket_read`), sauvegarder, fermer, rouvrir: la case est de nouveau décochée.
- QA a démontré que le bug ne vient pas du pur UI local: le test frontend de réouverture avec `MockTemplateGateway` passe.
- QA a isolé une rouge backend de contrat: `update_template` ne désérialise pas actuellement la clé frontend `mcpToolPermissions`; le DTO backend n'accepte que `defaultMcpToolPermissions` / `defaultMcpToolPolicy`.
- Test rouge de référence: `cargo test -p app-tauri --test dto_templates update_template_request_does_not_currently_deserialise_frontend_mcp_tool_permissions_key -- --exact`.
- Conclusion de reprise: traiter ce ticket comme un correctif backend de contrat/persistance, puis faire revalider frontend+backend par QA.
- Prochaine étape: cadrage Architect, décision Git, implémentation DevBackend, revalidation QA, intégration Git.