daily-report

daily-report

Pylot 团队的标准报告格式。用于晨会点名派发的任务，以及任何站会／状态报告任务。

适用场景

• 你接到了一项点名或站会任务
• 任务要求“按 /daily-report 撰写今日团队报告”
• 任何要求提供团队状态报告的任务

标准章节

第 0 节：生产环境健康状况（强制 — 必须进行 P0/P1 验证）

每个仓库一行。必须放在最前面 — 生产环境问题绝不能被埋在问题或 PR 之后。

格式：

- org/repo — 🟢 green: up, no incidents
- org/repo — 🔴 red: 500 errors on /api/products (issue #84, since 2026-04-11) [verified: curl → 503]
- org/repo — 🟡 yellow: degraded response times, investigating
- org/repo — ⚠️ UNVERIFIED: repo#84 claims 500 — production returns 200, likely false positive

如果没有正在发生的事故：All repos: 🟢 green

P0/P1 验证流程

任何声称严重性为 P0/P1，或标题或正文包含关键词 500、down、broken、production 的问题，在列入简报之前都必须经过验证。 未经验证的 P0 会浪费 Max 的办公时间 — 它们比漏报真实事故危害更大。

决策树：

Issue claims P0/P1 or has keywords (500, down, broken, production)?
├── YES → Extract production URL from body (https:// that is NOT a GitHub URL)
│   ├── URL found → run liveness check:
│   │   STATUS=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$PROD_URL")
│   │   ├── 5xx or timeout → CONFIRMED outage
│   │   │   → 🔴 P0: org/repo — [title] (issue #N, since DATE) [verified: curl → $STATUS]
│   │   └── 200 → UNVERIFIED — production is up, claim is questionable
│   │       → ⚠️ UNVERIFIED: org/repo#N claims [keyword] — production returns 200, likely false positive
│   └── No production URL → check issue body for evidence:
│       ├── Has evidence (curl output, screenshot, error log, Sentry/Bugsnag link)
│       │   → 🟡 NEEDS REVIEW: org/repo#N — [title] — has evidence, cannot auto-verify
│       └── No evidence → comment on the issue asking for evidence (see template below)
│           → ⚠️ UNVERIFIED: org/repo#N claims [keyword] — no production URL or evidence; asked filer
└── NO → Standard reporting, no verification needed

不同情形的输出格式：

情形	格式
已验证的服务中断（curl 5xx）	🔴 P0: org/repo — [title] [verified: curl → 503]
未验证（curl 200）	⚠️ UNVERIFIED: org/repo#N claims [keyword] — production returns 200, likely false positive
有证据，但无 URL	🟡 NEEDS REVIEW: org/repo#N — [title] — has evidence, cannot auto-verify
无 URL，无证据	⚠️ UNVERIFIED: org/repo#N claims [keyword] — no production URL or evidence; asked filer

向提交者询问的评论模板（未找到 URL 和证据时发布）：

gh issue comment $ISSUE_NUMBER --repo $ORG/$REPO --body "Promoting this to P0 in rollcall requires production evidence.
Please add one of:
- curl output showing the error: \`curl -I https://your-production-url.com\`
- Screenshot or error log from production
- Sentry/Bugsnag link

Without evidence, this will appear as ⚠️ UNVERIFIED in the morning briefing."

第 1 节：未关闭的问题

列出每个仓库的所有未关闭问题。逐一确认问题确实处于未关闭状态 — 不要照搬过时数据。

每个问题的格式：

- #N [Title](https://github.com/org/repo/issues/N) — labels: priority-high, bug

如果没有未关闭问题，请明确说明。

第 2 节：待处理的 PR

将功能 PR 和依赖 PR 分开 — 绝不能放在同一个列表中。

功能 PR：

- #N [Title](https://github.com/org/repo/pull/N) — status: review | 3d / 2026-04-10
- #N [Title](https://github.com/org/repo/pull/N) — status: draft | 15d / 2026-03-26 [STALE]

依赖 PR（每项一行，附带风险标签）：

- #N [bump lodash 4→5](https://github.com/org/repo/pull/N) — CRIT | 2d / 2026-04-11
- #N [bump eslint 8→9](https://github.com/org/repo/pull/N) — LOW | 5d / 2026-04-08

风险标签：

• CRIT — 安全 CVE、已知故障，或有记录说明存在破坏性变更的主版本
• HIGH — 可能包含 API 破坏性变更的主版本升级
• MED — 有显著变更的次版本
• LOW — 补丁更新、常规更新

PR 数量标题：N open (X actionable, Y stale drafts) — 不能只写数量。

未配置 CI 的仓库：在章节末尾注明一次，不要逐个 PR 注明。

第 3 节：最新更新

列出已合并事项的名称、PR 编号和合并日期。只写数量（“合并了 8 个 PR”）没有用。

格式：

- PR #N [Title](url) — merged 2026-04-10
- PR #N [Title](url) — merged 2026-04-09

如果过去 7 天没有合并任何内容，请明确说明，并注明上次合并日期。

第 4 节：建议的后续任务

提出 2-3 项具体行动。每项必须包含：

• 适用时提供准确的斜杠命令：/review-pr 47 CLAPES-UC/ipc-med-backend ipcmed-runner
• 顺序重要时注明执行顺序：“在合并依赖项之前先执行此操作 — 有锁文件冲突风险”
• 说明理由，并与团队 Direction 目标关联
• 对危险依赖项提示风险：“未经本地测试，切勿合并 Next.js 16”

质量规则

• 每个问题／PR 都必须包含完整的可点击 URL（https://github.com/org/repo/issues/N 或 /pull/N）
• 日期同时包含绝对日期和相对时间：3d / 2026-04-10 — 不能只写 3d
• “一切平静”不算报告 — 如果没有任何进展，请说明待办列表中接下来应该做什么
• 报告前确认数据是最新的 — 调用 gh issue list 和 gh pr list，不要猜测
• 已关闭的问题不属于未关闭问题 — 使用 gh issue view N --repo org/repo --json state 确认
• 生产环境中的 P0/P1 声明在列入简报之前必须通过 curl 验证 — 请参阅第 0 节的 P0/P1 验证流程。简报中未经验证的 P0 比漏报真实事故更浪费时间。

空闲团队的精简格式

未关闭问题和功能 PR 均为 0 的团队使用 10 行状态卡，而非完整格式：

## {team} — IDLE
Prod: 🟢 green | Issues: 0 | Feature PRs: 0 | Dep PRs: N
Last merge: YYYY-MM-DD / PR #N [Title](url)
Next: {suggested action — e.g., "process dep PRs on weekend, watch for Next.js 16 breaking changes"}

不要为闲置团队逐节生成完整报告 — 这只会增加噪声，不会提供有效信息。

报告位置

所有报告都保存到 $(git rev-parse --show-toplevel)/reports/。绝不要放在 crew/*/reports/ 或任何子目录中。

编写报告文件

完成上述所有章节的草稿后，使用 /write-report 编写文件：

/write-report --group rollcall --id {your-team-name} --type rollcall

这样可以确保：

• 路径正确（从仓库根目录开始的 reports/，绝不要使用 crew/*/）
• 文件名符合 CONVENTIONS.md 中的时间戳命名规则
• 自动发布到 Quest DB
• 所有团队的命名保持一致

不要使用 Write 工具手动编写文件——始终使用 /write-report。