autocrew 0.1.0 → 0.2.0

package/skills/teardown/SKILL.md

@@ -1,24 +1,41 @@
 ---
 name: teardown
 description: |
-  拆解对标内容 — 用户粘贴一段文案，输出结构化拆解报告。分析钩子、HKRR、时钟节奏、评论触发、微操技巧。结果存入 intel 系统供创作参考。
-trigger: 当用户说"拆解"、"teardown"、"分析这条"、"对标分析"时触发
+  拆解对标内容 — 支持文本和视频两种模式。文本：用户粘贴文案，输出结构化拆解。
+  视频：用户发视频链接或文件，通过 Omni 全模态分析输出四学科视角深度拆解。
+  结果存入 intel 系统供创作参考。
+trigger: 当用户说"拆解"、"teardown"、"分析这条"、"对标分析"、"拆解这个视频"时触发
 ---
 
 # Competitive Teardown（对标拆解）
 
-> 免费版：分析用户粘贴的文案。Pro 版（待实现）：通过 Chrome Relay 抓取视频/账号数据。
+> 支持文本和视频两种模态。文本拆解分析文案技巧；视频拆解通过 MiMo-V2-Omni 全模态
+> 分析画面+文案+节奏+结构，输出传播学/心理学/内容结构/视听语言四个学科维度的深度报告。
 
 ## 触发方式
 
-用户说 "拆解这条内容" / "teardown" / "帮我分析对标" 并粘贴一段文案。
+- 用户说 "拆解这条" / "teardown" / "帮我分析对标" 并粘贴文案 → **文本模式**
+- 用户发视频链接（douyin/xiaohongshu/bilibili/youtube/weixin 等）→ **视频模式**
+- 用户发本地视频文件路径（.mp4/.mov/.avi）→ **视频模式**
 
 ## 前置加载
 
 - `HAMLETDEER.md` — HKRR 框架、Clock Theory、Micro-Retention Techniques、Bang Moment Types
-- `~/.autocrew/creator-profile.json` — 用于对比自己的定位
+- `~/.autocrew/creator-profile.json` — 用于对比自己的定位 + 读取 videoCrawler/omniConfig 配置
 
-## 拆解流程
+## Step 0: 输入类型检测
+
+判断用户输入属于哪种模式：
+
+| 输入特征 | 判定 | 路径 |
+|----------|------|------|
+| 纯文本，没有 URL 也没有文件路径 | 文本模式 | → Step 1（文本拆解，下方） |
+| URL 包含 douyin/xiaohongshu/bilibili/youtube/weixin 域名 | 视频模式 | → Step V1（视频拆解） |
+| 路径以 .mp4 / .mov / .avi / .mkv / .webm 结尾 | 视频模式 | → Step V1（视频拆解） |
+
+---
+
+# 文本拆解（原有流程，不变）
 
 ### Step 1: 基本信息提取
 
@@ -77,68 +94,261 @@ trigger: 当用户说"拆解"、"teardown"、"分析这条"、"对标分析"时
 
 列出 2-3 个可以应用到自己内容的具体技巧。
 
