# seek PRD v6：单点工具补齐（umbrella）

> 目标版本：seek v0.7.x
> 依赖基础：v0–v5 全部子系统已 ship（agent 编排 + 调度 + worktree 已落地）
> 前置阅读：[`docs/comparison.md`](../comparison.md) §"第二档单点工具缺口" + 差距汇总 🟡 P1 段；本文是把那 5 项 P1 装订成单一规划文档。
> 状态：🚀 **5/5 柱全交付**。柱 L 以瘦身版落地（`references` 语义找引用；definition/hover/symbols 经 ROI 评估故意不做，见 `feature-lsp.md`）。

**本文是 umbrella 文档**——v5 关闭了过去版本里"架构级缺口"全部 3 个 P0 项后，剩下的差距收敛成 5 个**互不耦合的单点工具**。v6 把它们规划成一组而非一个，因为它们**没有共享基础设施**，强行做成 umbrella 子柱关系反而误导；本文的作用是排序、估时、依赖梳理，让每项可以独立挑出来 ship。

| 柱 | 主题 | 估时 | 依赖 | feature PRD |
|---|---|---|---|---|
| **I** | ✅ AskUserQuestion v2 结构化选择器（多题 stack + preview 双栏） | ~2 天 | TUI（`internal/tui`）| `feature-askuser-v2.md` |
| **J** | ✅ 复合 code-review skill（low/medium/high + --fix） | ~2 天 | plan-mode v2 + skill v2 | `feature-code-review.md` |
| **K** | ✅ Monitor + 后台 bash | ~5 天 | bash 工具（`internal/tools/bash`） + 进程组管理 | `feature-bash-monitor.md` |
| **L** | ✅ LSP `references`（gopls / pyright / tsserver · 瘦身版） | ~7 天 → 实际瘦身 | tool 框架 | `feature-lsp.md` |
| **M** | ✅ 移动端通知 webhook 桥 | ~2 天 | routines（v5 柱 H） | `feature-mobile-push.md` |

> ✅ 已交付。**v6 五柱全交付**（柱 L 为瘦身版 `references`）。

**共 ~18 天**，建议按上表顺序串行（小投入先 ship + UX 改善早受益 + 各项无依赖关系不冲突）；个别项可并行（I 与 M 完全独立，K 与 L 不冲突）。

---

## 1. 动机

走完 v5 后，[Claude Code 对比文档](../comparison.md)的差距汇总长这样：

```
🟢 已交付 (v0.4-v0.6): 8 项 — git checkpoint / undo-redo / hooks / Tab / 键位 / subagent / worktree / routines
🟡 P1:              5 项 — LSP / Monitor / AskUserQuestion v2 / 复合 review / 移动 push
🟠 P2:              3 项 — TUI MCP 重启 / NotebookEdit / WebSearch
🔵 P3:              3 项 — Fast 模式 / Devcontainer / 语音输入
—— 范围外:           3 项 — SDK / 企业管理 / 多端
```

**P1 是当前最值得攻关的优先级带**：
- P0 已清零（无更高优先级阻塞）
- 全是**独立可补的单点**——任意一项 ship 后立刻可用，不需要等其他项做完
- 每项工作量都在天级别（不是周/月），ROI 高
- 全部 5 项加起来 ~18 天，2-3 周可走完一整波 P1 收尾

v6 不是 v5 那样的"架构级 umbrella"——v5 的子代理 + 调度 + worktree 必须一起设计（共享调度面 / 权限传播 / 成本归集）。v6 的 5 项**没有任何共享基础设施**，强行做成"柱 I-M 互相依赖"反而误导读者。本文功能是：
1. 写出**共同的规划维度**（估时、依赖、ROI 排序）
2. 让每项有**足够细节起步**，进入实施前可单独长成 feature PRD
3. 锁定**实施顺序与并行性建议**

## 2. 跨柱设计约束

v3 § 2 / v4 § 2 / v5 § 2 的约束全部在 v6 继续生效（prefix-cache 字节确定性、复用 Registry、信任前置、`pkg/` 零变更、失败降级、permission 单调收紧、零常驻 daemon）。

