Skip to main content
Die StackKit Open Spec ist der schlanke, veröffentlichte Vertrag hinter „dem offenen Homelab-Standard“. Sie verzeichnet Artefakte, die mit jedem StackKits-Release ausgeliefert werden, und führt kein neues Schema ein. Die Spec-Version folgt dem Release-Tag, mit dem sie ausgeliefert wird, und Änderungen innerhalb von v0 sind additiv. Die kanonische Kopie liegt im öffentlichen Repository unter docs/OPEN-SPEC.md. Alles in der Spec kommt ohne Konto aus: Der Standard Mode braucht kein kombify-Konto, keinen gehosteten kombify-Endpunkt und kein Techstack.

​
1. Architektur-Snapshot

Der Architektur-Snapshot, der nur Fakten enthält, beschreibt ein Release: Kits, Topologie, Fähigkeiten, Platzierungsmodell, Module, Add-ons und Support-Reifegrad. CUE ist die technische Source of Truth; der Snapshot ist eine Projektion davon. Ein Konsument liest den Snapshot, nie das CUE, und muss additive Felder tolerieren.

​
2. Lebenszyklus-Verben

Jedes Kit wird über dieselben Verben durch das stackkit-CLI und den stackkit-mcp-Connector gesteuert. Ein- und Ausgaben sind in der CLI-Referenz und der CLI-Schritt-für-Schritt-Anleitung dokumentiert. Ein Verb endet entweder mit Nachweis oder schlägt mit einem endgültigen Grund fehl. Es meldet nie Erfolg für Arbeit, die es nicht geleistet hat.

​
3. Platzierungs-Taxonomie

Die Platzierung beschreibt, wo ein Kit oder Modul laufen darf. Das Vokabular ist in foundation/placement.cue veröffentlicht:
  • #PlacementMode: local-only, standard, managed-serverless
  • #PlacementSupport: Eignungs-Metadaten pro Modul (in welchen Modi ein Modul laufen kann)
Der Open-Source-Lebenszyklus setzt local-only und standard um. managed-serverless sind reine Eignungs-Metadaten; die Umsetzung liegt außerhalb von StackKits und außerhalb dieser Spec.

​
4. Verifikationsnachweise

Reifegrad-Begriffe sind durch Nachweise belegt, nie bloß deklariert. Die Nachweisformen sind öffentliche JSON-Schemas; das Release liefert die Instanzen mit. Vokabular:
  • Kits: supported (für die festgeschriebene Zelle existiert ein zitierter Verifikationspfad), preview (lässt sich installieren, aber Nachweise für Verifikation oder Wiederherstellung stehen aus), alpha (nur Definition).
  • Kompatibilitätszeilen (Betriebssysteme, Hypervisoren, Kits nach Umgebung, Anwendungen): supported (jede Lebenszyklus-Phase hat im neuesten Lauf auf dem Nachweis-Release bestanden), preview (Installation bis Verifikation bestanden; eine spätere Phase ist fehlgeschlagen) oder unverified (auf diesem Release noch kein abgeschlossener Lauf, oder der neueste Lauf ist vor der Verifikation fehlgeschlagen). Fehlende Nachweise werden als unverified veröffentlicht, nie als Unterstützung.
  • Ein Status wird nur erweitert, wenn ein zitierter Lauf für exakt dieses Release existiert.

​
5. Konformität

Ein Tool oder Dienst ist StackKit-kompatibel, wenn es
  1. den Architektur-Snapshot genau des Releases verwendet, auf das es zielt,
  2. Kits nur über die oben genannten Lebenszyklus-Verben steuert (direkt oder über den MCP-Connector) und deren Nachweise bewahrt,
  3. die Platzierung mit der veröffentlichten Taxonomie beschreibt und
  4. Verifikationsergebnisse in den oben genannten Nachweisformen mit dem Release-Tag veröffentlicht, zu dem sie gehören.

​
Status

Dies ist ein v0-Entwurf, veröffentlicht mit der öffentlichen Beta. Ein eigenes Spezifikations-Repository mit Versionierungsrichtlinie folgt nach der Beta; bis dahin sind das Repository-Dokument und die verlinkten Artefakte die Spec.