-## 保存拆解结果
+---
+
+# 视频拆解（Omni 全模态分析）
+
+### Step V1: 视频获取
+
+**如果输入是本地文件路径：** 直接使用，跳到 Step V3。
+
+**如果输入是视频链接：** 读取 `creator-profile.json` → `videoCrawler` 配置：
+
+```
+if videoCrawler.type == "mediacrawl":
+   → 用 Bash 执行: {videoCrawler.command} --url {链接}
+   → 等待下载完成，获取本地文件路径
+
+elif videoCrawler.type == "playwright":
+   → 用 Playwright 浏览器打开链接
+   → 通过浏览器下载视频到临时目录
+   → 获取本地文件路径
+
+elif videoCrawler.type == "manual" (或未配置):
+   → 提示用户:
+     "视频拆解需要先获取视频文件。请：
+      1. 手动下载视频到本地
+      2. 告诉我文件路径（例如 ~/Downloads/video.mp4）"
+   → 等待用户提供路径
+```
+
+如果 `videoCrawler` 未配置，默认走 manual 模式。
+
+### Step V2: 视频元信息提取（可选）
+
+如果视频来自链接，尝试提取：
+- 视频标题
+- 发布账号
+- 点赞/评论/收藏数
+- 发布时间
+
+获取不到不阻塞，标记为"未获取"继续。
+
+### Step V3: Omni API 视频分析
+
+**前置检查：** 读取 `creator-profile.json` → `omniConfig`。如果未配置：
+> "视频拆解需要配置 Omni API。请在 creator-profile.json 中添加 omniConfig：
+> ```json
+> "omniConfig": {
+>   "baseUrl": "https://api.xiaomimimo.com/v1",
+>   "model": "mimo-v2-omni",
+>   "apiKey": "your-api-key"
+> }
+> ```
+> 获取 API Key：https://platform.xiaomimimo.com"
+
+**限制检查：**
+- 视频时长 ≤ 30 分钟。超过提示用户裁剪关键片段。
+- 文件大小 ≤ 200MB。超过提示压缩或裁剪。
+
+**调用方式（OpenAI 兼容）：**
+
+使用 Bash 或 SDK 调用 Omni API。视频文件 → base64 编码 → 通过 `image_url` content type
+以 `data:video/mp4;base64,{encoded}` 格式发送。
+
+Prompt 使用下方**视频拆解模板 v2**的完整内容。
+
+### Step V4: 视频拆解模板 v2（Omni Prompt）
+
+⚠️ 以下是发送给 Omni 模型的完整 prompt。**不可删减任何维度，每个子维度必须有具体分析。**
+
+```
+请对这段视频进行深度拆解分析。你是一位精通传播学、心理学、内容创作和视听语言的分析师。
+按以下四个学科视角逐一分析，每个子维度都必须给出具体分析，不可跳过或泛泛而谈。
+
+---
+
+## 1. 传播学视角 — 这条内容为什么会被传播？
+
+### 信息不对称设计
+- 创作者掌握了什么观众不知道的信息？这个信息差是如何被制造和维持的？
+- 信息揭示的节奏：一次性全揭示 vs 逐层剥开？哪种策略更有效？
+
+### 社会货币
+- 观众转发这条视频时，他在向朋友表达什么身份信号？
+  ("我很懂" / "我有品味" / "我关心你" / "看这个离谱的事")
+- Berger 的 STEPPS 模型命中了哪些？逐一判断：
+  Social Currency / Triggers / Emotion / Public / Practical Value / Stories
+
+### 框架效应
+- 这个创作者选择了什么叙事框架来组织信息？
+- 如果换一个框架（比如从"机会"换成"危机"，或反过来），效果会怎样？
+- 框架选择背后的受众洞察是什么？
+
+---
+
+## 2. 心理学视角 — 观众的大脑在经历什么？
+
+### 认知负荷管理
+- 复杂概念是如何被拆分成可消化的信息单元的？每个单元有多"重"？
+- 有没有刻意设计的"认知休息区"（笑点、停顿、重复、举例）？在什么位置？
+
+### 情绪弧线
+- 画出这条视频的情绪曲线：开场情绪状态→中间的起伏节点→结尾情绪状态
+- Peak-End Rule：观众会记住哪个高峰时刻？结尾留下了什么情绪？
+- 情绪转折点在视频的什么时间位置？
+
+### 身份投射
+- 观众看完这条视频后，会觉得自己是什么样的人？
+  ("我是聪明人" / "我是行动派" / "我不孤单" / "我能做到")
+- 这条视频满足了马斯洛需求层次的哪一层？（归属感/尊重/自我实现）
+
+### 开放循环与蔡格尼克效应
+- 视频中有多少个未关闭的信息缺口？分别在什么时间点打开、什么时间点关闭？
+- 观众是在"满足中离开"还是在"好奇中留下"？
+- 哪个开放循环设计得最巧妙？
+
+---
+
+## 3. 内容结构视角 — 论证架构是否有效？
+
+### 论证结构
+- 这条视频的核心论证链是什么？按这个格式分析：
+  观点 → 证据类型(数据/案例/权威背书/类比) → 反驳预处理 → 行动号召
+- 论证链中最薄弱的环节在哪里？观众可能在哪个环节开始质疑？
+
+### 承诺-兑现分析
+- 前 3 秒（显性或隐性地）承诺了什么？
+- 这个承诺最终兑现了吗？是超额兑现、刚好兑现、还是打折兑现？
+- 如果打折兑现：观众是否会感到被标题党了？
+
+### 信息密度曲线
+- 哪些时间段信息密度高（新概念/新数据密集出现）？
+- 哪些时间段是"呼吸空间"（重复、举例、情绪渲染、视觉留白）？
+- 高密度和低密度的交替节奏是否合理？有没有连续高密度导致"听不进去"的段落？
+
+### 观点光谱定位
+- 这个观点在行业共识光谱上的位置：纯共识 ←────→ 极度反共识
+- 反共识的程度是否恰到好处？（太顺=没传播价值，太反=失去信任）
+- 创作者如何在"反共识"和"可信度"之间取得平衡？
+
+---
+
+## 4. 视听语言视角 — 形式如何服务内容？
+
+### 视觉叙事
+- 画面在传递什么文案/口播没有说的信息？（隐性信息层）
+- 在关键论证节点，为什么选择这个画面？是强化、反差、还是补充论证？
+- 有没有纯靠画面推进叙事（没有口播/文字）的段落？效果如何？
 
-将拆解报告保存到 intel 系统：
+### 节奏与注意力（Clock Theory）
+- 按时钟理论标注四个关键节点（12:00/3:00/6:00/9:00）各有什么 bang moment：
+  | 时钟位 | 时间点 | 内容 | Bang moment 类型 | 强度 |
+  |--------|--------|------|-----------------|------|
+  | 12:00 | | | | 强/弱/缺失 |
+  | 3:00 | | | | 强/弱/缺失 |
+  | 6:00 | | | | 强/弱/缺失 |
+  | 9:00 | | | | 强/弱/缺失 |
+- 剪辑切镜节奏是否和论证节奏同步？论点密集时切镜是否加快？
 
+### HKRR 诊断
+- 主导维度是哪个（H快乐 / K知识 / R共鸣 / R节奏）？纯粹度如何？
+- 是否存在维度冲突？（想教知识又想搞笑 = 哪个都不到位）
+- 短视频（<60s）是否只选了一个维度？长视频是否有效组合了多个维度？
+
+---
+
+## 5. 可借鉴清单（最重要的输出）
+
+### ✅ 方法论级借鉴（可迁移到任何主题的"公式"）
+- 列出 2-3 个这个创作者用的可复用方法
+
+### ⚠️ 风格级借鉴（好但需要适配自身风格）
+- 列出 1-2 个需要调整后才能用的点
+
+### ❌ 不适合借鉴
+- 列出 1 个这个账号做但不适合我们做的，说明为什么
+
+### 💡 创作启发
+- 看完这个视频后产生的新选题想法、新切入角度、或新的表达方式
 ```
