blomios/IdeaSDK
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(tickets): synchronise l'état runtime des tickets et de la mémoire

Browse Source 
Clôture #114/#115/#116/#117, suppression #111, ouverture #119/#120/#121,
notes mémoire root-cause #113 et angle d'investigation #120.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Blomios
2026-07-31 23:52:33 +02:00
parent 32c257d2e1
commit 5efb026a80
21 changed files with 487 additions and 107 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
.ideai/memory/ticket113-controlled-args-field-rootcause.md Normal file
View File

@ -0,0 +1,20 @@
---
name: ticket113-controlled-args-field-rootcause
description: memory note ticket113-controlled-args-field-rootcause
metadata:
type: project
---
---
name: ticket113-controlled-args-field-rootcause
description: Cause racine identifiée du bug ticket #113 (espaces impossibles dans le champ Arguments supplémentaires llamacpp) et niveau de fix attendu.
metadata:
type: project
---
Root cause confirmée dans le code (2026-07-31) : `frontend/src/features/model-servers/ModelServersPanel.tsx:645-647` affiche `value={draft.args.join(" ")}` et parse via `parseArgs` (`modelServer.ts:133`, `split(/\s+/).filter(non-vide)`) à chaque `onChange`. Le state du champ est un `string[]` reconstruit en texte à chaque frappe, donc tout espace en fin de saisie ou espace double est immédiatement absorbé avant le prochain re-render : l'utilisateur ne peut jamais laisser un espace « en attente ».
Le même pattern existe à l'identique dans `frontend/src/features/first-run/FirstRunWizard.tsx:264` (même `parseArgs` importé depuis `first-run/profile.ts`) — probablement le même bug latent, non signalé par l'utilisateur mais à couvrir dans le même correctif.
**Why:** classique piège de champ contrôlé dont le state est un type dérivé (array) plutôt que la chaîne brute tapée — le round-trip parse→join efface la saisie en cours.
**How to apply:** le fix attendu est purement frontend/local : garder une valeur de saisie brute en state local (string) pendant la frappe, ne convertir vers `args: string[]` qu'à la sortie du champ (blur/submit), sans reconstruire `value` depuis `args.join(" ")` à chaque `onChange`. Aucun changement domaine/backend/DTO nécessaire — `args: string[]` reste le contrat de sortie inchangé.