Back to Details

session-report

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Session Report

会话报告

Audit your own session against the task file(s) you were given. Surface assumptions you made and context gaps that caused struggles. These are observations for the human — not things you can fix after the fact.
根据提供给你的任务文件，审查你自己的会话。找出你所作的假设，以及导致困难的上下文缺口。这些是供人类参考的观察结果，而不是你事后能够自行修复的问题。

Review Process

审查流程

Work through each dimension in order. For every finding, cite specific evidence.
按顺序逐一检查每个维度。对于每项发现，都要引用具体证据。

Dimension 1: Assumption Audit

维度 1：假设审查

Identify every place you made a decision that was not dictated by the task file or spec. For each assumption:
  • Ambiguity — what the spec didn't say
  • Choice — what you decided and why (the reasoning, not just the outcome)
  • Risk — what could go wrong if this choice is wrong. Be specific: name the scenario, the affected code path, and what would break. "Could surprise future workflows" is not specific enough — say which workflow shape triggers it and what the symptom would be.
  • Impact classification: 
    • benign
      — reasonable default, no real consequence (do not report)
    • notable
      — meaningful choice that could have gone differently
    • risky
      — could cause problems, warrants review
  • Recommendation — what the reviewer should do: verify behavior, add a test, clarify the spec, or approve as-is with rationale.
Report only 
risky
and 
notable
assumptions. Drop 
benign
entirely — they dilute the signal. Sort 
risky
first, then 
notable
.
找出每一个并非由任务文件或 spec 明确规定、而由你自行作出决定的环节。对于每项假设：
  • 歧义（Ambiguity） — spec 未说明的内容
  • 选择（Choice） — 你决定了什么，以及为什么（说明推理过程，而不只是结果）
  • 风险（Risk） — 如果该选择有误，可能出现什么问题。要具体说明：指出具体场景、受影响的代码路径，以及会出现什么故障。“可能会给未来工作流带来意外”不够具体——应说明哪种工作流形态会触发该问题，以及具体症状。
  • 影响分类： 
    • benign
      — 合理的默认值，没有实际影响（不要报告）
    • notable
      — 有意义的选择，可能存在不同做法
    • risky
      — 可能引发问题，需要审查
  • 建议（Recommendation） — 审查者应采取的行动：验证行为、添加测试、澄清 spec，或说明理由后按原样批准。
仅报告 
risky
和 
notable
假设。完全省略 
benign
，因为它会稀释信号。先列出 
risky
，然后列出 
notable
。

Dimension 2: Context Gaps

维度 2：上下文缺口

A context gap is a major, avoidable hole in the task file or project context that sent you down a fundamentally wrong path, caused you to build the wrong thing, or wasted significant effort that better upfront information would have prevented entirely.
The bar is high. Most sessions have zero context gaps. Fixing a linter warning is not a context gap. Searching for a convention is not a context gap. Iterating on validator feedback is not a context gap — it is the normal development loop.
Examples of real context gaps:
  • The task said to extend module X, but module X was deleted last week and replaced by module Y — you built against a nonexistent target
  • The task required integrating with service A but didn't mention that service A requires an auth token from a separate provisioning step — you couldn't have known this without tribal knowledge
  • The task file pointed you to the wrong directory or package, wasting significant effort before you found the right one
Things that are NOT context gaps (do not report these):
  • Anything the validator caught (lint, security, permissions, test failures) — the validator's entire purpose is to catch what the task doesn't enumerate
  • Quick searches for conventions, patterns, or existing code — that is normal development
  • Iterative fix cycles of any kind — fixing things the first pass missed is expected, not a gap
  • Learning something new about the codebase during implementation
For each genuine context gap:
  • What happened — the concrete wasted effort or wrong direction
  • What was missing — the specific information that, if present, would have prevented it entirely
上下文缺口是指任务文件或项目上下文中一个重大且本可避免的空白，它使你走上了根本错误的路径、导致你构建了错误的东西，或浪费了大量本可通过前期信息完全避免的工作。
门槛要高。大多数会话没有上下文缺口。修复 linter 警告不是上下文缺口。搜索约定、模式或现有代码不是上下文缺口。根据 validator 反馈进行迭代不是上下文缺口——这是正常的开发循环。
上下文缺口的真实示例：
  • 任务要求扩展模块 X，但模块 X 上周已被删除，并由模块 Y 取代——你基于一个不存在的目标进行了开发
  • 任务要求与服务 A 集成，但未说明服务 A 需要通过单独的置步骤获取 auth token——如果没有团队隐性知识，你不可能知道这一点
  • 任务文件指向了错误的目录或 package，导致你在找到正确位置前浪费了大量精力
不属于上下文缺口的内容（不要报告这些）：
  • validator 捕获到的任何问题（lint、安全、权限、测试失败）——validator 的全部目的就是捕获任务未逐项列出的问题
  • 快速搜索约定、模式或现有代码——这是正常开发
  • 任何形式的迭代修复周期——第一次没修好是预期现象，不属于缺口
  • 在实现过程中了解到的代码库新信息
对于每个真实存在的上下文缺口：
  • 发生了什么 — 具体浪费的工作或错误方向
  • 缺失了什么 — 如果事先提供，就能完全避免问题的具体信息

Output Format

输出格式

markdown
undefined
markdown
undefined

Assumption Audit

假设审查

Risky

高风险

  1. [What the spec didn't say]
    • Choice: [What you decided and why]
    • Risk: [Specific scenario that breaks — name the code path, workflow shape, and symptom]
    • Recommendation: [What the reviewer should do]
  1. [spec 未说明的内容]
    • 选择： [你决定了什么，以及为什么]
    • 风险： [会导致故障的具体场景——指出代码路径、工作流形态和症状]
    • 建议： [审查者应采取什么行动]

Notable

值得注意

  1. [What the spec didn't say]
    • Choice: [What you decided and why]
    • Risk: [Specific scenario that breaks — name the code path, workflow shape, and symptom]
    • Recommendation: [What the reviewer should do]
  1. [spec 未说明的内容]
    • 选择： [你决定了什么，以及为什么]
    • 风险： [会导致故障的具体场景——指出代码路径、工作流形态和症状]
    • 建议： [审查者应采取什么行动]

Context Gaps

上下文缺口

  • [What happened] — Missing context: [what was needed]

Omit any section (`Risky`, `Notable`) that has zero items. Do not include a `Benign` section.
  • [发生了什么] — 缺失的上下文：[所需信息]

如果某个部分（`Risky`、`Notable`）没有条目，则将其省略。不要包含 `Benign` 部分。

Guardrails

防护规则

  • Do not suggest fixes for context gaps. Report what needs attention; leave solutions to the human.
  • Do not conflate code quality issues with assumptions. An assumption is a decision you made where the spec was silent — not a code style choice.
  • 不要针对上下文缺口建议修复方案。 报告需要关注的内容；把解决方案留给人类。
  • 不要将代码质量问题与假设混为一谈。 假设是指在 spec 未作说明的情况下你作出的决定——而不是代码风格选择。