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.

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).

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.

npm install

Server und Oberfläche laufen getrennt:

npm run dev:server

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

Bauen

npm run build

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:

{
  "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)