Scripts

 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

# Scripts

*[English version](README.md)*

## `launch-ori.applescript` — démarrer le sandbox et ouvrir ori-desktop

Un seul geste au lieu de deux commandes : le script démarre (ou redémarre) le sandbox `ori`, attend que le serveur ori réponde, puis ouvre l'application desktop.

Ce qu'il fait, dans l'ordre :

1. Retrouve la racine du dépôt à partir de son propre emplacement (`<dépôt>/scripts/…`). Renseigne la propriété `repoDirOverride` en tête de fichier si tu le déplaces ailleurs.
2. Vérifie que `ori-desktop/build/bin/ori-desktop.app` existe ; sinon il affiche comment la construire (`cd ori-desktop && wails build && xattr -cr build/bin/ori-desktop.app`).
3. Si `sbx ls -q` liste déjà un sandbox nommé `ori`, le redémarre avec `sbx run -d --name ori`. Sinon il le crée :
   ```bash
   sbx run -d claude . --template k33g/ori:0.0.2 --kit ./kits/ori --name ori -p 5555:8888/tcp
   ```
4. Interroge `http://localhost:5555/healthz` toutes les 2 s, jusqu'à 90 s (`healthTimeoutSeconds`). Si le serveur ne répond jamais, il ouvre quand même l'app et indique où regarder : `sbx exec ori cat /var/log/sbx-kit-startup.log`.
5. Ouvre `ori-desktop.app`, qui se connecte automatiquement à l'URL mémorisée la dernière fois (`~/Library/Application Support/ori-desktop/settings.json`, clé `serverUrl`). Saisis `http://localhost:5555` sur l'écran de connexion la première fois.

Template, kit, ports, nom du sandbox et délai sont des lignes `property` en tête du script.

### Lancer depuis un terminal

```bash
osascript scripts/launch-ori.applescript
```

### Le rendre double-cliquable

Compile le script en bundle d'application :

```bash
osacompile -o "scripts/Launch Ori.app" scripts/launch-ori.applescript
```

- Double-clique sur `scripts/Launch Ori.app` dans le Finder, glisse-le dans le Dock, ou lance-le depuis Spotlight (« Launch Ori »).
- Le `.app` est un artefact de build, ignoré par git (`scripts/*.app/`). Recompile-le après chaque modification du `.applescript`.
- Construit localement, il ne porte pas d'attribut de quarantaine : Gatekeeper ne le bloque pas. macOS demandera peut-être une fois l'autorisation d'afficher des notifications.
- La progression est signalée par des notifications ; un échec bloquant (app non construite, `sbx run` en erreur, le plus souvent parce que Docker Desktop ne tourne pas) ouvre une boîte de dialogue.

### Pourquoi ces choix

- **Un lancement depuis le Finder reçoit un `PATH` minimal** sans `/opt/homebrew/bin` : le script l'exporte avant chaque commande shell.
- **`sbx run -d`** (détaché) rend la main dès que le sandbox existe et l'exempte de l'arrêt automatique de sbx après 30 s. Le kit démarre ensuite le serveur ori de façon asynchrone, d'où l'attente sur `/healthz` avant d'ouvrir l'app.
- **Redémarrer plutôt que recréer** quand le sandbox existe : relancer la commande de création échouerait sur le nom, et `sbx rm` + création perdrait la session Claude du sandbox.

### Tester les handlers sans créer de sandbox

```bash
osacompile -o /tmp/launch-ori.scpt scripts/launch-ori.applescript
osascript -e 'set s to load script POSIX file "/tmp/launch-ori.scpt"
set s'"'"'s healthTimeoutSeconds to 4
return s'"'"'s waitForServer("http://localhost:5555")'   # false sauf si quelque chose répond sur :5555
```