Benutzer, Organisationen und Kontexte
LightNow trennt öffentliches Registry-Browsing, deinen persönlichen Workspace und jeden Organisations-Workspace. Der aktive Kontext entscheidet, wem ein Write gehört, welche Runtime Profiles und Einstellungen sichtbar sind, welche Rolle gilt und welcher Plan die Operation steuert.
Kontextmodell
Eine Mitgliedschaft aktiviert nicht automatisch eine Organisation. Die UI muss
sie auswählen, die CLI muss sie speichern oder ein Command muss die wörtliche
Option --tenant übergeben.
Was der Kontext verändert
| Oberfläche | Persönlicher Kontext | Organisationskontext |
|---|---|---|
| Runtime Profiles | Gehören deinem Account | Werden in der Organisation geteilt und über Rollen verwaltet |
| Favoriten | Sind nur für dich sichtbar | Werden mit der ausgewählten Organisation geteilt |
| Ownership Proof | Belegt deine Publisher-Claims | Belegt Claims der Organisation |
| Client-Policy | Nutzt dein Profil und lokale Entscheidungen | Nutzt Organisationsstandards und Managed-Client-Regeln |
| Secrets und Config | Persönlicher Runtime-Zustand | Organisationsbezogener Runtime-Zustand und Provider |
| Plan und Billing | Dein persönlicher Plan | Plan der ausgewählten Organisation |
Öffentliche Registry-Reads benötigen keinen dieser Write-Kontexte.
Kontext vor Zustandsänderungen auswählen
Nutze Personal für dein eigenes Experiment. Nutze eine Organisation, wenn das Ergebnis als Team-Arbeit geteilt, verwaltet oder abgerechnet werden soll.
Wähle den Kontext, bevor du Profile, Ownership, Einstellungen, Favoriten, Billing oder veröffentlichte Artefakte änderst.
Prüfe den Kontextindikator der App oder führe vor einem schreibintensiven
CLI-Workflow lightnow context --show aus.
Übergib --tenant <slug-or-id>, wenn nur ein unterstützter Command für eine
Organisation handeln soll, ohne den gespeicherten CLI-Default zu ändern.
Kontext in UI und CLI wechseln
Nutze den Kontext-Switcher in der App-Shell, bevor du eine Organisationsoberfläche bearbeitest. Der sichtbare Kontextindikator zeigt, wohin der nächste UI-Write gehört.
Die CLI speichert standardmäßig Personal. lightnow context listet verfügbare
Optionen. Der wörtliche Optionsname bleibt --tenant, auch wenn die öffentliche
Dokumentation den Begriff Organisation verwendet.
lightnow context --show lightnow context --tenant acme lightnow context --show lightnow sync --client codex --profile platform --local-proxy
Wechsle explizit zurück zu Personal:
lightnow context --personal
lightnow context --show
Für einen einzelnen Organisations-Publish ohne Änderung des Defaults:
lightnow publish --server ./server.json --tenant acme
Wie API-Kontext aufgelöst wird
Die meisten Nutzer müssen Header nicht selbst verwalten, weil UI und CLI dies übernehmen. Für einen eigenen API-Client ist die Grenze explizit:
- Ein gültiges User-Token ohne
X-Tenantnutzt persönlichen User-Kontext. - Ein gültiges User-Token mit erlaubtem
X-Tenantaktiviert diese Organisation. - Die Organisation muss existieren und zu den Organisationen im Token passen.
- Ein ungültiger Organisationswert wird abgelehnt, statt still auf Personal zurückzufallen.
Public Mode gilt nur für Routen, die anonymen Zugriff ausdrücklich erlauben und kein Bearer Token erhalten.
Context Drift vermeiden
Context Drift bedeutet, dass ein Command in einem anderen gültigen Workspace erfolgreich ist als vom Operator beabsichtigt. Verhindere das mit einem kurzen Preflight:
lightnow status
lightnow context --show
Wenn Profil, Favorit, Ownership Proof oder Publish-Ergebnis im falschen Workspace auftauchen:
- prüfe den aktuellen UI- oder CLI-Kontext,
- bestätige Organisationsmitgliedschaft und Rolle,
- wechsle in den vorgesehenen Kontext,
- wiederhole nur die fehlende Operation und
- kopiere Zustand nicht als Workaround zwischen Kontexten.
Verstehe, wie persönliche und Organisationsprofile zur Client-Runtime werden.
Lege Ownership Proof in dem Kontext an, der den Server veröffentlichen soll.
Verstehe, welcher Plan für persönliche und Organisationsoperationen gilt.