Conversation
…e l'envoi silencieux Un `/goal <condition>` (SET) part désormais avec une bulle : une carte « Goal set » (icône cible + condition en entier) au lieu de l'envoi silencieux. `/goal clear` (bouton du chip et tapé) et le `/goal` de statut restent silencieux — pur plumbing représenté par le chip cible. - goalCommand.tsx : parseGoalCommand (formes brute + wrappée, condition multi-ligne) + GoalCommandCard. Branché dans UserText avant le chip slash-command générique ; userMessagePreviewText → « Goal: … » pour pin/peek. - ConductorComposer + useSendMessage : flag `goal: "set" | "plumbing"` remplace `silent`, découplant l'affichage de la bulle du pilotage titre/résumé (un SET montre la bulle sans piloter l'auto-titre). Chip cible toujours rafraîchi (markGoalSeen/scheduleGoalRefresh). - history.rs : is_goal_command_noise scinde l'echo SET (rendu) vs clear/status (droppé) ; tous les stdouts goal restent droppés. Helper command_args tolérant aux wrappers non terminés. Parité live (bulle optimiste, echo was_ours droppé → pas de doublon) ↔ reload (echo rendu, stdout droppé). Aucun changement IPC/bindings. Rien côté Codex. Tests : goalCommand.test.ts, userText.test.ts, parity assembler.rs, history.rs. Vérifs : tsc, vitest 933, cargo --lib 386, build — tous verts. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…es inline dédiées Une AskUserQuestion était classée comme step ordinaire : une ligne « Question » anonyme perdue dans une section repliée, et sous clean-output elle se pliait avec le travail — un round texte → outils → question ne montrait que des rangées d'outils (constat sur une vraie session : 6 tours agglomérés, échange illisible). Une question est un artefact de DÉCISION, exactement comme un plan (ExitPlanMode) : segment `question` dédié qui casse le run, carte inline (QuestionCard : intitulés + réponse choisie une fois le tool_result arrivé, « En attente… » sinon — l'interactif reste dans l'AskTurn du bas), splitFinalMessage pèle une question de fin de réponse AVEC sa prose d'explication (elles restent en clair sous clean-output), et renderFoldedWork scinde le fold autour d'une question enfouie comme il le fait pour un plan. Au passage, le diagnostic a montré que le gros du symptôme rapporté (« je ne vois pas les explications ») venait du MODÈLE : la narration de l'agent était émise en blocs thinking (vides sur le wire), pas en text — l'app affichait fidèlement le wire. Cette carte corrige la part app : l'échange question/réponse reste désormais lisible et ancré dans le fil. Tests : segment + peel + round-trip atoms (3 nouveaux, 679 verts). Typecheck et build OK. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…s robuste au wording CLI Depuis 7ff57a8 il existait DEUX cartes de récap post-réponse AskUserQuestion : QuestionnaireSummary (chips, corps d'outil déplié) et QuestionCard (inline). Fusionnées en UN composant QuestionnaireCard, utilisé par le fil principal (via le wrapper live QuestionCard), le détail d'outil (ToolDetail) et les transcripts de sous-agents (SubAgentTranscript). QuestionnaireSummary + parseAnswerPairs (regex naïve) supprimés. Bug racine : le binaire claude a changé le libellé du tool_result AskUserQuestion (~24/07) — « The user answered: … Read the answers carefully — … » au lieu de « Your questions have been answered: … You can now continue … ». Le parser n'ancrait que sur l'ancien prefix → depuis ~24/07 les réponses tombaient en texte brut. parseAnsweredResult ancre désormais sur un SET de prefixes/suffixes (les deux wordings coexistent, même dans une session — vérifié sur 175 résultats disque). La carte unifiée reprend les forces de l'ancienne : réponses en chips (split multi-select-aware, free-text « Other » à virgules gardé entier), lecture de input.answers d'abord, et repli TEXTE BRUT sous les questions quand le format est inconnu (zéro erreur silencieuse). Header découplé du .cv-q-tab interactif. Tests : 12 nouveaux (wording actuel/legacy, multi-select, free-text à virgule, format inconnu, skip). tsc + 947 tests + build verts. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… non terminé parseGoalCommand (TS) exigeait une balise </command-args> fermante, alors que le Rust `command_args` tolère un wrapper non terminé et garde la ligne comme SET. Résultat : Rust gardait la ligne dans le fil mais le front la rendait en chip nu au lieu de la carte Goal. Aligne le front sur le Rust (helper wrappedArgs) + test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- CLAUDE.md : nouveau principe directeur « réversibilité & contrôle utilisateur » synchronisé depuis le contexte projet TOSSE (un toggle pour toute vraie feature / vrai changement d'UX, jamais pour un bugfix ; demander en cas de doute). - CHANGELOG v1.4.0 : puce user-facing pour la carte AskUserQuestion. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… du binaire claude Modeles: labels Opus 4.8->Opus 5, Sonnet 4.6->Sonnet 5; Sonnet 5 gagne xhigh (+ Ultra code). Gestion update CLI: nouveau service cli_update (version installee via claude --version, derniere publiee via registry npm, claude update borne, toggle auto-update via env.DISABLE_AUTOUPDATER ecrit par extensions), bandeau dismissable + section Reglages > Updates > Claude Code CLI; extensions gagne SETTINGS_WRITE_LOCK; gate auto-update correct pour npm/brew (verifie sur le binaire). Durci par revue adversariale (10 findings corriges). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… Claude Code) La section « Claude Code CLI » arrivait collée sous le bouton de la section app (titre de carte sans respiration), et les deux updaters affichaient chacun un « Check for updates » identique à 150 px d'écart — impossible de savoir lequel mettait quoi à jour. - Un seul PageHead « Updates » couvre les deux ; chaque updater devient une carte titrée (FLIGHT DECK / CLAUDE CODE CLI) → marges du kit, symétrie. - Une seule action par carte : le CTA d'installation de l'app quitte le bas du hero pour sa carte (le hero reste l'ANNONCE, la carte porte l'ACTION). - Nouvelle brique partagée VersionStatus (SettingsKit) : version installée en pastille mono, flèche vers la nouvelle, point d'état (vert à jour / coral MAJ dispo / gris inconnu — une version illisible n'est jamais maquillée en « à jour ») + détail d'install. Utilisée par les DEUX cartes pour qu'elles se lisent comme un seul système. - Toggle « Update banner » retiré, ainsi que la pref showClaudeCliBanner : le dismiss par version EST l'interrupteur, et il se ré-arme à la version suivante. - mockBindings : ?cliUpdate rend l'état « mise à jour disponible », sinon invérifiable tant qu'Anthropic n'a pas publié plus récent que l'installé. tsc + 953 tests verts. Vérifié visuellement (navigateur + mock) dans les 3 états : à jour, MAJ CLI dispo, MAJ app + CLI dispo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…CLI Claude Code Le bump v1.4.0 (2a9535f) précédait 3de1745 (catalogue de modèles + gestion des mises à jour du binaire `claude`) et 5aecc7c (onglet Updates en deux cartes) — la section du CHANGELOG ne les mentionnait donc pas. Comme release.yml compose les notes GitHub ET les notes affichées in-app à partir de cette section, la v1.4.0 serait sortie sans ses deux changements les plus visibles. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… exacts `QuestionCard` réimplémentait inline le sélecteur `useToolResult` du store — il l'utilise désormais, une seule lecture de tool_result partagée. Commentaires remis en accord avec le code : la carte n'a plus « THREE surfaces » (depuis que `groupBlocks` peel `AskUserQuestion` en segment `question`, la branche `ToolDetail` est un filet inatteignable, désormais documentée comme tel), et `SubAgentTranscript` n'est pas une surface « LIVE » (transcript à froid, résultats fournis depuis le disque). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…stes Le switch « Automatic updates » ne pilotait qu'UNE des deux portes que le CLI honore : il écrit `env.DISABLE_AUTOUPDATER`, mais `autoUpdates:false` dans `~/.claude.json` — fichier qui appartient à `claude` et qu'on n'écrit jamais — peut tenir l'auto-update fermé quand même. L'activer semblait marcher puis revenait tout seul à la relecture suivante, sans un mot. - `ClaudeCliStatus` gagne `auto_update_locked` : dans ce cas le switch est DÉSACTIVÉ avec la raison en texte visible, plutôt qu'un contrôle qui ne fait rien. Règle générale ajoutée à CLAUDE.md (« un réglage qu'on ne peut pas tenir ne doit pas être offert »). -⚠️ La raison ne peut PAS vivre dans un tooltip : un contrôle désactivé ne reçoit pas d'événements de survol, son `title` ne s'affiche jamais. `ToggleRow` prend donc `disabled` seul, l'explication va dans le `hint`. - Écriture acceptée ≠ réglage pris en compte : relecture disque derrière chaque write. `refresh()` est sérialisé (le garde `if (loading) return` avalait cette relecture) et renvoie son succès ; une lecture partie AVANT le write est ignorée (`writeEpoch`) pour ne pas faire rebondir le switch. Un read-back raté est dit, pas passé pour un état confirmé. - `error` (échec d'update, seul montrable par le bandeau, dont le bouton relance un update) séparé de `toggleError` (échec du switch, Réglages), qui se nettoie à la réouverture au lieu de rester à vie. - Échec de `claude update` : lire stderr d'abord — stdout n'est PAS vide (il portait la progression), on rapportait donc « Checking for updates… » comme cause. Et la ligne de résultat est trouvée par marqueur en remontant, plus « la dernière ligne » (une ligne de queue suffisait à lire un vrai update comme un no-op). - « Claude CLI not detected » n'est plus affirmé avant qu'une sonde ait répondu. - Démarrage : 1er check différé de 20 s, et requête npm sautée si aucun `claude` n'est installé (un utilisateur Codex-only ne paie aucun appel réseau). - Les deux bandeaux de MAJ ne s'empilent plus (prédicat pur `isUpdateBannerVisible`, qui tient aussi pendant un re-check pour ne pas clignoter) ; celui du CLI garde le créneau tant que SON update tourne ou vient d'échouer. CLAUDE.md : `cli_update/` dans la structure et les services encapsulés, les 3 commandes IPC dans la surface, `claudeCliUpdate.ts` dans les stores, l'onglet Updates à deux cartes, et `SETTINGS_WRITE_LOCK` dans la règle anti-race. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release v1.4.0. Voir les commits de dev depuis la dernière release.