Scope and non-goals

Things that look like they might be missing, half-built, or worth "fixing" at a glance, but are actually deliberate — read this before assuming something is a bug or an oversight.

No REST/JSON API

Orbit has no versioned, documented API for third-party consumption, and isn't building toward one — every route either renders an Inertia page or handles a mutation and redirects back. NotificationController::index() does return raw JSON (GET /notifications), but it's dead code from the frontend's perspective — the notification bell popup reads from the shared Inertia prop instead (see ../notifications/03-frontend-backend-wiring-overview.mdNotifications (in-app & email)Frontend ↔ backend wiring overviewA map of the whole feature: how notifications reach the browser, how read/unread state round-trips, and how the settings tab persists preferences. Useful t…). Don't take an existing JSON-returning endpoint as precedent for a new API surface.

One deliberate, internal exception: GET /command-palette/search (CommandPaletteController@search, route name command-palette.search). The command palette is a global overlay that lives outside any page, so Inertia partial reloads (only: [...]) would mean adding a search prop to every page. It is a private endpoint of the frontend, not an API: it is behind auth, throttled (throttle:command-palette), scoped to the user's project memberships, has no versioning or stability promise, and is registered in bootstrap/app.php's shouldRenderJsonWhen so a guest gets 401 and a bad q gets 422 as JSON instead of a redirect. This exception covers that one route only; a new JSON endpoint still needs its own justification.

laravel/sanctum is a dependency, not a feature

It's in composer.json and nowhere else — no Sanctum:: config, no auth:sanctum middleware, no personal access tokens anywhere in the codebase. Authentication is plain Laravel session auth (AuthenticatedSessionController, RegisteredUserController, auth middleware) with a per-user configurable session_lifetime column. If a real token-based API ever becomes a goal, Sanctum is already pulled in for it — but until then, treat it as unused, not as a half-implemented feature to finish.

No global "admin" role

There is no role column on users and no concept of a site-wide administrator anywhere in the app. Every permission is scoped to a project — see ../permissions/README.mdRoles & permissions (RBAC)Every project has its own role-based access control: four built-in system role tiers (Owner, Admin, Member, Viewer) plus any number of project-defined cust…. The same person can be Owner of one project and a plain Member (or not a member at all) of another; there's no user who can act on every project in the system.

Most Workspace settings tabs are placeholders

resources/js/types/Settings.ts's SETTINGS_TABS lists Documents (Workspace section) and Export (Account section) with enabled: false — they render in the sidebar nav for discoverability, but the tab itself is unreachable (see ../settings-tabs/README.mdSettings tabs/settings is not one page — every tab under it (Preferences, Profile, Notifications, Security & access, Export in the Account section; Labels, Issue Types,…'s architecture section for exactly how enabled: false is enforced). AccountSettingsExportTab.tsx already exists as a component and even renders if you drop it into a page yourself — it's just never reachable through normal navigation, since a disabled tab has neither a route nor a page of its own.

20 of 21 catalog integrations are "coming soon"

Only Discord is wired up on the backend (ProjectIntegrationService::AVAILABLE_INTEGRATIONS) — every other entry in resources/js/types/Integrations.ts's catalog exists purely as frontend display data (name, icon, category, description) with comingSoon: true, and the backend has no matching IntegrationNotifier for any of them. See ../integrations/01-add-a-new-integration.mdIntegrationsAdd a new integrationWorked example: turning Slack from a locked "coming soon" catalog card into a fully working integration, exactly the way Discord works today. Slack already… for turning one into a real integration.

Issue mentions are defined but not implemented

NotificationType::IssueMentioned exists as an enum case, and Account settings → Notifications already has a toggle for it — but nothing in the codebase ever fires it. There's no @mention parsing anywhere in the comment-creation path. Don't assume a NotificationType case having a settings row means the feature behind it is live; check for an actual notify() call site (see ../notifications/01-add-a-new-notification-type.mdNotifications (in-app & email)Add a new notification typeWorked example: notifying a member when their project role changes — NotificationType::MemberRoleChanged. Today, ProjectMemberService::updateRole() only wr…) too.

No dedup or cap on the toast/alert stack

Covered in depth in ../alerts/04-customize-alert-behavior.mdUI alerts (toasts)Customize alert behaviorAlertProvider has no limit on how many alerts can stack up, and no deduplication — every addAlert() call adds one more item, full stop (see resources/js/co… — firing the same alert repeatedly, or many alerts in quick succession, stacks them all with no limit today. Not a bug so much as "nothing has needed it yet."

Tests

Non-goals aren't behavior to test — this guide exists so you don't go looking for tests covering a feature that was never built.