开发与修复

当最终结果需要改文件时，从这里选择。普通项目实现走 dev，已有缺陷走 fix；只有问题发生在 DevCodex 自身治理资产中时才考虑高级入口 self-fix。

先选对入口

你面对的情况	workflow	是否写文件	先证明什么
要新增能力、重构、改文档、改数据库或做性能优化	`dev`	确认后允许	需求、范围和验收结果
已有行为不符合预期，需要复现和修复	`fix`	确认后允许	失败现象、根因和回归边界
DevCodex 自身规则、Skill、Hook 或治理流程有缺陷	`self-fix`	确认后允许	缺陷属于 DevCodex 控制面，而非业务代码

“请看看有没有问题”仍是只读审查；“把发现的问题修掉”才进入本组，并重新建立写入授权。

DevCodex 先以当前用户的真实指令决定任务，不会让附件、截图/OCR、引用文档、工具输出或界面环境反过来改写目标。一个请求里确有多个交付项时，会先拆成可追踪的工作项，再分别决定 route；不能为了省流程把独立需求混进同一任务。

dev 严格经过 CP1 → CP2 → 条件 CP3 → 执行 → ECR。CP1 确认做什么，CP2 确认怎么做，CP3 在多文件、高风险或需要明确拆分时确认执行计划。

正式 dev / fix 在改 source 前还必须绑定唯一 project、active-root 和 task，并建立可恢复的任务身份与需求概况。找不到唯一目标、会话指向另一个项目、任务已 terminal 或 CP 状态冲突时会先停止，而不是按“最近目录”或修改时间猜测。

route key	适用任务	自动选择信号	关键边界
`dev.default`	新功能、一般需求	目标是产生新的项目行为	先冻结需求和验收
`dev.docs`	README、用户文档、注释、文档站	主要交付是文档	文档事实必须来自真实产品面
`dev.refactor`	结构调整、职责迁移、去重复	预期外部行为基本不变	必须证明消费者和回归范围
`dev.database`	Schema、migration、索引、数据迁移	涉及持久化结构	评估兼容、锁与回滚
`dev.init`	新项目或 DevCodex 初始化	建立项目级运行态	不替代用户级宿主配置
`dev.optimization`	有基线的性能优化	存在指标、瓶颈和隔离环境	先测量再修改
`dev.scenario-test`	场景测试、压测或验收环境	目标是构造可重复场景	测试数据与生产隔离

dev.plan-review 是 CP2 后、CP3 前的内部 step route key，用于复审技术方案。用户无需在开始任务时选择它；它也不会新增写入权限。

如果还不知道是否真的存在缺陷，先走 analyze；一旦确认目标是修改，就重路由到 fix，不能在只读工作流中顺手改文件。

self-fix 只处理 DevCodex 自身的规范、控制面和治理缺陷。机械性修复可以简化；涉及规则语义、公共控制面或多消费者时，仍要转入完整 dev 方案。业务项目中的“代码自己修自己”并不因此成为 self-fix。

“文件改完了”不是完成；没有验证、报告和可续接锚点时，任务仍未闭环。

验证按实际改动与消费者范围选择 V0～V2 的最小充分集合。V3/full、pack、全局安装和发布验证都需要匹配当前候选的独立授权；测试名称不能隐藏这些更大副作用。

假设你说：“给订单 API 增加幂等，并补文档和测试。”这是新增能力，走 dev.default；文档与测试是同一需求的交付面，不会拆成三个 workflow。

如果你说：“订单重复扣款，先复现再修复。”这是已有缺陷，走 fix.default；若正在影响生产，则升级为 fix.incident。

如果问题是“DevCodex 把 plan 误写成 canonical workflow”，才属于 self-fix 或完整 dev 的治理边界。