to-tester

name	to-tester
description	Generate a tester-facing change impact handoff for a completed Superharness task or a standalone current Git change without task artifacts. Use when superharness:finishing-a-development-branch offers the tester handoff, when the user asks to "生成影响范围", "生成测试文档", "生成测试影响范围", or "测试交接文档", or when /superharness:to-tester is invoked.
argument-hint	[task-id]

To Tester

Create or refresh a concise Chinese test handoff grounded in either durable task evidence or the current Git change.

Resolve the Source

Select exactly one evidence mode in this order:

1. Select Standalone change when the user explicitly refers to a small/current change or says no task exists.
2. Select Task-backed when /superharness:to-tester {task-id} supplies a task or superharness:finishing-a-development-branch passes one.
3. Select Task-backed when the current request explicitly refers to the task named in workflow context and its directory exists.
4. Select Standalone change for every other manual invocation.

Use workflow context as task evidence only when the current request explicitly refers to that task. Source resolution completes when the mode, repository root, target revision, and output path are unambiguous.

Task-backed

Read .superharness/tasks/{task-id}/task.json and write .superharness/tasks/{task-id}/to-tester.md. Ask for the exact task-id when the request chooses Task-backed mode but does not identify one.

Standalone change

Use the current Git repository without requiring .superharness/tasks/ or task artifacts. Write to the user-specified path when provided; otherwise write .superharness/to-tester.md and create its parent directory when needed.

Collect Evidence

Task-backed Evidence

Use this primary evidence priority: task.json → verification.md → Git → QA → trace.jsonl.

Read the available task evidence:

