@aibyzero/byz 0.1.1 → 0.1.3

package/workflows/cm-plugin/skills/idea-to-prd/SKILL.md

@@ -0,0 +1,289 @@
+---
+name: idea-to-prd
+description: '把一个模糊的点子逐步展开成 PRD 产品文档。像产品经理一样先判定产品类型、用选项题快速定框架，再对模糊处一个个追问，先产出「半成品骨架」，然后按你的指示逐层加深到成熟乃至可直接落地/交给 AI 建站工具的规格。纯对话，不联网。Use when the user has only a rough idea and wants help turning it into a PRD. Triggers on: 把这个想法变成 prd, 帮我写个 prd, 我有个点子, expand this idea, turn my idea into a prd, spec out this idea, plan this feature.'
+user-invocable: true
+allowed-tools: Read, Write, Edit, Bash, AskUserQuestion, Glob
+---
+
+# 点子 → PRD 产品搭档
+
+你是用户的**产品搭档 + 产品经理**。用户往往只有一句话的点子，脑子里很多东西没想清楚。你的工作**不是**急着排版生成文档，而是：**判定产品类型 → 把点子追问清楚 → 补全用户没想到的 → 先给半成品骨架 → 按用户节奏逐层加深**。
+
+## 核心原则
+
+1. **绝不一次性甩出完整文档就完事。** 先出「半成品骨架」（L1），让用户看到雏形、纠偏，再往深处扩写。文档是活的，是聊出来的。
+2. **一次只问一个问题。** 默认逐个提问，不要一口气抛一堆题让用户批量回答——那样压力大、体验差。问完一个、收到答案，再问下一个。（用户如果主动说「一起问吧」，才可以合并。）
+3. **每个问题自带推荐，没把握就开放式。** 每个问题尽量给缩进的字母选项，并把你推荐的那个标 `(推荐)`，让用户回一个字母即可。若你对该点子的领域没把握、编不出靠谱选项，就**改成开放式提问**，绝不用臆造的 A/B/C 诱导用户走偏。
+4. **能推断的就别问，先问最决定方向的那题。** 用户已经说清楚、或明显能推断的（比如"交易平台"显然是软件），直接采用合理默认、一句话带过，别浪费一次提问。把提问预算花在真正的**分叉**上，并**从最能决定整个产品方向的那个问题开始**。
+5. **狠收敛，别挤牙膏。** 通常 **3-5 个问题**就足够撑起 L1 骨架。框架一清晰就停，剩余空白一律用合理默认补上并标 `⚠️ 待补`。合规、安全这类深水区**不在提问阶段追问**，留到骨架里标记。
+6. **加深时先挖"承重项"。** 当用户问"下一步怎么走"或要升档时，优先深挖那些**能推翻或重塑整个产品的关键未知**（如商业/合规模式、核心技术可行性、资金/安全），而不是先给一堆功能补验收标准——细节随时能补，地基错了全白搭。
+7. **纯对话，不联网。** 完全从用户的想法出发展开，不做网络搜索或网站审计。
+8. **有领域包就先读领域包。** 收到点子后，检查 `references/domains/` 下是否有匹配该领域的文件（如交易/Web3 → `trading.md`）。有则**先读它**，把其中的「必问分叉」并入访谈、「必备章节」并入 PRD 模板——领域包里的分叉是"不问就会翻车"的题，不许跳过。没有匹配的领域包就走纯通用流程。
+
+## 提问方式
+
+- **一次一个**。用**纯文本 + 缩进字母选项**，让用户回一个字母（如 `A`）就能答。推荐项标 `(推荐)`。这种方式实测最稳、最省事。
+- `AskUserQuestion` 工具**可选不强制**——单个简单问题用纯文本反而更稳、更快；只有当选项较多、值得弹窗结构化时才考虑用工具。
+- 顺着上一题的答案问下一题，让访谈像真人对话一样自然推进。
+
+---
+
+## 产品类型（决定 L2/L3 用哪套模板）
+
+**先判定产品类型**（决定后续 L2/L3 用哪套模板）。**能从点子明显推断的（如"交易平台"→A 软件），就直接采用、别单独问一题**；只有真看不出时才问一句。别硬把非软件点子套上 API/组件这类章节：
+
+| 类型 | 例子 | L3「落地 spec」长什么样 |
+|---|---|---|
+| **A. 软件 / Web / App** | SaaS、小程序、网站 | 组件清单 · 数据模型 · API · 技术栈 · 文件结构树 |
+| **B. CLI / 开发者工具 / 库** | 命令行、SDK、插件 | 命令与参数 · 输入输出契约 · 配置项 · 集成点 |
+| **C. 硬件 / IoT** | 智能设备 | 物料/传感器清单 · 固件行为 · 云端交互 · 认证合规 |
+| **D. 线下服务 / 运营** | 门店、上门服务 | 服务蓝图 · 角色 SOP · 触点清单 · 资源与排期 |
+| **E. 内容 / 媒体业务** | 栏目、社区、课程 | 内容矩阵 · 生产/审核流程 · 分发渠道 · 变现路径 |
+
+L1 骨架**所有类型通用**；差异只从 L2/L3 开始体现。
+
+---
+
+## 成熟度三档（控制「半成品→成熟」的旋钮）
+
+| 档位 | 内容深度 | 适合 |
+|---|---|---|
+| **L1 半成品骨架**（默认） | 问题陈述 / 核心方案 / 目标用户 / 3-5 个用户故事（标题级）/ 成功指标 / 范围边界。约 1 页。**所有类型通用。** | 还在打磨想法阶段，要个雏形来纠偏 |
+| **L2 成熟 PRD** | L1 + 详细用户故事与验收标准 / 编号功能需求 / 非目标 / 边缘与异常状态 / 风险与依赖 / 开放问题 / 里程碑 | 想法基本清晰，要正式立项、对齐团队 |
+| **L3 可落地 spec** | L2 + **按产品类型取用**上表对应的落地章节 | 写完直接开工 / 喂 AI 建站工具（仅类型 A） |
+
+**默认从 L1 出发。** 用户看过骨架后可说「整体升到 L2」，也可说「把第 3 个用户故事、数据模型深挖一下」——只加深被点到的部分。
+
+---
+
+## 工作流
+
+### PHASE 0 —— 接住点子并复述
+
+用户给出点子后，先用**一句话复述**你的理解，确认没跑偏，并顺手推断产品类型（明显就别问）。例如：
+
+> 「我理解你想做的是：**一个让自由摄影师在线出租器材、按天计费的双边市场**（软件平台）。对吗？我一个一个问，先把框架定下来。」
+
+如果用户的点子已经很详细，可跳过大部分提问，直接进 PHASE 2 出骨架。
+
+### PHASE 1 —— 访谈（一次一个问题，问到框架清晰为止）
+
+**一次只问一个问题**，纯文本 + 缩进字母选项、推荐项标 `(推荐)`、没把握改开放式。收到答案再问下一个，顺着答案走。
+
+**从最决定方向的分叉问起**，通常按这个优先级，直到框架够撑起骨架（一般 3-5 个就够）：
+
+1. **核心定位 / 分水岭** —— 这个产品最核心是做什么？（同一句话点子往往有截然不同的解读，先劈开）
+2. **目标用户** —— 主要给谁用？（决定形态与复杂度）
+3. **关键约束** —— 领域相关的最大变量（如市场/平台/合规范围）
+4. **成熟度目标** —— L1 / L2 / L3？默认 L1，通常不必问。
+5. **范围** —— 完整产品还是先聚焦 MVP？默认先 MVP，通常不必问。
+
+**能推断或已知的维度直接默认掉，别占用提问。** 明显能看出的（产品类型、"当然先 MVP"）一句话带过即可。
+
+**收敛：框架一清晰就停**，不要把每个未知都问干净。合规、安全、技术选型这类深水区**不在这里追问**——留到骨架里标 `⚠️ 待补`。
+
+主流程这类开放问题若不适合做选项，用文本问，并**先给一版你猜的流程**让用户改：
+
+> 「帮我走一遍最重要的主流程——用户从打开到达成目标，一步步做什么？
+> （我先猜一版：①… →②… →③…。你改哪步？）」
+
+### PHASE 2 —— 产出半成品骨架（L1）
+
+框架够了就**主动停止提问**，用下面的 L1 模板生成 PRD，**显式标注没想清楚的地方**（`⚠️ 待补：…`），尤其把合规/安全/技术可行性等承重未知列进「待明确的问题」。生成后主动问：
+
+> 「这是半成品骨架。你想 **① 整体升到 L2 成熟版**，**② 指定某几块深挖**，还是 **③ 先纠正骨架里跟你想的不一样的地方**？」
+
+### PHASE 3 —— 逐层加深
+
+**先挖承重项**：用户问"下一步"或没指定时，主动建议先深挖那些能推翻/重塑产品的关键未知（商业/合规模式、核心技术可行性、资金/安全），而不是先给功能铺验收标准。
+
+按用户指令扩写，**按产品类型取用对应章节**：
+- 「升到 L2」→ 补齐 L2 增量章节。
+- 「升到 L3」→ 再补齐 L3 增量：**类型 A** 用组件/数据模型/API/技术栈/文件树；**类型 B/C/D/E** 用「产品类型」表里对应的落地章节。
+- 点名某几块 → 只深挖那几块，其余不动。
+
+加深时又冒出模糊点，仍然**一次一个问题**地问（文本 + 推荐），且同样狠收敛，别把用户拖进无止境追问。
+
+### PHASE 4 —— 保存
+
+产出稳定后：
+1. 询问文件名，默认 `prd-[点子的-kebab-名].md`。
+2. **确定保存目录**：先探测是否在 git 仓库内——
+   ```bash
+   git rev-parse --show-toplevel 2>/dev/null
+   ```
+   - 有输出 → 存到 `<仓库根>/prd/`
+   - 无输出 → 存到当前目录 `./prd/`
+   - 目录不存在则 `mkdir -p` 创建。
+3. **保存前把完整路径告诉用户确认**，再写入。
+4. 告知最终保存路径。
+
+---
+
+## 骨架模板（L1，所有类型通用）
+
+```markdown
+# [产品名] —— 产品需求文档（PRD）
+
+> 成熟度：L1 半成品骨架 ｜ 类型：[A 软件 / B 工具 / C 硬件 / D 服务 / E 内容]
+> 一句话：[这个产品是什么、给谁、解决什么]
+
+## 1. 问题陈述
+[谁，在什么场景，遇到什么痛点，现在怎么将就的、有多痛。2-4 句。]
+
+## 2. 目标用户
+| 角色 | 描述 | 主要诉求 |
+|---|---|---|
+| [主要用户] | [是谁] | [最想要什么] |
+
+## 3. 核心方案
+[高层次描述解决办法，不写实现细节。1-2 句。]
+
+## 4. 核心用户故事（3-5 个）
+- **US-1 [标题]**：作为 [角色]，我想要 [动作]，以便 [价值]。
+- **US-2 …**
+（⚠️ 待补：验收标准将在 L2 补齐）
+
+## 5. 成功指标
+- [可衡量的信号，如「30 天内完成首单的用户占比 ≥ 40%」]
+
+## 6. 范围
+**做**：[本次明确包含的]
+**不做**：[明确排除的，防止范围膨胀]
+
+## 7. 待明确的问题
+- ⚠️ [还没想清楚、需要用户或团队定的]
+```
+
+## L2 增量章节（升级到成熟 PRD 时追加，所有类型通用）
+
+```markdown
+> 成熟度：L2 成熟 PRD
+
+## 4'. 用户故事（含验收标准）
+### US-1 [标题]
+**描述**：作为 [角色]，我想要 [动作]，以便 [价值]。
+**验收标准**（可二元判定通过/失败）：
+- [ ] [具体、可测的标准，如「点击删除时弹出二次确认弹窗」]
+- [ ] [边缘情况：…]
+- [ ] [异常状态：…发生时…]
+
+## 8. 功能需求（编号）
+- FR-1：系统/服务必须允许用户……
+- FR-2：当用户执行 X，系统必须……
+
+## 9. 边缘与异常状态
+[空状态、失败/超时、权限不足、离线、并发等；服务类则含爽约、超时、投诉等]
+
+## 10. 风险与依赖
+| 风险/依赖 | 影响 | 缓解措施 |
+|---|---|---|
+
+## 11. 里程碑
+[MVP → 后续阶段，每阶段交付什么]
+```
+
+## L3 增量章节（按产品类型取用其一）
+
+### 类型 A —— 软件 / Web / App（可直接喂 AI 建站工具）
+
+```markdown
+> 成熟度：L3 可落地 spec（软件）
+
+## AI 建造摘要
+[给 AI 工具的机器可读指令，祈使句。说明造什么、用什么栈、最硬的约束。
+例：「用 Next.js 14 + Supabase 造一个器材租赁双边市场。MVP 不含实时聊天。必须支持押金预授权。」]
+
+## 12. 组件清单
+| 组件 | 类型 | 作用 | 关联故事 |
+|---|---|---|---|
+| [名称] | 表单/布局/操作/展示/导航/弹窗 | [做什么] | US-1 |
+
+## 13. 数据模型
+（TypeScript interface 或纯语言描述每个实体）
+```typescript
+interface [模型名] { id: string; createdAt: string; /* ... */ }
+```
+
+## 14. API / 集成面
+| 方法 | 路径 | 说明 | 需鉴权 | 返回 |
+|---|---|---|---|---|
+| GET | /api/[资源] | 列出…… | 是 | `{ data: Model[], total: number }` |
+
+## 15. 技术栈建议
+| 层 | 选型 | 理由 |
+|---|---|---|
+
+## 16. 文件结构（仅新增/改动）
+```
+[root]/ ├── app/[feature]/ └── lib/
+```
+```
+
+### 类型 B —— CLI / 工具 / 库
+
+```markdown
+> 成熟度：L3 可落地 spec（工具）
+
+## 12. 命令与参数
+| 命令 | 参数/选项 | 作用 |
+|---|---|---|
+
+## 13. 输入输出契约
+[stdin/文件/参数 → stdout/退出码/产物；错误码约定]
+
+## 14. 配置项
+[配置文件字段、环境变量、默认值]
+
+## 15. 集成点
+[如何被其他工具/CI/编辑器调用]
+```
+
+### 类型 C —— 硬件 / IoT
+
+```markdown
+> 成熟度：L3 可落地 spec（硬件）
+
+## 12. 物料 / 传感器清单
+## 13. 固件行为（状态机、上电/异常处理）
+## 14. 云端交互（上报/下发协议、离线缓存）
+## 15. 认证与合规（安规、无线认证、数据合规）
+```
+
+### 类型 D —— 线下服务 / 运营
+
+```markdown
+> 成熟度：L3 可落地 spec（服务）
+
+## 12. 服务蓝图（前台动作 / 后台支撑 / 关键触点，按时间轴）
+## 13. 角色 SOP（每个岗位在每一步做什么）
+## 14. 触点与物料清单
+## 15. 资源与排期（人力、场地、设备、班次）
+```
+
+### 类型 E —— 内容 / 媒体业务
+
+```markdown
+> 成熟度：L3 可落地 spec（内容）
+
+## 12. 内容矩阵（栏目/形式/更新频率/目标受众）
+## 13. 生产与审核流程（选题→生产→审核→发布）
+## 14. 分发渠道与排期
+## 15. 变现路径与指标
+```
+
+---
+
+## 写作规则
+
+- **从「为什么」和「是什么」出发，把「怎么实现」留给执行**（L3 的落地章节除外）。
+- 用具体数字替代模糊词：不说「快」，说「2 秒内加载」。
+- 验收标准必须可判定：「工作正常」不合格，「未登录时返回 401」才合格。
+- 每个用户故事小到能在一次专注开发内做完，故事之间尽量独立。
+- 语言简单直白，面向可能是初级开发者或 AI 的读者：编号、要点、少行话。
+
+## 参考
+
+- `references/example-prd.md` —— 一份从一句话点子("做个摄影器材租赁 App")展开出的 **L2 成熟 PRD** 完整样例。输出前对照它校准颗粒度与风格。
+- `references/domains/` —— **领域包**目录。点子命中某领域时必读对应文件,把其中的必问分叉与必备章节并入流程:
+  - `trading.md` —— 交易 / Web3 / 量化金融(托管分叉、风控框架、Key 安全三道闸、验证防自欺、合规免责)

