Référence : commandes

 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

# Référence : commandes

## `sidekicks`

```text
sidekicks [--config <fichier>]
```

| Option / variable | Effet |
| --- | --- |
| `--config <fichier>` | Fichier de configuration à utiliser. Prioritaire sur tout le reste. |
| `SIDEKICKS_CONFIG` | Fichier de configuration quand `--config` n'est pas donné. |
| (aucune) | `<dossier de config utilisateur>/sidekicks/config.yaml`, créé avec des commentaires s'il manque. |

L'ordre est détaillé dans la [référence de la configuration](configuration.md#emplacement).

## Cibles `make`

| Cible | Effet |
| --- | --- |
| `help` | Liste les cibles. |
| `install` | `pnpm install` dans `frontend/` (binaires natifs macOS et Linux). |
| `bindings` | Régénère `frontend/bindings` à partir des services et événements Go (`wails3 generate bindings -clean=true -ts -i`). |
| `frontend` | `install`, puis construit `frontend/dist`. |
| `dev` | `wails3 dev` : l'application avec rechargement à chaud. |
| `build` | `wails3 build` : `bin/sidekicks`. |
| `package` | `wails3 package` : sous macOS `bin/sidekicks.app`. |
| `package-linux` | `scripts/package.sh linux` : `.deb`, `.rpm`, `.AppImage` et `.tar.gz` pour l'architecture de la machine, dans `dist/`. Demande `file` (AppImage) et `rpm`. |
| `package-windows` | `scripts/package.sh windows amd64` puis `arm64` : installateur NSIS et `.zip` pour chacun, compilés depuis Linux ou macOS, dans `dist/`. Demande `makensis` et `zip`. |
| `release-build` | `scripts/build-release.sh` : sur le Mac, tous les paquets de release (macOS arm64, Windows amd64 et arm64) dans `dist/` et `SHA256SUMS`. |
| `release-tag` | `scripts/tag-release.sh` : tague `v<version>` sur `main` et le pousse. |
| `package-macos` | `scripts/package.sh macos` : `.dmg` et `.zip` pour Apple Silicon (arm64, signés ad hoc ; pas de build Intel), dans `dist/`. macOS seulement. |
| `install-test-config` | `scripts/install-test-config.sh` : écrit `examples/test-agents.yaml` à l'emplacement par défaut de la configuration, avec des chemins absolus vers le dépôt : chaque agent est `mm -acp -config agent.yaml` lancé dans son dossier, avec `afterStop: [<dépôt>/scripts/agents.sh, unload, <agent>]` pour décharger son modèle à l'arrêt, `mm` écrit avec son chemin absolu (`MM_BIN`, ou celui du `PATH`), et le `PATH` courant dans l'`env` de chaque agent ; un fichier existant est gardé sous `config.yaml.<date>.bak`. |
| `check` | `lint` puis `test`. |
| `verify` | `check` puis `bindings-check` : ce qu'il faut lancer avant de fusionner (il n'y a pas de CI). |
| `check-linux` | `scripts/check-linux.sh` : `make check` dans le conteneur Linux de `scripts/linux-packages.Dockerfile` (`LINUX_ARCH`, par défaut l'architecture du Mac), le dépôt monté sur `/src`. Demande Docker. |
| `test` | `test-go`, `test-frontend`, `test-scripts`. |
| `test-go` | `go test ./...` (construit `frontend/dist` d'abord s'il manque). |
| `test-frontend` | `vitest run` dans `frontend/`. |
| `test-scripts` | `scripts/agents_test.sh`, `scripts/check-license-headers_test.sh`, `scripts/package_test.sh` et `scripts/tag-release_test.sh`. |
| `test-real` | `go test -tags realagents -count=1 ./...` — nécessite `mm` et llmman. |
| `lint` | `lint-go`, `lint-frontend`, `lint-headers`. |
| `lint-go` | golangci-lint v2.14.0 (`tools/go.mod`), configuration `.golangci.yml`. |
| `lint-frontend` | `svelte-check`. |
| `lint-headers` | `scripts/check-license-headers.sh`. |
| `bindings-check` | `bindings`, puis échoue si `frontend/bindings` diffère de l'index (`git diff`) ou contient des fichiers que git ne connaît pas. |

## `scripts/check-license-headers.sh`

```text
scripts/check-license-headers.sh [racine du dépôt]
```

Liste les fichiers sources (`.go .ts .js .svelte .css .html .sh .py .yml .yaml`, `Makefile`) connus de git dont les trois premières lignes ne contiennent pas `Sidekicks Source-Available License`, et se termine avec le code 1 s'il y en a. Non vérifiés : `frontend/bindings`, `build/` et `Taskfile.yml` de Wails, `*.d.ts`, `pnpm-lock.yaml`, `vite.config.ts`, `svelte.config.js`, `agents/`, `*/testdata/*`, `git.sh`, `new.*.sh`, `tag-step.sh`, `.claude/`, `.tickets/`.

## `scripts/package.sh`

```text
scripts/package.sh linux | windows [amd64|arm64] | macos
scripts/package.sh names <système> <arch>
scripts/package.sh release-names
scripts/package.sh version
```

| Commande | Effet |
| --- | --- |
| `linux`, `windows`, `macos` | Construit les paquets de ce système dans `dist/` (voir les cibles `package-*`), puis liste `dist/`. |
| `names <système> <arch>` | Affiche les noms des fichiers qu'un build produit, un par ligne ; ne construit rien. |
| `release-names` | Affiche les fichiers d'une release : les noms de chaque cible de `RELEASE_TARGETS` (`macos/arm64 windows/amd64 windows/arm64`), puis `SHA256SUMS`. Utilisé par `tag-release.sh` et le workflow Release. |
| `version` | Affiche `info.version` de `build/config.yml`. |

| Système | Fichiers (`<v>` = version) |
| --- | --- |
| `linux` | `sidekicks_<v>_linux_<arch>.deb`, `.rpm`, `.tar.gz`, `Sidekicks-<v>-<x86_64\|aarch64>.AppImage` |
| `windows` | `Sidekicks-<v>-windows-<amd64\|arm64>-installer.exe`, `sidekicks_<v>_windows_<amd64\|arm64>.zip` |
| `macos` | `Sidekicks-<v>-macos-arm64.dmg`, `Sidekicks-<v>-macos-arm64.zip` |

## `scripts/build-release.sh`

```text
[WINDOWS_ARCHES="amd64 arm64"] [LINUX_ARCHES="amd64"] [SKIP="macos windows"] scripts/build-release.sh
```

Vérifie d'abord tous les prérequis, puis vide `dist/` et construit : macOS avec `scripts/package.sh macos` (macOS seulement), Windows avec `scripts/package.sh windows <arch>` pour chaque architecture de `WINDOWS_ARCHES` (par défaut `amd64 arm64` ; demande `makensis` et `zip`), et, seulement si `LINUX_ARCHES` est défini (vide par défaut : pas de Linux dans les releases pour le moment), Linux avec `scripts/package.sh linux` dans un conteneur par architecture, construit depuis `scripts/linux-packages.Dockerfile` (`ubuntu:26.04`, Go de `go.mod`, pnpm de `frontend/package.json`, CLI Wails) avec le dépôt monté sur `/src` et le cache des modules Go dans le volume `sidekicks-gomod-<arch>`. Écrit enfin `dist/SHA256SUMS`. `SKIP` laisse de côté les systèmes qu'il nomme. Échoue, avant de rien construire, si un prérequis manque (hôte macOS, `makensis`, `zip`, Docker pour Linux).

## `scripts/tag-release.sh`

```text
scripts/tag-release.sh [--remote <nom>] [--no-push]
```

Crée le tag annoté `v<version>` (`info.version` de `build/config.yml`, message `Sidekicks <version>`) et le pousse sur `--remote` (par défaut `origin`). Refuse si des fichiers suivis sont modifiés, si la branche courante n'est pas `main`, si `main` diffère de `<remote>/main` après un fetch, ou si le tag existe en local. Avertit, sans refuser, s'il manque dans `dist/` un paquet de la version ou `SHA256SUMS`. `--no-push` tague en local seulement.

## Workflow de release

`.github/workflows/release.yml`, au push d'un tag `v*`, avec `permissions: contents: write` : échoue si le tag n'est pas `v` + `info.version` de `build/config.yml`, puis crée la release `<tag>` nommée `Sidekicks <tag>` (`softprops/action-gh-release@v2`, via l'API compatible GitHub de Rickub derrière `GITHUB_API_URL`), avec des notes qui donnent le commit, les guides d'installation et le tableau des fichiers attendus (tirés de `scripts/package.sh release-names`). Il n'attache aucun fichier : les paquets sont attachés à la main.