Packs, Veröffentlichung und Vertrauen

Früher oder später muss deine Arbeit deine Maschine verlassen — ein Workflow, den jemand anderes ausführen soll, ein Block, auf dem Fremde aufbauen, ein Modell, das dein zukünftiges Ich reproduzieren muss. Scellis verschickt Arbeit als Pack: ein signiertes, versioniertes Bündel von Entitäten mit geschlossenem Abhängigkeitsgraphen — alles, was der Inhalt referenziert, reist entweder im Umschlag mit oder ist auf exakte Version und Content-Hash gepinnt. Diese Seite geht den Versandweg Schritt für Schritt ab: den Umschlag, das Lockfile, das Publikations-Gate, die Signatur, die Vertrauensleiter — und die Garantien, die Abhängige nie brechen lassen. Eine Unterscheidung vorweg: Ein Pack verschickt; ein Repository kuratiert; ein Listing verkauft. Drei Achsen, nie vermischt.

Ein Umschlag für alles, was verschickt wird#

Nicht jeder Export ist ein ganzes Pack. Es gibt fünf portable Ein-Datei-Formate — .scellis-workflow, .scellis-pack, .scellis-block-pack, .scellis-model, .scellis-dataset — und alle fünf teilen einen Umschlag. Das Manifest darin deklariert den Typ; die Bytes sind Byte für Byte reproduzierbar, derselbe Content ergibt zweimal exportiert also dieselbe Datei; und jeder Import verifiziert den Content-Hash, bevor irgendetwas in deinem Catalog landet. Eine Datei, die die Prüfung nicht besteht, wird abgelehnt — laut, in derselben kanonischen Diagnose, die jede Ablehnung auf der Plattform spricht. Es gibt keinen Import auf Bewährung und kein halbes Ankommen: verifizierte Bytes oder nichts.

Die Closure reist mit der Arbeit#

Das härteste Versprechen eines Packs ist Vollständigkeit — und Scellis überlässt sie nicht dem Gedächtnis der Autorin. Ruft dein Code andere Katalog-Entitäten auf — eine Op, eine Hilfsfunktion, einen Tokenizer —, löst sich jede dieser Nutzungen über ein Lockfile auf: eine automatisch abgeleitete Closure von allem, wovon die Arbeit abhängt, gepinnt auf Identität, exakte Version und Content-Hash, auf Zyklen geprüft. Dieselbe Closure ist es, die einen gespeicherten Workflow offline laufen lässt: Jeder gepinnte Hash liegt auf dem Gerät, bevor ein Run startet — geladen wird beim Authoring und bei der Installation, nie auf dem Ausführungspfad.

{
  "entity": "user/ada/robust-scaler",
  "version": 3,
  "content_hash": "sha256:9f2c41ac…",
  "uses": {
    "tensor/matmul@2": "sha256:41ac88d0…",
    "user/kim/winsorize@1": "sha256:b7e03f5e…",
    "text/tokenizer/bpe@4": "sha256:0d66c2a1…"
  },
  "effects": [],
  "min_engine": "1.4.0",
  "capabilities": ["webgpu.f16"]
}

Zwei Konsequenzen verdienen Nachdruck. Erstens: Effekte sind transitiv durch die Closure. Deklariert eine Abhängigkeit drei Ebenen tiefer Netzwerk-Egress, trägt das Pack diese Deklaration offen an der Stirn — ein „pures“ Wrapper-Stück kann keinen Aufruf durch seine Importe schmuggeln (wie Effekte überhaupt deklariert werden, zeigt Erweiterungen authoren). Zweitens: Die Installation löst dieselbe Closure auf dem Zielgerät erneut auf. Ein Pack ist nie fast installiert — entweder löst sich jeder Pin auf und verifiziert, oder die Installation verweigert und benennt den Pin, der scheiterte.

Die Veröffentlichung ist ein Preflight, kein Upload#

Du veröffentlichst eine committete Version, nie einen laufenden Entwurf. Entwürfe sind der Ort, an dem sich Dinge ändern; ein Commit ist das unveränderliche, inhaltsadressierte Artefakt, unter das du deinen Namen setzt — dieselbe Entwurf-gegen-Commit-Disziplin, die sich durch die Reproduzierbarkeit zieht. Auf dem Commit sitzt ein Gate, das das Bündel prüft, bevor irgendetwas rausgeht — und die Prüfungen selbst werden als Content ausgeliefert, die Latte kann also steigen, ohne dass die App ein Release braucht. Das Gate verlangt:

• Ein auflösbares Lockfile: jede Abhängigkeit gepinnt, jeder Pin auflösbar.
• Konformitätsnachweise: alles, was rechnet, trägt den Beleg seiner Übereinstimmung mit der Referenzimplementierung — bei einem GPU-Kernel das hash-gebundene ConformanceReceipt, das seine vertrauenswürdige Aktivierung überhaupt erst freigab.
• Eine Method Card: die menschenlesbare Darstellung dessen, was das ist und wie es sich verhält. Modelle ergänzen eine Model Card, Datensätze ein Datenblatt.
• Deklarierte Effekte: alles, was der Inhalt jenseits purer Berechnung berührt — Closure inklusive.
• Profil-Kompatibilität: deklariert, damit ein Gerät vor der Installation weiß, ob es das ausführen kann.
• Vollständige Metadaten und eine Lizenz: keine leeren Felder, wo ein Katalogeintrag stehen sollte — und nichts geht öffentlich ohne explizite SPDX-Lizenz.

