@haaaiawd/anws 2.0.0 → 2.0.1

package/README.md

@@ -14,15 +14,15 @@
 
 # Anws
 
-**Anws** is a spec-driven workflow framework for AI-assisted software development.
+**Anws** is a spec-driven workflow framework for AI-assisted development across modern AI IDEs and coding tools.
 
-It gives coding agents a disciplined path:
+It helps teams build production-ready software through a disciplined path:
 
 `PRD -> Architecture -> ADR -> Tasks -> Review -> Code -> Upgrade`
 
-Instead of letting AI jump straight into implementation, Anws forces design, preserves context in files, and projects the right workflow assets into the native layout of your target AI IDE.
+Anws enforces design-first principles, preserves context in files, and prevents architectural drift across multi-tool AI coding workflows.
 
-> **TL;DR**: stop treating AI like an autocomplete toy. Give it architecture, constraints, and a lifecycle.
+> **TL;DR**: a design-first workflow framework for AI coding tools that turns vibe coding into production-oriented engineering.
 
 ## ANWS
 
@@ -171,16 +171,25 @@ If you maintain old docs or release notes, update those references before publis
 ## Compatibility
 
 Anws keeps a **single canonical workflow / skill source**, then projects it into the native directory structure expected by each tool.
+Every supported target now receives:
+
+- a root `AGENTS.md`
+- a target-native `skills/` projection
+- one target-native workflow entry surface, depending on the tool:
+  - `workflows`
+  - `commands`
+  - `prompts`
+  - aggregated `skills` for Codex Preview
 
 | Environment | Status | Layout |
 | --- | --- | --- |
-| **Windsurf** | ✅ Full Support | `.windsurf/workflows/` + `.windsurf/skills/` |
+| **Windsurf** | ✅ Full Support | `AGENTS.md` + `.windsurf/workflows/` + `.windsurf/skills/` |
 | **Antigravity** | ✅ Full Support | `.agents/workflows/` + `.agents/skills/` + `AGENTS.md` |
-| **Claude Code** | ✅ Full Support | `.claude/commands/` |
-| **GitHub Copilot** | ✅ Full Support | `.github/agents/` + `.github/prompts/` |
-| **Cursor** | ✅ Supported | `.cursor/commands/` |
-| **Codex** | ⚠️ Preview | `.codex/skills/anws-system/` + `.codex/skills/<skill>/` |
-| **OpenCode** | ✅ Supported | `.opencode/commands/` + `.opencode/skills/` |
+| **Claude Code** | ✅ Full Support | `AGENTS.md` + `.claude/commands/` + `.claude/skills/` |
+| **GitHub Copilot** | ✅ Full Support | `AGENTS.md` + `.github/prompts/` + `.github/skills/` |
+| **Cursor** | ✅ Supported | `AGENTS.md` + `.cursor/commands/` + `.cursor/skills/` |
+| **Codex** | ⚠️ Preview | `AGENTS.md` + `.codex/skills/anws-system/` + `.codex/skills/<skill>/` |
+| **OpenCode** | ✅ Supported | `AGENTS.md` + `.opencode/commands/` + `.opencode/skills/` |
 
 ---
 
@@ -234,21 +243,32 @@ your-project/
 │   ├── install-lock.json
 │   ├── changelog/
 │   └── v{N}/
+├── AGENTS.md
 ├── .windsurf/
 │   ├── workflows/
 │   └── skills/
 ├── .agents/
 │   ├── workflows/
 │   └── skills/
-├── AGENTS.md
-├── .cursor/commands/
-├── .claude/commands/
+├── .cursor/
+│   ├── commands/
+│   └── skills/
+├── .claude/
+│   ├── commands/
+│   └── skills/
 ├── .github/
-│   ├── agents/
-│   └── prompts/
+│   ├── prompts/
+│   └── skills/
+├── .opencode/
+│   ├── commands/
+│   └── skills/
 └── .codex/
