Repository navigation
[MCP host] Share one engineering Canvas across a project’s conversations #55
Description
User outcome
A project has one shared Canvas for work produced in its multiple conversations. Open it from any conversation in the project and return to that exact chat. Tools belong to the project (#62), not each conversation.
Updated user decision: 2026-09-30. Parent #48. Project entry #61, shared tools #62, retained bytes #51, existing-work migration #63. This replaces the original conversation-owned Canvas scope; the current implementation is a useful component, not completion of this new acceptance.
Reuse and authority
Use the existing authoritative EngineeringProject id. Desktop owns presentation metadata keyed by that id: positions, groups, notes and exact (conversationId, viewerId) references. Reuse the current Canvas components and #51's archived source/result/export store; do not make a second artifact archive.
Project creation from intent through #61 does not require an approved brief. A direct tool result remains session work; organizing it on the Canvas does not publish Thread/CAS evidence, authorize MRTR, infer an engineering dependency, or run a solver.
Acceptance
- Open the same optional Canvas from either of two conversations under one project, including an empty new conversation.
- List and place exact retained results/viewers from every conversation in that project, with visible source conversation and version; open the owning chat/result.
- Provide names, groups, positions and lightweight notes. Present tool settings at project scope, shared with Chat.
- Preserve drafts and conversation history when switching Chat/Canvas or selecting another conversation; changing chat does not select a different Canvas.
- New results appear as project work without copying bytes or losing original ids/provenance.
- Persist one project layout and restore it after app restart, with acknowledgements/ordering that prevent stale writes. Reopen archived work offline without rerunning a provider.
- Reject cross-project references and maintain the owning-session boundary for live App tools/resources. Agent sessions remain distinct even though the Canvas is shared.
- Referenced artifacts participate in retention: closing/pruning a source chat cannot silently break the shared Canvas or discard its retained bytes.
- Existing per-conversation Canvas content can be imported explicitly through [MCP host] Attach existing chats and Canvas work to projects without losing artifacts #63 with origin retained and conflicts handled honestly.
- Native proof: project “Pièce test” → two chats using one enabled Build123d → both results placed on the common Canvas → export → close/reopen, with the exact same layout and archived result identities.
Scope
This owns the project Canvas and reference/persistence behavior. #61 owns project navigation, #62 owns tool activation/runtime context, #51 owns bytes, and #6 owns optional explicit selection-to-chat handoff. Reuse the existing whiteboard/viewer components rather than building a parallel Canvas product. #43 concerns density of authoritative Evidence graphs and remains distinct.
Activity
superWorldSavior commentedon Sep 30, 2026
Revue indépendante Sol + confirmation par le coordinateur au commit propre
0be84e7edba3c2f71f87d01867104039c048b3be(30 septembre 2026) : FIX FIRST. Canvas existe, s'ouvre depuis le chat et possède un modèle/layout persisté avec notes, noms et tâches. Deux écarts restent avant clôture.1. P1 — quitter Canvas avant 500 ms perd la dernière édition.
save(src/ui/src/thread/chat-canvas.tsx:99) retarde l'envoicanvas.set-layout, puis le cleanup d'unmount annule ce timer. Ajouter/éditer une note, un titre, une tâche ou une position puis revenir immédiatement au chat/sélectionner une autre conversation annule donc l'unique sauvegarde.Reproduction
/tmp/canvas-save-unmount-repro.mjs: les closures sont extraites du fichier réel, avec hooks/horloge simulés (pas de réécriture du comportement). Même édition : rester 500 ms → 1 commandecanvas.set-layout; quitter avant → 0 commande, même après avance de l'horloge. Relancée indépendamment avecnode /tmp/canvas-save-unmount-repro.mjs. Pas de navigateur natif utilisé pour cette reproduction. Assurer la sauvegarde du dernier layout de la bonne conversation lors de la sortie, et rendre un échec explicite ; ne pas conserver seulement l'état React local.2. P2 — Canvas ne montre pas la liste des fichiers et versions conservés.
La branche Canvas (
src/ui/src/thread/desktop-chat.tsx:814) ne rend que ChatCanvas ; la liste Saved work (src/ui/src/thread/desktop-chat.tsx:858) reste dans la branche chat. Les viewers et notes sont disponibles, mais les fichiers/export versions/états d'archive ne constituent pas une liste inspectable dans Canvas, contrairement au deuxième critère d'acceptation. Réutiliser les résultats conservés de #51, sans second store. Le défaut d'identité entre profils de #51 concerne également les associations Canvas.Validation : 39 tests ciblés contrats/modèle/coordinateur/store Canvas passent ;
deno task check:uipasse. Le lint sur les sources modifiées échoue sur 6 erreurs nouvellesno-window/no-window-prefixaux lignes 99, 102, 103 dechat-canvas.tsx. Aucun fournisseur ou LLM réel appelé, aucun fichier dépôt modifié. Les tests actuels ne couvraient pas la sortie pendant le délai de sauvegarde.superWorldSavior commentedon Sep 30, 2026
Implémentation reprise et validée le 2026-09-30. Changements dans le commit local, non poussé
070f66c8surcodex/desktop-mcp-host-reliability; ces preuves ne sont pas une livraison surmain.Canvas attend l'acquittement de stockage avant Back/changement de conversation, garde les éditions en attente après un échec et propose une reprise. La file de sauvegarde survit au démontage du Canvas. Saved work est également visible dans Canvas, avec export direct des sources/fichiers archivés.
Tests ciblés de latence/échec/reprise : verts. La preuve réelle du host final sauve trois références viewer, quitte, puis les retrouve inchangées hors ligne. Cela prouve la persistance via le contrat host ; les gestes et le rendu du WebView natif restent à mesurer. Aucune preuve de résistance à une coupure électrique avant acquittement n'est revendiquée.
[-][MCP host] Open an optional engineering Canvas from any conversation[/-][+][MCP host] Share one engineering Canvas across a project’s conversations[/+]