v6 独有的两条新约束：

### 2.1 单点工具不变更核心架构

v6 任一柱**不应触发 `pkg/agent` / `pkg/deepseek` / `internal/permission` 的接口变更**。如果某项实施时发现需要改这些，停下来评估——可能它根本不是"单点工具"，需要单独升级到 feature PRD 而非塞进 v6 umbrella。

理由：v0-v5 在这三个包里已经积累了大量正确性测试（race 测试、event-sourcing 重建、状态机断言）。v6 的"小工程"如果碰这些会让 review 范围爆炸，违背"P1 单点投入"的前提。

### 2.2 每项独立可回滚

v6 各柱**不依赖彼此**。柱 J 不能 import 柱 I 的代码、柱 K 不能依赖柱 L 的 LSP 启动；任一柱回滚都不影响其他柱。

理由：v5 三个柱之间因共享 cache.Tracker / permission / sysprompt 而**没法独立回滚**（要 revert M11.0 就得连带 revert M11.2 一部分）——这是 umbrella 的代价。v6 既然每项独立可补，就**别引入这种耦合**。每柱写成"我自己加 1 个工具 + 我自己 1 套测试"的形态，回滚就是 revert 1 个 commit。

---

## 3. 各柱设计草稿

### 3.1 柱 I — AskUserQuestion v2 结构化选择器

**现状（已校正）**：`ask_user` v1 已支持 **multiSelect**（`internal/tools/askuser/askuser.go:96`）和 **"Other" 自由文本自动追加**（`internal/askuser/askuser.go:60`，TUI 自动加 row + 测试 `TestValidate_RejectsReservedOtherID` 钉死）。剩下与 Claude Code `AskUserQuestion` 的真实差距只有两项：

- ❌ **一次多题**（v1 schema 只有 `question` 单数；Claude Code 一次最多 4 题，按顺序 stack 渲染）
- ❌ **`preview` 字段**（开侧栏渲染 mockup / 代码片段 / diagram；现 v1 选项只有 `label + description`）

每题最多 4 选项 + 4 题硬上限 + multiSelect + Other 这些机制 v1 已有，v2 只增"一次多题" + "preview 渲染"两个能力。

**v2 schema 草案**（粗体 = v2 新增；其他字段是 v1 已支持的语义，移到 questions 数组下而已）：

```json
{
  "questions": [                                      // ← v2 新增：数组
    {
      "question": "Which testing framework should we use?",
      "header": "Test framework",                     // ← v2 新增：短 label/chip
      "multi_select": false,                          // v1 已有
      "options": [
        {"label": "go test (stdlib)", "description": "Built-in, zero deps"},
        {"label": "testify", "description": "Assertions + mocks"},
        {"label": "ginkgo", "description": "BDD-style"}
      ]
    }
  ]
}
```

可选 `preview` 字段（每选项）：
```json
{
  "label": "Glassmorphism",
  "description": "Frosted-glass look with backdrop blur",
  "preview": "┌────────────────────┐\n│  ░░░░ blur 12px   │\n│  rgba(255,.1)     │\n└────────────────────┘"
}
```

**TUI 渲染**：
- 单题时退化为现有 picker（向后兼容）
- 多题时纵向 stack，每题独立 selector
- 任一题选 "Other" 时弹 inline 文本输入框
- 有 preview 时切换为左右双栏（左选项列表，右 preview）

**实施点**：
- `internal/tools/askuser/` 新增 v2 工具（与 v1 并存，旧 skill / prompt 不破坏）
- `internal/tui` 加多题 stack 渲染 + preview 双栏 component
- LLM 工具描述明确：单题简单场景用 v1，结构化多题用 v2

**估时分解（校正后）**：
- 工具 schema 扩为 `questions: []` 数组 + 向后兼容旧单题 schema ~0.5 天
- TUI 多题 stack 渲染（复用 v1 单题 picker 组件）~0.5 天
- preview 双栏 component + 窄终端 collapse ~0.5 天
- 集成测试（多题、preview、跨 v1/v2 schema）+ 文档 ~0.5 天
- **共 2 天**（multiSelect + "Other" v1 已有，不再算）