-~/.autocrew/data/pipeline/intel/_teardowns/{slug}-{date}.md
+
+### Step V5: 格式化拆解报告
+
+将 Omni 返回的分析整理为结构化 markdown 报告。
+
+### Step V6: 保存拆解报告
+
+**写入 `_teardowns/` 目录：**
+
+```
+~/.autocrew/data/pipeline/intel/_teardowns/{date}-{slug}.md
 ```
 
 YAML frontmatter:
 ```yaml
 ---
-title: "拆解: {原内容标题或前20字}"
+title: "拆解: {视频标题或前20字}"
 type: teardown
-platform: "{预估平台}"
-hookType: "{钩子类型}"
-dominantHKRR: "{最强HKRR维度}"
-hookScore: 0
+mode: video
+platform: "{平台}"
+source_url: "{视频链接，如有}"
+source_account: "{账号名，如有}"
+video_duration: "{时长}"
+analysis_model: "mimo-v2-omni"
+dominantHKRR: "{最强维度}"
 overallScore: 0
 createdAt: "{ISO timestamp}"
-tags: [teardown]
+tags: [teardown, video]
 ---
 ```
 
-## 输出格式
+**写入 intel 库触发 wiki sync：**
 
+调用 `autocrew_intel` with `action: "ingest"`:
+```json
+{
+  "action": "ingest",
+  "text": "{报告摘要：基础信息 + 四个视角各一句核心结论 + 可借鉴清单}",
+  "domain": "content-strategy",
+  "tags": ["teardown", "video", "{相关标签}"]
+}
 ```
-## 🔍 对标拆解报告
 
