/chinese-copyright-application

name: chinese-copyright-application
version: 1.1.0
description: 中国软件著作权申请材料生成工具。申请表直接输出 Markdown 提交，源程序/用户手册/设计说明书三份生成 LaTeX 并编译为 PDF。自动分析项目代码，生成四份材料（前后各30页共60页源程序、含页眉页脚的用户手册和设计说明书、Markdown 申请表），并做版本号一致性、模块覆盖双向核验、字数限制等信息一致性校验。适用于微信小程序、Web应用、移动App、桌面应用等各类软件项目。当用户提到软件著作权、软著申请、版权登记时必须使用此 Skill。当用户要为任何软件项目准备著作权材料、生成软著文档时也应使用。

中国软件著作权申请材料生成

核心原则

• **申请表**：直接输出 Markdown（`.md`）文件提交，不参与 LaTeX 编译。
• **源程序、用户手册、设计说明书**：生成 `.tex` 文件，用 XeLaTeX 编译为 PDF。

v1.1 关键变更

• 申请表载体由 LaTeX→PDF 改为 Markdown（PDF 文本提取带换行造成的录入问题）
• 主要功能字数：200 字 → **500–1000 字（建议 500–600）**
• 新增**版本号一致性核验**（信息收集阶段就要查项目里的 version 字符串与目标版本号是否一致）
• 新增**遗留代码识别**（mockData/util.js 模板/logs 等不应进入鉴别材料）
• 设计说明书 §4 详细设计强制 **6 段结构** + **模块覆盖双向对应**
• 源程序 PDF **必须正好 60 页**，提供 `--front-lines` / `--back-lines` 微调参数

快速开始

1. 环境检查与安装引导 2. 收集著作权人信息与关键参数 3. 分析项目结构和代码 4. 生成四份 LaTeX 文档 + 编译脚本 5. 生成截图清单 6. 运行一致性校验

工作流程

第零步：环境检查

申请表是 Markdown，**不需要 LaTeX 环境也能拿到**。LaTeX 环境只用于编译三份 PDF（源程序、用户手册、设计说明书）。

执行 `xelatex --version` 检测。

**如已安装**：继续下一步。

**如未安装**：告知用户当前可以先生成全部 Markdown/LaTeX 源文件 + Markdown 申请表，待安装 LaTeX 后再编译三份 PDF；询问是否立即安装。用户同意后按以下命令执行：

• macOS：`brew install --cask basictex && sudo tlmgr update --self && sudo tlmgr install ctex xecjk fancyhdr lastpage fancyvrb tabularx enumitem float xcolor longtable collection-fontsrecommended`
• Linux：`sudo apt install texlive-xetex texlive-lang-chinese texlive-latex-extra texlive-fonts-recommended`
• Windows：引导用户安装 TeX Live 完整版（https://www.tug.org/texlive/）

第一步 A：版本号一致性核验（先做）

> 这是上次（集享 V1.0 软著流水号 2026R11L0626727）被打回补正的**首条意见**：申请表填 V1.0，但 `utils/config.js` 写的是 `version: '1.1.1'`，截图角标也是 V1.1.1，被审查员第一眼抓到。在收集软件参数之前必须先做这一步。

**操作流程**：

1. 先问用户「这次软著要申请的版本号是多少」（首次申请通常 V1.0）。 2. 然后扫描项目里所有版本号字符串：

   # 配置文件中的 version 字段
   grep -rEn '"version"\s*:\s*"[0-9]+(\.[0-9]+)+"' <项目路径> \
     --include='*.js' --include='*.ts' --include='*.json' \
     --exclude-dir=node_modules --exclude-dir=miniprogram_npm

   # 页面 footer / 关于页里硬编码的版本号
   grep -rEn 'V[0-9]+\.[0-9]+|版本.*[0-9]+\.[0-9]+' \
     <项目路径>/pages <项目路径>/components <项目路径>/src 2>/dev/null

3. 如果用户已经提供了运行截图目录，提醒用户检查截图右下角/关于页/启动页是否带版本号。 4. 把扫描结果以表格形式列出来：**所有出现位置 + 对应版本字符串**。 5. 如果发现不一致（任何位置的版本号 ≠ 用户拟申请的版本号），**必须停下来**，让用户裁决：「最终申请使用哪个版本号？」并明确告知用户：在提交申请前必须把所有出现位置统一（含重新截图）。 6. 全部一致才能继续下一步。

