feature-listlisted

# Maintain Feature List 维护 `docs/product-spec/feature-list.md` 这一份唯一功能基准。最终文件必须完全脱离原代码库：任意 AI 只读取它，就能复刻并验收清单声明范围内的完整产品。 本 skill 只修改功能清单，不修改源码、测试、配置或工程文档，也不自动执行 `/code-cleanup:cleanup`。 ## 开始前 完整读取 `../../references/feature-list-contract.md`，然后根据目标文件状态选择模式： - 文件不存在：执行初始化。 - 文件存在且用户提供已确认业务变化：执行更新。 - 文件存在且用户要求补全、核查或刷新：执行完整性审计，只吸收有权威业务依据的内容。 用户未明确指定子产品或模块时，范围必须是仓库承载的整个可交付产品。不得根据当前打开文件、最近对话、最近 diff 或最熟悉的模块隐式缩小范围。用户显式限定 CodeBench 等产品范围时，只盘点该范围，并准确填写“覆盖范围”和“不包含范围”；覆盖状态按声明范围内的完整程度���定，不因仓库还有范围外产品自动降为 `partial`。 ## 初始化 1. 先盘点声明范围内的全部可交付应用、服务和产品域，建立产品面覆盖表；未指定范围时，声明范围就是仓库承载的整个可交付产品。再盘点每个产品面的入口、页面、导航、角色、公开接口、任务、通知和外部集成。阅读产品资料、测试和运行行为，并按需实际操作产品。 2. 建立临时证据矩阵，追踪每项行为的来源、冲突和缺口。证据矩阵只用于分析，不能写入最终清单。 3. 先恢复产品边界、体验规范、全局规则和功能索引，再逐项补齐功能详述、跨功能旅程、公开契约、数据生命周期和质量属性。 4. 从产品使用者和复刻者视角描述“产品做什么”，删除全部实现信息。 5. 对无法确认且会影响复刻的内容标为 `draft`，提出精确业务问题；继续补齐声明范围内的其他产品面。声明范围尚未覆盖完整或仍有阻塞项时不得把整体标为 `ready`。 初始化是唯一允许以现有产品和代码行为恢复初始事实的阶段。基准建立后，代码不再拥有定义功能的权力。 ## 更新 1. 只接受用户确认、产品决策、正式需求或等价权威来源作为业务变化。 2. 把变化写成可判定的前后差异，并检查角色、体验、规则、上下游功能、公开契约、数据生命周期和质量属性的连锁影响。 3. 保持功能 ID 稳定；新增功能分配新 ID；废弃功能保留 ID，标记 `deprecated` 并说明替代和兼容边界。 4. 同步修改索引、详述、旅程和所有关联章节，更新语义化版本与变更记录。 5. 更新后的 `ready` 内容立即成为代码必须达到的新基准，不要求当前实现已经完成。 当前代码只能帮助发现影响范围。代码与基准不同时，不得依据代码反向修改基准；没有已确认业务变化时，应把差异留给实现或 `/code-cleanup:cleanup` 修正。 ## 无代码内容 最终功能清单不得出现： - 源码、伪代码、代码块、文件或目录路径。 - 函数、类、方法、模块、组件等实现符号。 - 框架、库、依赖包、构建工具、配置项或环境变量。 - 数据库表、字段、索引、迁移脚本或内部存储结构。 - 调用链、实现证据、测试文件或“当前代码如何完成”。 - 内部路由模板、权限码、配置键、原始状态常量、国际化键或代码风格标识符。 公开页面、用户操作、公开 API、事件、文件格式和外部集成属于产品行为，必须完整描述，但使用自然语言