-    ├── prompts/
-    └── skills/
+    ├── skills/
+    │   ├── anws-system/
+    │   │   ├── SKILL.md
+    │   │   └── references/
+    │   └── <skill>/
+    │       └── SKILL.md
 ```
 
 > One source model. Multiple target layouts. Explicit ownership on disk.

package/lib/adapters/index.js

@@ -7,7 +7,7 @@ const TARGETS = {
   windsurf: {
     id: 'windsurf',
     label: 'Windsurf',
-    rootAgentFile: false,
+    rootAgentFile: true,
     projectionTypes: {
       workflow: ['workflows'],
       skill: ['skills']
@@ -35,7 +35,7 @@ const TARGETS = {
   cursor: {
     id: 'cursor',
     label: 'Cursor',
-    rootAgentFile: false,
+    rootAgentFile: true,
     projectionTypes: {
       workflow: ['commands'],
       skill: ['skills']
@@ -49,7 +49,7 @@ const TARGETS = {
   claude: {
     id: 'claude',
     label: 'Claude',
-    rootAgentFile: false,
+    rootAgentFile: true,
     projectionTypes: {
       workflow: ['commands'],
       skill: ['skills']
@@ -63,7 +63,7 @@ const TARGETS = {
   copilot: {
     id: 'copilot',
     label: 'GitHub Copilot',
-    rootAgentFile: false,
+    rootAgentFile: true,
     projectionTypes: {
       workflow: ['prompts'],
       skill: ['skills']
@@ -77,7 +77,7 @@ const TARGETS = {
   codex: {
     id: 'codex',
     label: 'Codex (Preview)',
-    rootAgentFile: false,
+    rootAgentFile: true,
     projectionTypes: {
       workflow: ['skills'],
       skill: ['skills']
@@ -90,7 +90,7 @@ const TARGETS = {
   opencode: {
     id: 'opencode',
     label: 'OpenCode',
-    rootAgentFile: false,
+    rootAgentFile: true,
     projectionTypes: {
       workflow: ['commands'],
       skill: ['skills']

package/lib/init.js

@@ -35,6 +35,7 @@ async function init() {
   const skipped = [];
   const successfulTargets = [];
   const failedTargets = [];
+  const sessionWrittenFiles = new Set();
 
   for (const targetPlan of targetPlans) {
     const target = getTarget(targetPlan.targetId);
@@ -45,11 +46,11 @@ async function init() {
         forceYes: !!global.__ANWS_FORCE_YES
       })
       : {
-        shouldWriteRootAgents: false,
+        shouldWriteRootAgents: true,
         shouldWarnMigration: false
       };
 
-    const conflicting = await findConflicts(cwd, targetPlan.managedFiles);
+    const conflicting = await findConflicts(cwd, targetPlan.managedFiles, sessionWrittenFiles);
     if (conflicting.length > 0) {
       const confirmed = await askOverwrite(conflicting.length, target.label);
       if (!confirmed) {
@@ -72,6 +73,9 @@ async function init() {
     });
 
     written.push(...result.written);
+    for (const rel of result.written) {
+      sessionWrittenFiles.add(rel);
+    }
     skipped.push(...result.skipped);
     successfulTargets.push(summarizeTargetState(targetPlan, cliVersion));
 
@@ -122,9 +126,12 @@ async function init() {
  * 找出 cwd 中已存在的托管文件列表。
  * @returns {Promise<string[]>} 已存在的托管文件相对路径数组
  */
-async function findConflicts(cwd, managedFiles) {
+async function findConflicts(cwd, managedFiles, sessionWrittenFiles = new Set()) {
   const conflicts = [];
   for (const rel of managedFiles) {
+    if (sessionWrittenFiles.has(rel)) {
+      continue;
+    }
     const abs = path.join(cwd, rel);
     const exists = await pathExists(abs);
     if (exists) conflicts.push(rel);
@@ -236,4 +243,4 @@ function printTargetSummary(successfulTargets, failedTargets) {
 }
 
 module.exports = init;
-
+

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haaaiawd/anws",
-  "version": "2.0.0",
+  "version": "2.0.1",
   "description": "Anws — A spec-driven workflow framework for AI-assisted development. Empowers prompt engineers to build production-ready software through structured PRD → Architecture → Task decomposition. Works with Claude Code, GitHub Copilot, Cursor, Windsurf, and any tool that reads AGENTS.md.",
   "keywords": [
     "anws",

package/templates/.agents/skills/sequential-thinking/SKILL.md

@@ -1,166 +1,179 @@
----
-name: sequential-thinking
-description: 当复杂问题需要系统性逐步推理时使用。适用于多阶段分析、设计规划、问题分解，或初始范围不明确且可能需要修正、分支与动态调整思考范围的任务。
-license: MIT
----
-
-# Sequential Thinking
-
-通过可修正、可分支、可动态扩展的顺序推理，帮助 AI 处理复杂问题。
-
-## Core Capabilities
-
-- **迭代推理**: 将复杂问题拆解为连续的 thought 步骤
-- **动态范围**: 随着理解深入调整 `totalThoughts`
-- **修正能力**: 当新证据出现时回看并修正早期判断
-- **分支探索**: 从关键分叉点探索替代路径
-- **上下文保持**: 在整个推理过程中维持清晰的思考链条
-
-## When to Use
-
-在以下场景使用：
-- 问题需要多个相互关联的推理步骤
-- 初始范围或方法不明确
-- 需要在复杂性中找到核心问题
-- 可能需要回溯或修正早期结论
-- 想探索替代方案路径
-
-**不适用场景**: 简单查询、直接事实、单步任务，或解决路径已经非常明确的问题。
-
-## Basic Usage
-
-按如下 JSON 形态组织思考步骤。
-
-### Required Fields
-
-- `thought` (string): 当前推理内容
-- `nextThoughtNeeded` (boolean): 是否还需要继续推理
-- `thoughtNumber` (integer): 当前 thought 编号，从 `1` 开始
-- `totalThoughts` (integer): 当前预估总步数，可动态调整
-
-### Optional Fields
-
-- `isRevision` (boolean): 标记当前 thought 是否在修正先前思路
-- `revisesThought` (integer): 指明修正的是哪一个 thought
-- `branchFromThought` (integer): 指明从哪一个 thought 开始分支
-- `branchId` (string): 当前分支标识符
-
-## Workflow Pattern
-
-```
-1. 从 `thoughtNumber: 1` 开始。
-2. 每一步：
-   - 在 `thought` 中表达当前推理
-   - 用 `totalThoughts` 估计整体范围，必要时调整
-   - 若还需继续，设置 `nextThoughtNeeded: true`
-3. 当结论已经足够清晰时，设置 `nextThoughtNeeded: false`
-```
-
-## Example 1: 基础推演 (Baseline Reasoning)
-
-```typescript
-// First thought
-{
-  thought: "问题表面上是“查询性能下降”，但先不要急着选优化手段。需要先把问题拆成三层：是单条 SQL 退化、接口级 N+1、还是更上层的调用放大。若根因没分清，后面的缓存、索引、重写都可能只是补丁。",
-  thoughtNumber: 1,
-  totalThoughts: 4,
-  nextThoughtNeeded: true
-}
-
-// Second thought
-{
-  thought: "从查询日志看，用户详情接口在一次请求里触发了大量重复读取，已经出现明显的 N+1 信号。但还不能直接下结论，因为重复查询也可能只是症状；需要继续确认慢点究竟来自“查询次数过多”，还是“某条关键查询本身很慢”。因此总步数上调一档。",
-  thoughtNumber: 2,
-  totalThoughts: 6,
-  nextThoughtNeeded: true
-}
-
-// Final thought
-{
-  thought: "结论可以收敛了：主因是列表页批量加载时触发的 N+1，次因是关联字段缺少索引放大了单次查询成本。优化顺序应该先消除 N+1，再补索引验证尾延迟；这样既先打掉主矛盾，也避免一上来引入缓存复杂度。",
-  thoughtNumber: 6,
-  totalThoughts: 6,
-  nextThoughtNeeded: false
-}
-```
-
-## Example 2: 修正前提 (Revision in Flight)
-
-```typescript
-{
-  thought: "回看 profiling 结果后，前面的判断需要修正：真正拖垮接口的不是 N+1 本身，而是关联列缺少索引，导致每次关联查询都在放大全表扫描成本。也就是说，N+1 仍然存在，但它不是第一性瓶颈，优先级应该后移。",
-  thoughtNumber: 4,
-  totalThoughts: 6,
-  isRevision: true,
-  revisesThought: 2,
-  nextThoughtNeeded: true
-}
-```
-
-## Example 3: 复杂变更拆解 (Structured Impact Analysis)
-
-```typescript
-{
-  thought: "用户一次性提出了多项规则修改，不该把它们当成同一种改动处理。先拆开看：有的是机制原则调整，有的是数值平衡，有的是接口语义变化，还有的是文档与实现脱节。如果不先分型，后面会把“该改 ADR 的”“该改设计文档的”“该补代码契约的”混成一锅。",
-  thoughtNumber: 1,
-  totalThoughts: 3,
-  nextThoughtNeeded: true
-}
-
-{
-  thought: "先做影响矩阵。机制原则类改动通常会回流到 ADR 和 System Design；数值平衡会影响规则表、配置与测试基线；接口语义变化最危险，因为它会悄悄破坏调用方的假设。这里最该警惕的不是改动数量，而是有没有改到“被多个模块默认依赖、但文档里没写清楚”的隐性契约。",
-  thoughtNumber: 2,
-  totalThoughts: 3,
-  nextThoughtNeeded: true
-}
-
-{
-  thought: "可以收敛了：先处理那些会改变系统边界或调用语义的项，再处理数值与体验层面的项。顺序上应优先修正文档与契约，再讨论平衡性；否则后续所有实现和评审都会建立在漂移的前提上。结论不是“先改最显眼的”，而是“先修最容易污染系统认知的”。",
-  thoughtNumber: 3,
-  totalThoughts: 3,
-  nextThoughtNeeded: false
-}
-```
-
-## Example 4: 分支比较 (Branching Trade-offs)
-
-```typescript
-// Branch A
-{
-  thought: "方案 A：先引入缓存削峰。好处是见效快、对接口层侵入小，适合先止血；坏处是会把问题从“数据库慢”转成“缓存一致性与失效策略复杂”，如果根因其实是查询设计不合理，这条路容易把偶然复杂度永久留在系统里。",
-  thoughtNumber: 3,
-  totalThoughts: 7,
-  branchFromThought: 2,
-  branchId: "cache",
-  nextThoughtNeeded: true
-}
-
-// Branch B
-{
-  thought: "方案 B：直接做索引优化和查询重写。好处是从根上消除瓶颈，长期结构更干净；代价是需要更仔细验证写入放大、锁竞争和回归风险。这条路更慢，但如果业务模型稳定，通常比提前上缓存更符合简单优先的原则。",
-  thoughtNumber: 3,
-  totalThoughts: 7,
-  branchFromThought: 2,
-  branchId: "query",
-  nextThoughtNeeded: true
-}
-```
-
-## Heuristic Reminders
-
-以下提醒是**辅助思考的启发式问题**，不是硬约束。按任务性质选择性使用即可。
-
-- **问题定义提醒**: 你现在是在描述现象，还是在定位根因？
-- **证据提醒**: 当前判断基于事实、观察结果，还是基于猜测与假设？
-- **边界提醒**: 当前问题影响的是局部模块、单系统，还是跨系统结构？
-- **复杂度提醒**: 你是在消除本质复杂度，还是在增加偶然复杂度？
-- **收敛提醒**: 当前是否已经足够形成结论，还是仍在无效发散？
-
-## Tips
-
-- 先给出粗略的 `totalThoughts`，随着理解深入再调整
-- 当早期假设被证伪时，优先修正，不要沿着错误前提继续推进
-- 当存在明确替代路径时，可以用分支并行比较
-- 在 `thought` 中明确表达不确定性，比过早下结论更可靠
-- 最后一个 thought 应明确给出结论，必要时补充下一步行动
-
+---
+name: sequential-thinking
+description: 当复杂问题需要系统性逐步推理时使用。适用于多阶段分析、设计规划、问题分解，或初始范围不明确且需要受控收敛的任务。
+license: MIT
+---
+
+# Sequential Thinking
+
+这个 skill 的核心不是“多写几段 thought”，而是让 AI 在复杂问题里**持续推进、允许修正，并最终收敛成结论**。CLI 只是执行载体；skill 本身负责定义什么时候该进入这种思考方式，以及如何避免把顺序思考退化成松散输出。
+
+## Mission
+
+这个 skill 用来把复杂问题处理成一个**有边界、可修正、可复核的推理过程**：
+
+- 先澄清问题，而不是急着给答案
+- 在推进过程中允许修正和调整判断
+- 在复杂度上升时比较替代路径，而不是单线硬推
+- 在有限步数内收敛成结论与建议
+- 最后保留可回放的推理轨迹
+
+它解决的不是“不会想”，而是“想得太散、太早下结论、太难复核”。
+
+## Core Capabilities
+
+- **迭代推进**: 把复杂问题拆成连续步骤，而不是试图一口气得到完整答案
+- **动态修正**: 当新证据出现时，允许回看并修正前面的判断
+- **分支比较**: 当存在替代路径时，允许先比较再收敛
+- **上下文保持**: 在多步推理中维持清晰的问题边界与目标
+- **结论收束**: 最终必须形成判断，而不是无限发散
+
+## When to Use
+
+在以下场景调用：
+
+- 问题需要多个相互关联的推理步骤
+- 初始范围或方法不明确，需要先拆问题、再形成方法
+- 需要在有限候选方案之间做比较，而不是无限发散
+- 需要回看已有判断、识别漏洞、证据不足与隐含假设
+- 需要留下可回放、可导出的推理轨迹
+
+**不适用场景**：
+
+- 简单事实查询
+- 单步即可完成的任务
+- 路径已经非常明确、无需多步推演的问题
+- 纯头脑风暴且暂时不要求收敛的场景
+
+## Working Philosophy
+
+- **先找主问题，再找答案**：不要把现象描述误当作根因定位
+- **允许修正，而不是硬撑前提**：前面想错了，就回头修，不要带着错误前提继续推进
+- **先消除复杂度，再堆解决方案**：优先识别主矛盾，而不是抢着给补丁
+- **每一步只推进一步**：当前步只表达当前判断，不重复整套背景
+- **最终必须落到结论**：不能把“我还能继续想”当作默认出口
+
+## Installation & Runtime Model
+
+这个 skill 面向 agent 交付思考方式与调用约束；CLI 通过 npm 分发。
+
+在使用前，应先确保本地已安装对应 CLI：
+
+```bash
+npm install -g sequential-thinking-cli
+
+# 或
+pnpm add -g sequential-thinking-cli
+```
+
+安装后，使用 `sthink` 作为命令入口。
+
+## CLI Contract
+
+本 skill 不再要求 AI 手写 thought JSON。执行层通过 CLI 主路径动作完成：
+
+- `start`
+- `step`
+- `replay`
+
+### `start`
+
+只接受四个输入：
+
+- `name`
+- `goal`
+- `mode`
+- `totalSteps`
+
+约束：
+
+- `mode` 仅允许 `explore`、`branch`、`audit`
+- `totalSteps` 仅允许 `5` 或 `8`
+
+如果你不确定该选哪种模式，默认用 `explore`。只有在任务明显是在比较候选路径时才用 `branch`；只有在任务明显是在审查既有判断时才用 `audit`。
+
+### `step`
+
+只接受：
+
+- `content`
+
+其余上下文应由 runtime 自动恢复并注入。
+
+### `replay`
+
+用于读取已完成会话并生成 replay 文档；如需要，可额外导出到当前目录。
+
+## Recommended Workflow
+
+```text
+1. 先判断问题是否真的需要 sequential-thinking，而不是默认套用。
+2. 如需要，先安装或确认本地已有 npm CLI。
+3. 用 `sthink start` 给出 `name`、`goal`、`mode`、`totalSteps`。
+4. 用 `sthink step` 逐步推进，每一步只写当前推进内容。
+5. 当出现新证据时，允许修正，而不是硬撑旧判断。
+6. 到收敛阶段时，必须输出结论、风险与下一步建议。
+7. 完成后按需使用 `sthink replay` 生成与导出回放文档。
+```
+
+## Examples
+
+以下示例不是为了让你回去手写 JSON，而是为了说明这种 skill 真正有价值的地方：**如何推进、如何修正、如何收敛**。
+
+### Example 1: 基础推演
+
+```bash
+sthink start --name "query-diagnosis" --goal "定位查询性能下降的主因" --mode explore --totalSteps 5
+sthink step --sessionPath "<session-path>" --content "先不要急着选优化手段。需要先把问题拆成几层：是单条 SQL 退化、接口级 N+1，还是更上层的调用放大。若根因没分清，后面的缓存、索引、重写都可能只是补丁。"
+sthink step --sessionPath "<session-path>" --content "从查询日志看，用户详情接口在一次请求里触发了大量重复读取，已经出现明显的 N+1 信号。但还不能直接下结论，因为重复查询也可能只是症状；需要继续确认慢点究竟来自“查询次数过多”，还是“某条关键查询本身很慢”。因此总步数上调一档。"
+sthink step --sessionPath "<session-path>" --content "结论可以收敛了：主因是列表页批量加载时触发的 N+1，次因是关联字段缺少索引放大了单次查询成本。优化顺序应该先消除 N+1，再补索引验证尾延迟；这样既先打掉主矛盾，也避免一上来引入缓存复杂度。"
+```
+
+### Example 2: 修正前提
+
+```bash
+sthink step --sessionPath "<session-path>" --content "回看 profiling 结果后，前面的判断需要修正：真正拖垮接口的不是 N+1 本身，而是关联列缺少索引，导致每次关联查询都在放大全表扫描成本。也就是说，N+1 仍然存在，但它不是第一性瓶颈，优先级应该后移。"
+```
+
+### Example 3: 复杂变更拆解
+
+```bash
+sthink start --name "change-impact-analysis" --goal "拆解复杂变更的影响与优先级" --mode explore --totalSteps 5
+sthink step --sessionPath "<session-path>" --content "用户一次性提出了多项规则修改，不该把它们当成同一种改动处理。先拆开看：有的是机制原则调整，有的是数值平衡，有的是接口语义变化，还有的是文档与实现脱节。如果不先分型，后面会把“该改 ADR 的”“该改设计文档的”“该补代码契约的”混成一锅。"
+sthink step --sessionPath "<session-path>" --content "先做影响矩阵。机制原则类改动通常会回流到 ADR 和 System Design；数值平衡会影响规则表、配置与测试基线；接口语义变化最危险，因为它会悄悄破坏调用方的假设。这里最该警惕的不是改动数量，而是有没有改到“被多个模块默认依赖、但文档里没写清楚”的隐性契约。"
+sthink step --sessionPath "<session-path>" --content "可以收敛了：先处理那些会改变系统边界或调用语义的项，再处理数值与体验层面的项。顺序上应优先修正文档与契约，再讨论平衡性；否则后续所有实现和评审都会建立在漂移的前提上。结论不是“先改最显眼的”，而是“先修最容易污染系统认知的”。"
+```
+
+### Example 4: 分支比较
+
+```bash
+sthink start --name "performance-tradeoff" --goal "比较缓存止血与查询优化的优先级" --mode branch --totalSteps 5
+sthink step --sessionPath "<session-path>" --content "方案 A：先引入缓存削峰。好处是见效快、对接口层侵入小，适合先止血；坏处是会把问题从“数据库慢”转成“缓存一致性与失效策略复杂”，如果根因其实是查询设计不合理，这条路容易把偶然复杂度永久留在系统里。与此同时，方案 B：直接做索引优化和查询重写。好处是从根上消除瓶颈，长期结构更干净；代价是需要更仔细验证写入放大、锁竞争和回归风险。这条路更慢，但如果业务模型稳定，通常比提前上缓存更符合简单优先的原则。"
+```
+
+## Storage & Export Boundary
+
+- runtime 会自动保存会话状态与步骤记录
+- 完成态可生成 replay 文档
+- `replay` 支持导出到当前目录，便于审阅与复用
+
+## Heuristic Reminders
+
+以下提醒是启发式问题，不是硬约束。真正重要的是：它们能帮助你减少空转，逼近结论。
+
+- **问题定义提醒**: 你现在是在描述现象，还是在定位根因？
+- **证据提醒**: 当前判断基于事实、观察结果，还是基于猜测与假设？
+- **边界提醒**: 当前问题影响的是局部模块、单系统，还是跨系统结构？
+- **复杂度提醒**: 你是在消除本质复杂度，还是在增加偶然复杂度？
+- **收敛提醒**: 当前是否已经足够形成结论，还是仍在无效发散？
+
+## Tips
+
+- 不要再手写 thought JSON；让 CLI runtime 负责节奏、落盘与 replay
+- 不要把 sequential-thinking 当成默认模式，只在真正需要多步收敛时调用
+- 如果不确定模式，先用 `explore`
+- `step` 的 `content` 只表达当前推进内容，不要重复补全系统上下文
+- 如果发现前提错了，就明确修正，不要硬撑
+- 到收敛阶段时，应明确输出结论、风险和下一步动作
+- 只有已完成会话才能执行 `replay`
+