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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
# Managed by IssueSpec. Hand edits are welcome; keep the schema valid.
id: 4
title: "Spécifier le format du fichier de configuration YAML"
state: closed
author:
name: k33g
email: ph.charriere@gmail.com
createdAt: 2026-10-29T07:20:02.000Z
updatedAt: 2026-10-29T08:51:00.000Z
labels:
- "kind::chore"
- "documentation"
- "area::config"
- "citizen-ux"
- "priority::high"
- "size::S"
milestone: "Initialize"
epic: "Specifications"
body: |
## Contexte
Le draft [#1 — draft](.tickets/issues/0001-draft.yaml) demande un fichier de configuration **YAML** (et non JSON comme Zed) « pour faciliter la UX », qui décrit au minimum les agents et les channels, avec un emplacement par défaut et la possibilité d'en choisir un autre.
## Pourquoi le spécifier avant de coder
- C'est un **contrat avec l'utilisateur** : une fois des fichiers en circulation, changer le format casse leurs configs. On ajoute donc un champ `version:` dès le départ.
- Le citizen user éditera ce fichier dans le panel Settings ([#18 — Panel Settings : éditeur YAML intégré](.tickets/issues/0018-panel-settings-editeur-yaml-integre.yaml)) : les noms de clés doivent être compréhensibles, les valeurs par défaut généreuses, les erreurs explicables.
- Il faut trancher **ce qui va dans le YAML vs dans Pebble** (cf. [#5 — Définir l'architecture et le modèle de données](.tickets/issues/0005-definir-l-architecture-et-le-modele-de-donnees.yaml)) : la config décrit *ce qui existe* (agents, définition des channels), Pebble stocke *ce qui se passe* (messages, sessions).
## Proposition de départ (à valider)
```yaml
version: 1
ui:
theme: dark
agents:
- name: alice # identifiant utilisé avec @alice
title: "👩 Alice (assistante)"
command: mm
args: ["-acp", "-config", "./agents/alice/agent.yaml"]
cwd: ./agents/alice # workspace
runtime: # local | sbx | container (cf. #28)
type: local
channels:
- name: général
agents: [alice]
```
## Emplacement
- Par défaut : `os.UserConfigDir()/sidekicks/config.yaml` (`~/Library/Application Support/sidekicks/` sur macOS).
- Surcharge : flag `--config`, variable `SIDEKICKS_CONFIG`, ou choix dans l'UI ([#19 — Choisir un autre fichier de configuration](.tickets/issues/0019-choisir-un-autre-fichier-de-configuration.yaml)).
- Les chemins relatifs sont résolus **par rapport au fichier de config** (permet de versionner un dossier « équipe d'agents »).
## Critères d'acceptation
- [ ] Schéma documenté (champs, types, défauts, exemples).
- [ ] JSON Schema produit (sert à la validation [#9 — Charger, valider et sauvegarder la configuration YAML](.tickets/issues/0009-charger-valider-et-sauvegarder-la-configuration.yaml) et à l'autocomplétion dans l'éditeur [#18 — Panel Settings : éditeur YAML intégré](.tickets/issues/0018-panel-settings-editeur-yaml-integre.yaml)).
- [ ] Exemple complet avec les 4 agents de test.
tasks:
- id: 1
title: "Lister les clés agents / channels / ui / runtime"
state: closed
priority: high
author:
name: k33g
email: ph.charriere@gmail.com
createdAt: 2026-10-29T07:20:02.000Z
updatedAt: 2026-10-29T08:51:00.000Z
closedAt: 2026-10-29T08:51:00.000Z
- id: 2
title: "Définir les règles de nommage (nom technique pour @ vs titre affiché)"
state: closed
priority: medium
author:
name: k33g
email: ph.charriere@gmail.com
createdAt: 2026-10-29T07:20:02.000Z
updatedAt: 2026-10-29T08:51:00.000Z
closedAt: 2026-10-29T08:51:00.000Z
- id: 3
title: "Définir l'emplacement par défaut et l'ordre de priorité des surcharges"
state: closed
priority: high
author:
name: k33g
email: ph.charriere@gmail.com
createdAt: 2026-10-29T07:20:02.000Z
updatedAt: 2026-10-29T08:51:00.000Z
closedAt: 2026-10-29T08:51:00.000Z
- id: 4
title: "Définir la résolution des chemins relatifs"
state: closed
priority: medium
author:
name: k33g
email: ph.charriere@gmail.com
createdAt: 2026-10-29T07:20:02.000Z
updatedAt: 2026-10-29T08:51:00.000Z
closedAt: 2026-10-29T08:51:00.000Z
- id: 5
title: "Écrire le JSON Schema"
state: closed
priority: medium
author:
name: k33g
email: ph.charriere@gmail.com
createdAt: 2026-10-29T07:20:02.000Z
updatedAt: 2026-10-29T08:51:00.000Z
closedAt: 2026-10-29T08:51:00.000Z
- id: 6
title: "Écrire l'exemple avec Alice, Bob, Riker, Garfield"
state: closed
priority: medium
author:
name: k33g
email: ph.charriere@gmail.com
createdAt: 2026-10-29T07:20:02.000Z
updatedAt: 2026-10-29T08:51:00.000Z
closedAt: 2026-10-29T08:51:00.000Z
comments:
- id: 1
author:
name: k33g
email: ph.charriere@gmail.com
createdAt: 2026-10-29T08:51:00.000Z
body: |
## Résultat
- Référence (EN/FR) : [docs/en/reference/configuration.md](docs/en/reference/configuration.md), [docs/fr/reference/configuration.md](docs/fr/reference/configuration.md).
- JSON Schema : [schema/config.schema.json](schema/config.schema.json), embarqué par le package Go `schema` (`ValidateConfig`), réutilisable par #9 et #18.
- Exemple avec les 4 agents de test : [examples/test-agents.yaml](examples/test-agents.yaml) — les agents passent par `scripts/agents.sh run`, donc la limite de 2 s'applique aussi à Sidekicks en dev.
- Tests : 4 documents valides, 12 invalides (chacun rejeté pour la bonne raison) — `make test`.
Choix notables : clés inconnues = erreurs (fautes de frappe signalées), `limits.maxRunningAgents` / `stopIdleAgentsAfter`, `runtime` en `if/then` plutôt que `oneOf` pour des erreurs lisibles, les règles inter-entrées (noms uniques, membres existants) relèvent du chargeur (#9).
|
