Gemeinsam
Workspaces, Repositories und Teilen
Zusammenarbeit braucht mehr als einen Einladen-Button. Sie braucht eine Grenze, an der Regeln wirklich binden, ein Regal, das genau das trägt, was du ausgewählt hast, und einen Weg, einer Person genau eine Sache zu geben — nicht mehr, und nicht für immer, wenn du das nicht willst. Scellis baut jedes davon als eigenes Instrument und erzwingt die entscheidenden auf dem Server — unterhalb von allem, was ein Client-Bug erreichen könnte.
Fünf Gruppierungskonzepte tragen das alles. Jedes besitzt genau eine Achse, und sie werden nie vermischt:
| Konzept | Seine eine Achse |
|---|---|
| Pack | Liefert Content aus |
| Listing | Verkauft ihn |
| Workspace | Regelt ein Team |
| Repository | Kuratiert ein Regal |
| Pool | Rechnet gemeinsam |
Ein Pack liefert aus, ein Listing verkauft, ein Pool rechnet — jedes hat seine eigene Seite. Hier geht es um die Mitte der Tabelle: wie ein Team regelt, wie eine Sammlung kuratiert bleibt und wie Arbeit zwischen Menschen wandert.
Ein Workspace regelt#
Ein Workspace ist die Team-Grenze. Die Mitgliedschaft ist die Isolationsgrenze: Was in einem Workspace liegt, sehen seine Mitglieder — und niemand sonst. Vier Rollen ordnen, was ein Mitglied darf — owner > admin > editor > viewer — strikt geordnet.
Durchgesetzt wird serverseitig — und in Schichten. Die Oberfläche spiegelt deine Rolle; sie implementiert sie nie. Unter der Anwendung liegt eine zweite, unabhängige Instanz: Row-Level-Security-Policies in der Datenbank selbst entscheiden, welche Zeilen eine Anfrage sehen kann. Diese Instanz ist generiert, nicht handgeschrieben — ein Generator deckt beide Sichtbarkeitsgitter, Grants und Link-Grants ab —, sodass ein Client-Bug Zugriff nicht ausweiten kann: Der Client war nie die Stelle, die entscheidet.
Hinweis
Einen Button auszublenden ist Höflichkeit. Die serverseitige Prüfung ist die Grenze, und die Row-Level-Security der Datenbank hat darunter das letzte Wort — beiden ist egal, was die Oberfläche behauptet.
Policy, die die Oberfläche nicht überstimmen kann#
Ein Workspace trägt außerdem Policy — und Policy ist eine Durchsetzungsgrenze, keine Präferenz. Ein Workspace kann verlangen, dass nur signierte Packs installiert werden, Netzwerk-Effekte komplett verbieten, ausschließlich deterministische Ausführung erzwingen und seine Logs unveränderlich machen. Keine lokale Einstellung überstimmt davon irgendetwas: Policy bindet auf dem Server, für jedes Mitglied — egal, was dessen Client tut.
Audit-Logs machen die Grenze belegbar. Admins können abfragen und exportieren, wer was wann ausgeführt hat. Für regulierte Arbeit ist genau das der Sinn der Sache — keine Policy, die du behauptest, sondern eine Grenze, die du einem Auditor zeigen kannst.
Entitlements können dem Workspace gehören#
Ein Team zu regeln und für eines zu zahlen ist dieselbe Achse — also hält Scellis beides auf einem Modell. Ein Entitlement — ein Tarif oder ein gekauftes Pack — kann einer Identität oder einem Workspace erteilt werden, seat-gepoolt über seine Mitglieder. Team-, Kurs- und Campus-Lizenzierung ist damit Daten, kein nachgerüstetes zweites Billing-System: einmal für den Workspace kaufen, und jedes Mitglied ist abgedeckt — und derselbe Server-Checkpoint, der Rollen erzwingt, erzwingt den Tarif. Wie die kommerzielle Seite davon funktioniert — Abrechnung, Rechnungen, Erstattungen — ist Thema des Marketplace, und die Tarife selbst stehen auf der Preis-Seite.
Ein Repository kuratiert#
Ein Repository ist eine benannte, teilbare Sammlung von allem — Workflows, Modellen, Datensätzen, Blöcken — und jeder Eintrag ist auf eine Version gepinnt. Es ist ein Regal, auf dem exakt das steht, was du kuratiert hast. Und weil die Versionen gepinnt sind, bleibt das Regal stabil: Veröffentlicht jemand Version 12 eines Modells, ändert das nicht still die Version 7, hinter der du stehst. Dass unveränderliche Versionen koexistieren, macht ein Repository als Ganzes zitierbar — eine Leseliste, die sich morgen genauso auflöst.
Ein Repository hat keine Rollen und keine Policies — mit Absicht. Wünschst du dir Rollen auf einem Repository, willst du in Wahrheit einen Workspace: Ein Repository kuratiert, ein Workspace regelt. Eine Achse pro Konzept — das ist auch der Grund, warum ein Repository kein Pack ist. Ein Pack liefert einen geschlossenen Abhängigkeitsgraphen als eine signierte Einheit; ein Repository zeigt nur auf Versionen, die du zusammengestellt hast.
Sichtbarkeit läuft nur bergauf; Teilen ist ein Grant#
Jede Entität hat eine Sichtbarkeit, und Sichtbarkeit ist monoton: private → workspace → public, nur aufwärts. Zurückstufen gibt es — aber als eigenen Akt mit eigenem Namen: Ein Unpublish ist ein eigenständiger, auditierter Vorgang, nie ein stilles Zurückgleiten. Und ohne angehängte SPDX-Lizenz geht nichts public.
Mit einer Person zu teilen ist bewusst kein Sichtbarkeitswert. Es ist ein Grant: eine personenbezogene Berechtigung, geordnet als viewer ⊏ commenter ⊏ editor ⊏ owner, mit optionalem Ablauf und sofortigem Entzug. „Mit mir geteilt“ ist kein zweites Speichersystem, sondern eine Abfrage über deine Grants — derselbe Grant, der einem Editor die Run-Kontrolle in einer Live-Session gibt. Einladungen haben dieselbe Form: Du lädst per E-Mail ein, und die Annahme prägt einen Grant.
Menschen zu finden, mit denen du teilen willst, stellt sie nicht bloß. Die Personensuche liefert nur ausdrücklich öffentliche Profilfelder — Handle, Anzeigename, Avatar — nie eine E-Mail-Adresse und nie ein Inventar, wem was gehört. Ein Profil kann sich der Suche auch ganz entziehen.
Zwei Arten von Share-Link#
Ein Link kann zwei verschiedene Dinge meinen, also gibt es in Scellis zwei verschiedene Links — und sie werden nie verwischt. Ein Snapshot-Link löst zu einer eingefrorenen, inhaltsadressierten Version auf: unveränderlich, ohne Login, selbstverifizierend — was ankommt, kann beweisen, dass es das ist, was der Link benennt. Das ist das Reproduzierbar-per-URL-Primitiv; eine Kollegin öffnet exakt die committete Version, die du geteilt hast — nicht das, was über Nacht aus deinem Entwurf geworden ist.
Ein Session-Link öffnet den lebenden, editierbaren Entwurf — und verlangt deshalb Identität. Selbst ein Besucher ohne Konto editiert unter einem stabilen, zurechenbaren anonymen Handle mit; alles in einer Live-Session hat einen Urheber. Ein lebender Entwurf wird nie gehasht: Brauchst du etwas Zitierbares, committe es und verschick den Snapshot-Link.
In beiden Fällen lebt das Link-Geheimnis nur im URL-Fragment — dem Teil nach „#“, den der Browser nie an den Server schickt. Der Server speichert nur einen Hash des Geheimnisses: Er erkennt einen Link, den er ausgegeben hat, kann ihn aber nicht rekonstruieren.
Ehrliche Grenzen
Entzug wirkt nach vorn. Einen Grant oder Link zu widerrufen kappt künftigen Zugriff sofort — aber Bytes, die jemand bereits auf sein Gerät synchronisiert hat, lassen sich nicht zurückholen. Kein System kann Daten ent-senden, und Scellis tut nicht so, als könnte es das. Und für regulierte Dokumente kann Policy Bearer-Links komplett verbieten: Ansehen nur identitätsgebunden.
Spiel die Änderung zurück#
Lesen ist der Einstieg ins Verbessern. Jede Entität, die du lesen kannst, kannst du forken; ist dein Fork besser, spielst du die Änderung zurück. Der Owner prüft einen echten Diff — die Änderung selbst, nicht ihre Beschreibung — und mergt per Drei-Wege-Merge. Eine akzeptierte Änderung landet als gewöhnliche neue Version, der Art nach nicht zu unterscheiden von einer, die der Owner selbst geschrieben hat. Ein Proposals-Eingang auf der Home-Oberfläche hält Review sichtbar — eine gute Änderung hängt nie davon ab, dass jemand ans Nachschauen denkt.
Selbst Eigentum wandert durch dieselbe Schleife: Eine Entität zu übertragen ist ein Vorschlagen-und-Annehmen — genau wie jede andere Änderung. Es ist dieselbe Fork-and-Propose-Bewegung, die den Sharing-Graphen zu einer Einbahnstraße in beide Richtungen macht, statt zu einem Haufen Sackgassen-Kopien.