• task.json for identity, profile, lifecycle state, task item status, result, and commit; read prd.md and contract.md for intent and acceptance boundaries.
• plan.md for planned module boundaries when present.
• verification.md for the Verified Implementation HEAD and Base, exact command results, Original Final Review, Fix-Diff Reviews, Effective Final Review, QA Evidence, Unverified items, and Known Risks.
• Git for the commits and actual diff described by the task evidence.
• trace.jsonl plus the QA Evidence section for persisted QA facts; evals/* is only current-session local supplementary evidence.
• trace.jsonl for lifecycle facts and user interventions.

When verification.md exists, resolve the implementation revision from Verified Implementation HEAD; accept legacy HEAD only for historical evidence. Run superharness task evidence {task-id} --json and use the Verified Implementation HEAD only when it is valid. QA is usable only when its verification and trace records agree on run, revision, and verdict and that revision equals the verified implementation HEAD; mark every other persisted QA record stale. evals/* cannot establish a historical QA fact. Resolve an invalid chain by having the user select the revision the handoff should describe.

Shared Git Evidence

Resolve the repository root and current revision first:

git rev-parse --show-toplevel
git rev-parse HEAD

Use the base branch supplied by the finishing context. For a manual invocation without that context, inspect the common candidates:

git merge-base HEAD main
git merge-base HEAD master

Select the single existing candidate, or either candidate when both resolve to the same merge base. Ask the user to confirm the base when the results differ or neither candidate exists. Then inspect the actual branch changes with:

git status --short
git log --oneline <base>..HEAD
git diff --name-status <base>...HEAD
git diff --stat <base>...HEAD
git diff <base>...HEAD
git diff
git diff --cached

Filter the selected output file from Git evidence before classifying changes. This keeps a refreshed handoff outside its own implementation scope.

Standalone Evidence

Use the user's current request for intent and background. Use commit subjects and the shared Git evidence for implementation scope. Use exact verification commands and results already available in the current session. When no verification evidence exists, record 当前未提供验证证据.

Confirm that at least one committed, staged, or unstaged change exists. When every diff is empty, report that no change is available to document and stop.

Treat the Git diff as implementation truth. In Task-backed mode, use prd.md and contract.md to explain why the change exists. In Standalone change mode, use the user request and commit subjects. Evidence collection completes when every changed file and every recorded unresolved finding has been classified into a user-facing module or an internal-only change.

Synthesize the Handoff

Write in Chinese for a tester who needs scope and risk, not a file-by-file implementation summary.

• Describe the background in business or user terms.
• Split impact into direct behavior changes and regression surfaces.
• Express every impact item as a table row with 模块, 功能点, and 描述. Write each description as 适用场景 + 行为变化, such as 酒店因私预定场景下不限制城市选择范围.
• Label every direct impact row and every focus module row with a change type of 新增, 修改, or 删除. Derive the change type from business-visible behavior, never from the Git file status: a new control added to an existing page is 新增, and a behavior change on an existing control is 修改. Keep one row per functional point; a module with several changed functional points still occupies several rows, each carrying its own change type. Resolve a functional point that both adds and alters behavior by the precedence 新增 > 修改 > 删除. Do not add a change type to regression impact or suggested test scenarios, because those rows describe existing behavior rather than this change.
• Express every focus module as a table row with its change type, change, risk, and recommended verification method.
• Express every suggested test scenario as a table row derived from acceptance criteria, changed behavior, boundaries, error paths, and regression surfaces that appear in the evidence.
• Extract environment, account, data, configuration, and feature-switch prerequisites that testers need before execution.
• Separate verified facts, unverified items, and known risks. Use exact commands and concise results from verification.md or current-session evidence.
• State missing evidence as unavailable. Ground every claim in the selected source and Git diff.

Write the Document

Replace the selected output file on every run so the handoff describes the current change:

• Task-backed: .superharness/tasks/{task-id}/to-tester.md
• Standalone change: user-specified path or .superharness/to-tester.md

Use this exact structure:

# 测试影响范围

> 来源：{任务 {task-id} / 当前 Git 改动}
> 基线：{base branch or commit}
> 当前版本：{HEAD}

## 1. 背景

{说明需求来源、用户问题和本次改动目标。}

## 2. 影响范围

### 直接影响

| 模块 | 变更类型 | 功能点 | 描述 |
|------|----------|--------|------|
| {用户可识别的业务模块或页面} | {新增/修改/删除} | {具体交互、组件、接口或业务能力} | {适用场景 + 行为变化} |

### 回归影响

| 模块 | 功能点 | 描述 |
|------|--------|------|
| {可能受变化链路影响的业务模块或页面} | {需要回归的既有功能点} | {适用场景 + 需要确认的既有行为} |

## 3. 重点关注模块

| 模块 | 变更类型 | 变化点 | 风险点 | 建议验证方式 |
|------|----------|--------|--------|--------------|
| {模块或流程名称} | {新增/修改/删除} | {本次发生了什么变化} | {最可能出错的边界或依赖} | {如何观察并确认该模块行为正确} |

## 4. 建议测试场景

| 优先级 | 场景 | 操作 | 预期 |
|--------|------|------|------|
| {P0/P1/P2} | {场景名称} | {测试操作} | {可观察结果} |

## 5. 测试准备

- 环境：{所需环境；无特殊要求时写“无特殊要求”。}
- 账号与权限：{所需账号、角色或权限；无特殊要求时写“无特殊要求”。}
- 测试数据：{前置数据及构造方式；无特殊要求时写“无特殊要求”。}
- 配置与开关：{配置、灰度或功能开关；无特殊要求时写“无特殊要求”。}

## 6. 已验证项与已知风险

### 已验证项

- `{command}`：{result}（来源：`verification.md` 或当前会话验证证据；无证据时写“当前未提供验证证据”）

### 尚未验证项

- {尚未覆盖的行为或环境。}

### 已知风险

- {review、QA 或 diff 暴露的风险；没有记录时写“当前证据未记录已知风险”。}

Completion Gate

Re-read the generated file and confirm:

• The selected mode and output path follow Resolve the Source.
• Task-backed reports agree with the named task artifacts; Standalone change reports cover every committed, staged, and unstaged change in scope.
• The six numbered sections exist once and remain in order.
• Direct impact uses the exact | 模块 | 变更类型 | 功能点 | 描述 | table header, and regression impact uses the exact | 模块 | 功能点 | 描述 | table header.
• Every impact row names one module and one functional point, and its description states the applicable scenario and behavior change.
• Every direct impact row and every focus module row carries a change type that is exactly 新增, 修改, or 删除.
• Every directly changed testable module appears in the impact scope and focus modules.
• Focus modules use the exact | 模块 | 变更类型 | 变化点 | 风险点 | 建议验证方式 | table header, and every row contains all five fields.
• Suggested scenarios use the exact | 优先级 | 场景 | 操作 | 预期 | table header, and every row has an observable expected result.
• Test preparation covers environment, account and permissions, test data, configuration, and feature switches.
• Verification, unverified items, and known risks agree with the evidence.
• Task-backed evidence passes superharness task evidence {task-id} --json.
• The file contains no placeholders or unsupported claims.

Report the output path. When Task-backed mode is invoked from superharness:finishing-a-development-branch, return control to its option menu after generation.