**风险**：
- 多题 UX 容易把 TUI 变拥挤；要严格上限 4 题
- preview 渲染如果用 markdown 会引入新依赖；草案是**纯 monospace 文本**（与现有 mockup 一致）
- 模型可能滥用——比如该问 1 题硬塞 4 题；工具描述里点明"低 ROI 多题不要乱用"

**Anti-goals**：不做 GUI 控件（slider / color picker / file picker）——超出 TUI 范畴。

---

### 3.2 柱 J — 复合 code-review skill

**现状**：seek 有 `/review` 命令——激活 plan + review prompt，单跑。功能上对应 Claude Code 的 `/code-review` 入门款。

Claude Code 的 `/code-review` 是**复合 skill**，有 effort 等级 + 模式开关：
- `low` / `medium`：少而高置信的发现（precision-first）
- `high` / `max`：广覆盖，可能含不确定项（recall-first）
- `--fix`：把发现直接 apply 到工作树
- `--comment`：发到 PR inline comment（需 `gh` CLI）
- `ultra`：云端多 agent 协作复审（不在本柱范围；那是 Claude Code 独有 + seek 不计划做）

**v6 柱 J 设计**：写一个 `~/.seek/skills/code-review/SKILL.md`（内置 skill）实现这套语义：

```yaml
---
name: code-review
description: Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups at the given effort level (low/medium: fewer, high-confidence findings; high→max: broader coverage, may include uncertain findings). Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the review.
---

# code-review

Run by `/code-review [low|medium|high|max] [--fix] [--comment]`. Defaults: `medium`, no --fix, no --comment.
...
```

**实施点**：
- 新内置 skill `internal/skill/builtin/code-review.md`（按现有 skill 框架）
- 模型 prompt 模板按 effort 等级切换 framing
- `--fix` 走 plan-mode v2 propose + per-step approve 路径（已 ship）
- `--comment` 走 `bash gh pr review ... --comment` 路径（已可用）

**估时分解**：
- skill prompt 工程（4 effort 等级 + 2 flag 组合）~1 天
- 集成现有 plan-mode + propose ~0.5 天
- 测试 + 文档 ~0.5 天
- **共 2 天**

**风险**：
- effort 等级靠 prompt framing 区分，效果取决于模型——需要在 v0.5+ DeepSeek V4 上 dogfood 校准
- `--comment` 依赖用户机器有 `gh` CLI + 已 auth；skill 里加 pre-check

**Anti-goals**：
- 不做云端 ultra review（架构选择：seek 是本地工具）
- 不做自定义 lint 规则集（skill 描述里点明用户应配 `pre-commit` 或 IDE lint，code-review skill 关注的是 LLM 能发现的语义问题）

---

### 3.3 柱 K — Monitor + 后台 bash

**现状**：`bash` 工具一次 exec、返回 stdout/stderr/exit code。长任务（`go build ./...` 跑 5 分钟、`npm install` 跑 10 分钟、`pytest` 跑 30 分钟）期间模型啥也干不了，turn 卡住。

Claude Code 的解法：
- Bash 支持 `run_in_background: true` 立即返回 + 给一个 task id
- `Monitor` 工具流式 follow 某个 task 的 stdout
- 任务可显式 kill / 自动在 session 退出时 kill

**v6 柱 K 设计**：

工具 1（`bash` 增强）：
```json
{
  "name": "bash",
  "args": {
    "command": "go build ./...",
    "run_in_background": true  // 新字段，默认 false 行为不变
  }
}
```
返回（背景模式）：
```
[bash:background] task-id=BG-001 (started). Use monitor tool to follow.
```

工具 2（新 `monitor` 工具）：
```json
{
  "name": "monitor",
  "args": {
    "task_id": "BG-001",
    "follow": true,        // true=streaming, false=snapshot
    "tail_lines": 100      // 历史回溯行数
  }
}
```
返回：增量 stdout/stderr chunks + 当前 task 状态（running / exited / killed）+ 已执行墙钟时间。

