# Overview (/web) The web app is the shared source of truth for Mogplex account state, GitHub coverage, reusable agents, hosted routing, and runtime inspection. If the question is about account setup, GitHub eligibility, reusable hosted behavior, or why something ran the way it did, the answer usually starts here. ## What the web app actually owns [#what-the-web-app-actually-owns] * **Projects** lives at `/spaces`. It is where repository import, project organization, sandbox launch, and workspace opening happen. * **Sandboxes** lives at `/spaces/sandboxes`. It is the cross-repo runtime view for running, pending, and stale preview environments. * **Agents** lives under `/agents/*` and manages the reusable agent roster plus shared skills, rules, and context. * **Automations** at `/automations` is the canvas builder for multi-step GitHub-triggered workflows. * **Triggers** at `/triggers` is the lighter-weight event-to-agent router for direct GitHub webhook handling. * **Assignments** at `/assignments` binds repos to agents for repeatable review, cron, and triage work. * **Observability** tracks runs, pressure, failures, model calls, tool usage, and sandbox-linked activity. * **Settings** manages GitHub identity, App coverage, connections, access tokens, models, preferences, billing access, and synced MCP definitions. * **Available Models** explains the live model catalog, enabled-state rules, default-model behavior, plan access, CLI sync, and repo-level exclusions. ## The clean mental model [#the-clean-mental-model] The web app is not just “the browser version of the CLI.” It owns three different jobs: * **setup**: identity, GitHub coverage, connections, models, and repo sync * **routing**: deciding what should run from GitHub events, repo-owned rules, or workflow graphs * **inspection**: checking runs, failures, tool calls, cost, and sandbox health That framing helps you choose the right page faster: * use [Settings](/web/settings) and [Installations](/web/installations) when Mogplex cannot yet do the work * use [Available Models](/web/models) when a picker, agent, flow, or CLI run cannot use the model you expect * use [Projects](/web/spaces), [Triggers](/web/triggers), [Assignments](/web/assignments), or [Automations](/web/automations) when you are deciding what should run * use [Observability](/web/observability) and [Sandboxes](/web/sandboxes) after work has queued or started ## Start in this order [#start-in-this-order] For a new account or a new repo, the most reliable path through the product is: 1. [Settings](/web/settings) to connect GitHub and confirm your account can use the product. 2. [Installations](/web/installations) to verify GitHub App coverage for the correct user or org. 3. [Projects](/web/spaces) to sync repos, organize them, and open a workspace. 4. [Agents](/web/agents) to create or fork the agents you actually want to run. 5. [Triggers](/web/triggers), [Assignments](/web/assignments), or [Automations](/web/automations) depending on how much routing logic you need. That sequence matters because most apparent “routing bugs” are really setup bugs: missing App coverage, missing repo sync, or missing shared account state. ## Choose the smallest routing surface that fits the job [#choose-the-smallest-routing-surface-that-fits-the-job] * Use **Triggers** when the rule is simply `one GitHub event -> one agent`. * Use **Assignments** when the repo is the durable unit of routing and you want standing work such as PR review, issue triage, CI failure response, or cron. * Use **Automations** when you need multiple steps, branching, delays, publishable drafts, or explicit mention-entry workflows. If the choice is not obvious yet, read [Choose the Right Routing Surface](/web/guides/choose-routing-surface). ## Web app vs CLI [#web-app-vs-cli] The clean split is usually: * do shared account setup, GitHub coverage, and routing in the web app * do repo-local execution in the CLI * come back to the web app for observability, repair actions, and shared hosted state This matters because Mogplex intentionally reuses some hosted state in the CLI, including account-backed model defaults and remote MCP definitions. ## What a healthy setup feels like [#what-a-healthy-setup-feels-like] Once the web app side is set up correctly: * the correct repos appear in [Projects](/web/spaces) * the correct owner shows real GitHub App coverage in [Installations](/web/installations) * the agents you expect are available for routing * Triggers or Automations offer real installations instead of looking empty * [Observability](/web/observability) can tell you what actually ran ## Legacy route notes [#legacy-route-notes] Several older dashboard routes still exist, but they now forward to the current surfaces: * [`/flows`](/web/flows) redirects to `/automations` * [`/library`](/web/library) redirects to agent libraries or model settings, depending on tab * [`/primitives`](/web/primitives) redirects to the agent library surfaces The product language still says **Projects** even though the route is `/spaces`. The docs use the current UI label and call out the route where it matters. For the full redirect map, use [Legacy Routes](/web/guides/legacy-routes). ## Common “where do I fix this?” questions [#common-where-do-i-fix-this-questions] * **Why is Triggers empty?** Usually because GitHub OAuth is connected but the Mogplex GitHub App is not installed for the owner that holds the repo. Check [Installations](/web/installations). * **Why can I see repos but not launch the kind of work I want?** Repo sync and webhook coverage are separate concerns. Projects can show synced repos before they are fully triggerable. * **Where do I set up models and external tools?** Use [Settings](/web/settings) for account access and connections, and [Available Models](/web/models) for model availability, defaults, and enabled state. Agent behavior belongs in [Agents](/web/agents). * **Where do I manually stop or inspect previews across repos?** Use [Sandboxes](/web/sandboxes). * **Where do I start for mention-driven workflows?** Use [Triggers](/web/triggers) for a direct mention route, or [Automations](/web/automations) if the mention should fan into a workflow.