feat: 导出 SproutClaw .sproutclaw 配置

包含 extensions、skills、prompts、settings、auth、models、mcp 等配置。
排除 node_modules、npm 缓存、sessions 等运行时数据。

agent/skills-disabled/SoftwareCopyright-Skill/software-copyright-materials/references/application_fields.md

@@ -0,0 +1,61 @@
+# 申请表信息字段
+
+按官网实际表单顺序和字段名：
+
+1. 软件全称
+2. 软件简称（可选）
+3. 版本号
+4. 软件分类（应用软件/嵌入式软件/中间件/系统软件/其他）
+5. 开发完成日期（YYYY-MM-DD）
+6. 开发方式（单独开发/合作开发/委托开发/下达任务开发）
+7. 软件说明（原创 / 修改（含翻译软件、合成软件））
+8. 发表状态（已发表/未发表）
+9. 首次发表日期（已发表时填写，YYYY-MM-DD）
+10. 著作权人（复合字段：国家/省市/类型[自然人/法人]/姓名/证件类型/证件号）
+11. 权利范围（全部权利/部分权利）
+12. 权利取得方式（原始取得/继受取得）
+13. 开发的硬件环境（≤50字符）
+14. 运行的硬件环境（≤50字符）
+15. 开发该软件的操作系统（≤50字符）
+16. 软件开发环境 / 开发工具（≤50字符，格式：开发环境: xxx/开发工具: xxx）
+17. 该软件的运行平台 / 操作系统（≤50字符）
+18. 软件运行支撑环境 / 支持软件（≤50字符）
+19. 编程语言（预设按钮选择 + 自定义输入≤120字符）
+20. 源程序量（纯数字，单位行，指全部源程序总行数）
+21. 开发目的（≤50字符，不能只写软件名称）
+22. 面向领域 / 行业（≤50字符）
+23. 软件的主要功能（500~1300字符）
+24. 软件的技术特点（多选标签 + 文本描述≤100字符；标签：APP/游戏软件/教育软件/金融软件/医疗软件/地理信息软件/云计算软件/信息安全软件/大数据软件/人工智能软件/VR软件/5G软件/小程序/物联网软件/智慧城市软件，都不符合时可不选）
+25. 页数（代码鉴别材料实际页数）
+
+## 字段来源与填写口径
+
+- 软件全称、版本号、著作权人、日期：由用户确认。
+- 软件全称必须显式确认；正式资料文件名、代码 Word 页眉、操作手册标题和正文中的软件名称均以申请表信息中的"软件全称"为准。
+- 软件简称：可选；如有常用简称则填写。
+- 版本号必须显式确认；如果项目配置中的版本号小于 V1.0，需提醒用户软著首次提交通常写 V1.0，并让用户确认填写 V1.0 还是项目当前版本号。
+- 软件分类：默认选"应用软件"。
+- 开发完成日期和首次发表日期：必须使用 YYYY-MM-DD 格式。
+- 开发方式：默认"单独开发"，多人合作项目选"合作开发"。
+- 软件说明：默认"原创"。
+- 发表状态：用户确认已发表或未发表；已发表需附首次发表日期。
+- 编程语言、源程序量、功能模块、技术特点：根据项目分析生成。编程语言官网为预设按钮选择 + 自定义输入（≤120字符），预设选项包括 Assembly language、C、C#、C++、Delphi/Object Pascal、Go、HTML、Java、JavaScript、MATLAB、Objective-C、PHP、PL/SQL、Perl、Python、R、Ruby、SQL、Swift、Visual Basic、Visual Basic .Net。
+- 源程序量：只填纯数字（不含"行"字），指登记软件全部源程序的总行数（非仅代码材料抽取行数）。
+- 软件开发环境 / 开发工具：≤50字符，格式 `开发环境: <OS>/开发工具: <IDE>`，例如 `开发环境: Windows 11/开发工具: Visual Studio Code`；不要填写 React、Next.js、Vite、TypeScript 等技术栈。
+- 开发该软件的操作系统：≤50字符，填写实际开发电脑的操作系统版本。
+- 该软件的运行平台 / 操作系统：≤50字符，填写软件运行所在的操作系统或浏览器环境。
+- 软件运行支撑环境 / 支持软件：≤50字符，直接列出运行依赖（如 Node.js、npm、浏览器），不加格式前缀。
+- 开发的硬件环境：≤50字符，优先读取当前电脑 CPU、内存、硬盘配置作为建议值。
+- 运行的硬件环境：≤50字符，默认可沿用开发硬件建议值，也可按实际运行设备填写。
+- 开发目的：≤50字符，用一句话说明软件开发目的，不能只写软件名称。
+- 面向领域 / 行业：≤50字符。
+- 软件的主要功能：500~1300字符，详细描述软件核心功能。
+- 软件的技术特点：多选标签（APP/游戏软件/教育软件等）+ 文本描述≤100字符；标签都不符合时可不选。
+
+## 一致性要求
+
+- 软件全称和版本号必须与代码材料、操作手册一致。
+- 正式代码 Word 页眉软件名称必须与申请表信息中的“软件全称”一致，生成 Word 时以申请表软件全称为准。
+- 正式代码 Word 页眉版本号必须与申请表信息中的“版本号”一致，生成 Word 时以申请表版本号为准。
+- 主要功能必须来自当前项目，不得沿用范本中的旧项目描述。
+- `待用户确认` 字段在正式输出前应尽量替换为确认值；如仍存在，必须写入生成报告。