package/workflows/cm-plugin/skills/idea-to-prd/references/domains/trading.md

@@ -0,0 +1,97 @@
+# 领域包：交易 / Web3 / 量化金融
+
+> 当点子涉及**交易、套利、量化策略、DeFi、交易机器人、资管跟单**等，加载本包。
+> 本包把访谈中"不问就会翻车"的分叉变成必问清单，把风控智慧变成 PRD 必备章节。
+> 借鉴来源：agiprolabs/claude-trading-skills（风控框架）、binance/binance-skills-hub
+> （Key 安全实践）、redlabs-sc/ai-trading-claude-skills（熔断与防幻觉）及实战访谈沉淀。
+
+---
+
+## 一、必问分叉（访谈阶段，仍然一次一个；已能推断的跳过）
+
+按优先级问，前 3 个几乎不可跳过：
+
+### 1. 托管分叉（最承重，第一个问）
+> 「用户的钱/仓位怎么接进来？」
+- **A. 非托管**——各绑各的交易所 API Key / 各连各的钱包，钱不过平台手 (通常推荐——法律与信任风险低一个量级)
+- **B. 托管**——用户把钱交给平台统一操盘（⚠️ 本质是资管/代客理财，多数司法辖区需要牌照，必须提示）
+- **C. 混合**——平台只出信号/大脑，执行在用户侧
+
+### 2. 策略类型分叉（决定风险模型）
+> 「具体是什么玩法？」给出风险对比，别让用户凭感觉选：
+- **趋势/波段**（赌方向）—— 市场风险高
+- **网格/区间**——赚震荡赔单边，跌出区间即套牢
+- **套利类**：三角（技术门槛极高，散户难抢过做市商）/ 跨所搬砖（转账路上风险）/
+  **期现·资金费率**（对冲不赌方向，市场风险最低，收益像利息，但要防合约腿爆仓）
+- **跟单/信号**——风险转移给"被跟的人"的水平
+
+### 3. 市场与场所分叉
+- 加密（CEX：API 开放、7×24，最易起步 / DEX·链上：加 MEV、滑点、Gas 变量）
+- 股票/期货/外汇（券商通道 + 牌照，监管重一档）
+- 单一交易所 or 跨所？（跨所 = 复杂度与风险各升一档）
+
+### 4. 用户与形态分叉
+- 自用脚本 / 小圈子工具 / 对外产品——三档的安全、合规、账户体系要求完全不同
+- 若"给别人用"：**必须**回到分叉 1 确认托管模式，并问「收不收费？怎么收？」
+  （抽成/订阅可能触发投顾/资管定性）
+
+### 5. L3 才问的
+- 语言/框架偏好（Python 事实标准）、回测数据来源、部署形态（云/本地/每人一实例）
+
+---
+
+## 二、PRD 必备章节（交易类点子的 L1/L2 硬性增补）
+
+普通产品可选，交易产品**缺了就是不合格 PRD**：
+
+### L1 骨架必须包含
+- 「待明确的问题」里**强制列出**：Key/资金安全、极端行情处置、合规边界、
+  盈利模式的法律定性——即使用户没提。
+
+### L2 必须增加「风控框架」章节（借鉴执行层最佳实践，上提为需求）
+写 PRD 时按此清单核对，缺项要么补上、要么显式写"不适用+理由"：
+
+1. **仓位与敞口上限**：单笔风险上限（业内常规 ≤ 账户 2%）、单策略/单标的敞口上限、
+   现金保留比例（常规保留 20-50%）。
+2. **回撤熔断阶梯**（例，按风格调）：日亏 -3~5% 当日停机；周亏 -5% 减半仓、
+   -10% 全停；总回撤 -15~25% 停机复盘。连续 N 次亏损 → 降到最小仓位。
+3. **执行熔断**：两腿策略必须"任一腿失败立即撤销/对冲另一腿"；限价+最大滑点，
+   禁裸市价；API 断连的降级行为（持仓怎么办）必须定义。
+4. **相关性警示**：加密资产在暴跌时相关性 >0.7，"分散持仓"在崩盘日会同涨同跌，
+   PRD 的风险章节应据此设总敞口而非单币敞口。
+5. **一键熔断**：管理员能暂停全部自动交易，这是需求不是加分项。
+
+### L2 必须增加「Key/资金安全」章节（非托管产品的命门）
+三道闸模型：
+- **绑定闸**：强制校验权限（只留交易、**禁提现**）+ 引导交易所侧 IP 白名单；
+- **存储闸**：加密落库（AES-256-GCM 级），主密钥与数据异机（KMS），永不回显、日志脱敏；
+- **运行闸**：单账户调用频率与下单额度上限，防 bug 疯狂下单。
+- **架构升级项**：中心化保管所有用户 Key = 蜜罐。可评估"读写分离"
+  （中心只持只读 Key 做看板，交易 Key 留在用户侧实例）或"每人一实例"。
+
+### L2 必须增加「验证与防自欺」章节
+- 上线前**强制回测 + 前向/模拟盘验证**，并写明"什么指标达标才允许接真钱"；
+- 警惕过拟合：回测要含手续费、滑点、资金费，用走样验证（walk-forward）；
+- 收益展示用**净值口径**（扣费后），禁用"理论年化"误导。
+
+### 成功指标的特殊要求
+- 必须含**风险指标**（最大回撤、爆仓次数=0），不能只写收益；
+- 必须有**基准对照**："净年化跑不赢无风险基准（如交易所理财/国债），产品不成立"
+  ——这是产品存在性检验，写进指标。
+
+### 合规与免责（所有交易类 PRD 收尾必查)
+- 即使非托管，"向他人提供自动交易工具/信号"在部分辖区有监管定性——PRD 必须
+  标注"需当地法律确认"，不许含糊带过；
+- 面向用户的文案需要免责声明：不构成投资建议、过往业绩不代表未来、用户自担风险。
+
+---
+
+## 三、领域常识速查（访谈与写作时直接引用，别现编）
+
+- 币安资金费率每 **8 小时**结算一次；期现套利 = 现货多 + 永续空，赚正费率;
+  费率会转负，处置策略（容忍期/成本对比/硬止损）必须在 PRD 定义。
+- 期现套利年化常见个位数~15%，是"利息型"收益，谁宣称远超此数需警惕。
+- 三角套利机会转瞬即逝且被做市商垄断，散户自建基本无利可图——用户选它时要泼冷水。
+- DEX/链上交易要额外考虑：MEV（三明治攻击）、滑点、Gas 成本、合约风险。
+- 多标的轮动（持有当期预测资金费最高的标的，价差覆盖换仓成本才轮动）通常优于
+  单标的死守，属于低成本的策略增强。

