# CLAUDE.md

Thunderbird-MailExtension „HPS Vorlagen & Signaturen" mit Gitea-Sync.

## Workflow (WICHTIG)

1. **Nach jeder Code-Änderung am Plugin immer die `.xpi` neu bauen** (siehe Build unten),
   damit `templates-reply-hotel.xpi` aktuell ist.
2. **Sobald der User zufrieden ist ("happy"), committen** — Code-Änderung + neu gebaute
   `.xpi` zusammen. Nicht ungefragt vorher committen; auf das OK des Users warten.

## Build der .xpi

Immer **ohne** `defaults.local.json` bauen — die Datei enthält den Gitea-Token und darf
nicht in der (öffentlich released) `.xpi` landen. `zip` ist nicht installiert, `7z` schon:

```bash
rm -f templates-reply-hotel.xpi
7z a -tzip templates-reply-hotel.xpi . \
  -xr'!.git' -xr'!node_modules' -xr'!web-editor' -xr'!.claude' \
  -xr'!defaults.local.json' -xr'!*.xpi' -xr'!release.sh' -xr'!*.md'
```

`defaults.local.json` wird nur beim allerersten Start gelesen (`templates_options.js`,
`if (!config)`) und ist nur zum Vorkonfigurieren frischer Installationen gedacht. Updates
brauchen sie nicht — bestehende Installs behalten ihre Config in `storage.local`.

## Auto-Update (self-hosted über Gitea)

- `manifest.json` → `browser_specific_settings.gecko.update_url` zeigt auf `updates.json`
  (raw auf `main`). Repo muss öffentlich bleiben, sonst 401 für den anonymen Updater.
- Neues Release veröffentlichen: `version` in `manifest.json` bumpen, `.xpi` neu bauen, dann
  `GITEA_TOKEN=… ./release.sh` (hasht die xpi, aktualisiert `updates.json`, legt das Gitea-
  Release an + lädt die xpi hoch). `release.sh` bricht ab, falls der Token in der xpi steckt.
- Danach `updates.json` + `manifest.json` committen & pushen.

## Repo

- Sync-Daten-Repo (Templates/Signaturen): `hps/email-vorlagen` auf `git.hotel-park-soltau.de`.
- Plugin-Source + Release-Host: `kendrick.bollens/hps-thunderbird-templates`.
  **Muss public bleiben** — der Thunderbird-Auto-Updater greift anonym (ohne Token) auf
  `updates.json` und die Release-`.xpi` zu. Privat = 401 = Auto-Updates kaputt.