Fehlt ein Stück, wird die Veröffentlichung verweigert — jedes fehlende Teil beim Namen genannt, nie still, nie mit einem generischen Fehler. Du behebst genau, was das Gate auflistet, und veröffentlichst erneut; geraten wird nicht.

Signiert auf deinem Gerät, Vertrauen durch Nachweise#

Signiert wird dort, wo deine Arbeit lebt: im Browser. Ein Signierschlüssel ist selbst eine Katalog-Entität; die private Hälfte wird lokal erzeugt und verlässt das Gerät nie — nicht synchronisiert, nicht hochgeladen, für Scellis nicht wiederherstellbar. Die Veröffentlichung signiert den Content-Hash, und jede Installation verifiziert Signatur und Hash gemeinsam — was auf einer anderen Maschine ankommt, ist beweisbar das, was du veröffentlicht hast.

Vertrauen ist eine eigene Achse, getrennt von Autorschaft und Popularität. Eine veröffentlichte Version trägt eine verdiente Stufe — unverifiziert, Community, verifiziert, offiziell — und Nutzerarbeit steigt bis verifiziert über genau dieselbe Nachweislatte wie alles vom Plattform-Team, weil User-Content strukturell identisch mit Builtins ist. Offiziell markiert schlicht Scellis-gepflegten Content; alles andere bewegt sich hinauf durch Nachweise, nie durch Bevorzugung.

Veröffentlichte Versionen bewegen sich nie unter dir#

Eine veröffentlichte Version ist unveränderlich — sie „in place zu fixen“ ist per Konstruktion verboten. Ändert sich die Bedeutung, springt die Version, und die alte bleibt für immer lauffähig, weil Abhängige exakte Versionen in Lockfiles pinnen. Aktualisieren ist damit eine Entscheidung, die du triffst, nicht etwas, das dir passiert: Du löst bewusst auf die neue Version um, lässt deine Prüfungen laufen und ziehst weiter. Dieselbe Regel folgt dem Content in den Handel: Wer v2 gekauft hat, behält v2, wenn v3 erscheint.

Abhängige werden auch strukturell verteidigt. Das endgültige Löschen einer veröffentlichten Entität wird verweigert, solange irgendein Lockfile sie pinnt. Wird ein Konto gelöscht, werden veröffentlichte Entitäten zu Tombstones — die Autorin anonymisiert, die gepinnten Bytes bleiben auflösbar —, sodass niemandes Arbeit bricht, weil jemand anderes gegangen ist. Und zieht Upstream in eine Richtung, der du nicht folgen willst: Forken ist erstklassig. Forke alles, was du lesen kannst, und dir gehört eine vollwertige Kopie — editierbar, veröffentlichbar, geprüft wie alles andere. Diese Art Beständigkeit ist ein Versprechen der Plattform, keine Kulanz.

Zustimmung bei der Installation; Policy aus dem Workspace#

Die Installation ist der Moment, in dem über Sicherheit entschieden wird — und entschieden wird über Deklarationen. Ein Pack benennt die Effekte, die seine Closure braucht, und die Zustimmung wird aus dieser Aussage berechnet:

Ein Workspace kann die Linie für alle darin enger ziehen: nur signierte Packs zulassen, Netzwerk-Effekte verbieten oder deterministische Ausführung verlangen. Keine lokale Einstellung steht über der Workspace-Policy — das Interface lässt sich an keiner Regel vorbeireden, die der Workspace gesetzt hat.

Lieferung in Sync-Geschwindigkeit — ehrlich bis zur letzten Meile#

Veröffentliche — und die Lieferung ist nicht mehr dein Problem. Es gibt keinen Release-Zug, weil es nichts zu releasen gibt: Die kompilierte App enthält nur die Engine, jede Fähigkeit kommt aus der Datenbank — ein frisch veröffentlichtes Pack ist für andere Clients also Sekunden nach ihrem nächsten Sync live. Kein App-Rebuild, keine Neuinstallation, kein Warten auf ein Versionsfenster.

Schnelles Ausliefern liefert auch Fehler aus, deshalb hat jeder veröffentlichte Hash einen Advisory-Kanal. Ein Advisory alarmiert jeden gepinnten Abhängigen — eine Benachrichtigung, ein Katalog-Badge auf der markierten Version und ein Ein-Schritt-Re-Resolve, um von ihr wegzukommen — und Neuinstallationen einer markierten Version können am Byte-Serving-Engpass blockiert werden, durch den jede Installation fließt.

Das ist der ganze Weg von deinem Gerät zu allen anderen: ein Umschlag, eine Closure, die mitreist, ein Gate, das seine Anforderungen benennt, eine lokal erzeugte Signatur, Versionen, die sich nie bewegen, Zustimmung aus Deklarationen berechnet — und Lieferung in der Geschwindigkeit eines Syncs.