Project management
Project managers use Server Web to manage members, invitations, source access, and related projects. Server stores project metadata, permissions, and version snapshots; it never executes uploaded project code.
Project avatars
Project lists, details, and settings display avatars from projectCard.icon, iconColor, and iconBackgroundColor. New projects without an avatar use their project type's icon with randomly generated, saved foreground and background colors. Their contrast ratio is at least 4.5:1. Refreshing the page or reconnecting an existing project does not generate new colors.
Older projects without avatar metadata use their project type's default icon and colors. iconUrl remains readable for compatibility, while these views consistently use the icon and colors.
Click a project list avatar to open its details, or a standalone detail avatar to preview it. User avatars in member and uploader lists open the currently visible profile information. The account menu avatar opens its menu, while the personal profile avatar selects an upload. Dialogs support keyboard dismissal and return focus to their trigger.
Fixed roles
Accounts are ordinary users or system administrators. Business access is assigned per project or group using four fixed roles.
| Role | Cumulative capabilities |
|---|---|
guest | Read projects, published versions, KV, Knowledge, project files and previews; download published source to run locally. |
developer | Edit drafts, upload, publish and write Server KV, Knowledge and project files. |
maintainer | Manage project information, icons, visibility and official configurations; manage guests and developers. |
owner | Assign every role, manage owners, delete projects and transfer ownership. |
Cookie and API key requests use current account status and memberships. Revocation, disabling an account or making a public project private affects subsequent requests immediately, including previews. Guests may use local data when running downloaded projects; Server writes fail with a permission error. Personal configurations remain available within published field rules.
Groups and subgroups
Open Groups in the sidebar to create a top-level group or navigate its projects, subgroups and breadcrumbs. A project belongs to one group or is an ungrouped personal project. Permission groups are independent of multi-project upload and publication bundles.
Any signed-in user can create a personal project or top-level group and become its owner. Group developers may create projects and maintainers may create subgroups. Their creators retain inherited roles without automatic promotion.
Effective access is the highest direct project role or role inherited from the containing group and every ancestor. Lower levels cannot reduce inherited access. Member pages show direct and effective roles with links to the source group. Removing direct membership preserves inherited permissions.
Directories and member lists search and paginate authorized records on the Server. A public project neither grants group membership nor exposes private projects in the same group.
Members, invitations and requests
Maintainers may grant guest or developer roles and manage users whose effective role is below maintainer. Owners manage every role. Invitation acceptance and request approval recheck current permissions and preserve existing higher roles. Membership invitations expire and are single use; recipients must sign in. Account invitations and password setup are separate from project and group invitations. Server does not send email.
Project and group invitation lists follow the roles the caller can grant: maintainers see guest and developer invitations, while owners and system administrators see every role. System administrators can also approve access requests with an admin key.
Public projects grant every signed-in user guest access without inserting membership records. Private projects accept access requests through published-version share links; approval by a maintainer or owner adds the requester as a guest. Source downloads no longer use separate grants. Revoke approved access through the member page and inspect inherited sources.
Top-level groups and personal projects retain at least one active owner, protected by transactions. Group resources may inherit owners. Transfers require owner access to the resource, its source group when present and its destination. Cycles are prohibited. Only empty groups may be deleted; move their projects and subgroups first.
Source and versions
Uploads only extract, statically validate and save files. Server never installs dependencies, builds or executes uploaded code. Failures preserve drafts and published versions. Publication saves an immutable snapshot and updates latest; duplicate versions return 409.
A developer upload cannot modify management metadata or ownership. Guests download published versions; draft reads require developer access. Archives exclude KV, PersistentValue, SQLite, environment files and CLI credentials.
Related projects and batch publication
Related declarations contain aliases, target UUIDs and read/write grants. Both declarations must agree, using none, all or prefixes rules. Related reads require the user's read access on both projects. Writes require developer access on both sides and valid bilateral write grants. Membership or relationship revocation affects subsequent calls immediately.
Multi-project publication rechecks developer access on each dependency and the root. Downloads check guest access per project and return missing dependencies and request links. Source operations never copy Server data.
System administration and audit
User administration sets account status and system administrator identity. System administrators have global management access and handle accounts, system audit and administrative tools. System audit is administrator-only, with credentials redacted.
HTTP responses expose access: { effectiveRole, sources, capabilities }. Clients use capabilities to control actions, and Server independently authorizes every operation. Client-supplied role fields never grant access. See the OpenAPI specification for the full contract.
Project configurations
Core Agent projects show AI models first in configuration details. Add system subscription models and third-party API models to one list, then edit, delete or set the default. Add and edit actions open a dialog with a segmented source selector. System AI needs only Provider and model selections and generates the name automatically. Fields have bordered groups, and the lone Configuration values tab is hidden when publication management is unavailable. After saving, Studio / CLI Web composers select only saved entries. Third-party models work independently of system AI sign-in; sharing excludes values by default, while complete backups contain model keys.
Authors can declare allowThirdParty: false on the model field in the source configuration.json. The editor then only offers system AI. Third-party saves and imports fail atomically, and publishing the model field retains this rule. Existing third-party entries display as unavailable and can be removed or replaced with system models. Execution also rejects custom endpoint overrides.
The configuration page opens with a profile list. Click a profile to view its fields and publication permissions, then use Back to list to return. The active profile has a highlighted row and an In use badge; other profiles offer a Use this configuration button. Viewing a profile preserves the execution selection. Switching disables duplicate actions, and failure keeps the previous selection and allows retrying. Unsaved values and permission rules must be saved or discarded before returning.
Edit fields directly and save changes together. Use the reset icon to restore a default or clear a field without a default; no separate enable checkbox is needed.
All three project types expose fields, named profiles and complete import/export. Studio and local CLI share local storage; Server values are per project and account. Studio Control can query and manage configurations even when the panel is closed. See Project configurations for the JSON actions, version checks and execution snapshot rules.
File configuration fields upload personal attachments to Server storage. Field permissions and account isolation apply when saving their references.
Configuration authors use the separate Publication and permissions tab to select profiles, a default, value inclusion and field/JSON Pointer editing rules. Only maintainers, owners or system administrators may save official drafts. The recipient preview shows the filtered version; personal configuration imports never change official rules. Published source shares and downloads use that same immutable template and its attachment copies. See Project configurations.
After selecting a published version, users can read and edit permitted personal configurations even when the project has no draft. Draft publication checks are returned only when reading the draft.
Projects declaring profilePolicy filter configurations using actual project and inherited group roles. Guests see only guest base profiles such as Ask and may edit permitted values, while developers may use Build and manage personal profiles. Personal requests cannot change fixed modes, role labels, or minimum roles. Configuration responses, personal exports, and attachment reads share these checks. See Project configurations.
Personal configurations for v2 projects default to the latest published template. Source-draft access does not expose unpublished author fields or defaults. Maintainers, owners and system administrators retain official draft management. Role-controlled configurations must have a published template before developers use them.