printing-press-output-review

printing-press-output-review（内部）

审查打印CLI的采样输出，发现dogfood、verify以及基于规则的scorecard --live-check规则无法捕获的合理性问题。Wave B策略：所有发现以警告形式呈现，绝不作为错误。

此技能仅限内部（user-invocable: false）。由父技能调用——主printing-press技能在shipcheck阶段4.85，polish技能在其诊断循环中。单独运行会产生浮动发现文本，无ship裁决、无修复应用、无发布提议；可操作包装是/printing-press和/printing-press-polish。技能携带context: fork，以便审查代理的诊断对话与调用技能的上下文隔离。

输入

调用者将$CLI_DIR作为参数传递：打印CLI工作目录的绝对路径。

此技能捕获的内容

基于规则的检查遗漏的错误，通常通过5分钟手动测试发现，但逃过了dogfood、verify和scorecard --live-check规则：

子串匹配结果偶然包含查询但语义不匹配（例如，查询匹配了较大无关术语的子串）
聚合命令在仅返回部分请求源时静默丢弃源
排名或排序命令返回的top-N结果并非查询的最佳结果（权重错误、提取器回退）
输出中的URL指向类别索引页面、feed端点或随机选择路由，而非规范内容永久链接
基于规则层未捕获的格式错误（乱码、不一致的复数形式、截断/换行的单元格内容）

步骤

步骤1：收集样本数据

# 定位research.json。与二进制文件相邻覆盖了promote后的布局（独立polish、针对库副本的shipcheck）。
# 祖父回退覆盖了中间管道调用，其中$CLI_DIR是$PRESS_RUNSTATE/runs/<id>/working/<cli>，
# research.json位于$PRESS_RUNSTATE/runs/<id>/research.json。没有回退时，scorecard在中间管道报告`unable: true`，
# 我们跳过最信息丰富的审查。使用bash数组以便标志能处理带空格的路径。
RESEARCH_ARGS=()
if [ ! -f "$CLI_DIR/research.json" ]; then
  _grandparent="$(dirname "$(dirname "$CLI_DIR")")"
  if [ -f "$_grandparent/research.json" ]; then
    RESEARCH_ARGS=(--research-dir "$_grandparent")
  fi
fi

cli-printing-press scorecard --dir "$CLI_DIR" "${RESEARCH_ARGS[@]}" --live-check --json > /tmp/output-review-livecheck.json 2>&1 || true

如果scorecard调用失败或/tmp/output-review-livecheck.json为空，则返回SKIP结果（步骤3），不调度审查器。

步骤2：调度审查代理

使用Agent工具（通用）并遵循以下提示合同：

审查位于$CLI_DIR的已发布CLI的采样输出。您有以下真实来源：

采样命令输出：读取/tmp/output-review-livecheck.json并检查live_check.features[]数组。每个条目包含命令、示例调用、经过编辑的stdout证据（在output_sample中，限制约4 KiB）、经过编辑的通过/失败原因以及warnings数组（由基于规则的检查填充，如原始HTML实体检测器）。将<redacted>标记视为隐私脱敏值，而非格式错误。

仅审查status: pass的条目。 status: fail的条目要么崩溃、超时，要么具有占位符参数（<id>、<url>），从未产生真实输出——其样本为空，您无需判断。阶段5的dogfood处理测试覆盖率和退出代码问题。

$CLI_DIR/research.json中的novel_features（按功能计划的预期行为）和novel_features_built（已验证构建的命令）。

CLI二进制文件位于$CLI_DIR/<cli-name>-pp-cli——当发现需要验证时，您可以调用其他命令以收集更多输出。

对于以下每项检查，报告发现，每条不超过50字。仅报告人类用户在5分钟手动测试中会注意到的问题，而非全面QA可能发现的每个边缘情况：

输出语义上与查询意图匹配。 对于带有查询参数的采样新功能，判断超出live-check中机械查询令牌检查的相关性。通过live-check的outputMentionsQuery测试的功能仍然包含某个查询令牌——但“buttermilk”作为“butter”结果的子串出现，或“brownies”因提取器回退到相邻内容而返回辣椒食谱，都逃过了机械检查。仅当人类用户查看顶部结果并说“这不是我想要的”时才标记。当示例没有查询参数时跳过此检查。

没有明显的格式错误。 输出是否包含原始HTML实体、乱码（标题中的问号或替换字符）或格式错误的URL（指向类别索引页面、feed端点或随机选择路由，而非规范内容永久链接）？基于规则的live-check捕获数字实体；此层捕获更广泛的类别。

聚合命令显示所有请求的源。 对于带有--source/--site/--region CSV标志的命令：如果用户请求N个源，输出是否显示N个，或者stderr是否解释缺失的源？失败源的静默丢弃是扇出命令的主要失败模式。

结果排序/排名合理。 对于声称排名或排序的命令，顶部结果是否看起来是查询的最佳结果？注意分数权重错误、差一排序错误以及当相关性计算失败时静默回退到最新。

学习循环命令样本（recall、learnings、playbook）的校准：在全新打印中，本地学习存储为空，因此空候选列表、零计数的learnings stats和“未记录学习”的输出是合理正确的。不要将其标记为静默失败或数据缺失。

返回发现列表。对于每个：检查名称、严重性（Wave B中为warning；error保留给Wave C）、一行描述、一句修复建议。如果CLI通过所有四项检查，返回“PASS — no findings.”

步骤3：输出结构化结果块

以父技能解析的---OUTPUT-REVIEW-RESULT---块结束技能响应：

干净通过时：

---OUTPUT-REVIEW-RESULT---
status: PASS
findings: []
---END-OUTPUT-REVIEW-RESULT---

有警告时：

---OUTPUT-REVIEW-RESULT---
status: WARN
findings:
- check: <检查名称>
  severity: warning
  description: <一行描述>
  suggestion: <一句建议>
- ...
---END-OUTPUT-REVIEW-RESULT---

审查器失败时（超时、代理预算耗尽、缺少live-check数据）：

---OUTPUT-REVIEW-RESULT---
status: SKIP
reason: <一行描述>
findings: []
---END-OUTPUT-REVIEW-RESULT---

Wave B策略（当前）

所有发现以warning形式呈现——绝不作为error。Shipcheck继续进行。
调用者将发现记录到运行的工件目录（例如manuscripts/<api>/<run>/proofs/phase-4.85-findings.md）并向用户展示。发现不会持久化到scorecard.json——该路径保留给Wave C。
用户逐案决定是否在发布前修复。

非交互式合同（CI、cron、批量重新生成）：

如果stdout不是TTY，调用者遵循失败开放并记录：记录发现，shipcheck继续进行而不提示。
status: SKIP（审查器崩溃、超时、数据缺失）是信息性的——shipcheck不会因此阻塞。
尚无--auto-approve-warnings标志。Wave B中策略已经是“警告不阻塞”，因此该标志没有门控效果。

Wave C（单独的未来PR）将在校准数据表明整个库的误报率低于10%后，将error严重性的发现转为阻塞。

为什么使用智能而非仅模板

输出合理性问题无法通过模式匹配源代码。基于规则的live-check规则覆盖了正则表达式能处理的内容（数字HTML实体、查询令牌缺失）。其他所有内容——“这些替换结果对查询是否合理？”、“顶部搜索结果看起来相关吗？”——都是LLM形式的问题。令牌成本有限（每次运行一次，而非每个命令），并且针对此阶段推动的错误类别的捕获率证明了调度的合理性。