1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

# Managed by IssueSpec. Hand edits are welcome; keep the schema valid.
id: 39
title: "Workspace et terminal pour les sandboxes sbx"
state: closed
author:
  name: k33g
  email: ph.charriere@gmail.com
createdAt: 2026-10-29T18:17:05.000Z
updatedAt: 2026-10-30T05:43:02.000Z
labels:
  - "kind::feature"
  - "area::workspace"
  - "priority::medium"
  - "size::M"
milestone: "M4 · Workspace des agents"
epic: "Workspace des agents"
related:
  - 28
  - 31
body: |
  ## Contexte
  M4 a livré le workspace (fichiers, changements, terminal) pour les agents **locaux** et **en conteneur** ([#28 — Abstraire le workspace](.tickets/issues/0028-abstraire-le-workspace-local-sandbox-sbx-contain.yaml), [ADR 0007](docs/adr/0007-agent-workspaces.md)). Pour un agent `runtime: {type: sbx}`, la vue indique « not supported yet ».

  ## Pourquoi un ticket à part
  La CLI `sbx` n'est pas disponible dans la sandbox de développement : impossible de vérifier comment y exécuter un shell et y lire des fichiers. Le propriétaire a choisi de ne pas écrire de code non testé.

  ## Périmètre
  - Établir, sur le Mac, la commande qui exécute une commande dans une sandbox (équivalent de `docker exec`, avec et sans TTY).
  - Implémenter `workspace.Sandbox` sur le modèle de `workspace.Container` (mêmes scripts POSIX), et le brancher dans `workspace.For`.
  - Faire passer la suite de tests de contrat (là où `sbx` est disponible).
  - Vérifier que fermer le terminal termine bien la session dans la sandbox.

  ## Critères d'acceptation
  - [ ] La vue d'un agent sbx montre ses fichiers et ouvre un terminal.
  - [ ] La suite de contrat passe sur une sandbox.
tasks:
  - id: 1
    title: "Établir la commande d'exécution dans une sandbox (TTY ou non)"
    state: closed
    priority: medium
    author:
      name: k33g
      email: ph.charriere@gmail.com
    createdAt: 2026-10-29T18:17:05.000Z
    updatedAt: 2026-10-30T05:43:02.000Z
    closedAt: 2026-10-30T05:43:02.000Z
  - id: 2
    title: "Implémenter workspace.Sandbox"
    state: closed
    priority: medium
    author:
      name: k33g
      email: ph.charriere@gmail.com
    createdAt: 2026-10-29T18:17:05.000Z
    updatedAt: 2026-10-30T05:43:02.000Z
    closedAt: 2026-10-30T05:43:02.000Z
  - id: 3
    title: "Terminal dans une sandbox sbx"
    state: closed
    priority: medium
    author:
      name: k33g
      email: ph.charriere@gmail.com
    createdAt: 2026-10-29T18:17:05.000Z
    updatedAt: 2026-10-30T05:43:02.000Z
    closedAt: 2026-10-30T05:43:02.000Z
  - id: 4
    title: "Tests de contrat sur une sandbox"
    state: closed
    priority: medium
    author:
      name: k33g
      email: ph.charriere@gmail.com
    createdAt: 2026-10-29T18:17:05.000Z
    updatedAt: 2026-10-30T05:43:02.000Z
    closedAt: 2026-10-30T05:43:02.000Z
comments:
  - id: 1
    author:
      name: k33g
      email: ph.charriere@gmail.com
    createdAt: 2026-10-30T05:43:02.000Z
    body: |
      ## Résultat — vérifié, issue fermée

      `sbx exec [-i|-it] <sandbox> …` se comporte comme `docker exec` : conteneurs et sandboxes partagent une seule implémentation, `workspace.Remote` (outil `docker` ou `sbx`), qui n'utilise que `exec`, `-i` et `-it` — le dossier et `TERM` sont réglés dans le script du shell. sbx monte le dossier de l'hôte au même chemin : `workspacePath` vaut par défaut `workspace`.

      Vérifié par le propriétaire sur `milo-sbx` : la suite de contrat complète (`SIDEKICKS_TEST_SBX=milo-sbx go test -run TestSandboxWorkspace ./internal/workspace`, 11/11), puis l'agent Milo dans l'interface (fichiers, terminal, conversation). Documentation : guides « Lancer un agent dans une sandbox sbx » et « … dans un conteneur Docker » (EN/FR), [ADR 0007](docs/adr/0007-agent-workspaces.md).