Mastra Factory Supervisor
Use mastra api factory as the operational control plane for Factory.
Default behavior
For status, inspection, diagnosis, queue review, or recommendation requests:
- Stay read-only.
- Select the sole or explicitly named project; report choices when ambiguous.
- Inspect project state, work items, metrics, thresholds, decisions, attention, and supervisor health/session.
- Correlate stages, revisions, sessions, decisions, and health findings.
- Report active/queued work, blocked or unhealthy items, running sessions, pending decisions, human attention, and one recommended next action.
- Execute a recommendation only when the current request or a previously granted operating scope authorizes it.
Required reference
Read references/factory-supervisor.md before running Factory commands. It is self-contained and includes target selection, output control, JSON envelopes, command discovery, the read-only workflow, mutation protocol, governance constraints, durable-session limitation, and error handling.
Safety boundary
- Never read or reveal
.env, bearer tokens, saved login contents, or platform/provider credentials.
- Never invent IDs, stages, revisions, request IDs, or sessions.
- Establish the user's operating scope before mutating. Authorization may cover one action or grant standing autonomy over named projects, resources, action types, or objectives.
- Within a clear delegated scope, act without asking for confirmation before every mutation. Ask only when an action is ambiguous, outside scope, or materially more destructive than the granted authority.
- Fetch current state before a write, make the smallest in-scope change, then refetch and report IDs, revisions, and final state.
- Use transitions—not metadata updates—for stage changes, with the current revision and a fresh UUID request ID.
- Never use private HTTP routes to bypass unsupported CLI operations.
- If
work-item start lacks a supported durable user session, report the block; never substitute the supervisor session or invent a session UUID.
1---2name: mastra-factory3description: Operate and supervise Mastra Factory through `mastra api factory`. Use for Factory status or queue summaries, project and work-item inspection, metrics, health, decisions, attention, supervisor sessions, and user-authorized autonomous or interactive Factory operations on hosted, local, remote, or self-hosted servers.4license: Apache-2.05---6
7# Mastra Factory Supervisor
8
9Use `mastra api factory` as the operational control plane for Factory.
10
11## Default behavior
12
13For status, inspection, diagnosis, queue review, or recommendation requests:
14
151. Stay read-only.
162. Select the sole or explicitly named project; report choices when ambiguous.
173. Inspect project state, work items, metrics, thresholds, decisions, attention, and supervisor health/session.
184. Correlate stages, revisions, sessions, decisions, and health findings.
195. Report active/queued work, blocked or unhealthy items, running sessions, pending decisions, human attention, and one recommended next action.
206. Execute a recommendation only when the current request or a previously granted operating scope authorizes it.
21
22## Required reference
23
24Read [`references/factory-supervisor.md`](references/factory-supervisor.md) before running Factory commands. It is self-contained and includes target selection, output control, JSON envelopes, command discovery, the read-only workflow, mutation protocol, governance constraints, durable-session limitation, and error handling.
25
26## Safety boundary
27
28- Never read or reveal `.env`, bearer tokens, saved login contents, or platform/provider credentials.
29- Never invent IDs, stages, revisions, request IDs, or sessions.
30- Establish the user's operating scope before mutating. Authorization may cover one action or grant standing autonomy over named projects, resources, action types, or objectives.
31- Within a clear delegated scope, act without asking for confirmation before every mutation. Ask only when an action is ambiguous, outside scope, or materially more destructive than the granted authority.
32- Fetch current state before a write, make the smallest in-scope change, then refetch and report IDs, revisions, and final state.
33- Use transitions—not metadata updates—for stage changes, with the current revision and a fresh UUID request ID.
34- Never use private HTTP routes to bypass unsupported CLI operations.
35- If `work-item start` lacks a supported durable user session, report the block; never substitute the supervisor session or invent a session UUID.