workflow-status

工作流状态（编排器的传感器）

一次只读扫描，用一个固定的 JSON 封装一次性回答：现有什么、什么被什么阻塞、当前可以启动什么，以及建议的下一条命令是什么。 脚本是确定性生成器：scripts/workflow-status.mjs 会执行已发布的 SENSOR_CORE 序列（步骤 1–9，包括 6a）并输出该封装。此技能运行脚本、读取 JSON、结合下方参考资料进行解读，并输出人工可读的报告——它绝不会手动组装封装。

回合约定 — 结束回合前验证

✓ The script was RUN — `bun scripts/workflow-status.mjs [--json-only]
  [--last-envelope <json|path>] [--compact]` (node is the fallback when bun is
  absent, per the repository's runtime convention); the envelope is the script's
  stdout, never assembled by the model
✓ Nothing was edited, committed, pushed, or created — read-only, always
✓ `next.recommended` is non-bare (carries the unit's slug/NN, never a bare
  `/unit-lane`) AND the script computed it from the unit's resolved status:
  `idea`/`defined` → `/unit-lane <slug>` (or `/unit-lane --fix <n>` for a fix);
  `planned`/`in-progress` → `/execute-phase <NN>` (its triage block is the
  authority; no separate plan-receipt currency check, step 6a)
✓ `detail.crash_recovery` carries a verdict from the decision table and the
  envelope `state` matches it (CLEAN→OK, RESUMABLE→CONTINUE,
  AMBIGUOUS→NEEDS_INPUT)
✓ Every `detail.design_candidates[].next` begins with `/unit-lane `
✓ Every degraded dimension is named in `detail.degradations` as
  `unavailable-<source>-<cause>` — and, when `--last-envelope` was supplied, the
  no-progress guard's `workflow_observations` note is present (never a silently
  repeated bland recommendation)
✓ The envelope is emitted on **every** invocation, including a same-session
  natural-language follow-up about state — never replaced by prose
✓ The human-readable summary is printed, then the machine envelope (the script's
  JSON) is the ABSOLUTE last output

使用 --json-only 时，跳过人工可读摘要：仅输出封装。

紧凑模式 — --compact

--compact 会输出相同的封装，但省略仓库历史记录（在成熟仓库中可减少约一半字节数）；具体的保留／删除项见封装字段。

使用时机

• 编排步骤之间：外部驱动程序运行此技能，以决定下一条命令和模型层级，无需解析散文。
• 手动选择任务前：“我现在可以启动什么？”
• 不用于评估质量（review-change／audit-pr）或产品健康状况（product-audit）——此技能只报告状态，不做评判。

步骤 0 — 发现项目（始终首先执行）

遵循 Agent 指南中的工作流约定和文档映射。脚本会读取此技能所需的内容（docs/features/ROADMAP.md、修复索引 docs/fix/README.md、每个进行中功能文件夹中的 TASKS.md、progress.md 和 review-findings.md，以及 docs/workflow/REPOSITORY_STATE.md）；只有在需要解读脚本输出的字段时，才自行阅读这些文件。

渐进式加载 — 固定传感器路径

参考资料允许列表严格限定为以下七个链接路径。绝不自行编造或读取其他 references/ 路径。此技能是只读传感器。

1. 传感器核心 — 脚本执行的序列
2. 崩溃恢复
3. 封装核心
4. 封装字段
5. 执行前证据
6. 护栏

只有当存在单元、问题、发现项或建议时，才添加传感器信号；空项目会跳过该文件，但仍会输出封装字段中定义的空结构。只有当平台确实缺少某个具名原语时，才添加可移植性。--json-only 不会跳过任何基准文件。

可移植性

传感器仅使用仓库和代码托管平台命令。当某项具名 Agent 功能不可用时，遵循可移植性，且不得更改 JSON 约定。

与其他技能的关系

• 作为 advance 指挥器的传感器对应技能：外部编排器（或 advance 本身）调用 workflow-status → 根据封装进行路由 → 直接调用 unit-lane／execute-phase／review-change／audit-pr／triage-issue，并为每一步选择模型——与 Agent 内自动驾驶采用相同的循环。
• audit-docs（评估一致性并可进行修复）和 product-audit（评估健康状况）的只读同类技能：此技能只报告状态。
• 架构所有者：orchestration-envelope（内部）。

完成条件

• 脚本已运行，报告中的每项结论都来自其封套——没有从记忆中推断，也没有手动拼凑。
• detail.design_candidates、detail.features、detail.fixes、 detail.startable_now、detail.blocked_units、detail.open_prs、 detail.untriaged_issues、detail.urgent、detail.degradations 和 detail.crash_recovery 均从封套中读取，且封套的 state 与崩溃恢复判定一致。
• 提供了 --last-envelope 时：无进展保护机制已运行——停滞的 /unit-lane 提示会作为 workflow_observations 说明显示，而不会无声地重复输出平淡内容，且未引入新的写入路径。
• 人类可读摘要（除非使用 --json-only）和封套均已打印，封套最后打印。
• 未修改任何内容。
• 如果封套包含 next.continuation，下一条命令回显会引用输出的 next.continuation（用于显示的 rendering），绝不会自行编写精确的命令令牌；下方面向用户的说明性 → Next: 区块保持不变。

→ Next：封套中的 next.recommended 命令——它根据实际状态计算，因此就是推荐命令 · 查看人工概览 → 阅读打印出的表格 · 以编程方式进行编排 → 解析脚本的 JSON