aisee:spec-migrate

aisee:spec-migrate — 现有项目 Spec 基线迁移

把已有项目的当前行为整理成 OpenSpec 静态层 openspec/specs/。它回答“系统现在是什么”，为已有系统接入 OpenSpec、二次开发前建立 baseline，并为后续 /opsx:new、delta specs 和 archive 提供稳定起点。

aisee:spec-migrate 不是 aisee:srs：不整理未来需求。 aisee:spec-migrate 不是 aisee:change-plan：不规划 OpenSpec change 边界。 aisee:spec-migrate 不写 change 级 proposal.md、design.md 或 tasks.md。

输入

用户提供以下任意一种输入：

• 现有项目目录
• 现有需求文档、README、接口文档、测试目录
• 已初始化的 OpenSpec 项目
• 指定模块或目录范围

可选参数：

• --scope project|module|path|auto — 迁移范围，默认 auto
• --mode inventory|draft|write|auto — 只盘点、生成草案或写入 baseline specs，默认 auto
• --batch-size <n> — 单批最多生成的 spec 文件数，默认 5
• --write patch|direct|chat — 写入方式，默认 patch
• --lang zh|en — 输出语言，默认 zh

输出边界

aisee:spec-migrate 只产出现有系统行为的 OpenSpec baseline 和迁移索引。

必须输出或写入：

• 迁移范围和证据来源
• 能力边界图：按业务能力 / 领域划分，不按文件类型机械划分
• openspec/specs/ 目录规划
• openspec/specs/project.md 的缺口建议或补丁
• openspec/specs/<capability>/spec.md baseline specs
• 证据追踪、可信度、冲突和 Open Questions
• 迁移批次计划，避免一次生成巨型 spec

禁止输出：

• 新功能需求或未来规划
• active change 的 delta spec，除非用户明确要求 bootstrap change
• /opsx:new、/opsx:propose、/opsx:apply 执行命令
• proposal.md、design.md、tasks.md
• 数据库迁移、实现计划或代码修改
• 无证据的业务规则断言

事实源边界

• openspec/specs/ 是 baseline 规范事实源。
• aisee/docs/spec-migration/ 是迁移索引、草案、证据和冲突记录区，不是最终规范事实源。
• Active changes 只能作为“未归档变更上下文”，不能直接当作当前 baseline 行为。
• 历史 SRS / UI / Architecture 文档中的文档内编号或 source ref 只作为证据入口，不能直接当作 baseline 已确认行为。
• 低可信度推断只能进入迁移索引或 Open Questions，不能写入正式 baseline spec。

Phase 0 — 预检与扫描

确认 OpenSpec 状态：

node -e "const fs=require('fs'); for (const p of ['openspec/config.yaml','openspec/specs']) { try { const s=fs.statSync(p); console.log(p + ':' + (s.isDirectory()?'dir':'file')); } catch { console.log(p + ':missing'); } }"

处理规则：

• 缺少 openspec/config.yaml：停止写入 openspec/specs/，建议先运行 openspec init 或 aisee:init。
• 缺少 openspec/specs/：可以创建目录补丁，但必须说明这是 baseline migration。
• 已有 openspec/specs/：先读取现有 spec，避免覆盖和重复建模。
• 已有 active changes：读取 openspec/changes/，标注可能冲突；不要把 active delta 当作 baseline 事实。