agent/skills-disabled/SoftwareCopyright-Skill/software-copyright-materials/references/business_understanding_rules.md

@@ -0,0 +1,49 @@
+# 业务理解规则
+
+申请表信息和操作手册不能只根据代码结构泛泛生成，必须先理解软件业务。
+
+## 证据收集
+
+先用脚本收集证据，输出 `草稿/业务理解证据.md/json` 和 `草稿/业务理解模型稿模板.json`。证据通常包括：
+
+- `README.md`
+- `docs/*PRD*.md`
+- `docs/*BRD*.md`
+- `docs/*ARCHITECTURE*.md`
+- 产品说明、需求文档、设计文档
+- 前端页面标题、按钮文案、路由、核心组件名
+- 后端 API 路由和模型名称
+
+这些只是候选证据，不代表最终行业、功能和手册结构。
+
+## 输出业务理解草稿
+
+模型必须阅读证据和必要源码，自行判断应该抽取哪些业务信息，再生成业务理解模型稿 JSON。不得用关键字表或固定模板决定行业、功能和结构。
+
+模型稿经脚本校验后生成 `草稿/业务理解.md` 和 `草稿/业务理解.json`，至少包含：
+
+- 产品定位
+- 面向领域 / 行业
+- 目标用户
+- 用户痛点和核心价值
+- 主要业务功能
+- 典型操作流程
+- 操作手册结构建议
+- 操作手册页面/流程模块，必须说明每个真实页面或核心流程的使用场景、进入位置、用户可见元素、用户动作、输入/状态规则、结果反馈和截图预留
+- 申请表建议口径
+- 证据来源
+- 待用户确认项
+
+## 外部调研
+
+如果项目材料不足、业务类型较新，或用户明确希望参考竞品，可联网搜索相近产品和行业资料。
+
+外部调研只用于帮助理解行业表达，不能编造项目不存在的功能。需要把调研结论写入业务理解草稿，并区分“项目证据”和“行业参考”。
+
+## 生成材料约束
+
+- `申请表信息.md/txt` 的开发目的、行业、主要功能、技术特点必须优先来自业务理解。
+- `操作手册.md/docx` 的说明、功能特点、系统要求、核心页面/流程、常见问题、术语表和章节结构必须优先来自模型确认后的业务理解。
+- 操作手册不应只生成抽象“功能列表”。模型应把路由、页面、按钮、输入框、列表、弹窗、状态提示、额度或权限规则等用户可见证据整理到 `manual_modules`，供脚本按通用操作手册骨架排版。最终成稿应是段落化用户手册，不是“进入方式/页面内容/操作步骤/结果反馈”的字段列表。
+- 如果缺少 `manual_modules`、`system_requirements`、`faq` 或 `glossary`，应回到业务理解阶段补充真实内容；脚本不得用分类模板兜底生成。
+- 如果业务理解仍不充分，先提示用户补充产品说明，而不是直接生成泛泛描述。

agent/skills-disabled/SoftwareCopyright-Skill/software-copyright-materials/references/code_selection_rules.md