工具 3（新 `kill_task` 工具，可选）：
```json
{
  "name": "kill_task",
  "args": {"task_id": "BG-001"}
}
```

**实施点**：
- `internal/tools/bash` 扩 `run_in_background` 支持 + 拉起 detached goroutine + buffered ring buffer 存输出
- 新包 `internal/bgtasks` 管理 task 注册 / 状态 / 生命周期
- session 退出 hook：清理所有活跃 task（SIGTERM → 5s 等 → SIGKILL，沿用 bash 工具现有 escalation）
- TUI 新 panel `/tasks` 列活跃 task（snapshot view，与 `/agents` 同形）
- `monitor` 工具 ReadOnly = true → 与 `agent` 并发 dispatch 兼容

**估时分解（校正后）**：
- 后台 bash + ring buffer ~1 天
- `internal/bgtasks` 管理器 ~1 天
- `monitor` + `kill_task` 工具 ~1 天
- TUI `/tasks` panel + session 清理 hook ~1 天（含 session-exit 时 SIGTERM → grace → SIGKILL escalation 复用现有 bash 代码）
- 集成测试（含进程组 + race + ctx-cancel mid-stream）+ 文档 ~1 天
- **共 5 天**

**关键设计约束**：`monitor` 返回**单个增量 chunk** 而非真流式 stdout——CLAUDE.md "tool 输出大小写入端就限定" 不允许无界输出。每次 `monitor` 调用 yield 至多 N KB（默认 4 KB），模型用 polling 模式（连续调 monitor 取增量），不是 SSE/WebSocket-style 流。`tail_lines` 字段控制初次回溯量。这是与 Claude Code `Monitor` 工具的**语义差异**——它走真流式（model 的 SDK 层支持），seek 走 polling（与 chat-completion API 一致）。

**风险**：
- 进程组清理在 cross-platform 上不一样（Unix `setpgid` vs Windows `CREATE_NEW_PROCESS_GROUP`）——已有 `bash` 工具的现成抽象，沿用
- ring buffer 大小：默认 1 MB / task；超出 truncate 头部，避免 OOM
- task 存活跨 session？**不**——session 退出（Ctrl+C 退、`/exit`、TUI crash）即 SIGKILL 所有活跃 task。**用户 UX 影响**：误按 Ctrl+C 会丢正在跑的后台 build。`/tasks` 面板必须明确告知"task 是 session 局部"，建议 README + skill 文档同步强调。理由：跨 session 持久任务会变成第二个 v5（生命周期 / 权限 / cost 累计）问题。本柱明确不做——要持久走 `seek cron` 或 `schedule_wakeup`
- `monitor` polling 模式下模型可能反复调到等不及——文档明确推荐 pattern: "每 5-10s 调一次 monitor，不要 1s tight-loop"

**Anti-goals**：
- 跨 session 持久任务（如果真需要，应该走 `seek cron` 或 `schedule_wakeup`）
- 任务串联（task A 完成后 trigger task B）——不在本柱

---

### 3.4 柱 L — LSP 工具

**现状**：所有"找符号 / 找引用 / 看 hover" 路径都走 grep + read。对大 monorepo / 动态类型语言（Python / TypeScript）不够精确：同名符号可能命中多个、需要多轮 read 才能定位真正定义。

**v6 柱 L 设计**：

新工具 `lsp`：
```json
{
  "name": "lsp",
  "args": {
    "operation": "definition",  // definition | references | hover | symbols
    "file": "internal/foo/bar.go",
    "line": 42,
    "column": 8,
    "query": "FooBar"  // for symbols only
  }
}
```

返回：JSON 结构化结果（file + line + col + snippet）。

**懒启动 language server**：
- 首次 `lsp` 调用时根据 cwd 检测语言：`go.mod` → gopls；`pyproject.toml` → pyright；`package.json` + `tsconfig.json` → tsserver
- 每 session 缓存 LSP server 实例（一个 session 通常一种主语言）
- LSP server crash → 自动重启 + 重发 init params
- 用户没装 LSP binary → 工具返回 `[lsp: gopls not found in PATH; install via: go install golang.org/x/tools/gopls@latest]`