详见 [requirements.md](references/requirements.md#版本号一致性核验)。

第一步：信息收集

分两轮收集信息。

第一轮：著作权人信息

先检查项目根目录或用户工作目录下是否存在 `copyright-owner.json`。

**如已存在**：读取文件内容，向用户展示并确认是否有变更。用户确认无误则直接使用，跳到第二轮。

**如不存在**：首次使用，需引导用户提供信息并保存。先问著作权人是个人还是企业，然后收集对应信息。

个人需提供：姓名、身份证号、地址、邮编、联系人、电话、邮箱。

企业需提供完整工商信息（参考 [requirements.md](references/requirements.md)「著作权人信息」章节）：公司全称、统一社会信用代码、企业类型、法定代表人、注册资本、住所地址、登记机关、营业执照登记日期、联系人、电话、邮箱。

收集完成后将信息保存为 `copyright-owner.json`，格式如下：

{
  "type": "企业",
  "name": "星辰科技（北京）有限公司",
  "credit_code": "91110108MA01EXAMPLE",
  "enterprise_type": "有限责任公司",
  "legal_representative": "张三",
  "registered_capital": "伍佰万元整",
  "address": "北京市海淀区中关村大街1号",
  "registration_authority": "北京市海淀区市场监督管理局",
  "license_date": "2022年6月15日",
  "contact": "",
  "phone": "",
  "email": ""
}

此文件后续申请时直接复用，著作权人信息只需填一次。

第二轮：软件关键参数

自动分析项目后预填建议值，让用户确认：

| 参数 | 说明 | |------|------| | 软件全称 | **必须以"软件"二字结尾**（如"智慧记账软件"），有辨识度，所有文档中完全一致。用户提供的名称若未以"软件"结尾，自动补上 | | 版本号 | V1.0（首次申请统一使用 V1.0） | | 开发完成日期 | 软件实际完成开发的日期 | | 首次发表日期 | 软件首次上线/发布的日期（≥ 开发完成日期） | | 源程序量 | 项目实际总代码行数（可自动统计后让用户确认） |

**日期约束**：开发完成日期 ≤ 首次发表日期 < 申请日期。生成时自动校验，不合规则提醒用户修改。

第二步：项目分析与源程序生成

运行 `scripts/analyze_and_generate_source.py` 完成项目分析和源程序 .tex 生成：

python3 scripts/analyze_and_generate_source.py <项目路径> \
  --name "软件全称" \
  --version "V1.0" \
  --owner "著作权人名称" \
  --date "2025年4月30日" \
  --output copyright-materials/

脚本自动完成： 1. 检测项目类型（微信小程序/Web/Node.js 等） 2. 遍历代码文件，排除 node_modules 等无关目录 3. 识别**遗留代码候选项**（mockData、util.js 模板、logs 等），输出到 JSON 的 `legacy_candidates` 字段 4. 统计有效代码行数（排除空行和纯注释行），输出按文件类型的行数分布 5. 按文件优先级排序，去除空行后提取前30页 + 后30页代码，生成源程序 .tex 文件 6. 输出 `project_analysis.json` 供后续文档生成参考

**遗留代码排除规则**（默认识别 + 用户裁决）：

脚本会扫描以下模式作为遗留代码候选项，**列出但不自动排除**：

• `mockData*.js` / `mock*.js` / `fakeData*.js` — 仅供开发期使用的假数据
• `utils/util.js` — 微信小程序默认模板的 `formatTime` 样板（条件：文件 < 1KB 或仅含模板函数）
• `pages/logs/**` — 微信开发者工具默认模板的日志页
• 空文件、占位文件、临时调试代码

Claude 在拿到 `legacy_candidates` 后，必须**列出来询问用户**是否排除，确认后通过 `--exclude-pattern` 参数重新运行脚本。这是为了避免源代码鉴别材料里出现"文档里写不出来对应模块"的代码（上次集享被打回的第二大原因）。

**排版经验值**（10pt + `\small` Verbatim + 上下2cm左右1.5cm边距，基于实测校准）：

| 参数 | 值 | 说明 | |------|------|------| | 标准页容量 | 50行/页 | 满页代码行数 | | 首页容量 | 40行 | 标题区域占约10行空间 | | 后30页首页 | 48行 | 分隔标题占约2行空间 | | 前30页目标 | 1490行 | 40 + 29×50（可用 `--front-lines` 覆盖） | | 后30页目标 | 1498行 | 48 + 29×50（可用 `--back-lines` 覆盖） | | 总目标 | 2988行 | 去除空行后的代码行数 |

代码量不足2988行时，脚本使用全部代码，不强凑60页。

脚本输出的 `total_lines_effective` 即为申请表中的「源程序量」。

**60 页硬约束（重要）**：源程序 PDF 编译完后**必须正好 60 页**（除非项目代码本就不足 60 页）。多 1 页或少 1 页都属于格式不合规。编译后用 `pdfinfo <软件全称>源程序.pdf | grep Pages` 核对；如不对，调整 `--front-lines` / `--back-lines` 参数（默认 1490 / 1498，每次 ±2~5 行试探）重新生成并编译。

第三步：生成四份文档

所有文档的 LaTeX 编写规范见 [references/requirements.md](references/requirements.md)。每份文档的模板见 references 目录下对应的 `.tex` 模板文件。

输出文件夹与命名

输出目录：`copyright-materials/`

生成文档前先创建目录结构：

mkdir -p copyright-materials/images

文件命名规范为「软件全称 + 文档类型」，举例：

• `智慧记账软件著作权登记申请表.md`（**Markdown 直接提交**，不编译）
• `智慧记账软件源程序.tex` / `.pdf`
• `智慧记账软件用户手册.tex` / `.pdf`
• `智慧记账软件设计说明书.tex` / `.pdf`
• `build_all.sh`
• `images/`（图片目录，用户后续在此放入截图）

3.1 著作权登记申请表（Markdown）

模板：[application-form-template.md](references/application-form-template.md)

**载体**：直接生成 `.md` 文件，**不参与 LaTeX 编译**。申请表本身没有格式硬要求，Markdown 表格 + 段落即可。

格式要求：

• 用 Markdown 表格组织字段（`| 字段 | 内容 |`）
• 主要功能段落写在表格外，分段展开
• 分为：基本信息、著作权人信息、开发者信息、软硬件环境信息、软件基础信息、软件技术特点、软件分类、备注
• 申请表字段有严格字数限制（详见 requirements.md「字数限制」章节），生成后必须校验

**字数限制速查**：

• 硬件环境/操作系统/开发工具/运行平台/支撑环境：各 ≤50 字符
• 开发目的/面向领域：各 ≤50 字
• **主要功能：500–1000 字（建议 500–600 字以减少出错）**
• 技术特点：≤100 字

3.2 源程序

由第二步的脚本自动生成，无需手动编写。生成规则详见 [requirements.md](references/requirements.md)「源程序文档要求」。

3.3 用户手册

模