package/workflows/cm-plugin/skills/idea-to-prd/references/example-prd.md

@@ -0,0 +1,92 @@
+# 器材租 —— 产品需求文档（PRD）
+
+> 成熟度：L2 成熟 PRD ｜ 类型：A 软件 / Web / App
+> 一句话：一个让自由摄影师把闲置器材按天租给同行的双边市场，解决"租不到 / 租不出"的问题。
+
+*这是一份填好的示例，供 `idea-to-prd` 技能参考输出风格与颗粒度。原始点子只有一句："做个摄影器材租赁的 App。"*
+
+---
+
+## 1. 问题陈述
+自由摄影师常为一次性拍摄需要昂贵器材（如特定镜头、灯光），买不划算、临时租又找不到靠谱渠道；同时大量摄影师的器材一年闲置大半，没有安全的变现方式。现在他们只能在微信群里私下问，缺乏信用、押金和保险保障，交易风险高。
+
+## 2. 目标用户
+| 角色 | 描述 | 主要诉求 |
+|---|---|---|
+| 租客（摄影师） | 临时需要特定器材的拍摄者 | 快速找到、价格透明、有保障 |
+| 出租方（摄影师） | 有闲置器材想变现的同行 | 收益、押金/保险兜底、少纠纷 |
+
+## 3. 核心方案
+一个按天计费的器材租赁双边市场：出租方发布器材与档期，租客搜索下单、平台托管押金与租金，双方线下或邮寄交割，归还确认后放款。
+
+## 4. 用户故事（含验收标准）
+
+### US-1 发布器材
+**描述**：作为出租方，我想要发布一件器材并设置日租价和可租档期，以便让别人租走。
+**验收标准**：
+- [ ] 可填写：器材型号、成色、日租价、押金额、可租日期区间、取货方式
+- [ ] 至少上传 1 张图，否则不能发布
+- [ ] 发布后出现在搜索结果中
+- [ ] 边缘情况：档期与已有订单冲突时，冲突日期自动置灰不可选
+
+### US-2 搜索并查看器材
+**描述**：作为租客，我想按器材类型和日期搜索，以便找到当下能租的器材。
+**验收标准**：
+- [ ] 支持按类别（镜头/机身/灯光…）+ 日期区间筛选
+- [ ] 只显示所选日期全程可租的器材
+- [ ] 空状态：无结果时提示"换个日期或类别"并给推荐
+- [ ] 详情页展示图、价、押金、成色、出租方信用分
+
+### US-3 下单与托管付款
+**描述**：作为租客，我想选定租期并付款，以便锁定器材。
+**验收标准**：
+- [ ] 选租期后自动算总额（日租×天数 + 押金）
+- [ ] 押金走预授权（冻结非扣款）
+- [ ] 付款成功后该档期对他人锁定
+- [ ] 异常状态：支付超时（15 分钟）自动释放档期
+- [ ] 未登录时跳转登录并保留下单意图
+
+### US-4 归还确认与放款
+**描述**：作为出租方，我想在收到归还后确认，以便解冻押金并收到租金。
+**验收标准**：
+- [ ] 双方任一方可发起"已归还"，另一方确认
+- [ ] 确认后押金预授权解除，租金入出租方账户
+- [ ] 争议情况：任一方可在确认前发起"报损"，进入人工介入，暂不放款
+
+## 5. 成功指标
+- 上线 3 个月内，月活出租方 ≥ 200、月成单 ≥ 500
+- 下单到支付完成的转化率 ≥ 60%
+- 交易纠纷率 ≤ 3%
+
+## 6. 范围
+**做**：发布、搜索、下单、押金托管、归还确认、信用分、争议人工介入。
+**不做**（MVP）：实时聊天、平台自营保险、跨城物流、企业批量租赁。
+
+## 8. 功能需求（编号）
+- FR-1：出租方必须能创建含图片、价格、押金、档期的器材条目。
+- FR-2：系统必须按日期可用性过滤搜索结果。
+- FR-3：下单时系统必须对押金做预授权而非直接扣款。
+- FR-4：支付超时 15 分钟系统必须自动释放被锁档期。
+- FR-5：归还需双方确认；任一方报损则进入人工介入且暂缓放款。
+
+## 9. 边缘与异常状态
+- 支付超时 / 失败；押金预授权额度不足。
+- 档期并发下单（两人同时下同一档期）——先支付成功者得。
+- 器材报损、逾期未还、地址填错导致邮寄失败。
+
+## 10. 风险与依赖
+| 风险/依赖 | 影响 | 缓解措施 |
+|---|---|---|
+| 押金托管依赖第三方支付预授权能力 | 无预授权则押金体验差 | 优先接入支持预授权的支付渠道 |
+| 冷启动一侧供给不足 | 搜不到器材，租客流失 | 首城地推出租方，前期补贴发布 |
+| 器材损坏纠纷 | 口碑与复购受损 | 报损人工介入 + 信用分惩罚机制 |
+
+## 11. 里程碑
+- **M1（MVP）**：发布 + 搜索 + 下单 + 押金托管 + 归还确认。单城试点。
+- **M2**：信用分、争议工作台、评价体系。
+- **M3**：邮寄物流、保险、多城扩张。
+
+## 7. 待明确的问题
+- ⚠️ 押金预授权用哪家支付？额度上限多少？
+- ⚠️ 信用分初始值与升降规则如何设计？
+- ⚠️ 报损时估损与赔付标准由谁定、依据什么？

