# Software-Bibliothek

Zentrale Softwareverteilung für den Betrieb: Ein Server hält Installer und interne
Werkzeuge auf dem aktuellsten Stand, alle anderen laden sie über den Browser herunter.

Die Bibliothek holt sich die Dateien selbst — aus GitHub-Releases, über winget, aus SVN,
von einem Direktlink oder indem sie ein Git-Repository klont und baut. Es wird nichts von
Hand hochgeladen, und niemand muss mehr suchen, ob eine Version noch aktuell ist.

Die technische Innensicht steht in [ARCHITEKTUR.md](ARCHITEKTUR.md).

---

## Betrieb

### Die fertige Programmdatei

Der Auslieferungsstand ist eine einzelne `software-bibliothek.exe`. Sie braucht kein
installiertes Node, keine Laufzeitumgebung und keine Installation — ablegen, starten,
fertig. Beim ersten Start legt sie ihren Datenordner an und meldet im Fenster, wo er liegt.

```
Software-Bibliothek läuft auf http://localhost:3000
Daten:         C:\ProgramData\Software-Bibliothek\data
Einstellungen: C:\ProgramData\Software-Bibliothek\konfiguration.json
```

### Wo die Daten liegen

Standard ist `%ProgramData%\Software-Bibliothek` — bewusst außerhalb des Programmordners,
damit ein Austausch der Programmdatei nichts mitreißt. Ein anderer Ort lässt sich in den
Einstellungen hinterlegen (Zahnrad oben rechts, nur direkt am Server erreichbar).

| Unterordner | Inhalt |
|---|---|
| `files/<id>/` | Die bereitgestellten Programmdateien — das, was heruntergeladen wird |
| `sources/<id>/` | Arbeitskopien der Git-Repositories, die selbst gebaut werden |
| `secrets/<id>.json` | Hinterlegte API-Schlüssel; Zugriff auf SYSTEM, Administratoren und das Dienstkonto beschränkt |
| `bibliothek.db` | Katalog und Zugriffsprotokoll (SQLite) |

Für die Datensicherung genügt dieser Ordner.

### Wer was darf

Die Grenze verläuft an der Netzwerkschnittstelle, nicht an einer Anmeldung:

- **Direkt am Server** (`localhost`) — vollständige Verwaltung: Einträge anlegen, ändern,
  löschen, Quellen prüfen, Schlüssel hinterlegen, Einstellungen, Zugriffsprotokoll.
- **Aus dem Netzwerk** — Katalog ansehen und herunterladen. Jede verwaltende Route
  antwortet mit 403.

Jeder Download wird protokolliert: Zeitpunkt, IP, aufgelöster Rechnername, Programm.

### Aktualität

Einmal täglich prüft die Bibliothek alle Quellen selbsttätig; „Alle prüfen" stößt es von
Hand an. Liefert eine Quelle nichts Brauchbares — Seite tot, HTML statt Programmdatei,
plötzlich winzige Datei — bleibt die zuletzt bereitgestellte Datei unangetastet und der
Eintrag meldet das Problem. Ein kaputter Link führt nie dazu, dass ein funktionierender
Download verschwindet.

---

## Entwicklung

Node 22 oder neuer (die eingebaute SQLite-Schnittstelle wird gebraucht), npm-Workspaces.

```bash
npm install
```

Server und Oberfläche laufen getrennt:

```bash
npm run dev:server
```

```bash
npm run dev:client
```

Der Server bedient `http://localhost:3000` und liefert dort auch die gebaute Oberfläche
aus. Der Entwicklungsserver auf `http://localhost:5000` bringt Hot Reload mit und leitet
`/api` an Port 3000 weiter — Änderungen an der Oberfläche sind dort sofort sichtbar, auf
Port 3000 erst nach einem Bau.

### Aufteilung

| Paket | Inhalt |
|---|---|
| `packages/bibliothek-types` | Gemeinsame Typen — der Vertrag zwischen Server und Oberfläche |
| `packages/bibliothek-server` | Express, SQLite, Bezugsquellen, Zugriffsgrenze |
| `packages/bibliothek-client` | Oberfläche aus dh-components (Lit) |

### Bauen

```bash
npm run build
```

```bash
npm run build:exe
```

Der zweite Befehl erzeugt die eigenständige Programmdatei: TypeScript übersetzen, den
Server mit esbuild bündeln, die Oberfläche als Ressourcen einbetten und beides über Nodes
Single-Executable-Verfahren in eine `.exe` schreiben.

---

## Ein internes Werkzeug anbinden

Werkzeuge, die selbst gebaut werden, beschreiben ihren Bau im eigenen Repository — die
Bibliothek muss nichts über sie wissen. Dafür liegt eine `software-bibliothek.json` im
Wurzelverzeichnis:

```json
{
  "buildCommand": "npm install && npm run build-win",
  "artifact": "dist/MeinWerkzeug.exe"
}
```

Braucht der Bau einen API-Schlüssel, wird er dort deklariert und sein Wert in der
Bibliothek hinterlegt; beim Bau steht er als Umgebungsvariable bereit. Das vollständige
Verfahren beschreibt der Skill `build-secrets` im Repository `dh-claude-rules`.

Im Katalog wird als Quelle **nur die Repository-URL ohne Benutzernamen** eingetragen — die
Kennung kommt aus den Einstellungen der Bibliothek, damit ein Kontowechsel nicht jeden
Eintrag berührt.

---

## Offen

- HTTPS; solange die Verbindung unverschlüsselt ist, bleiben dem Browser die Schnittstellen
  für Dateizugriff verwehrt
- Betrieb als Windows-Dienst mit Autostart
- Automatisierte Tests
- Rollen und Rechte (im Ticket bewusst zurückgestellt)