核心用法
Close Loop 是一套结构化会话终结协议，在用户触发 wrap-up、close session 等指令时执行。它采用四阶段线性流程：
1. Ship State（交付状态）：固化当前工作成果，生成可发布的代码/文档/配置
2. Memory Consolidation（记忆固化）：提取关键决策、失败模式、工具使用模式，写入长期记忆索引
3. Self-Improvement（自我改进）：基于本轮表现触发元认知更新，识别可复用的解决模式
4. Publish Queue（发布队列）：输出人读报告 + 机读 JSON 双格式交付物
整个流程强制遵循 01-design-principles.md 中的执行策略与行动门控（action gates），确保高风险操作必须经过显式确认。
显著优点
- 防遗忘机制：自动捕获会话中的隐性知识，避免"做完就丢"
- 双轨输出：同时生成面向人类的 Markdown 报告和面向系统的 JSON 结构化数据
- 模块化架构：四阶段解耦，便于团队定制特定行业的收尾流程
- 安全门控：设计原则中嵌入执行策略检查，阻断危险操作自动执行
- 可审计性：每个会话的改进建议都被追踪，形成持续优化飞轮
潜在缺点与局限
- 过度结构化风险：轻量任务可能觉得流程冗长，需配置"快速模式"豁免
- 记忆噪声累积：若无定期清理策略，固化记忆可能膨胀，降低检索效率
- JSON Schema 僵化：机读格式若版本迭代，下游系统需同步升级解析器
- 单点依赖：高度依赖
components/目录完整性，文件缺失会导致流程中断
适合人群
- 需要严格交付物管理的工程团队（尤其是合规敏感行业）
- 追求会话可复现性的 AI 辅助研发工作流
- 希望建立"数字记忆"系统的长期项目维护者
- 多轮对话后常丢失上下文的复杂任务场景
常规风险
- 误触发风险：用户随口说"wrap up"可能意外终结活跃会话
- 数据泄露：固化记忆可能意外捕获敏感输入，需配合
security_level分级过滤 - 循环依赖：自我改进模块若设计不当，可能将错误模式强化而非修正
- 版本漂移：组件分散在多个
.md文件，版本不一致会导致行为异常