package/workflows/cm-plugin/templates/arch-reference.md

@@ -0,0 +1,55 @@
+# 扩展架构基准参考表（快照日期: 2026-07 · G1 使用时必须联网校验刷新）
+
+> 本表是**离线兜底基准**,不是权威答案。G1 推荐架构前应 WebSearch 扩展脚手架生态的当年状态;
+> 网络不可用时才直接使用本表,且必须向用户标注"基于 2026-07 快照,建议联网复核"。
+
+## 扩展脚手架
+
+| 场景 | 推荐 | 脚手架命令 | 依据 |
+| ---- | ---- | ---- | ---- |
+| 大多数新项目 | **WXT** | `npx wxt@latest init` | 约定式 entrypoints、HMR 完善、跨浏览器构建（Chrome/Firefox 双产物）与 `wxt zip`/自动发布链路齐全,社区活跃度 2026 领先 |
+| React 重 UI、偏好文件约定 | Plasmo | `npm create plasmo` | 文件名即入口,上手快;注意 2024 后维护节奏放缓,选用前联网核实状态 |
+| 想完全掌控 Vite 配置 | CRXJS + Vite | `npm create vite@latest` + `@crxjs/vite-plugin` | 手写 manifest,最透明;配置成本自担 |
+| 无构建极简插件(几个文件) | 原生无框架 | 手写 manifest.json | 零依赖;超过 3 个源文件就不值得 |
+
+UI 层惯配: React/Vue 任选 + Tailwind CSS;与团队既有栈一致优先。
+
+## 表面选择
+
+| 需求 | 表面 | 备注 |
+| ---- | ---- | ---- |
+| 点击即用的轻交互 | popup | 失焦即销毁,不放长任务 |
+| 常驻工具面板 | side panel | Chrome 114+;Firefox 用 sidebar_action,跨浏览器需适配 |
+| 改写/增强特定网站 | content script | isolated world + shadow DOM 隔离 |
+| 全局设置页 | options page | |
+| 调试/开发者工具类 | devtools panel | |
+| 替换新标签页 | chrome_url_overrides | 商店审核对此类更严格 |
+
+## 配套后端（仅在需要账号/同步/密钥代理时引入）
+
+| 场景 | 推荐 | 依据 |
+| ---- | ---- | ---- |
+| TS 团队/轻量代理层 | **Hono / Fastify**（可部署 Cloudflare Workers） | 扩展后端多为薄代理,edge 部署延迟低免运维 |
+| 快速起量/免运维 | Supabase / Firebase(BaaS) | 自带鉴权,注意锁定成本 |
+| 无账号无密钥需求 | **不建后端** | chrome.storage 足够;别为架构完整性凑后端 |
+
+扩展侧鉴权注意：无传统 cookie 会话,用 token（chrome.storage 存储 + 后端校验）;CORS 允许来源写 `chrome-extension://{id}`。
+
+## 跨浏览器
+
+| 目标 | 方案 |
+| ---- | ---- |
+| 仅 Chrome/Edge | 直接用 `chrome.*`(MV3) |
+| 含 Firefox | webextension-polyfill + 构建期双 manifest（WXT 原生支持）;side panel/declarativeNetRequest 等差异 API 逐项确认 |
+| 含 Safari | `safari-web-extension-converter` 转换 + Xcode 打包,成本显著,默认不承诺 |
+
+## 测试与发布工具链（推荐时一并写入 ADR）
+
+- E2E = Playwright `launchPersistentContext` + `--load-extension`（扩展不能用默认无头远程浏览器）
+- UI 验收 = BackstopJS（popup/options/side panel 均为浏览器可渲染表面）
+- 发布 = 脚手架打包命令出 zip + Chrome Web Store 提审;CI 自动上传可用 `chrome-webstore-upload-cli`（联网核实维护状态）
+
+## 维护规则
+
+- 本表由 G1 联网校验结果**顺手更新**（发现快照过时 → 更新表格与快照日期,是 doc-syncer 职责的延伸）
+- 表中"推荐"永远让位于 G1 的两条一票否决：团队约束、发布条件

package/workflows/cm-plugin/templates/auto-update/cm-announce.sh

@@ -0,0 +1,19 @@
+#!/usr/bin/env bash
+# SessionStart hook：把 cm-update.sh 留下的更新播报，在 Claude Code 启动时报给用户。
+# 报完即删——只报一次。没有待播报内容时输出空，不打扰。
+set -uo pipefail
+
+ANNOUNCE="$HOME/.cm-plugin-workflow/pending-announce"
+[ -s "$ANNOUNCE" ] || exit 0
+
+msg="$(cat "$ANNOUNCE")"
+rm -f "$ANNOUNCE"
+
+# 用 jq 转义，消息里的引号/换行/中文都不会破坏 JSON
+if command -v jq >/dev/null 2>&1; then
+  jq -n --arg m "$msg" '{systemMessage: $m}'
+else
+  # jq 缺席时的兜底：手工转义最低限度的字符
+  esc="$(printf '%s' "$msg" | sed 's/\\/\\\\/g; s/"/\\"/g' | awk '{printf "%s\\n", $0}')"
+  printf '{"systemMessage": "%s"}\n' "$esc"
+fi