第 12 章：把源码串成一次真实工作流

场景：为已有项目增加一个需要安全审查的功能

下面用“新功能 + 数据库变更 + 需要安全审查”来串起 ECC 的各层。它不是固定脚本，而是一条推荐的控制流。

1. Plan：先形成可验证计划

用户触发 /plan 或直接请求复杂功能。commands/plan.md 要求重述需求、识别风险、拆解步骤，并在写代码前等待确认。需要 brownfield 规格时，委派 spec-miner；需要架构判断时，委派 architect。

2. Choose：选择 skill 与 agent

主 Agent 根据项目栈加载 backend-patterns、database-migrations、对应语言 skill 和 tdd-workflow；安全敏感任务再加入 security-review。角色委派到 planner/tdd-guide/database-reviewer，避免所有工作由一个大 prompt 承担。

3. Implement：工具调用进入 hook 管道

每次 Write/Edit/Bash 先过 PreToolUse：配置保护、tmux 检查、治理捕获、观察器等可以提醒或阻断。工具完成后，PostToolUse 进行格式化、质量门、typecheck 或构建分析。

4. Verify：把“完成”定义成证据

verification-loop 把 build、typecheck、lint、test、security scan 和 diff review 排序；code-reviewer 从新上下文检查实际 diff；security-reviewer 关注认证、输入校验、秘密、注入和权限边界。失败时交给 build-error-resolver 或相应语言 resolver，而不是直接修改测试让它变绿。

5. Remember：记录值得复用的知识

Stop/SessionEnd hook 写入 session summary，continuous-learning v2 从纠正、失败修复和重复工作中提取 project-scoped instinct。若要换 harness，使用 ecc memory handoff 交接有界上下文，而不是复制全部 transcript。

6. Improve：让成功方案回到 catalog

重复出现的模式通过 /evolve 聚类成 skill/command/agent；跨项目复用前通过 /promote 提升到 global scope。维护者再通过 skills-health、harness-audit 和测试审查它是否应进入公共 catalog。

这条链的关键不是自动化数量

ECC 的工程价值在于它把“建议”和“证据”分开：

层	对结果的承诺
skill/command	给模型和用户一套可重复步骤
agent	把复杂步骤交给窄角色
hook	在关键边界自动观察或阻断
verification	产生 build/test/security/diff 证据
memory	把结果沉淀成未来可加载知识

没有 verification，workflow 只是漂亮的 prompt；没有 memory，成功只能停留在一次对话；没有 installer 和 adapter，能力无法可靠进入不同 harness。

读者可以如何复现实验

在 ECC checkout 中先做只读检查：

node scripts/ecc.js catalog
node scripts/install-plan.js --list-profiles
node scripts/install-plan.js --profile developer --target claude --json
node scripts/ecc.js doctor --target claude
node scripts/ecc.js status --json

想观察 hook 而不写入目标，可以使用 dry-run，并阅读 hooks/README.md 的输入契约。不要在未确认目标目录和 profile 前直接对用户级目录运行 full install。

最后的心智模型

ECC = 内容 catalog
    + 委派角色
    + 生命周期自动化
    + 可解析的安装计划
    + 跨 harness 适配器
    + 有界记忆与学习
    + 安全/治理/验证

这套组合使 ECC 更接近“Agent 的开发流程与运行环境”，而不是一组孤立的提示词文件。