**多语言支持**：v0.7 仅 gopls / pyright / tsserver。其他（rust-analyzer / clangd / jdtls）需求出现后再加。

**实施点**：
- 新包 `internal/lspclient`（LSP 协议——JSON-RPC over stdio，~300 行 Go）
- 新包 `internal/tools/lsp/`（工具 wrapper）
- 启动检测 + 缓存：`internal/lspclient/manager.go`
- 单测：mock LSP server（stdio 双向 JSON-RPC，echo 模式）
- 集成测：真实启动 gopls 对 seek 自身 repo 跑 definition / references（CI 友好）

**估时分解**：
- LSP 协议客户端（init / shutdown / 4 个 method）~3 天
- 启动检测 + 多 server 缓存 + crash 重启 ~1 天
- 工具 wrapper + ReadOnly 标记 + 测试 ~1 天
- 集成测真实 gopls / pyright / tsserver ~1 天
- 文档 + skill 集成（推荐用 lsp 替代 grep）~1 天
- **共 7 天**

**风险**：
- LSP 协议非平凡——init handshake、capability negotiation、workspace folder、didOpen/didClose 同步都得处理
- LSP server 启动慢（gopls 冷启动 5-15s）——首次调用必然慢；提前预热？暂不做，懒启动 + 进度提示
- 多 session 同 cwd → 多个 gopls 进程吃内存。**单 session 单 server** 是基线；跨 session 共享是后续优化
- gopls / pyright / tsserver 版本兼容性——CI 上 pin 已知 working 版本，文档明确测过的版本

**Anti-goals**：
- 不做 LSP server 安装管理（用户负责装 + 在 PATH）
- 不做 LSP 完整覆盖（completion / signatureHelp / formatting / codeAction）——这些 IDE 已经覆盖，seek 这边只补"读取符号信息" 4 件套
- 不做 `lsp` 工具的写操作（不发 `didChange`）——seek 用 edit / write 改文件后**不**主动告诉 LSP；下一次 lsp 调用前用 `didOpen` 重读

---

### 3.5 柱 M — 移动端通知 webhook 桥

**现状**：v5 柱 H 的 OS 通知（macOS osascript / Linux notify-send / Windows toast pending）只能弹本地桌面 banner。如果用户在外面跑 cron / wakeup，回到电脑前才能看到通知。

Claude Code routines 走云 push → 直接推到用户手机。但走云会引入：服务端 / 数据上传 / 移动 app 安装 / OAuth / 推送服务商绑定。与 seek "本地 + 零 daemon + 隐私" 立场冲突。

**v6 柱 M 设计：webhook 桥**——seek 已经在跑通知时拿到 (title, body) 对，把它**额外**通过 HTTPS POST 推送到用户配置的 webhook URL。让用户自选 push 渠道：

| Push 通道 | 用户操作 |
|---|---|
| **ntfy.sh**（推荐 — 开源 + 免费 + 有 iOS/Android 客户端） | 装 ntfy app + 订阅 `ntfy.sh/<own-topic>`；webhook = `https://ntfy.sh/<topic>` |
| **Pushover** | 注册 + 拿 user-key/app-token；webhook = Pushover API |
| **Slack** | 创建 incoming webhook；URL = `https://hooks.slack.com/...` |
| **Discord** | webhook URL = `https://discord.com/api/webhooks/...` |
| **自托管** | 自己写 HTTP endpoint 收 POST |

**Config schema**：
```json
{
  "push_webhooks": [
    {
      "url": "https://ntfy.sh/my-seek-topic",
      "events": ["cron.failed", "cron.completed", "trigger.completed"],
      "format": "ntfy"  // ntfy | slack | discord | raw
    }
  ]
}
```

存在 `~/.seek/config.json`。OS 桌面通知**不替代**——webhook 是**额外**通道，不是替换。

