Forensic Report

Generated: {ISO timestamp} Problem: {user's description}

---

Evidence Summary

Git Activity

• Last commit: {date} — "{message}"
• Commits (last 30): {count}
• Time span: {earliest} → {latest}
• Uncommitted changes: {yes/no — list if yes}
• Active worktrees: {count — list if >1}

Planning State

• Current milestone: {version or "none"}
• Current phase: {number — name — status}
• Last session: {stopped_at from STATE.md}
• Blockers: {any flags from STATE.md}

Artifact Completeness

Phase	PLAN	CONTEXT	RESEARCH	SUMMARY	VERIFICATION
{for each phase: name	✅/❌ per artifact}

Anomalies Detected

{Anomaly Type} — {Confidence: HIGH/MEDIUM/LOW}

Evidence: {specific commits, files, or state data} Interpretation: {what this likely means}

{repeat for each anomaly found}

Root Cause Hypothesis

Based on the evidence above, the most likely explanation is:

{1-3 sentence hypothesis grounded in the anomalies}

Recommended Actions

1. {Specific, actionable remediation step}
2. {Another step if applicable}
3. {Recovery command if applicable — e.g., /gsd:resume-work, /gsd:execute-phase N}

---

Report generated by /gsd:forensics. All paths redacted for portability.

报告的章节结构（Evidence Summary / Git Activity / Planning State / Artifact Completeness / Anomalies Detected / Root Cause Hypothesis / Recommended Actions）与产物完整性五列表格，均被 [tests/forensics.test.cjs](https://gitcode.com/GitHub_Trending/getshi/get-shit-done/blob/dee2434b0ff956547f3741df7a81d2fa23b88f7a/tests/forensics.test.cjs?utm_source=gitcode_repo_files) 的 report structure 测试用例作为强约束断言，可见该模板属于需要长期保持稳定的对外契约。

### 脱敏规则（Redaction rules）

报告需要可移植且不含敏感信息，规则如下：
- 绝对路径替换为相对路径（去掉 `$HOME` 前缀）；
- 移除 git diff 输出中出现的任何 API key、token、凭据；
- 大段 diff 截断为前 50 行。

这一要求与命令级 `critical_rules` 中的 "Redact sensitive data: Strip absolute paths, API keys, tokens from reports and issues" 一一呼应。

## 呈现、跟进与收尾

报告生成后流程依次为：

1. **Step 5 内联呈现**：完整展示报告内容。
2. **Step 6 交互式深入调查**：向用户提供继续深挖的选项——追踪某个异常到根因、读取证据中引用的具体文件、或检查历史上是否报告过类似问题；后续问题只基于已收集证据回答，仅在确有必要时才读取额外文件。
3. **Step 7 创建 GitHub issue**：若发现可行动的异常（HIGH 或 MEDIUM 置信度），征得确认后格式化发现并脱敏路径，再使用 `gh` 创建 issue。工作流刻意把 issue 提交到维护仓库 `gsd-build/get-shit-done` 而非用户当前项目仓库——这一点被 [tests/forensics.test.cjs](https://gitcode.com/GitHub_Trending/getshi/get-shit-done/blob/dee2434b0ff956547f3741df7a81d2fa23b88f7a/tests/forensics.test.cjs?utm_source=gitcode_repo_files) 的正则断言严格保护（`gh issue create` 必须携带 `--repo gsd-build/get-shit-done`），其目的从测试注释可知是"避免把缺陷提交到用户当前项目仓库"。使用 `bug` label 前还会先查询其是否存在：

```bash
# 使用前先检查 "bug" label 是否存在
BUG_LABEL=$(gh label list --repo gsd-build/get-shit-done --search "bug" --json name -q '.[0].name' 2>/dev/null)
LABEL_FLAG=""
if [ -n "$BUG_LABEL" ]; then
  LABEL_FLAG="--label bug"
fi

gh issue create \
  --repo gsd-build/get-shit-done \
  --title "bug: {concise description from anomaly}" \
  $LABEL_FLAG \
  --body "{formatted findings from report}"

4. Step 8 更新 STATE.md：把"取证调查完成"记入会话跟踪，保证诊断活动本身进入可审计的会话历史：

gsd-sdk query state.record-session "" \
  "Forensic investigation complete" \
  ".planning/forensics/report-{timestamp}.md"