> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vinmake.com/llms.txt
> Use this file to discover all available pages before exploring further.

# UI Structure

> The four surfaces — Inbox, Ask, Task, Engine — and what each is for

# UI Structure

Brain's UI has four surfaces. Each one has a clear job, and the boundary between
them is intentional. The shape mirrors how operations work in practice: things
arrive, things get asked, things get done, things get configured.

## Inbox

Everything that needs attention lands here.

Inbox is not only for human emails. It receives:

* Client emails (RFQs, replies, follow-ups)
* Agent messages ("I need your approval to create this style")
* Approval requests (every workflow's draft preview)
* Missing-field questions ("I couldn't extract the currency — what should I use?")
* Duplicate detection warnings
* "Needs review" notifications
* Workflow exceptions (something failed mid-flow)
* Risk alerts from the oversight agent

Example item:

```text theme={null}
AI needs approval:
Create style draft from Jaspal RFQ email?

Client: Jaspal · Style Ref: J26WGW153 · 3 attachments
[Review draft] [Approve & Create] [Reject] [Mark Duplicate]
```

The Inbox is where most of Mai's daily approval work happens. It's also where
Zean sees risk alerts and ownership gaps.

## Ask

Where users query and instruct the system in natural language.

Ask is the chat entry point. Everything typed here goes through the
[aggregator agent](/brain/staging/architecture/aggregator-and-workflows), which
classifies intent and routes to the right registered workflow. The aggregator
enforces scope — anything that doesn't map to a workflow gets the polite redirect.

Two kinds of messages live here:

**Queries** — read-only questions answered by Brain:

* "What is the status of Jaspal style J26WGW153?"
* "Show all RFQs waiting for quotation."
* "Which styles have true cost but no quotation?"
* "Summarize latest client comments on this style."

**Instructions** — natural-language workflow invocations:

* "Draft a quote for Jaspal J26WGW153 at 18% markup"
* "Create a new client from this sales contract" (with attachment)
* "Generate a BOM from the tech pack I just uploaded"
* "Send the quotation to Kaimook"

Both kinds land in the aggregator; the workflow that runs is whichever the
aggregator routes to. Query answers are structured and source-linked per
[Manager Queries](/brain/staging/workflows/manager-queries). Instructions invoke
the corresponding workflow and surface its draft for approval.

### Slash commands

For power-user invocation, every workflow is also exposed as a slash command
(`/create-style`, `/generate-bom`, etc.). Slash commands bypass the aggregator —
they invoke the named workflow directly with whatever parameters the user
provides or attaches. Same workflow, faster path.

Both paths are first-class. Mai might use chat for ambiguous requests and slash
commands for things she does daily. The Inbox shows slash-command shortcuts on
approval cards so she learns them naturally.

## Task

Where work-in-flight lives. Two task types share this surface, clearly separated.

### Human tasks

Operational work assigned to a person:

* Create style
* Review BOM
* Assign material
* Approve quotation
* Follow up with a client

### AI monitoring tasks

Background tasks Brain creates to track progress:

* Watch this RFQ
* Check for client reply
* Alert if no quotation after 2 days
* Track this negotiation thread

### Task categories

| Task Type      | Owner                  | Purpose                           |
| -------------- | ---------------------- | --------------------------------- |
| Human Task     | Merchandiser / Manager | Requires a human action           |
| AI Task        | Agent                  | Monitoring or background tracking |
| Approval Task  | Human                  | Human-in-the-loop decision        |
| Exception Task | Human                  | Something uncertain or risky      |

The distinction matters because the right view for Mai is different from the right
view for the oversight agent's monitor list. Both live in Task, but filtered
differently.

## Engine

The technical / admin surface. Shows the system's internals to people who need
them:

* Agents currently registered
* Workflows defined
* Tools available
* Skills installed
* Workflow runs (history)
* Run status
* Logs and traces
* Connected systems (CutMake, email, Supabase)

Engine is the surface where engineers debug a misbehaving workflow, audit which
tool produced which output, and configure system-level settings. Most merchandisers
won't open it.

## Why these four

Each surface answers a different question:

* **Inbox:** "What needs my attention right now?"
* **Ask:** "What is happening with X?"
* **Task:** "What's in flight and who owns it?"
* **Engine:** "How is the system itself configured and behaving?"

Collapsing them into one surface (a chat with a sidebar, say) makes everything
worse: notifications get lost, queries get noisy, ownership gets unclear, and
admin config drowns daily work.

## Related

* [Inbox vs. Task — design decision](/brain/staging/principles) — referenced in
  the inbox/task split
* [Oversight Agent](/brain/staging/workflows/oversight) — major producer of Inbox
  risk alerts and AI tasks
* [Manager Queries](/brain/staging/workflows/manager-queries) — what Ask answers