-**内容摘要：** {前50字}...
-**预估平台：** {platform}
-**字数：** {count}
+→ 自动触发 knowledge-sync → wiki 页面更新。
 
-### 钩子分析
-- 类型：{hook type}
-- 公式：{title formula or 无匹配}
-- 强度：{score}/10
-- 评价：{一句话评价}
+### Step V7: 输出给用户
 
-### HKRR 评分
-| H | K | R | R |
-|---|---|---|---|
-| {n}/10 | {n}/10 | {n}/10 | {n}/10 |
-**最强维度：** {element}
+展示完整拆解报告，然后：
 
-### Clock 映射
-{table}
+> 拆解报告已保存到 `_teardowns/{filename}`，知识库已同步。
+>
+> 你可以：
+> 1. 基于这个拆解写一篇内容 — 我会自动引用拆解结论
+> 2. 继续拆解另一个视频
+> 3. 对比多个拆解报告，找共性规律
 
-### 评论触发点
-{list}
+---
 
-### 微操技巧
-{list}
+## 与 write-script 联动
 
-### 💡 总结
-{一句话总结}
+write-script 在创作时会自动搜索 `pipeline/intel/_teardowns/` 目录，查找与当前主题相关的
+拆解报告作为参考。视频拆解和文本拆解的报告都在同一目录，统一被检索。无需手动操作。
 
