§ Plattform / Auf Dauer gebaut
Deine Arbeit überdauert unsere Releases.
Scellis trennt, was ausgeliefert wird, von dem, was bleibt: Die App selbst ist eine kleine, versionierte Engine — alles, was du baust, ist unveränderlicher Content, der genau deklariert, was er braucht. Content, den die Engine nicht ausführen kann, wird laut abgewiesen statt falsch ausgeführt, eine neuere Engine muss alles ausführen, was eine ältere konnte, und ein Gerät ohne Netz rechnet auf seiner gecachten Engine unbegrenzt weiter.
Eine Engine, die erscheint — Arbeit, die bleibt
Die App, die du lädst, ist bewusst klein — eine Engine, sonst nichts. Jede Fähigkeit, die du tatsächlich nutzt — Blocks, Kernels, Modelle, Viewer —, kommt als Content aus dem Katalog, identifiziert über den Hash ihrer Bytes. Deine Arbeit lebt nie in unserer Binary, unser Release-Zyklus kann sie also nicht in Geiselhaft nehmen: Beide bewegen sich auf getrennten Uhren, verbunden durch einen expliziten Vertrag.
Der Vertrag hat zwei Hälften. Die Engine trägt eine Versionsnummer und eine Liste dessen, was sie kann — f16-Training, Secure Aggregation und so weiter —, und Content prüft Fähigkeiten, nie Versionsnummern. Content trägt die Liste dessen, was er braucht. Kann die laufende Engine eine Deklaration nicht erfüllen, weist der Loader laut ab: eine klare Diagnose und ein „Braucht ein neueres Scellis“-Badge im Katalog — nie ein Crash und nie eine stille Fehl-Ausführung, denn ein falsches Ergebnis altert weit schlechter als ein verweigertes. Wie die Engine deklariert, was sie ausführen kann, steht im Guide.
Eine neuere Engine führt alles aus, was die alte ausgeführt hat
| Änderung | Release-Klasse | Deine bestehende Arbeit |
|---|---|---|
| Eine neue Fähigkeit | additiv | Läuft unberührt weiter — dein Content hat den neuen Wert nie referenziert. |
| Jedes neue Engine-Release | vor dem Release verifiziert | Der eingefrorene Golden Corpus muss erfolgreich neu ausgeführt werden, bevor ein Release existiert. |
| Fähigkeit zurückziehen, Bedeutung ändern | major | Ein Migrationspfad ist Pflicht — nie ein stilles Fallenlassen. |
| Neue Version eines Blocks oder Op | koexistiert | Pins lösen weiter die alte Version auf — veröffentlichte Versionen sind unveränderlich. |
| Content, der neuer ist als deine Engine | laut abgewiesen | Ein „Braucht ein neueres Scellis“-Badge — nie eine Fehl-Ausführung; du updatest, wann du willst. |
Die Anforderung ist mechanisch: Automatische Prüfungen führen den eingefrorenen Korpus gegen jede Engine-Änderung erneut aus und halten jede Deklaration ehrlich — bevor irgendetwas ausgeliefert wird.
Rückwärtskompatibilität ist hier eine getestete Anforderung, keine Changelog-Höflichkeit. Ein eingefrorener Golden Corpus — Beispiel-Ops, -Blocks und -Modelle jeder früheren Engine — wird von der aktuellen Engine erneut ausgeführt, innerhalb der deklarierten Toleranzen, bevor ein Release überhaupt existieren kann. Würde eine Änderung die Zahlen eines alten Op verändern oder seine Ausführung brechen, wird das Release blockiert: Korrektheit wird genauso versioniert, wie sie bewiesen wird.
Die Engine wächst durch Hinzufügen, nie durch Umschreiben: Eine neue Fähigkeit ist ein Wert, den dein bestehender Content nie referenziert hat — er läuft also unberührt weiter. Eine Fähigkeit zurückzuziehen oder die Bedeutung einer bestehenden zu ändern ist ein Major-Release mit Migrationspfad, nie ein stilles Fallenlassen. Und veröffentlichter Content ist per Identität unveränderlich: Eine Version ist ein Vertrag, neue Versionen koexistieren neben alten, und alles Gepinnte löst weiter exakt die Bytes auf, die es immer aufgelöst hat.
Updates sind atomar, verifiziert — und passieren zu deinen Bedingungen
Ein Engine-Update kommt über denselben Weg wie Content. Die neue App-Shell wird im Hintergrund geladen, ihre Bytes werden vor der Aktivierung gegen einen signierten Hash verifiziert, dann in einem Schritt getauscht — eine halb aktualisierte App läuft nie, und deine lokale Datenbank bleibt unberührt. Du siehst ein ruhiges „Neu laden für Update“-Signal mit Release Notes: die neue Version und genau das, was sie ändert (Changelog) — nie eine App, die sich über Nacht still unter dir verändert hat.
Lehne das Neuladen ab — oder verliere das Netz — und nichts degradiert. Ein Gerät ohne Verbindung rechnet unbegrenzt auf seiner gecachten Engine weiter: Das Local-first-Arbeitspaket ist auf dem Gerät vollständig, ein Laptop im Feldeinsatz kann also ein Jahr auf einer Engine bleiben und die ganze Zeit zeichnen, ausführen und trainieren. Ein Update ist hier etwas, das du nimmst — nicht etwas, das dir passiert.
Ein Update legt keinen wiederkehrenden Tab lahm
| Auf deinem Gerät | Über ein Update hinweg | Mechanismus |
|---|---|---|
| Entwürfe & ungesyncte Änderungen | bleiben erhalten, immer | Dauerhafter Speicher wächst nur; jede automatische Reparatur bewahrt ihn. |
| Committete Arbeit | Byte-identisch | Per Hash adressiert — die Bytes an einem Hash ändern sich nie. |
| Deine Katalog-Kopie | in Sekunden neu abgeleitet | Bei geänderter Speicherform geräumt und über den normalen Sync neu aufgebaut. |
| Die App selbst | in einem Schritt getauscht | Vor der Aktivierung gegen einen signierten Hash verifiziert. |
| Einstellungen & Profile | bleiben erhalten | Dauerhafter Zustand — er wächst nur, nie destruktiv. |
| Ein verklemmter Tab | eine Zeile zur Rettung | Ein dokumentierter Reset in der Adresszeile lädt sauber neu — ganz ohne Entwicklerwerkzeuge. |
Releases werden bewiesen, nicht gehofft: Eine Rückkehrer-Prüfung lädt die frische App gegen eine alte Datenbank und einen veralteten Cache — und muss sich zu einem funktionierenden Studio reparieren.
Local-first macht „mit altem Zustand zurückkommen“ zum Normalfall, nicht zur Ausnahme: Ein neues Release trifft routinemäßig auf einen Browser, der noch Caches und lokale Datenbank des vorherigen hält. Deshalb trägt die Form von allem, was auf deinem Gerät liegt, einen eigenen Fingerabdruck. Beim Start, bevor irgendein gespeichertes Datum angefasst wird, räumt ein geänderter Fingerabdruck genau das ab, was sich wieder herleiten lässt — die Katalog-Kopie, die Caches, die App-Shell — und baut es in Sekunden über den normalen Sync neu auf. Invalidiert und neu abgeleitet, nie in-place migriert, nie halb konsistent zurückgelassen.
Was nur dein Gerät hält — Entwürfe, noch nicht gesyncte Änderungen, deine Einstellungen — bewahrt jede automatische Reparatur. Löschen kannst nur du es, mit einem dokumentierten Reset in der Adresszeile; derselbe Einzeiler ist die Rettung für jeden verklemmten Tab, ganz ohne Entwicklerwerkzeuge. Selbst ein fehlerhafter Hintergrund-Worker ist per Konstruktion behebbar — ein schlechtes Update kann also nie zur dauerhaften Blockade werden.
Ein Run erinnert sich an die Engine, die ihn erzeugt hat
Reproduzierbarkeit über Releases hinweg wird aufgezeichnet, nicht erinnert. Jeder Run pinnt alles, was er genutzt hat, per Hash *und* die Engine-Version, die ihn ausgeführt hat, mit deklarierter Striktheit — ein Ergebnis zu reproduzieren beginnt Jahre später also mit einer maschinenlesbaren Aussage darüber, was lief, worauf und wie strikt. Zitierte, committete Arbeit löst zu identischen Bytes auf, solange der Link existiert, und eine Reproduktion läuft auf jeder Engine, die den aufgezeichneten Vertrag erfüllt.
Wo die Garantie eine Kante hat, sagt es der Record, statt aufzurunden: GPU-Floats laufen innerhalb der Toleranz erneut, die der Run deklariert hat, und Bit-Exaktheit über Geräte hinweg braucht den CPU-Referenzpfad — Grenzen, die wir in den ehrlichen Grenzen drucken. Das Ergebnis ist Reproduktion, die über Jahre ehrlich bleibt: Die Aussage wandert kalibriert mit dem Run, statt zu Folklore zu verfallen. Die Arbeitspraxis steht im Reproduzierbarkeits-Guide.
Langlebigkeit, die nicht auf Vertrauen in uns angewiesen ist
Ein Langlebigkeits-Versprechen ist genau dann am schwächsten, wenn du es am dringendsten brauchst — deshalb sind die Ausgänge eingebaut. Alles, was du machst, exportiert als portable, dokumentierte .scellis-*-Dateien — Workflows, Packs, Modelle, Datasets —, Byte für Byte reproduzierbar und beim Import selbst hash-geprüft; dazu ein gerätelokales Backup von allem auf deinem Gerät (Zugangsdaten per Konstruktion ausgenommen: Sie verlassen es nie). Was du erstellst, gehört dir — und es geht, wann immer du es sagst.
Die Formate überleben ohne unser Wohlwollen: Die Schemas, die Exportdateien, der Konformanz-Korpus und die CPU-Referenz sind permissiv veröffentlicht — der Interchange-Ring —, jeder kann deine Arbeit lesen, verifizieren und darauf aufbauen, ohne uns zu fragen. Die Engine selbst ist als Quelltext zu Fair-Code-Bedingungen publiziert, und jedes Release konvertiert mit der Zeit zur permissiven Lizenz. Wir planen Jahrzehnte von Releases; der Punkt der Architektur ist, dass deine Arbeit nicht darauf wetten muss.