@@ -0,0 +1,39 @@
+# 代码抽取规则
+
+## 选择方式
+
+脚本只生成候选源码清单，不默认决定抽取文件。模型需要先理解项目业务、页面入口和源码职责，再决定抽取哪些文件或行段，并在 `代码文件选择.json` 中填写：
+
+- `selected`
+- `start_line`
+- `end_line`
+- `model_reason`
+
+选择时通常优先考虑审核员能看懂软件功能和运行逻辑的源码，例如入口、页面、业务组件、数据交互、状态处理、业务服务等。具体选择由模型根据项目实际判断，不能用固定路径规则直接拍板。
+
+## 排除项
+
+排除以下内容：
+
+- `node_modules`
+- `dist`、`build`、`.next`、`.nuxt`、`coverage`
+- lock 文件
+- 图片、字体、二进制文件
+- sourcemap、minified 文件
+- 自动生成文件
+- 过短且无业务意义的配置文件
+
+## 真实性要求
+
+- 保留原始代码文本。
+- 可添加文件路径标记用于追溯。
+- 不改写业务逻辑。
+- 不使用 AI 补齐代码。
+
+## 用户确认要求
+
+- 代码抽取前必须先生成 `代码文件候选清单.md` 和 `代码文件选择.json`。
+- 模型必须先填写抽取选择和 `model_reason`，再让用户确认或手动调整 `selected`。
+- 用户可以通过 `start_line` / `end_line` 只抽取某个文件的指定行段。
+- 抽取脚本必须以 `代码文件选择.json` 为准，不能绕过确认步骤直接抽全量代码库。
+- `代码提取清单.md` 必须记录每个文件的抽取行段，便于回溯。

agent/skills-disabled/SoftwareCopyright-Skill/software-copyright-materials/references/copyright_material_rules.md

@@ -0,0 +1,22 @@
+# 软著材料规则
+
+## 鉴别材料
+
+根据《计算机软件著作权登记办法》第十条，软件鉴别材料包括程序和文档的鉴别材料。
+
+执行规则：
+
+- 源程序和文档一般由前、后各连续 30 页组成。
+- 整个程序或文档不足 60 页时，提交全部。
+- 除特定情况外，程序每页不少于 50 行。
+- 除特定情况外，文档每页不少于 30 行。
+
+## 本 skill 的落地规则
+
+- 代码分页默认每页 50 行。
+- 总页数 `>= 60` 时，只输出前 30 页和后 30 页代码材料。
+- 总页数 `< 60` 时，只输出全部代码材料。
+- 不为大项目输出全量代码 Word，避免文件过大且不符合常规提交需求。
+- 代码材料必须来自项目源文件，不能由 AI 生成。
+- 文件页眉或页首必须包含软件全称和版本号。
+- 页码必须连续且清晰。

agent/skills-disabled/SoftwareCopyright-Skill/software-copyright-materials/references/manual_structure.md

