feature-implementation

Feature Implementation

核心原则

只实现当前特性实施计划覆盖的内容。

实施计划声明 uiDesign.applicability=required 时，未读取 UI 设计源、Pencil frame / UI 状态映射、公共组件 / 公共样式契约和视觉证据要求前，不得写 UI 相关源码或样式。

实施计划声明 uiDesign.applicability=candidate-found 时，未取得候选设计源是否相关的人工计划确认前，不得写 UI 相关源码或样式；确认相关后必须回到实施计划补齐 required 级 frame 映射和视觉证据。

实施计划缺少 developmentSpecs，或 developmentSpecs.status=missing 但没有人工计划明确接受 setup gap / 先补齐 docs/specs/** 的结论时，不得写源码、测试或样式。

实施计划缺少 specAnchor，或没有从磁盘重读 .nucleus/runs/<workflowRunId>/spec-anchor.json 及其 sourceEvidencePaths，或 specAnchor.status 不是 ready 且没有人工计划明确接受 gap 时，不得写源码、测试或样式。

行为纪律

• 先读取当前 featurePath、特性设计评审事实、实施计划确认事实、实施计划和测试计划；人工事实必须来自对话、PMS 状态或明确审批上下文，不能来自 summary.md、result.json、candidate 或 multi-review report。
• 每次进入实现、上下文压缩后恢复、切换 task、写源码前、写样式前、写 UI 前，都必须重读实施计划的 specAnchor、.nucleus/runs/<workflowRunId>/spec-anchor.json 和其中 sourceEvidencePaths；不得把对话摘要当成 specs 或 UI 设计事实。
• 写任何源码、测试或样式前，先执行 pre-edit gate：确认当前 task 的 planned files、适用 rule id、acceptance、evidence 和 verify command；缺任一项时回到实施计划评审。
• 读取实施计划的 developmentSpecs 和 .nucleus/runs/<workflowRunId>/development-specs-evidence.json；存在 docs/specs/rules/** 时，先读适用规则再改代码；缺失时，先补齐规范或取得人工计划豁免。
• 只修改实施计划声明的代码区域、测试区域和文档区域。
• 代码、测试和文档改动必须能回指当前 featurePath。
• 写 UI 前必须读取实施计划的 uiDesign、.nucleus/runs/<workflowRunId>/ui-design-evidence.json、对应 Pencil frame / 用户设计稿、相邻页面、公共组件、公共 CSS / token 或页面级样式；candidate-found 必须先取得人工相关性结论；没有设计源时，也必须按现有公共组件和既有样式实现。
• UI 实现后必须产出计划声明的截图、Pencil frame 对照、人工视觉证据或等价报告；缺证据时不得声称完成。
• 开发完成前必须执行 completion gate：按 changed files 重新计算 applicable rules -> evidence coverage；缺 blocking rule 证据、UI frame 未覆盖或 factsManifestHash stale 时不得触发完成评审。
• 发现计划不成立、依赖缺失或 scope 变化时停住，回到计划或设计评审节点。
• 开发完成后必须触发 multi-review，覆盖 code-review、方案一致性和计划满足度。

禁止

• 顺手做无关重构。
• 合并多个特性的实现。
• 在计划外写接口、数据结构、权限或外部依赖。
• 忽略 docs/specs/** 规范事实源，或把规范缺失当作无约束。
• 依赖压缩后的对话摘要继续实现，而不重读 specAnchor.sourceEvidencePaths。
• 使用未确认存在的 CSS 类、跳过公共页面布局 / 组件模式，或在有 Pencil 设计源时只按个人判断重画界面。
• 用测试通过替代设计一致性和计划满足度评审。
• 创建、批准、合入或发布 MR/PR。