Users, organizations and contexts

LightNow separates public Registry browsing, your personal workspace and every organization workspace. The active context decides who owns a write, which Runtime Profiles and settings are visible and which role applies. Plans control specific capabilities, but never the number of Runtime Profiles.

Context model

Membership alone does not activate an organization. The UI must select it, the CLI must store it, or a command must pass the literal --tenant option.

What context changes

Surface	Personal context	Organization context
Runtime Profiles	Owned by your account	Shared within the selected organization and governed by role
Favorites	Private to you	Shared with the selected organization
Ownership proof	Proves your publisher claims	Proves claims owned by the organization
Client policy	Your profile and local choices	Organization defaults and managed-client rules
Secrets and config	Personal runtime state	Organization-scoped runtime state and providers
Plan and billing	Your personal plan	The selected organization's plan

Public Registry reads do not need either write context.

Select context before changing state

1

Decide who should own the result

Use Personal for your own experiment. Use an organization when the result should be shared, governed or billed as team work.

2

Switch before editing or publishing

Select context before changing profiles, ownership, settings, favorites, billing or published artifacts.

3

Verify the active signal

Check the app context indicator or run lightnow context --show before a write-heavy CLI workflow.

4

Use an explicit one-command override

Pass --tenant <slug-or-id> when only one supported command should act for an organization without changing the stored CLI default.

Switch context in the UI and CLI

Use the context switcher in the application shell before editing an organization surface. The visible context indicator is the source for where the next UI write belongs.

The CLI stores Personal by default. lightnow context lists available choices; the literal option name remains --tenant even though public documentation uses the term organization.

Store and verify an organization context

lightnow context --show
lightnow context --tenant acme
lightnow context --show
lightnow sync --client codex --profile platform --local-proxy

Return explicitly to Personal:

lightnow context --personal
lightnow context --show

For a one-command organization publish without changing the default:

lightnow publish --server ./server.json --tenant acme

How API context is resolved

Most users do not need to manage headers because the UI and CLI do it. For a custom API client, the boundary is explicit:

• a valid user token without X-Tenant uses personal user context,
• a valid user token with an allowed X-Tenant activates that organization,
• the organization must exist and match the organizations in the token, and
• an invalid organization value is rejected rather than silently falling back to Personal.

Public mode applies only to routes that intentionally allow anonymous access and receive no bearer token.

Avoid context drift

Context drift means the command succeeds in a different valid workspace than the operator intended. Prevent it with a short preflight:

lightnow status
lightnow context --show

If a profile, favorite, ownership proof or publish result appears in the wrong workspace:

1. check the current UI or CLI context,
2. confirm organization membership and role,
3. switch to the intended context,
4. repeat only the missing operation, and
5. do not copy state between contexts as a workaround.

Context-aware configRuntime Profiles

See how personal and organization profiles become client runtime.

Publisher scopeOwnership & Verification

Create ownership proof under the context that should publish the server.

Plan scopePlans and billing

Understand which plan applies to personal and organization operations.