@@ -0,0 +1,39 @@
+# 操作手册结构
+
+操作手册应像真实软件随附的操作说明，目标是让读者知道软件用途、功能和基本操作。
+
+推荐采用软著审核友好的通用骨架，类似传统操作手册：
+
+1. 相关文档：用表格指向总体设计、详细设计、测试案例等配套资料。
+2. 说明：说明软件定位、目标用户、业务场景和整体流程。
+3. 功能特点：按当前项目真实功能概括 4-8 项特点，每项说明业务作用和用户可见结果。
+4. 系统要求：用表格说明最低配置和推荐配置；Web 项目可写浏览器、网络和服务访问要求，桌面项目可写操作系统、处理器、内存、存储和分辨率。
+5. 具体页面 / 功能操作：从第 5 章开始，按真实页面、导航入口或核心流程逐章说明，每章写使用场景、页面用途、进入位置、页面内容、用户动作、输入限制或异常提示、操作结果和截图预留。
+6. 典型使用流程：如项目存在清晰串联流程，可单独写一章串起从进入软件到完成核心任务的过程。
+7. 常见问题解答：写 3-5 个与当前软件真实使用相关的问题和解决方法。
+8. 术语表：解释软件名称、核心业务对象、页面模块和用户可能不熟悉的术语。
+
+以上是通用骨架，不是旧项目内容。正式章节标题使用中文大写序号，例如 `一、相关文档`，不要使用 `(1)、相关文档`。生成时必须根据当前项目业务、页面入口、功能关系和用户可见控件填充内容，不要照抄用户提供的范本文案。
+具体页面和流程必须来自 `草稿/业务理解.json` 中模型写入的 `manual_modules`。如果该字段为空，不能根据 `business_features` 生成兜底模块，应停止并要求模型阅读真实页面和项目资料后补全。
+
+## 写作口径
+
+- 使用通用、客观、简洁的中文。
+- 不写面向终端用户的复杂教程。
+- 每个章节必须有段落化说明，不能只写项目符号列表；正文不要用 `-`、`*`、`1. 2. 3.` 堆信息。
+- 每个核心页面或功能模块必须覆盖“使用场景 + 页面用途 + 进入位置 + 页面内容 + 用户动作 + 输入/状态规则 + 系统反馈 + 截图预留”，但这些信息要合并成自然段落，不能直接输出成字段表单。
+- 优先写用户真实能看到和操作的内容，例如输入框、按钮、下拉框、标签页、列表、卡片、弹窗、错误提示、状态栏、导入导出入口、额度或权限提示。
+- 补充说明段落只能写当前软件的用途、业务场景、页面组织和用户流程，不写“本操作手册用于……”“面向软著审核……”“不描述代码实现……”这类解释文档写作方式的元话语。
+- 禁止在脚本中按 auth、query、form、workflow 等分类自动生成入口、步骤或结果反馈。入口和步骤必须来自模型对当前项目真实页面的阅读。
+- 功能特点不要写成“开头一句总述 + 编号列表 + 结论”的头中尾结构。每个特点用段落展开，说明该功能解决什么业务问题、用户在页面上看到什么、完成操作后得到什么结果。不同功能的说明要有差异，避免每条都使用相同句式。
+- 页面章节不要输出“进入方式：”“页面内容：”“操作步骤：”“操作规则：”“操作结果与反馈：”这类模板小标题。
+- 操作手册语言要让审核员和普通读者能看懂，重点说明模块是做什么的、怎么操作、操作后看到什么。避免代码、框架、接口、状态管理、异步任务等技术化表达。
+- “AI 味”主要表现为空泛、整齐、万能、没有项目现场感：例如每个模块都用同一种句式，反复写“提升效率、优化体验、提供支持”，使用“旨在、赋能、一站式、智能化、高效便捷、显著提升、强大能力、丰富功能”等口号，却没有说明当前项目的真实页面、真实对象、真实动作和真实反馈。发现这类内容时必须改写成朴素、具体、可回溯到项目证据的表达。
+- 截图前必须先让用户在 Chrome DevTools MCP、Codex Computer Use、用户自行截图三种方式中选择；选择后检查对应能力是否可用。用户说现在不截图或先跳过截图时，记录为 `skip`，并在每个需要截图的位置保留正式 Word 中可见的截图预留文字。
+- 不夸大不存在的功能。
+- 功能名称和章节组织由模型根据项目证据判断；路由、页面、README、接口和组件命名只是证据来源，不是固定抽取规则。
+- Markdown 草稿生成前由 agent 自行检查章节完整性、内容厚度、项目流程一致性和语言自然度，发现章节过薄、模块套话、AI 味、技术化表达或相邻模块含义混淆时先循环补写和修正；完整草稿生成后只向用户发起一次整体确认，再进入 Word 生成。
+- 操作手册生成时必须同步输出 `操作手册自检记录.md/json`。记录中至少包含初稿生成、按项目流程扩写、去除制式表达和 AI 味三轮；如果第三轮仍发现问题，要继续自动修正并追加轮次记录。
+- 操作手册必须基于已确认的业务理解写作。相近功能应结合项目真实业务分别说明各自的操作目的、用户动作和结果反馈，不能用同一段话替换不同模块。
+- 自检时必须检查是否生成了“功能操作说明”大章下反复套同一批模块的情况；如果出现同一模块重复多次，必须改为每个真实页面独立成章。
+- 禁止把测试项目中的行业、角色、流程、功能名称或示例文案写成通用规则；范本只能帮助理解软著手册需要“通顺、具体、能给审核员看懂”，不能作为固定内容来源。