Workspace Supervisor

The Workspace Supervisor organizes long-running, multi-panel work: charters, intake, run history, loops, readiness, and optional LLM review. It is an execution layer after you know the goal — not the first place to invent a vague chat.

一件事

吐卡。让队列可见。停到人决定。

1. 01
   CI / PR 唤醒

   监督器读已拉到的侧栏 checks，吐出一张可批的卡，然后停。不是 GitHub webhook。

2. 02
   队列看得见

   任务相位是排队 / 已领取 / 运行中。人能看见队列。不替换手机上的等待审批。

3. 03
   同一张卡

   IDE 收件箱和 imux Mobile 共用 imux.proposed-action.v1。批准在 Mac 上做。手机这轮只读。

When to use Supervisor (and when not to)

Use it at transitions: starting a multi-step job, after a failure, or before handoff. Prefer a terminal agent CLI or Agent Chat for single-threaded coding tasks. Do not run Supervisor loops on every keystroke.

Task Charters

Define what a workspace should do with a task charter:

• A charter is a concise statement of the workspace objective: what to accomplish, relevant files, and success criteria.
• The charter stays attached to the workspace, providing persistent context even when you switch tasks or return after a break.
• Update the charter as the objective evolves, keeping the workspace aligned with the current goal.

Startup and Session Intake

When a workspace session begins, the supervisor captures the starting state:

• Records the initial working directory, Git branch, open files, and any explicit task charter.
• Produces a startup brief that summarizes what the workspace should accomplish in this session.
• The intake snapshot is stored with the session so you can review what was planned versus what was done.

Run History

Track task execution over time with structured run history:

• Each supervised run records start time, end time, outcome, and any artifacts produced.
• Run history is stored per-workspace, so you can trace the full lifecycle of a task across multiple sessions.
• Use run history to review what was tried, what succeeded, and what still needs attention.

CI / PR 提案卡

侧栏 checks 变红，或当前分支的 PR 已绿时，监督器吐出一张可批的卡然后停。不会默默再转一轮。

• IDE 收件箱和 imux Mobile 共用同一 schema。批准在 Mac 上做；手机这轮只读。
• v1 读的是已经拉到的侧栏 PR checks，不是 GitHub webhook。
• 批准只记决定。下一轮请自己点开始循环。驳回和延后都不会自动再转。

任务队列

任务的运行相位与状态并列，领取时队列仍然可见。

• runPhase 是排队、已领取或运行中。新任务从排队开始。
• status 仍是进行中 / 完成 / 失败 / 取消。手机等待审批是另一个字段。
• 没有 runPhase 的旧会话按运行中解码，避免改写旧含义。

我们不加这些

• CI webhook，或吐卡后再默默转一轮。
• 进会机器人或第二套工单。
• 这轮不做手机决定接口 — 批准在 Mac 上。
• 本仓库没有 Bot 决定表面。

Loop Settings

Configure retry and restart behavior for supervised tasks:

• Set the maximum number of retry attempts before the supervisor marks a task as failed.
• Define a delay between retries to allow external conditions (builds, deploys, tests) to settle.
• Customize restart behavior: always restart on failure, prompt before retrying, or stop after the first failure.

Readiness Probes

Define health checks for workspace tasks:

• A readiness probe is a command or script that the supervisor runs to check whether a task is healthy and making progress.
• Probes can check file existence, process state, network connectivity, or any custom condition relevant to the task.
• If a probe fails repeatedly, the supervisor can trigger a restart, notification, or escalation based on loop settings.

LLM-Backed Review State

Optionally enable AI review of task output:

• After each run, the supervisor can send the output and workspace context to an LLM for automated review.
• The LLM review flags issues, suggests improvements, and provides a structured assessment of the task outcome.
• Review state is attached to the run history entry, giving you both human and AI perspectives on task progress.

Session Persistence

Supervisor state is per-workspace and persists across app restarts:

• Charters, run history, loop settings, and review state are all encoded in session snapshots.
• When you quit and relaunch imux, each workspace restores its supervisor state alongside its layout.
• Session snapshots respect autosave limits for windows, workspaces, layout depth, and scrollback, so supervisor data does not cause unbounded growth.