**实施点**：
- `internal/routines/notify.go` 加 webhook dispatcher（与 osascript / notify-send 并列）
- HTTPS POST + format-specific payload（ntfy 用 plain text body + `Title:` / `Priority:` / `Tags:` HTTP header（这是 ntfy.sh 的 API 形式，不是 JSON body）；slack 用 JSON body + `blocks`；discord 用 JSON body + `embeds`；raw 用 `{title, body}` JSON body）
- 失败处理：与 osascript 一致——失败 → WARN 到 run record，不阻塞 cron
- 配置层：扩 `~/.seek/config.json` schema + `seek cron config check` 验证 webhook URL

**估时分解**：
- HTTPS dispatcher + 3 个 format（ntfy / slack / discord）~1 天
- 配置 schema + 校验 + 文档（含 ntfy 安装指南）~0.5 天
- 测试（httptest server stub + 集成进 routines）~0.5 天
- **共 2 天**

**风险**：
- 用户配错 webhook URL → 每次 cron fire 都失败 → 日志爆。WARN 限流：同一 URL 连续失败 5 次后改 DEBUG 级别
- HTTPS 证书校验：跟 webfetch 同策略（SSRF guard 不适用——这是 outbound，不是模型驱动的；但要拒绝 file:// / 私网 IP 通过用户配置渗透进来）

**Anti-goals**：
- **不做** native iOS/Android push（要 Apple/Google 推送服务注册 + 后端中转 + app 发布——成本月级，非 v0.7 范围）
- **不做** SMS / 邮件（webhook 通道用户可自己接 webhook → SMS gateway）
- **不做** webhook server（这是 outbound only；inbound 走已有的文件桥 triggers/）

---

## 4. 实施顺序与并行性

| # | 柱 | 估时 | 关键依赖 | 可与谁并行 |
|---|---|---|---|---|
| 1 | **I** AskUserQuestion v2 | 2d | TUI | 与 M 完全并行 |
| 2 | **J** 复合 code-review | 2d | plan-mode + skill | 与 M 并行 |
| 3 | **K** Monitor + 后台 bash | 5d | bash 工具 | 与 L 并行 |
| 4 | **L** LSP 工具 | 7d | 无 | 与 K 并行 |
| 5 | **M** webhook 桥 | 2d | routines | 与任意并行 |

**建议节奏**：

| 阶段 | 内容 | 周 |
|---|---|---|
| **v0.7.0** | I + J + M（小投入 + UX 改善先 ship；2+2+2 = 6d） | ~1 周 |
| **v0.7.1** | K 后台 bash（5d，含测试 + cross-platform 调试缓冲） | ~1 周 |
| **v0.7.2** | L LSP（最大一块单独 ship；7d 估时偏紧，质量缓冲到 2 周） | ~2 周 |

并行可行性：I/J/M 任一人都可推进；K/L 是中等工程，串行更稳。**总 ~4 周**走完整波 P1。

**为什么这个顺序**：
1. **I 第一**——AskUserQuestion v2 影响每个 multi-option model interaction，改 UX 收益面最广
2. **J 第二**——纯 prompt 工程，最低风险高价值；同期 dogfood I 的多题 picker
3. **M 第三**——超小投入；让用户拿到一个 ROI 高的"我离开电脑也能收到通知" 功能
4. **K 第四**——bash 工具改动需要细心，但只触一个包，blast radius 小
5. **L 最后**——独立大块（7 天），单独 release，质量门槛最高（LSP 协议出错可能误导模型）

## 5. 与 v5 的关系

v6 不重构 v5——5 项全是叠加层：
- I：扩 ask_user 而非替换
- J：新内置 skill，与 `/review` 命令共存
- K：bash 工具加 flag，不破坏现有行为
- L：新工具，零现有路径影响
- M：notify 通道扩展，OS 通知不变

v5 的子代理 / cron / worktree 全部继续工作；v6 各柱可独立选择跟 v5 集成程度：
- 柱 K（后台 bash）**可用于** v5 子代理——子代理跑 `bash run_in_background=true` 也合法
- 柱 L（LSP）**可用于** v5 explore 子代理——`explore` 模板可加 lsp 工具进入白名单
- 柱 M（webhook）**直接挂** v5 cron 通知通道

