| name | dev-default |
| description | 默认开发子类型规范 — 通用功能开发六阶段流程（CP1→PR-1自检→CP2→plan-review→CP3→执行→ECR执行闭环复审） |
Dev Default Skill
触发条件
dev 工作流未匹配其他子类型时的默认路径，适用于：新功能开发、接口实现、业务逻辑变更。
六阶段执行
| 阶段 | 动作 | CP 关卡 |
|---|
| N1 需求确认 | 先判定入口类型：纯新需求且无产品角色时独立保留 00-需求概况.md / 原始附件，生成并确认 01-需求确认.md；有产品角色并由产品直接提供完整需求时，以 01-产品需求.md 为 CP1 真相源，产品模板正文只给产品填写完整 PRD，AI / 研发缺口 / 冲突检查记录在 CP1 摘要、02-技术方案.md 或报告中，不生成或重写产品需求；需求变更独立保留 00-需求变更概况.md，生成 01-需求变更确认.md 并回写目标需求真相源；Bug 转 fix | CP1 确认 |
| N2 技术方案 | 架构设计、接口定义、数据流 → PR-1 内部自检（需求完整性），不通过则修正后重检；契约驱动型需求须显式引用目标文档路径/模式/契约范围 | 自检通过后 → CP2 确认 |
| N3 方案验证 | 调用 dev-plan-review Skill（PR-2~PR-7）；PR-5② 触发则继续 impact-review | 🔴 阻断时回 CP2 |
| N4 实施计划 | 任务拆分、顺序、依赖、验证与回滚 | CP3 确认 |
| N5 执行 | ExecutionContract/TestRoute 对照 → 编码实现 → 接口变更时 api-verification → document-sync | — |
| N6 ECR 执行闭环复审 | 对照 §2 核心设计、关键产物、报告、记忆、SUMMARY、diff/commit 与验证证据做执行后正式复审；默认 reviewClass=R2，控制面等高风险升 R3+清单，禁止「永远轻量」口径 | 发现阻断问题须回退修正 |
N5 执行阶段补充规则
读取前置（F-18）：修改已有文件前须先 view 当前内容，确认最新状态；同会话内已读且无并行修改的文件可跳过重复 view。
执行中变更处理（F-10）：执行阶段发现方案调整需求时，立即暂停，按 10-dev.instructions.md §变更管理 变更分级走对应流程，产物文件须在代码落地前更新。
在途缺陷绑定（F-10A）：实施前或实施中复现与当前需求相关的缺陷时，必须执行 spec-governance#InFlightIssueRequirementBindingGate；PI/PF 只做治理追踪，不能替代当前需求修订。阻断项先写回需求并提醒纳入决定；用户已明确要求一并处理或优先修复时，记录该授权后直接同步方案、验收和测试并先修复。
执行期 CP3 回退（F-26）：若 N5 执行过程中实际修改范围扩展到 CP3 门槛（文件数从 <5 增至 ≥5、临时引入高风险操作，或命中控制面/模板/validate/部署副本联动），必须暂停 source mutation，回到 N4 / CP3 补做实施计划确认后再继续。
回归扫描（F-19）：修改已有文件时，完成后须对该文件涉及的调用路径执行最小范围 grep 确认无残留引用问题；纯新增文件不触发。
统一联查矩阵（F-25）：命中控制面规则、模板、接口契约/验证产物、工作区真相源/部署副本、发布口径等高联动场景时，默认升为 L2 标准联查；若同时涉及多真相源同步或模板-示例-校验链，升级为 L3 强联查并追加交叉验证。
最小实现守门（F-27）：执行阶段必须按 CP1/CP2/CP3 的 WorkflowPlanDecisionV1.designDepth 与复杂度预算落地；minimal 只做满足已确认产品事实源和技术验证项的局部最小实现，standard 必须有真实消费者、公共契约、迁移/恢复或演进边界证据。ceremonyTier 与 assuranceLevel 不得反向扩大实现；禁止无计划新增抽象、通用配置、预留扩展点或未确认防御分支。若确需超出预算，先暂停并回 CP2/CP3。旧复杂度字段只读兼容，不得新写入。
开发偏移守门（F-28A / DevelopmentDriftGate）：进入编码前必须对照 CP1/CP2/CP3、ExecutionContract、TestRoute、消费者同步和当前 dirty 边界做一次偏移检查。至少列出 allowedFirstBatch、blockedScope、noGoItems、driftTriggers、validationRoute 和 consumerSync；若实施中触达排除范围、扩大 package/API/配置/文档消费者、引入新依赖、改变验证路线或污染工作区，先暂停并回 CP2/CP3 重新确认，不能把后续阶段能力直接并入当前批次。
必要注释守门（F-28）：非显然业务规则、状态转换、不变量、兼容约束、安全边界、外部契约映射或反直觉权衡必须保留短注释；JavaScript / Node.js 中命中必要注释的导出函数、核心业务函数、类、复杂对象契约、参数/返回/异常说明必须使用标准 JSDoc；禁止逐行解释、重复代码含义、临时 TODO 或调试注释。
通用工程吸纳守门（F-29）：CP1 起前置平台工程判断（消费者、共享契约、模块职责、维护成本、非目标）；provider/SDK 字段级合同；包工程层；依赖升级拆分业务 vs 依赖层；共享库根因优先修库；简单 service 不重复 route/model 校验。条件域审计（ExistingDomainContractAudit、ConfigOwnershipMatrix、ApiDocVerificationSync、DataMutationPlan、AbsorptionDecision、FullV1ScopeGuard、StartupPhaseTrace）按触发执行。跨项目/吸纳类守门只在本 Skill 判定触发并记录 gateGroup / ownerSkill / validationRoute / skipReason；执行正文与 legacy anchors 一律读 ../spec-governance/gate-registry.json + Owner Skill，禁止在此展开 Gate 百科。
验证卫生与串行边界（F-30） / 验证卫生与并发边界：按 ConcurrencyPolicy 执行：只读准备和隔离验证可在不共享输出目录时并行；release / pack / benchmark / codegen / package boundary 检查不得与会删除、重建或写入 dist 的命令并行；消费者验证异常时先核对 package.json / lockfile / node_modules / npm ls <关键依赖>；完成前检查并清理本轮或旧验证遗留的无关 dirty 文件。
多需求并行编排（F-30A）：N5 前若出现多个 requirement / bug / optimization / scenario-test、用户要求并行推进、子 Agent、子会话或 worktree，必须先调用 requirement-parallel-orchestration。只有 RequirementIndependenceDecisionV1.status=independent 且 ParallelLaunchCardV1 校验通过时，才允许派发隔离执行；weakly-coupled-lock 只允许并行准备 + 单写者检查点；serial-required 禁止并行 source mutation。
技术路线对比门禁（F-31）：技术路线、架构优化、性能优化、框架能力设计或高维护成本方案，在 CP1 最终需求确认前执行对比调研；若存在同类产品/项目/框架/本仓库相似模块可比，必须记录证据范围和采纳/不采纳理由；不触发时写 N/A + skipReason。
需求方输入到产品需求链路（F-31A）：需求来自业务、运营、客户、老板、内部使用方、PRD、Word、原型、截图、会议纪要或用户补充消息时，CP1 必须先判定入口类型。无产品角色 / 研发兼产品时，纯新需求将需求方原始输入独立保留为 00-需求概况.md 或等价附件，且 00-需求概况.md 必须使用口语化问题收集“你希望系统帮你做到什么、现在你们怎么凑合处理、有哪些必须遵守的业务口径、给一个希望出现的例子、给一个不能接受的例子和相关材料”；需求方允许填写“没有 / 不知道 / 暂无 / 需要产品帮忙整理”。AI 再生成 01-需求确认.md 产品需求草稿，产品补充归一化后由需求方 + 产品双方确认。有产品角色并由产品直接提供完整需求时，使用独立 01-产品需求.md / product-requirement.prompt.md，产品模板正文只给产品填写完整 PRD，产品完整写清业务目标、流程图、文字步骤、节点解释、页面交互、字段描述、业务规则、示例 / 反例与不确定点；AI / 研发不生成或重写产品需求，缺口 / 冲突检查记录在 CP1 摘要、02-技术方案.md 或报告中，确认后直接进入技术方案。需求变更使用 00-需求变更概况.md + 01-需求变更确认.md，必须锚定原需求基线、变更前后差异、影响范围、不变内容和目标真相源，并在确认后回写目标需求文件；Bug / 异常 / 已承诺行为与实际不一致转 fix 的 00-问题概况.md / 01-问题确认.md，不得混入产品需求确认模板。技术方案只能承接双方确认后的产品需求、产品直接提供的完整需求或问题确认，不得直接把原始诉求当实现口径，也不得把需求方输入模板、产品完整需求模板和 AI 生成的产品确认模板混写。
条件 Gate 索引（F-32 / F-33 / F-33A / F-34）：N5 只做触发路由，完整字段与探针见 Owner Skill / gate-registry.json。未触发写聚合 N/A + skipReason。
| 触发面 | gateGroup（代表） | ownerSkill | 记录要求 |
|---|
| 前端 UI / 交互 / Figma / preview / i18n | frontend-runtime | audit-project · test-router · 前端相关 Owner | 设计来源、还原、状态、用户流、视觉验证纳入 CP2/CP3/TestRoute/ECR |
| 浏览器预算 / 用户自验 / finding 矩阵 / 数据迁移 / package 确认前证据等 | registry 对应组（finding-review、release、requirement-profile 等） | registry ownerSkills | gateGroup / ownerSkill / validationRoute / skipReason |
| data 台账吸纳 / 用户纠偏 / 仍需吸纳清单 | absorption-layering · confirmed-completeness | spec-absorption · spec-governance | LayeredAbsorptionDecision + layerChecks；禁止继续堆通用 guard 列表 |
全工作区 data/*.md 扫描 | （WorkspaceDataAbsorptionScope） | spec-absorption | 扫描 .devcodex/*/data/ 全部命名空间 + workspace；不得只扫 sticky 项目 |
错误处理验证（F-21）：实施完成后须验证边界/异常路径（如空值/权限拒绝/超时）均有处理，不得只验证正常路径。
调试清理（F-20）：执行完成后须检查并清除 console.log / 临时注释 / TODO 标注（业务 TODO 转为 issue 跟踪）。
N6 偏离分级处理（F-04）
| 偏离类型 | 说明 | 处理方式 |
|---|
| 🟢 实现细节偏离 | 算法/结构调整，不影响接口/行为 | 记录偏离原因，继续 |
| 🟡 接口形式偏离 | 参数名/路径调整，行为不变 | 更新 api-verification，说明原因 |
| 🔴 行为/范围偏离 | 与已确认需求或技术方案功能差异 | 必须回 CP2/CP1 处理（见变更管理规则） |
长会话重锚定（F-24）：会话超过 10 轮后，N6 开始前须重新 view 01-需求确认.md / 01-产品需求.md（历史目录可用 01-需求概述.md）和 02-技术方案.md，确保复审基于最新文档而非记忆。
N6 ECR 最小清单
执行完成后、最终报告完成前必须执行 ECR（Execution Closure Review）：
| 项 | 检查对象 | 目的 |
|---|
| ECR-1 | CP1/CP2/CP3、报告、daily tasks、SUMMARY | 避免压缩后状态错配 |
| ECR-2 | 需求条款 / 问题 ID → diff/commit 文件 | 避免确认范围漏实现 |
| ECR-3 | CP3 步骤 → 测试/部署/验证证据 | 避免计划与执行漂移 |
| ECR-4 | 报告声明 → 测试/探针/官方文档 | 避免过度宣称 |
| ECR-5 | memory daily → SUMMARY | 避免 SUMMARY 早标绿 |
| ECR-6 | git dirty 边界 | 避免混入用户另案变更 |
| ECR-7 | 控制面任务追加 validate / direct replay / host-contract probe；涉及规范源、Skill、Hook、CLI、MCP、模板、部署副本、路径规则或 validate 语义时必须执行 SCV（spec-governance）；release/pack 任务追加 PackageBoundarySerialCheck 与无关残留清理证据 | 避免校验假绿、规范漂移与验证残留 |
关键规则
- 强制顺序（R12）：方案 → PR-1 自检 → 确认 CP2 → PR-2~PR-7 → CP3 → 编码。禁止跳过 PR-1 直接请确认 CP2（Stop gap
pr1-skipped / R9）；禁止 CP2 未确认就改 hooks//skills//instructions//host-projections/ 等控制面（R10 复用 checkCpGate，strict deny / safety-only 披露 cp2-unconfirmed-write）。
- 三个 CP 必须按序获得用户确认，禁止合并跳过（C02）
- PR-1 在 CP2 前做 AI 内部自检，PR-2~PR-7 在 CP2→CP3 之间做详细验证（
dev-plan-review 两阶段流程）
- 执行阶段结束后触发：
api-verification（若涉及接口）→ document-sync → ECR 执行闭环复审（N6，内部包含方案一致性验证和 ECR-1~ECR-7）
- Auto、控制面、多批次、预计 ≥10 文件或发布类任务，执行前必须调用
execution-contract；测试路线复杂或跨模块时调用 test-router
- dev 任务包含规范缺口、审查 finding、回归或其他修复目标时，调用
execution-contract 的 repair-collaboration：低风险可内联 lightweight，高风险必须 full + independent re-review；纯新增功能不触发，模型名称不参与分类
- 高联动场景不得只做单文件修改；至少要同步直接真相源与同层联动文件
impact-review 仅由 PR-5②（跨模块架构依赖变更）触发，position：plan-review 之后、CP3 之前- N4 只确认实施计划，不重复技术方案中的架构决策、接口论证和兼容性主说明；
05-实施进度.md 对小任务不是默认文书，但多批次、预计 ≥10 文件、跨轮次、阻塞、控制面联动或用户要求持续跟踪时必须启用
- 高风险控制面 / 多批次任务的 ExecutionContract 与 TestRoute 必须显式列出历史能力回归矩阵，至少写清“历史能力 → 受影响批次 → 必跑验证 → 失败回滚点”
- Node.js 项目默认运行时、CI、Profile 与 README 不低于
>=18；低于 v18 必须有业务理由、风险和验证证据
- 关键 Markdown 产物（需求 / 方案 / 实施计划 / 实施进度 / 阅读型文档 / README）必须包含
## 目录导航；.http / .cjs 不适用
- 输出报告：
reports/requirements/ 目录，遵循 report Skill 命名规则
- 测试覆盖：实现完成后确认关键路径单测
豁免项
无特殊豁免，完整走 CP1→CP2→CP3 流程。
前端体验质量门禁 · CodeTruthRequirementGate · ManualReviewEvidenceRetention · GovernanceGateRegistry · V2FormalSolutionPackage · ReviewFindingIntakeGate · FigmaHighFidelityRestorationGate · DatabaseRecordMigrationExportGate · FrontendBrowserVerificationBudgetGate · RequirementPreConfirmGate · PackageAdapterPreConfirmEvidenceGate · SkillFirstAbsorptionGate · CapabilityToSkillPromotionGate · SkillAbsorptionDecision · LayeredAbsorptionGate · ProactiveBetterAlternativeGate · commonInstruction · skill · promptTemplate · executionConsumer · validationProbe · publicDocs · deployCopy · ConfirmedAbsorptionCompletenessGates · EvolutionCapabilityControlPlaneGate · FrontendAsyncCacheRenderGate · RemoteCIParityPushGate
FigmaProductionAssetBudgetGate
