Projects & Workspaces

Ce que c'est

Deux surfaces liées. Les Projects enregistrent une base de code (avec ses repos, son arborescence de fichiers et sa politique de périmètre) comme point d'ancrage des missions. Les Workspaces sont des dossiers de travail éphémères que les agents utilisent pour préparer des fichiers.

Surface opérateur

  • Projects — project_list, project_get, project_register, project_sync, project_delete, project_tree_get / project_tree_update, project_check_boundary.
  • Workspaces — workspace_create (renvoie le handle workspaceId dont tous les autres outils ont besoin), workspace_write_file, workspace_read_file, workspace_list_files, workspace_delete.

Côté REST, on trouve ProjectsController, WorkspaceDownloadController et les contrôleurs de connexions / onboarding ; le dashboard expose l'enregistrement des projets et les vues d'arborescence de fichiers.

Comment ça marche

Un ProjectRecord est relié à ses dépôts Git (ProjectConnection, ProjectMirrorMetadata, ProjectSubmodule) et stocke une arborescence enregistrée de fichiers / modules ainsi qu'une politique de périmètre que project_check_boundary applique pour que les agents restent à l'intérieur des chemins approuvés ; ProjectSession et PendingSync suivent l'état de synchronisation. Les Workspaces sont provisionnés dans un service genesis-workspace propre à chaque tenant et adressés uniquement par l'id qu'ils renvoient — ils sont délibérément séparés des repos de projet permanents, afin que les agents puissent gribouiller librement avant de produire des changements soumis à review.

Canevas de design

Une tâche de design (coding_task_dispatch avec taskType: "design", ou un nœud Coder de workflow dont le type de tâche est design) fait produire au coder un canevas de design — des maquettes multi-plans sous forme de fichiers .dc.html accompagnés d'une mise en page canvas.json, commités sous design/<slug>/ dans le dépôt du projet. Genesis assemble ces sources en un unique canevas pan/zoom et l'affiche sur la page du projet (/projects/{id}) et l'écran Aperçu ; chaque canevas s'ouvre à /projects/{id}/design/{taskId}/{slug}.

Il s'agit du skill propre à Genesis (genesis-design-canvas), et non de la fonctionnalité /design de Claude Code : le skill intégré et son outil Artifact exigent une connexion claude.ai que le coder, médié par le broker, n'a pas ; Genesis produit donc le même format .dc.html et réalise l'assemblage lui-même — rien n'est publié sur claude.ai. Le canevas est rendu dans une iframe srcdoc en bac à sable (origine opaque, allow-scripts uniquement), la même posture d'isolation d'origine que la vue conversation emploie pour les maquettes UI en ligne ; dans le dashboard il est en lecture-et-export seulement (pas de sauvegarde en retour), et c'est un chemin distinct, au rayon d'impact plus faible, que la voie de rendu des artefacts de run (voir artifacts).

Lorsqu'une direction visuelle est réellement ouverte, le coder esquisse 2 à 4 plans de direction basse fidélité, émet une demande d'attention (decision_create, une Clarification) et attend que l'opérateur réponde dans la file de décisions Genesis après avoir vu les directions sur le dashboard — seul un humain la résout (séparation des devoirs). Le coder construit ensuite la direction choisie dans Main.dc.html. Les tâches de design sont dispatchées explicitement ou intégrées à un workflow ; le décomposeur de mission n'en émet pas de lui-même.