但这些是**用户行为/配置层面**的自然组合，不是设计依赖。

## 6. 跨柱共同测试要求（继承 v5 经验）

CLAUDE.md "Testing (load-bearing)" 节的 5 条标准——cancellation、mid-loop 中断、malformed 输入、并发 -race、持久化 round-trip——v6 每柱都要适用：

- **柱 I**：用户在多题 picker 中途按 Esc → 安全清理 + 模型收到 `[ask_user: cancelled]`
- **柱 J**：`--fix` 中途 Esc → plan-mode v2 已有的 Esc 处理覆盖
- **柱 K**：session 退出时活跃 task 必须被清理；进程组 SIGKILL 测试
- **柱 L**：LSP server 在 init 后立刻被 kill → 工具优雅降级到 `[lsp: server died, fallback to grep]`
- **柱 M**：webhook 服务器返回 5xx → 重试 1 次 + WARN + 不阻塞 cron 主流程

## 7. 边界（v6 明确不做的）

- **不做云托管 routines**（架构选择已锁定，见 v5 + comparison §10）
- **不做 LSP 完整覆盖**——仅 read 类 4 个 method
- **不做 mobile native push**（柱 M 已说明）
- **不做 ultra review**（柱 J 已说明）
- **不做 task chaining / cross-session task**（柱 K 已说明）

这些不是 P1 缺口，要么超出 seek 定位，要么是 v0.8+ 范围讨论。

## 8. 风险

| 风险 | 缓解 |
|---|---|
| 5 项串行做完 ~4 周，期间外部模型/API 变化导致前提失效 | 每柱独立 PRD + 独立 ship；v0.7.0 ship 3 柱后基于 dogfood 反馈再决定继续顺序 |
| 柱 L LSP 7 天估时偏低（协议复杂） | 进入实施前再起独立 feature-lsp.md 重新拆 → 真实估时可能 10d；不是阻塞 v0.7.2 ship 节奏的硬约束 |
| 柱 K 后台 bash 跨平台进程组管理 | 沿用现有 bash 工具的 cross-platform 抽象（`process_*_unix.go` / `process_*_windows.go`）；已踩过坑，不需要重新设计 |
| 柱 M webhook URL 配错导致每次 cron 失败 | WARN 限流（连续 5 失败转 DEBUG）；首次 cron 时 dispatcher 自检（HEAD 请求验证 endpoint 可达） |
| 柱 I 多题 UX 把 TUI 弄拥挤 | 硬上限 4 题；preview 双栏在窄终端自动 collapse 为单栏 |
| 5 个独立 feature PRD 起草延后导致 v6 文档与实施脱节 | 每柱进入实施前**必须**先起 feature PRD（v3-v5 已建立的规则），v6 umbrella 只负责规划与排序，不替代 feature 级设计 |

## 9. 后续候选（v0.8+ brainstorm）

- 真实 LSP 写操作（formatting / codeAction / rename）—— 跟 edit/write 工具状态同步是另一坨工程
- 跨 session 持久后台任务（v5 cron 的扩展）
- ntfy.sh + 自托管 server 推荐文档
- AskUserQuestion v3 加 GUI 控件（slider / color picker / file picker）—— §3.1 anti-goal 在 v2 阶段明确不做，等 v2 dogfood 后若纯文本预览不够再重新评估
- 复合 review skill 加 `--baseline <commit>` 增量审查模式
- LSP 多 session 共享 server（resource sharing）

## 10. 总结

v6 不是革命，是**收尾**——v0–v5 已经把 seek 从"DeepSeek 客户端"演化成"全功能编程 agent 编排平台"。v6 把 Claude Code 对比里剩下的 5 项 P1 单点工具补上，让 seek 在**日常使用面**上跟 Claude Code 全等价；剩下的差距收敛到"架构选择不同"（零 daemon 本地 vs 云托管）和"超出范围"（SDK / 多端 / 企业）。

v0.7.x ship 完后再看 P2 / P3。预期工作量 ~4 周，可由 1 人推进；并行可行性 + 独立可回滚性使得它适合作为 dogfood-driven 节奏的迭代周期。
