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.
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
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.
Die Grenze verläuft an der Netzwerkschnittstelle, nicht an einer Anmeldung:
localhost) — vollständige Verwaltung: Einträge anlegen, ändern,Jeder Download wird protokolliert: Zeitpunkt, IP, aufgelöster Rechnername, Programm.
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.
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.
| 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) |
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.
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.