mastra-factory

Mastra Factory 主管

使用 mastra api factory 作为 Factory 的运营控制平面。

首次使用：先连接，再检查

阅读 references/connection.md。检查 CLI 是否可用，确认用户实际使用的 Factory URL；对于由平台托管的部署，运行 mastra auth whoami。如果用户已登出，请提供 mastra auth login，而不是悄悄启动浏览器登录。本地／可自托管部署的身份验证方式可能不同。

即使当前目录为空，也可以运行显式指定目标的 mastra api --url "$FACTORY_URL" factory project list；无需部署的代码仓库或 .mastra-project.json。切勿假设共享主机、组织、项目名称或 ID。后续命令中应保留显式指定的目标。

默认行为

对于状态、检查、诊断、队列审查或建议请求：

1. 保持只读。
2. 选择唯一的项目或明确指定的项目；如果存在歧义，则报告可选项目。
3. 检查项目状态、工作项、指标、阈值、决策、待处理事项以及主管健康状况／会话。
4. 关联各阶段、修订版本、会话、决策和健康检查结果。
5. 报告进行中／排队中的工作、受阻或不健康的项目、运行中的会话、待处理的决策、需要人工处理的事项，以及一项建议的后续操作。
6. 只有当前请求或先前授予的操作范围授权执行建议时，才执行该建议。

必读参考资料

在运行 Factory 命令前，阅读 references/factory-supervisor.md，了解输出控制、契约、只读工作流、变更协议、治理约束、持久会话的限制以及错误处理。

对于“我的工作”、实际执行进度、线程消息、记忆或健康状况解读相关请求，还需阅读 references/session-inspection.md。区分卡片阶段与运行中的 Agent、历史消息与当前记忆，以及 Agent 的说法与已验证的代码仓库结果。

安全边界

• 切勿读取或泄露 .env、Bearer 令牌、已保存的登录内容或平台／提供商凭据。
• 切勿捏造 ID、阶段、修订版本、请求 ID 或会话。
• 执行变更前，先确认用户的操作范围。授权可以涵盖单项操作，也可以针对指定项目、资源、操作类型或目标授予持续自主权。
• 在明确委派的范围内，无需在每次变更前都请求确认。只有操作存在歧义、超出范围，或其破坏性明显超过已授予的权限时，才需要询问。
• 写入前获取当前状态，进行范围内最小幅度的变更，然后重新获取状态并报告 ID、修订版本和最终状态。
• 阶段变更应使用状态转换，而不是元数据更新，并提供当前修订版本和新生成的 UUID 请求 ID。
• 切勿使用私有 HTTP 路由绕过 CLI 不支持的操作。
• 如果 work-item start 缺少受支持的持久用户会话，应报告受阻；切勿替代使用主管会话或捏造会话 UUID。