-### 🎯 可借鉴
-{2-3 bullet points}
-```
+## Error Handling
 
-向用户确认后保存。
+| 失败场景 | 处理 |
+|---------|------|
+| videoCrawler 未配置 | 降级到 manual 模式，提示用户手动下载 |
+| omniConfig 未配置 | 提示用户配置 API Key，给出具体步骤 |
+| 视频文件过大（>200MB）| 提示压缩或裁剪 |
+| 视频时长过长（>30min）| 提示裁剪关键片段 |
+| 采集器下载失败 | 降级到 manual 模式 |
+| Omni API 调用失败 | 显示错误信息，建议检查 API Key 和网络 |
+| 拆解报告保存失败 | 在聊天中展示完整报告供用户复制 |
 
-## 与 write-script 联动
+## Changelog
 
-write-script 在创作时会自动搜索 `pipeline/intel/_teardowns/` 目录，查找与当前主题相关的拆解报告作为参考。无需手动操作。
+- 2026-04-06: v2 — 新增视频拆解路径。Omni 全模态分析，四学科视角模板 v2，
+  可插拔视频采集器，intel ingest + wiki sync 集成。
+- 原版: v1 — 文本拆解。HKRR + Clock Theory + 微操技巧分析。

package/skills/write-script/SKILL.md

@@ -47,6 +47,104 @@ For video scripts: apply the **Clock Theory** from HAMLETDEER.md. Map the script
 
    Search `~/.autocrew/data/pipeline/intel/_teardowns/` for teardown reports related to this topic. If found, use them as reference for what works in this space.
 
+5.5. **⚠️ MANDATORY — Topic-specific research → populate `references/` BEFORE writing:**
+
+   **Why this exists:** Writing from LLM memory alone produces generic, unverifiable content
+   indistinguishable from a random chat response. Every claim, case study, name, and data
+   point in a draft must trace back to a real source. This step is non-negotiable.
+
+   **Step-by-step:**
+
+   a.0. **Query wiki knowledge base (if wiki exists):**
+      1. Check if `~/.autocrew/data/pipeline/wiki/index.md` exists. If not, skip to step a.
+      2. Read `index.md` and find wiki pages whose title, aliases, or summary
+         match the current topic's keywords or angle (fuzzy match, not exact).
+      3. Read matched pages (max 5, prioritize by number of sources — more sources
+         = more synthesized = more valuable).
+      4. For each matched wiki page, write it as a reference file into the project's
+         `references/` folder:
+         - Filename: `wiki-{page-slug}.md`
+         - Format: same as other reference files, but with `source: wiki/{page-slug}.md`
+         - Set `relevance: 8` (synthesized knowledge is higher value than raw intel)
+      5. Wiki-sourced references count toward the 6-reference minimum and can satisfy
+         multiple angle-coverage categories (wiki pages are cross-source syntheses).
+      6. If wiki already provides 4+ solid references, the subsequent intel queries
+         (steps b-d) can be lighter — focus on filling angle gaps rather than full research.
+
+   a. Compute the project slug early: `projectSlug = slugify(topic_title)`.
+      References will live at `~/.autocrew/data/pipeline/drafting/{projectSlug}/references/`.
+      mkdir it if needed (the save step will reuse the same dir).
+
+   b. **Query the existing intel library first** (fast, free):
+      ```json
+      { "action": "list" }
+      ```
+      via `autocrew_intel`. Scan the returned items for any whose title/summary matches
+      this topic's keywords or angle. If 3+ strong matches exist, you may skip step (c).
+
+   c. **Pull fresh intel targeted at this topic** (only if the library is thin):
+      ```json
+      { "action": "pull", "keywords": ["<keyword 1>", "<keyword 2>", "<keyword 3>"] }
+      ```
+      Derive 3-5 keywords from the topic title/angle — specific phrases, not generic.
+      Example: topic "vibe-coding 重新定义能力边界" → keywords like
+      `["vibe-coding 案例", "非程序员 AI 工具 产品", "Cursor 文科生", "GitHub 趋势 独立开发者"]`.
+      Avoid over-broad terms like "AI" alone.
+
+   d. If `web_search` is available, run 2-4 additional targeted queries to find primary
+      sources the intel collectors missed: news articles, product pages, creator interviews,
+      concrete numbers. Prefer named examples over anonymous anecdotes.
+
+   e. **Write each source as a reference file** into the project's `references/` folder.
+      Use the `Write` tool. Filename: `{short-slug}.md`. Format (strict):
+      ```markdown
+      ---
+      source: <url or intel ref>
+      title: <original title>
+      collected: <ISO timestamp>
+      relevance: <1-10, how directly this informs the draft>
+      ---
+
+      ## 要点
+      - <3-6 bullet points of the most useful facts/quotes/data>
+
+      ## 可引用
+      - <specific sentences, names, numbers you might cite verbatim>
+
+      ## 角度
+      - <what angle of the topic this source unlocks>
+      ```
+
+   f. **Minimum bar to proceed — both quantity AND angle coverage:**
+
+      **Quantity:** at least **6 reference files** with `relevance ≥ 6`. Fewer than 6
+      means you'll run out of fresh material by the middle of the draft and fall back to
+      LLM-memory filler.
+
+      **Angle coverage (all 4 categories must have ≥1 reference):**
+      1. **具体案例/人物** — named individual or company with a traceable story
+         (e.g., "腾讯文科生用 Cursor 3 个月做了约饭小程序")
+      2. **数据/数字** — concrete numbers from a report, dashboard, or study
+         (not "很多人", but "2000+ 员工在用" / "3000 万投资" / "涨薪 30%")
+      3. **反面/争议观点** — a dissenting view, failure case, or counter-evidence
+         (prevents the draft from becoming one-sided cheerleading)
+      4. **趋势/背景** — market context, timeline, or "why now" signal
+         (answers why this topic is worth writing about today, not last year)
+
+      Think of it as 2+2+1+1 = 6 minimum. More is better. Duplicates in the same
+      category do NOT count toward the other categories.
+
+      If you cannot hit BOTH bars (6+ total AND all 4 angles covered), stop and tell
+      the user honestly:
+      > 我目前找到 N 条相关信息源，覆盖角度：{已覆盖的角度}。缺少：{缺失的角度}。
+      > 不够支撑一篇有分量的文案。要不要我再调研一轮、换个切入角度、还是你直接补充几个你知道的案例？
+
+      Do NOT proceed to writing on thin research. "写出来再说" is the failure mode
+      this step exists to prevent.
+
+   g. Record the reference filenames in working memory — Step 6 will cite them, and
+      Step 8 will record them in `meta.yaml` via the save params.
+
 6. **Write the script:**
 
    a. **Hook** — pick the ONE strongest type for this topic:
@@ -67,6 +165,10 @@ For video scripts: apply the **Clock Theory** from HAMLETDEER.md. Map the script
    - Write like you're talking to ONE person sitting across from you, not lecturing to a crowd.
    - Vary sentence length deliberately: 3-4 short sentences, then one longer one. Then a one-word sentence. "真的。"
    - Each claim needs: why it's true + concrete example (named, specific, verifiable when possible).
+   - **Ground every factual claim in a reference file** from Step 5.5. If you cite a company,
+     number, name, or case study, it MUST come from one of the `references/*.md` files you
+     collected — not from LLM memory. If a claim has no reference backing, either find one
+     now or cut the claim. "我编的例子" is a bug, not a feature.
    - Total body: 800-1500 characters (text) or platform-specific limit.
 
    **Anti-patterns (NEVER do these):**
@@ -138,6 +240,12 @@ For video scripts: apply the **Clock Theory** from HAMLETDEER.md. Map the script
 7. **Self-review before saving** (fix any failure, don't just check):
    - [ ] 800+ characters total?
    - [ ] Contains at least 2 concrete examples or scenarios (not vague claims)?
+   - [ ] **Every named entity/number/case in the draft traces back to a file in `references/`?**
+   - [ ] **Reference angle coverage used in the draft** — the draft actually cites at least
+         one reference from EACH of the 4 angle categories collected in Step 5.5.f
+         (具体案例/人物, 数据/数字, 反面/争议观点, 趋势/背景). Collecting 6 references but
+         only drawing from the "案例" bucket produces a single-sided draft — fix by
+         weaving in at least one sentence grounded in each missing bucket.
    - [ ] Has a non-obvious insight or twist?
    - [ ] Tone matches STYLE.md profile (if available)?
    - [ ] No generic greetings, no essay-style paragraphs?
@@ -196,7 +304,52 @@ For video scripts: apply the **Clock Theory** from HAMLETDEER.md. Map the script
     Then:
     > 要修改的话直接说，或者确认后我帮你标记为待发布。
 
-11. **If adaptation is needed:**
+    **⚠️ IMPORTANT — Remember the `content_id` from the save result.** You will need it
+    for any subsequent revision in this conversation.
+
+11. **Handling revisions (MANDATORY — 不可只在聊天框里改):**
+
+    When the user requests modifications to a saved draft ("改一改", "换个角度", "这里调整一下",
+    "第二段重写", etc.), you MUST persist the revised content back to the pipeline. Never show
+    a rewritten version in chat only — the draft file must stay in sync.
+
+    Steps for every revision:
+
+    a. Rewrite the full body (or title) incorporating the user's feedback. Re-check against
+       the Step 7 self-review list — a revision is still a draft, same standards apply.
+
+    b. Call `autocrew_content` with `action: "update"`:
+       ```json
+       {
+         "action": "update",
+         "id": "<content-id from the original save>",
+         "title": "<updated title if changed, else original>",
+         "body": "<full revised body — not a diff, the complete new text>",
+         "diff_note": "<one-line summary of what changed and why, e.g. '换成悬念式开头，加 vibe-coding 具体案例'>"
+       }
+       ```
+       The storage layer will archive the previous `draft.md` into an immutable
+       `draft-v{N}.md` snapshot, then replace `draft.md` with your new body, and append
+       the snapshot entry to `meta.yaml` → `versions`. After this:
+       - `draft.md` always holds the newest revision
+       - `draft-v1.md`, `draft-v2.md`, ... are frozen historical states (never modified)
+
+    b.5. **If the user's revision changes the angle or adds new claims** (new companies,
+         new data, new cases), go back to Step 5.5 and add more reference files BEFORE
+         rewriting. New claims still need backing. Don't smuggle new unverified material in
+         under the label "minor tweak".
+
+    c. Confirm to the user that the new version is saved, and show the updated content.
+       Example:
+       > 已更新到 v2（`~/.autocrew/data/pipeline/drafting/{project}/draft.md`）。改动：{diff_note}
+
+    d. If the revision is substantial (new angle, new hook, new structure), re-run
+       `full_review` from Step 9 on the updated content before confirming.
+
+    **Never do:** paste the revised content in chat without calling `update`. If you catch
+    yourself about to show "这是修改后的版本..." without a tool call, stop and save first.
+
+12. **If adaptation is needed:**
     - Do not just trim one draft for another platform.
     - Use `platform-rewrite` / `autocrew_rewrite` to create the first platform-native version.
 

package/src/modules/intel/integration.test.ts

@@ -112,12 +112,13 @@ describe("Pipeline Integration — full flow", () => {
 
     const files = await fs.readdir(projectDir);
     expect(files).toContain("meta.yaml");
-    expect(files).toContain("draft-v1.md");
     expect(files).toContain("draft.md");
+    // No draft-v*.md exists on initial create — only after revisions replace draft.md
+    expect(files.filter((f) => f.startsWith("draft-v"))).toHaveLength(0);
 
     const projectName = slugify("高分选题");
 
-    // 5. Add draft version → meta.yaml updated with v2
+    // 5. Add draft version → original content archived to draft-v1.md, draft.md updated
     await addDraftVersion(
       projectName,
       "# 高分选题\n\n第二版内容",
@@ -127,9 +128,10 @@ describe("Pipeline Integration — full flow", () => {
 
     let meta = await getProjectMeta(projectName, testDir);
     expect(meta).not.toBeNull();
-    expect(meta!.versions.length).toBe(2);
-    expect(meta!.current).toBe("draft-v2.md");
-    expect(meta!.versions[1].note).toBe("improved draft");
+    expect(meta!.versions.length).toBe(1);
+    expect(meta!.versions[0].file).toBe("draft-v1.md");
+    expect(meta!.current).toBe("draft.md");
+    expect(meta!.versions[0].note).toBe("improved draft");
 
     // 6. Advance: drafting → production → published
     await advanceProject(projectName, testDir);
@@ -183,8 +185,8 @@ describe("Pipeline Integration — trash and restore", () => {
     // Verify state is preserved
     const meta = await getProjectMeta(projectName, testDir);
     expect(meta).not.toBeNull();
-    expect(meta!.versions.length).toBe(2);
-    expect(meta!.current).toBe("draft-v2.md");
+    expect(meta!.versions.length).toBe(1);
+    expect(meta!.current).toBe("draft.md");
     expect(meta!.title).toBe("回收还原测试");
 
     // History should show: drafting → trash → drafting

package/src/modules/profile/creator-profile.test.ts

@@ -142,6 +142,57 @@ describe("addCompetitor", () => {
   });
 });
 
+describe("videoCrawler and omniConfig", () => {
+  it("saves and loads videoCrawler and omniConfig", async () => {
+    const profile = await initProfile(testDir);
+    const full: CreatorProfile = {
+      ...profile,
+      videoCrawler: { type: "mediacrawl", command: "python3 /opt/mediacrawl/main.py" },
+      omniConfig: {
+        baseUrl: "https://api.xiaomimimo.com/v1",
+        model: "mimo-v2-omni",
+        apiKey: "sk-test-key-123",
+      },
+    };
+    await saveProfile(full, testDir);
+    const loaded = await loadProfile(testDir);
+    expect(loaded).not.toBeNull();
+    expect(loaded!.videoCrawler).toEqual({ type: "mediacrawl", command: "python3 /opt/mediacrawl/main.py" });
+    expect(loaded!.omniConfig).toEqual({
+      baseUrl: "https://api.xiaomimimo.com/v1",
+      model: "mimo-v2-omni",
+      apiKey: "sk-test-key-123",
+    });
+  });
+
+  it("loads profile without video config (backward compatible)", async () => {
+    // Write a minimal JSON file without the new fields
+    const filePath = path.join(testDir, "creator-profile.json");
+    const legacy = {
+      industry: "科技",
+      platforms: ["xhs"],
+      audiencePersona: null,
+      creatorPersona: null,
+      writingRules: [],
+      styleBoundaries: { never: [], always: [] },
+      competitorAccounts: [],
+      performanceHistory: [],
+      expressionPersona: "",
+      secondaryPersonas: [],
+      styleCalibrated: false,
+      createdAt: "2025-01-01T00:00:00.000Z",
+      updatedAt: "2025-01-01T00:00:00.000Z",
+    };
+    await fs.writeFile(filePath, JSON.stringify(legacy, null, 2), "utf-8");
+
+    const loaded = await loadProfile(testDir);
+    expect(loaded).not.toBeNull();
+    expect(loaded!.industry).toBe("科技");
+    expect(loaded!.videoCrawler).toBeUndefined();
+    expect(loaded!.omniConfig).toBeUndefined();
+  });
+});
+
 describe("detectMissingInfo", () => {
   it("reports all missing fields on empty profile", async () => {
     const profile = await initProfile(testDir);