{"id":"68d84710-cb54-4868-91af-7b4cf8b7479c","entityType":"agent","slug":"clawhub-krislu1221-auto-coding-skill","name":"Auto Coding V3","canonicalUrl":"https://www.xpersona.co/agent/clawhub-krislu1221-auto-coding-skill","canonicalPath":"/agent/clawhub-krislu1221-auto-coding-skill","generatedAt":"2026-10-09T14:52:50.525Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-09T07:12:56.736Z","emptyReason":null},"description":"智能自主编码系统 v3.7.17-compliance — 全子代理架构 + 分阶段技能注入。支持 8 步循环、Reviewer 否决权、复杂度自动分级、Risk Scorecard 量化检测。触发词: auto-coding, Auto coding, 启动自动编码 Skill: Auto Coding V3 Owner: krislu1221 Summary: 智能自主编码系统 v3.7.17-compliance — 全子代理架构 + 分阶段技能注入。支持 8 步循环、Reviewer 否决权、复杂度自动分级、Risk Scorecard 量化检测。触发词: auto-coding, Auto coding, 启动自动编码 Tags: latest:3.7.17 Version history: v3.7.17 | 2026-06-09T12:24:38.086Z | auto Auto-Coding Skill v3.7.17 - Compliance version bump and documentation updates (now v3.7.17-compliance). - Updated design and feature documentation in SKILL.m","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 3.7K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s1722js5hsngdpp170necz8fgn83r9q4:auto-coding-skill","sourceUrl":"https://clawhub.ai/krislu1221/auto-coding-skill","homepage":"https://clawhub.ai/krislu1221/skills/auto-coding-skill","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/krislu1221/auto-coding-skill","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/krislu1221/skills/auto-coding-skill","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":71,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"智能自主编码系统 v3.7.17-compliance — 全子代理架构 + 分阶段技能注入。支持 8 步循环、Reviewer 否决权、复杂度自动分级、Risk Scorecard 量化检测。触发词: auto-coding, Auto coding, 启动自动编码 Skill: Auto Coding V3 Own"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T07:12:56.736Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T07:12:56.736Z","emptyReason":null},"stars":null,"forks":null,"downloads":3687,"packageName":null,"latestVersion":"3.7.17","tractionLabel":"3.7K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T07:12:56.736Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T07:12:56.736Z","lastCrawledAt":"2026-10-09T07:12:56.736Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T07:12:56.736Z","lastVerifiedAt":null,"highlights":[{"version":"3.7.17","createdAt":"2026-06-09T12:24:38.086Z","changelog":"Auto-Coding Skill v3.7.17 - Compliance version bump and documentation updates (now v3.7.17-compliance). - Updated design and feature documentation in SKILL.md, clarifying sub-agent rules and coding disciplines. - Improved consistency and clarity in project overview, phase descriptions, and safety transparency sections. - No functional or architectural changes; changes are documentation and metadata only.","fileCount":47,"zipByteSize":171193},{"version":"3.7.16","createdAt":"2026-06-09T12:22:28.104Z","changelog":"Auto-Coding Skill v3.7.16 — Emphasizes compliance, safer defaults, and clearer progress/reporting. - Updated SKILL.md: Enhanced security coverage, clarified compliance defaults, and updated description/trigger phrases. - Progress reporting refined: Now foreground per-phase output is default, with background cron/notifications opt-in only. - Approval rules restricted: Default auto-approval narrowed; sensitive actions require explicit confirmation. - `.auto-coding/state.json` now only stores minimal resumable summaries; instructs users to `.gitignore` state files. - Documentation and policy clarified regarding external operations, notification channels, and allowed file system actions. - Removed obsolete `skill-card.md` file.","fileCount":47,"zipByteSize":171306},{"version":"3.7.15","createdAt":"2026-05-26T08:53:16.036Z","changelog":"- Added clarification for model adaptation: each phase should re-adapt its model configuration and use multi-model cross-validation to avoid blind spots. - Provided new bilingual note under the 8-step cycle about recommended model usage strategies. - No structural or functional changes to the system; documentation update only.","fileCount":47,"zipByteSize":171253},{"version":"3.7.14","createdAt":"2026-05-26T08:49:51.847Z","changelog":"**Changelog for auto-coding-skill v3.7.14** - Added DESIGN.md to provide explicit design philosophy and bilingual (中/EN) system overview. - Added publish_clawhub.sh script for streamlined publishing or deployment. - Completely reworked SKILL.md intro: now includes concise Chinese/English dual-language system summary and core concepts (\"概述 / Overview\" and \"Design Philosophy\"). - No change to core workflow — documentation is now clearer and more accessible for all audiences.","fileCount":47,"zipByteSize":171096},{"version":"3.7.13","createdAt":"2026-05-26T07:55:18.219Z","changelog":"v3.7.13: remove PII leak, update version","fileCount":45,"zipByteSize":164781},{"version":"3.7.12","createdAt":"2026-05-25T11:13:56.787Z","changelog":"v3.7.12 compliance: removed cron self-monitoring, tightened approval defaults, added permission declaration & user warnings, removed karpathy trigger, notify_on_complete defaults false","fileCount":44,"zipByteSize":166301},{"version":"3.7.11","createdAt":"2026-05-24T16:11:45.393Z","changelog":"v3.7.11: fix ClawHub display name","fileCount":46,"zipByteSize":172408},{"version":"3.7.10","createdAt":"2026-05-24T15:49:16.809Z","changelog":"v3.7.10: clean publish — no cosmetic renames, original field names restored","fileCount":46,"zipByteSize":172411}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s1722js5hsngdpp170necz8fgn83r9q4:auto-coding-skill","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-krislu1221-auto-coding-skill/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-krislu1221-auto-coding-skill/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-krislu1221-auto-coding-skill/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-krislu1221-auto-coding-skill/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-krislu1221-auto-coding-skill/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-krislu1221-auto-coding-skill/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-09T14:52:50.521Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-krislu1221-auto-coding-skill/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-krislu1221-auto-coding-skill/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-krislu1221-auto-coding-skill/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-krislu1221-auto-coding-skill/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-09T07:12:56.736Z","emptyReason":null},"readme":"Skill: Auto Coding V3\n\nOwner: krislu1221\n\nSummary: 智能自主编码系统 v3.7.17-compliance — 全子代理架构 + 分阶段技能注入。支持 8 步循环、Reviewer 否决权、复杂度自动分级、Risk Scorecard 量化检测。触发词: auto-coding, Auto coding, 启动自动编码\n\nTags: latest:3.7.17\n\nVersion history:\n\nv3.7.17 | 2026-06-09T12:24:38.086Z | auto\n\nAuto-Coding Skill v3.7.17\n\n- Compliance version bump and documentation updates (now v3.7.17-compliance).\n- Updated design and feature documentation in SKILL.md, clarifying sub-agent rules and coding disciplines.\n- Improved consistency and clarity in project overview, phase descriptions, and safety transparency sections.\n- No functional or architectural changes; changes are documentation and metadata only.\n\nv3.7.16 | 2026-06-09T12:22:28.104Z | auto\n\nAuto-Coding Skill v3.7.16 — Emphasizes compliance, safer defaults, and clearer progress/reporting.\n\n- Updated SKILL.md: Enhanced security coverage, clarified compliance defaults, and updated description/trigger phrases.\n- Progress reporting refined: Now foreground per-phase output is default, with background cron/notifications opt-in only.\n- Approval rules restricted: Default auto-approval narrowed; sensitive actions require explicit confirmation.\n- `.auto-coding/state.json` now only stores minimal resumable summaries; instructs users to `.gitignore` state files.\n- Documentation and policy clarified regarding external operations, notification channels, and allowed file system actions.\n- Removed obsolete `skill-card.md` file.\n\nv3.7.15 | 2026-05-26T08:53:16.036Z | auto\n\n- Added clarification for model adaptation: each phase should re-adapt its model configuration and use multi-model cross-validation to avoid blind spots.\n- Provided new bilingual note under the 8-step cycle about recommended model usage strategies.\n- No structural or functional changes to the system; documentation update only.\n\nv3.7.14 | 2026-05-26T08:49:51.847Z | auto\n\n**Changelog for auto-coding-skill v3.7.14**\n\n- Added DESIGN.md to provide explicit design philosophy and bilingual (中/EN) system overview.\n- Added publish_clawhub.sh script for streamlined publishing or deployment.\n- Completely reworked SKILL.md intro: now includes concise Chinese/English dual-language system summary and core concepts (\"概述 / Overview\" and \"Design Philosophy\").\n- No change to core workflow — documentation is now clearer and more accessible for all audiences.\n\nv3.7.13 | 2026-05-26T07:55:18.219Z | user\n\nv3.7.13: remove PII leak, update version\n\nv3.7.12 | 2026-05-25T11:13:56.787Z | user\n\nv3.7.12 compliance: removed cron self-monitoring, tightened approval defaults, added permission declaration & user warnings, removed karpathy trigger, notify_on_complete defaults false\n\nv3.7.11 | 2026-05-24T16:11:45.393Z | user\n\nv3.7.11: fix ClawHub display name\n\nv3.7.10 | 2026-05-24T15:49:16.809Z | user\n\nv3.7.10: clean publish — no cosmetic renames, original field names restored\n\nv3.7.9 | 2026-05-24T15:22:54.776Z | user\n\nv3.7.9: Fix SkillSpector — replace password example terms in skill files, document override design in SECURITY.md\n\nv3.7.8 | 2026-05-24T13:14:57.896Z | user\n\nv3.7.8: Fix ROUNDTable_MODELS comment that SkillSpector scans as hidden env var\n\nv3.7.7 | 2026-05-24T11:12:14.417Z | user\n\nv3.7.7: Remove all email PII traces\n\nv3.7.6 | 2026-05-24T09:37:51.297Z | user\n\nv3.7.6: Fix SkillSpector — __import__ removal, ROUNDTable_MODELS→AUTO_CODING_MODELS, env vars documented\n\nv3.7.5 | 2026-05-24T08:10:03.170Z | user\n\nv3.7.5: Remove karpathy from triggers. Fix ClawHub security audit — add SECURITY.md, tighten triggers, sanitize subprocess.\n\nv3.7.4 | 2026-05-24T08:05:26.810Z | user\n\nv3.7.4: Fix ClawHub security audit — add SECURITY.md, tighten triggers (remove 写代码/开发/coding), add security/data_privacy fields, sanitize subprocess inputs, sync version\n\nv3.7.3 | 2026-05-23T14:52:52.537Z | user\n\nv3.7.3: 重写 SKILL.md，完整设计理念 + Pro→Flash 双层路由 + Skill Injector + Risk Scorecard + Task Profiler 架构说明\n\nv3.7.2 | 2026-05-23T14:20:58.289Z | user\n\nv3.7.2: 用 AST 安全求值器替代 eval()，消除 ClawHub 静态分析告警\n\nv3.7.1 | 2026-05-23T14:16:47.619Z | user\n\nv3.7.1: fix display name\n\nv3.7.0 | 2026-05-23T14:13:31.124Z | user\n\nv3.7: 全子代理架构 + Risk Scorecard + 12技能模块化注入 + Reviewer 否决权 + 复杂度分级\n\nv2.1.2 | 2026-04-25T14:32:26.135Z | auto\n\nauto-coding-correctversion 2.1.2\n\n- Removed usage guide and test files (`USAGE.md`, `tests/test_decomposer.py`, `tests/test_worker.py`)\n- SKILL.md updated; some version and capability descriptions adjusted\n- Updated `delivery_check.py` with changes not detailed here\n\nv2.1.1 | 2026-04-25T14:27:30.570Z | auto\n\nauto-coding-correctversion v2.1.1\n\n- Updated documentation in README.md for clarity and completeness.\n- Minor metadata or configuration adjustments in clawhub.json.\n- No changes to code logic or features.\n\nv2.1.0 | 2026-04-25T14:19:29.949Z | auto\n\nauto-coding-correctversion v2.1.0\n\n- Updated clawhub.json file.\n- No user-facing features or documentation changes in this release.\n\nv2.0.0 | 2026-04-25T14:15:11.597Z | auto\n\nAuto-Coding Skill v2.0.0\n\n- Major refactor and redesign of skill structure, with extensive file reorganization and replacement.\n- Adds comprehensive documentation and usage guides: USAGE.md, DECOMPOSER_DESIGN.md, OPTIMIZATION_SUMMARY.md, and more.\n- Introduces decomposer.py (需求拆解器), deep_analysis.py, delivery_check.py, and significant new workflow scripts.\n- Migrates to a new worker-based architecture and completely replaces old workflow and manager scripts.\n- Updates metadata and dependency installation instructions to support nanobot ecosystem.\n- Removes legacy files related to the old agent-based implementation.\n\nv1.1.0 | 2026-03-20T06:49:16.024Z | user\n\nAuto-Coding Skill v1.1.0 – 上下文管理增强版\n\n- 增强上下文管理，提升多 Agent 代码开发过程中的信息追踪与流程一致性。\n- 新增/调整文档说明，增加 CHANGELOG 和 P0/P1 修复报告文档，聚合常用信息至 README.md。\n- 移除原有的完整版说明和安全审计文档，精简文档结构。\n- 保持“八步循环流程”开发主流程不变。\n\nv3.1.3 | 2026-03-19T16:49:34.195Z | user\n\nVersion 3.1.3\n\n- 增加了“安全说明”章节，详细说明了数据流向和权限边界。\n- 明确列出不读取敏感信息、不访问网络、不修改系统文件、不直接执行 shell 命令等限制。\n- 强化了数据安全与权限说明，便于用户了解使用范围和风险。\n- 其它内容保持不变，仅文档补充，无功能和代码变更。\n\nv3.1.2 | 2026-03-19T16:15:12.765Z | user\n\n**Auto-Coding v3.1.2 Changelog**\n\n- Major refactor: migrated to an 8-step, multi-Agent workflow with new core structure and documentation.\n- Added: Comprehensive guides and reference docs (README-FULL.md, DEPLOYMENT.md, SECURITY-AUDIT.md, PACKAGE-MANIFEST.md).\n- Added: New workflow modules (auto_coding_workflow.py, agent_soul_loader.py, dependency_manager.py, model_selector.py).\n- Removed: Legacy files including old core modules, prompts, tests, and configuration (e.g., agent_controller.py, auto_coding_worker.py, requirements.txt, cross_model_validator.py).\n- Simplified and clarified SKILL.md to reflect the new eight-step cycle and updated usage recommendations.\n- Multi-Agent flow and modular design replaces previous single-worker, cross-validation infrastructure.\n\nv3.1.1 | 2026-03-15T19:30:14.522Z | user\n\n**auto-coding-correctversion v3.1.1**\n\n- Added CHANGELOG.md file.\n\nv3.1.0 | 2026-03-15T19:22:03.211Z | user\n\nAuto-Coding v3.1.0\n\n- Introduced new core modules: agent_evolution.py, auto_coding_worker.py, cross_model_validator.py, model_validator.py, project_manager.py, self_reflection.py, and task_decomposer.py to enhance multi-agent capabilities and testing.\n- Added LICENSE and requirements.txt for proper licensing and dependency management.\n- Reorganized testing with tests/test_core_components.py; removed obsolete test_auto_coding.py.\n- Improved system structure to support advanced features such as cross-model validation, automatic task decomposition, self-reflection, and enhanced project management.\n- Aligned documentation and configuration with new modules and workflow.\n\nv1.2.1 | 2026-03-13T19:41:44.735Z | user\n\n- Clarified that the security allowlist in documentation is a reference implementation, not enforced by the skill itself.\n- Added notes explaining actual security enforcement depends on the OpenClaw Gateway runtime.\n- No functional or code changes; documentation improvements only.\n\nv1.2.0 | 2026-03-13T19:26:15.685Z | user\n\nAuto-Coding Skill 1.2.0\n\n- Major update to documentation with new SKILL.md, providing a complete project overview, features, architecture, security details, usage, and testing instructions.\n- Added clear command usage examples for both English and Chinese.\n- Expanded and documented security sandbox with specific allowed and blocked commands.\n- Detailed known limitations and environment configuration guidance.\n- Enhanced project transparency with authorship, licensing, and detailed module structure.\n\nArchive index:\n\nArchive v3.7.17: 47 files, 171193 bytes\n\nFiles: __init__.py (1226b), agent_soul_loader.py (16780b), approval_rules.py (8913b), auto_coding_workflow.py (50300b), CHANGELOG.md (19341b), check_auto_coding_status.py (6961b), clawhub.json (759b), complexity_analyzer.py (7110b), configs/scorecard.yaml (4746b), configs/verification-rules.yaml (8326b), dependency_manager.py (15348b), DESIGN.md (10500b), feishu_notifier.py (9244b), model_selector.py (12617b), PROJECT.md (9258b), prompts/coordinator.md (3029b), prompts/worker_engineering.md (2381b), publish_clawhub.sh (1530b), README-FULL.md (11761b), README.md (5705b), scorecard_engine.py (30533b), skill_injector.py (8791b), skill-card.md (2479b), SKILL.md (12366b), skills/code-review.skill.md (5220b), skills/decomposition.skill.md (4587b), skills/diagnose.skill.md (4914b), skills/discipline-meta.skill.md (5064b), skills/grill-with-docs.skill.md (4835b), skills/improve-architecture.skill.md (5136b), skills/optimize.skill.md (4690b), skills/risk-scorecard.skill.md (9529b), skills/tdd.skill.md (5013b), skills/testing.skill.md (4983b), skills/verification.skill.md (5318b), skills/zoom-out.skill.md (3766b), state_manager.py (16485b), task_manager.py (4477b), task_profiler.py (17034b), workers/__init__.py (393b), workers/base_worker.py (13056b), workers/engineering_worker.py (7492b), workers/reviewer_worker.py (8812b), workers/testing_worker.py (7620b), workflow_config.py (11842b), workflow_enhanced.py (62401b), _meta.json (137b)\n\nFile v3.7.17:SKILL.md\n\n---\nname: auto-coding-v3\ndescription: \"智能自主编码系统 v3.7.17-compliance — 全子代理架构 + 分阶段技能注入。支持 8 步循环、Reviewer 否决权、复杂度自动分级、Risk Scorecard 量化检测。触发词: auto-coding, Auto coding, 启动自动编码\"\nlicense: MIT\n---\n\n# Auto-Coding v3.7.17-compliance\n\n## 概述 / Overview\n\nAuto-Coding 是一个智能自主编码系统，通过全子代理架构 + 分阶段技能注入，完成从需求到代码的完整开发流程。\n\nAuto-Coding is an intelligent autonomous coding system that completes the full development lifecycle from requirements to code through a fully sub-agent architecture with staged skill injection.\n\n**本质**: 单进程串行 + 多角色 Prompt + 多模型切换。每一步换不同的人格和模型来审视代码，不是真正的多 Agent 并行。\n\n**Essence**: Single-process serial execution + multi-role prompting + multi-model switching. Each step uses a different persona and model to review the code — not true multi-agent parallelism.\n\n**核心特性**:\n- 全子代理架构 — 主会话只做监工，所有干活用子代理执行\n- 分阶段技能注入 — 每阶段注入对应技能文件，≤2 技能/阶段\n- 8 步循环 — 设计→分解→编码→测试→反思→优化→验证→输出\n- Reviewer 否决权 — 审查发现 🔴 阻塞项触发重写，最多 3 次迭代\n- 复杂度自动分级 — A (Micro) / B (Feature) / C (System)，自动跳过不需要的阶段\n- Risk Scorecard — 五元组量化检测，公用信号识别\n- 状态持久化 — `.auto-coding/state.json`，仅保存任务恢复所需摘要，session 断了可恢复\n- 审批策略 — `.auto-coding/rules.yaml`，默认收窄自动批准范围，敏感操作必须确认\n- 进度汇报 — 默认前台逐阶段输出；可选开启通知或调度检查，默认不创建后台 cron\n\n**Key features**:\n- Full sub-agent architecture — main session only supervises; all work delegated to sub-agents\n- Staged skill injection — each phase injects corresponding skill files, ≤2 skills per phase\n- 8-step cycle — Design → Decompose → Code → Test → Reflect → Optimize → Verify → Output\n- Reviewer veto power — 🔴 blockers trigger rewrite, up to 3 iterations\n- Auto complexity grading — A (Micro) / B (Feature) / C (System), auto-skip irrelevant phases\n- Risk Scorecard — 5-tuple quantified detection with public signal recognition\n- State persistence — `.auto-coding/state.json`, stores resumable task summaries only\n- Approval rules — `.auto-coding/rules.yaml`, narrow default auto-approval and require confirmation for sensitive actions\n- Progress reporting — foreground per-phase output by default; optional notification/scheduler check only when explicitly enabled\n\n---\n\n## 设计哲学 / Design Philosophy\n\n1. **思考优先** — 不假设，模糊需求列出假设或直接提问\n2. **极简主义** — 最少代码解决问题，自检\"200 行能否缩到 50 行\"\n3. **手术刀修改** — 只改必须改的，不顺手重构，遵循现有风格\n4. **目标导向** — 先定义 Done 标准再编码，验证通过才算完成\n\n1. **Think first** — Don't assume; list assumptions for ambiguous requirements or ask directly\n2. **Minimalism** — Solve with minimal code; self-check \"can 200 lines shrink to 50?\"\n3. **Scalpel edits** — Only change what's necessary; don't refactor opportunistically; follow existing style\n4. **Goal-oriented** — Define Done criteria before coding; verification pass = completion\n\n---\n\n## 🔴 执行铁律\n\n### 铁律 1: 自动推进，不中途停下\n启动后连续完成所有阶段。只在 3 种情况打断: (1) 需求不明确 (2) 多方案需选择 (3) 安全审批。\n\n### 铁律 2: 全子代理化，主会话只做监工\n所有干活用子代理执行。主会话职责: 分阶段派活、检查文件质量、打回重写、交付结果。\n\n### 铁律 3: 每步输出，不攒到最后\n每阶段完成后立刻在当前会话输出结果（当前阶段、模型、做了什么、发现了什么），然后直接进入下一阶段。这是默认进度汇报机制，避免依赖后台 cron 或外部通知。\n\n---\n\n## 📋 8 步循环流程 + 技能注入\n\n```\n设计 → 分解 → 编码 → 测试 → 反思 → 优化 → 验证 → 输出\n  ↑_______________________________________↓\n              迭代 (最多 3 次)\n```\n\n| 步骤 | 阶段 | 注入技能 | 模型 | 职责 |\n|------|------|---------|------|------|\n| 1 | **设计** | `grill-with-docs` | `deepseek-v4-pro` | 需求对齐、技术方案 |\n| 2 | **分解** | `decomposition` | `deepseek-v4-pro` | 任务拆解、依赖分析 |\n| 3 | **编码** | `tdd` | `deepseek-v4-pro` | TDD 红-绿-重构 |\n| 4 | **测试** | `testing` | `deepseek-v4-pro` | 边界覆盖、回归检测 |\n| 5 | **反思** | `zoom-out` + `code-review` | `deepseek-v4-pro` | 审查、🔴🟡💭 分级 |\n| 6 | **优化** | `optimize` | `deepseek-v4-pro` | 推理重构 |\n| 7 | **验证** | `verification` | `deepseek-v4-pro` | 交付验证 |\n| 8 | **输出** | — | — | 交付物 |\n\n> **注入规则**: 每阶段 ≤2 技能文件，全局文件（`risk-scorecard` + `discipline-meta`）随首次注入附带。注入失败不阻塞流程。\n>\n> **Reviewer 否决权**: 审查发现 🔴 阻塞项（安全漏洞、不符合需求、过度设计）→ 触发重写，最多 3 次迭代。\n> 详细见: `skills/code-review.skill.md`\n>\n> **调试子流程**: 测试失败或否决时触发 6 阶段调试（反馈循环→复现→假设→插桩→修复→清理）。\n> 详细见: `skills/diagnose.skill.md`\n>\n> **模型适配**: 各阶段模型应根据自身模型配置进行重新适配，推荐采用多模型交叉检测与验证的方式，避免单一模型盲区。\n>\n> **Model adaptation**: Each phase's model should be re-adapted based on available model configuration. Multi-model cross-validation is recommended over single-model detection to avoid blind spots.\n\n---\n\n## ⚡ 复杂度自动分级\n\n| 等级 | 特征 | 阶段数 | 典型耗时 |\n|------|------|--------|---------|\n| **A (Micro)** | 单函数、Bug 修复 | 编码→测试→验证 (3) | <2 分钟 |\n| **B (Feature)** | 模块开发、单 API | 设计→编码→测试→验证 (4) | 2-5 分钟 |\n| **C (System)** | 完整系统、多文件重构 | 设计→分解→编码→测试→反思→优化→验证 (7) | 5-15 分钟 |\n\n> A 级至少注入 `grill-with-docs`（需求确认部分）。连续 2 次阻塞自动升级为 B 级。\n\n---\n\n## 🤖 模型分配 + 降级\n\n| 阶段 | 首选 | Fallback 1 | Fallback 2 |\n|------|------|-----------|-----------|\n| 设计/分解 | `deepseek-v4-pro` | `MiMo v2.5 Pro` | — |\n| 编码/测试 | `deepseek-v4-pro` | `MiMo v2.5 Pro` | — |\n| 审查/优化 | `deepseek-v4-pro` | `MiMo v2.5 Pro` | — |\n| 验证 | `deepseek-v4-pro` | `MiMo v2.5 Pro` | — |\n\n**降级原则**: 优先同级别 → 降一级 → 记入日志。\n\n---\n\n## 📝 子代理铁律\n\n所有子代理禁止输出完整内容到对话:\n\n```\n✅ {阶段}完成\n📄 输出文件: {file1}, {file2}, ...\n💡 一句话结论: {核心结论}\n```\n\n---\n\n## 🧠 编码纪律（精简）\n\n1. **思考优先**: 不假设，模糊需求列出假设或直接提问\n2. **极简主义**: 最少代码解决问题，自检\"200 行能否缩到 50 行\"\n3. **手术刀修改**: 只改必须改的，不顺手重构，遵循现有风格\n4. **目标导向**: 先定义 Done 标准再编码，验证通过才算完成\n\n---\n\n## 📁 技能文件索引\n\n| 技能文件 | 注入阶段 | 职责 |\n|---------|---------|------|\n| `skills/grill-with-docs.skill.md` | Step 1 设计 | 需求对齐、结构化追问、CONTEXT.md 维护 |\n| `skills/decomposition.skill.md` | Step 2 分解 | 任务拆解纪律、依赖分析、粒度检查 |\n| `skills/tdd.skill.md` | Step 3 编码 | TDD 红-绿-重构循环、垂直切片规则 |\n| `skills/testing.skill.md` | Step 4 测试 | 测试策略、边界覆盖、回归检测 |\n| `skills/zoom-out.skill.md` | Step 5 反思 | 全局视角、跨模块依赖分析 |\n| `skills/code-review.skill.md` | Step 5 反思 | Reviewer 审查、🔴🟡💭 分级、Reviewer 否决权 |\n| `skills/optimize.skill.md` | Step 6 优化 | 重构纪律、性能优化检查清单 |\n| `skills/verification.skill.md` | Step 7 验证 | 交付验证清单、阶段聚合 |\n| `skills/diagnose.skill.md` | 调试子流程 | 6 阶段系统化调试 |\n| `skills/improve-architecture.skill.md` | Step 8.5 | 架构健康检查、深层耦合发现 |\n| `skills/risk-scorecard.skill.md` | 全局（首次附带） | Risk Scorecard 五元组、公用信号检测规则 |\n| `skills/discipline-meta.skill.md` | 全局（首次附带） | 元规则、量化上限、override 流程 |\n\n---\n\n## ⚠️ 安全透明声明\n\n### 进度汇报策略\n\n默认情况下，Auto-Coding **不创建后台 cron**，也**不主动发送飞书消息**。进度通过当前会话逐阶段输出：每完成一个阶段立即报告阶段名、产物、发现的问题和下一步。\n\n如用户明确要求“后台跑完通知我 / 开启进度检查”，才启用可选通知机制：\n\n| 模式 | 默认状态 | 数据流向 | 说明 |\n|------|---------|---------|------|\n| 前台逐阶段输出 | ✅ 默认开启 | 当前会话 | 每阶段完成后直接汇报，不产生后台任务 |\n| 终态通知 | ❌ 默认关闭 | 用户指定通知通道 | 仅发送任务标题、任务 ID、阶段摘要和完成状态 |\n| 调度检查 | ❌ 默认关闭 | 宿主调度器 | 仅在用户显式 opt-in 时创建；任务结束后自动删除，并提供手动清理指引 |\n\n### 外部操作\n\n| 操作 | 默认状态 | 数据流向 | 说明 |\n|------|---------|---------|------|\n| 模型推理 | 按宿主配置 | 任务描述 / 必要代码上下文 → 宿主模型服务 | 不读取或发送 API 密钥；具体模型网络路径由宿主环境决定 |\n| 外部通知 | 默认关闭 | 阶段摘要 / 完成状态 → 用户指定通道 | 仅在用户显式开启时使用 |\n| 环境配置 | 可选 | 本地配置 → 模型选择 | 仅读取非密钥模型选择项；不读取 `apiKey`、`baseUrl`、token 等敏感字段 |\n\n### 文件系统\n\n| 操作 | 范围 | 说明 |\n|------|------|------|\n| 读取 | 当前项目目录 | 读取需求相关代码、测试、配置和依赖文件 |\n| 写入代码 | 当前项目目录 | 仅修改任务相关文件；敏感路径需审批 |\n| 状态目录 | `.auto-coding/` | 保存 `state.json`、阶段摘要日志、审批状态和 scratchpad，用于恢复与审计 |\n\n`.auto-coding/` 可能包含任务描述、文件路径、阶段摘要、测试结果和局部代码片段。建议将其加入 `.gitignore`，避免误提交；任务完成后可删除该目录清理本地状态。\n\n### 模型环境变量\n\n```\nAUTO_CODING_MODEL_DESIGN=...     # 设计阶段模型覆盖\nAUTO_CODING_MODEL_DECOMPOSE=...  # 分解阶段模型覆盖\nAUTO_CODING_MODEL_CODE=...       # 编码阶段模型覆盖\nAUTO_CODING_MODEL_TEST=...       # 测试阶段模型覆盖\nAUTO_CODING_MODEL_REVIEW=...     # 审查阶段模型覆盖\nAUTO_CODING_MODEL_OPTIMIZE=...   # 优化阶段模型覆盖\nAUTO_CODING_MODEL_VERIFY=...     # 验证阶段模型覆盖\nAUTO_CODING_FALLBACK_MODEL_1=... # 回退模型 1\nAUTO_CODING_FALLBACK_MODEL_2=... # 回退模型 2\n```\n\n> 所有环境变量均为可选，只用于模型选择或降级策略，不应包含 API 密钥、Base URL、token 或其它敏感配置。\n\n---\n\n## 📦 使用示例\n\n- **A 级**: `auto-coding：写一个 Python 函数计算两个列表的交集` → 编码→测试→验证\n- **B 级**: `Auto coding：实现一个 REST API，支持用户注册和登录` → 设计→编码→测试→验证\n- **C 级**: `启动自动编码：从零搭建一个博客系统，支持文章发布和评论` → 完整 7 阶段\n\n---\n\n## ⚙️ 项目配置\n\n- **状态持久化**: `.auto-coding/state.json` — session 中断自动从上次阶段恢复\n- **审批策略**: `.auto-coding/rules.yaml` — 默认仅自动批准文档类低风险修改；代码修改、命令执行和敏感路径默认要求确认\n- **阶段日志**: `.auto-coding/logs/{order}-{phase}.log` — 每个阶段独立可追溯，建议不提交到版本库\n\n---\n\n*v3.7.17-compliance · 2026-06-09*\n\nFile v3.7.17:README.md\n\n# Auto-Coding v3.7.17\n\n**版本**: v3.7.17  \n**更新日期**: 2026-06-09\n\n---\n\n## 概述\n\nAuto-Coding 是一个智能自主编码系统，通过多角色 Soul + 多模型切换，完成从需求到代码的完整开发流程：\n\n```text\n设计 → 分解 → 编码 → 测试 → 反思 → 优化 → 验证 → 输出\n```\n\n**本质**：单进程串行 + 多角色 Prompt + 多模型切换。不是真正的多 Agent 并行，而是每一步换不同的人格和模型来审视代码。\n\n## 触发方式\n\n为避免误触发高权限编码流程，ClawHub 版仅建议使用以下明确触发词：\n\n- `auto-coding`\n- `Auto coding`\n- `启动自动编码`\n\n不要用泛化词如“写代码”“开发”“coding”作为自动触发词。\n\n---\n\n## 合规版核心调整\n\n### 1. 进度汇报：默认前台汇报，不默认创建 cron\n\nAuto-Coding 任务步骤多，确实需要持续汇报。合规版采用三层策略：\n\n| 层级 | 默认状态 | 用途 | 合规边界 |\n| --- | --- | --- | --- |\n| 当前会话逐阶段输出 | ✅ 默认开启 | 每阶段完成后立即报告阶段、产物、风险和下一步 | 不创建后台任务，不外发消息 |\n| 状态文件恢复 | ✅ 默认开启 | session 中断后从 `.auto-coding/state.json` 恢复 | 仅写本地项目目录 |\n| 后台调度 / 外部通知 | ❌ 默认关闭 | 用户离开会话后需要终态通知或进度检查 | 必须用户显式 opt-in，任务结束后清理 |\n\n因此，不做默认 cron 并不等于没有进度：**前台执行时每一步都会汇报**。只有当用户明确说“后台跑完通知我 / 开启进度检查”时，才建议由宿主环境创建可清理的调度任务。\n\n### 2. 飞书 / 外部通知：默认关闭，显式开启\n\n飞书通知不是默认行为。启用后只发送最小必要摘要：任务标题、任务 ID、当前阶段、完成状态、少量阶段摘要。不会发送 API Key、token、完整代码或大段上下文。\n\n### 3. 状态、日志、scratchpad\n\nAuto-Coding 会在项目内写入 `.auto-coding/`，用于恢复、审批和审计。可能包含：\n\n- `state.json`：任务 ID、阶段状态、完成状态、时间戳。\n- `logs/`：阶段摘要、测试结果、风险评分。\n- `pending_approval.json`：等待用户确认的操作。\n- scratchpad / output：中间推理摘要或交付摘要。\n\n合规建议：\n\n- `.auto-coding/` 已加入 `.gitignore`。\n- 不应提交 `.auto-coding/` 到远程仓库。\n- 任务完成后可删除 `.auto-coding/` 清理本地状态。\n\n### 4. 自动批准策略收窄\n\n默认仅自动批准低风险文档变更：\n\n```yaml\nauto_approve:\n  edit:\n    - \"docs/*\"\n    - \"*.md\"\n  run: []\n  create:\n    - \"docs/*\"\n    - \"*.md\"\n```\n\n以下操作默认需要确认：\n\n- 修改代码文件：`*.py`、`*.js`、`*.ts`、`src/*`、`tests/*` 等。\n- 修改配置、CI、环境文件。\n- 删除任何文件。\n- 运行任何命令，包括测试和构建命令。\n\n### 5. 表达式求值与命令执行\n\n- 风险阈值表达式使用 AST 白名单解释器，不使用动态代码执行。\n- 技能默认不通过 CLI 创建 cron，也不默认执行外部命令。\n- 需要运行测试、构建、发布、调度等命令时，必须经审批规则确认。\n\n---\n\n## 快速开始\n\n```python\nimport asyncio\nfrom workflow_enhanced import AutoCodingWorkflowEnhanced\n\nasync def main():\n    workflow = AutoCodingWorkflowEnhanced(\n        requirements=\"auto-coding：实现用户登录功能\",\n        project_dir=\"./my-project\",\n        resume=True,\n    )\n    await workflow.run()\n\nasyncio.run(main())\n```\n\n第一次运行会生成配置模板：\n\n- `.auto-coding/workflow.yaml.template`\n- `.auto-coding/rules.yaml.template`\n\n复制为实际配置后即可自定义阶段和审批策略。\n\n---\n\n## 文件清单\n\n| 文件 | 说明 |\n| --- | --- |\n| `auto_coding_workflow.py` | 主工作流（八步循环） |\n| `workflow_enhanced.py` | 增强版（状态 + 审批 + 前台进度汇报） |\n| `workers/base_worker.py` | Worker 基类（含模型调用） |\n| `workers/reviewer_worker.py` | ReviewerWorker（否决权） |\n| `approval_rules.py` | 审批规则引擎，默认收窄 auto-approve |\n| `scorecard_engine.py` | 风险评分与阈值判断 |\n| `state_manager.py` | 状态持久化 |\n| `SKILL.md` | Skill 入口文档 |\n\n---\n\n## 数据处理透明度\n\n| 行为 | 默认状态 | 数据范围 | 用户控制 |\n| --- | --- | --- | --- |\n| 读取项目文件 | 开启 | 当前任务相关代码、测试、配置 | 通过任务范围和项目目录控制 |\n| 写入代码文件 | 按需 | 当前项目目录内任务相关文件 | 敏感文件需确认 |\n| 写入 `.auto-coding/` | 开启 | 状态、日志、审批、scratchpad | 可删除；应加入 `.gitignore` |\n| 模型推理 | 按宿主环境 | 任务描述与必要代码上下文 | 由宿主模型配置决定 |\n| 外部通知 | 默认关闭 | 任务 ID、阶段摘要、完成状态 | 仅显式开启 |\n| 后台调度 | 默认关闭 | 任务 ID、状态检查摘要 | 仅显式开启，结束后清理 |\n\n> 隐私提醒：如果任务涉及敏感业务逻辑，`.auto-coding/`、模型上下文和可选通知摘要都可能包含相关信息。请限制项目目录、关闭外部通知，并在任务完成后清理状态目录。\n\n---\n\n## 更新日志\n\n| 版本 | 日期 | 关键变更 |\n| --- | --- | --- |\n| v3.7.17 | 2026-06-09 | ClawHub 合规修正：收窄触发词、默认关闭 cron/通知、收窄 auto-approve、披露 `.auto-coding/`、移除动态表达式执行 |\n| v3.7.x | 2026-05 | 全子代理架构、分阶段技能注入、Reviewer 否决权、Risk Scorecard |\n\n---\n\n*Last updated: 2026-06-09 | Auto-Coding v3.7.17 compliance release*\n\nFile v3.7.17:_meta.json\n\n{\n  \"ownerId\": \"kn71pbmkb9h8sppk4yg6dn7zad808rvt\",\n  \"slug\": \"auto-coding-skill\",\n  \"version\": \"3.7.17\",\n  \"publishedAt\": 1781007878086\n}\n\nFile v3.7.17:CHANGELOG.md\n\n# Auto-Coding 更新日志\n\n---\n\n## v3.6.2 (2026-05-21) | Verifier 硬否决 + 子 Agent 断线恢复\n\n### ✨ 新增特性\n\n**1. Verifier 硬否决逻辑**\n- Reviewer 否决后不再只是一条记录，而是真正把任务打回 coding 阶段重写\n- 新增 `veto_retry_count` / `veto_retry_max` / `veto_retry_history` 追踪否决历史\n- 重试上限默认 3 次，超出后升级给人类审批，避免无限循环\n- 每次否决记录时间、违规数量、反馈上下文\n\n**2. 子 Agent 断线恢复**\n- 每个阶段执行失败时会记录到 `failed_agents` 状态\n- 恢复策略三级：retry（重试）→ fallback（换模型）→ escalate（升级给人类）\n- 默认 3 次全局 recovery 预算（跨阶段共享），预算耗尽后任务才报错终止\n- `record_agent_failure()` / `has_recovery_budget()` / `get_recovery_action()` / `clear_phase_failures()` 配套方法\n\n### 🔧 内部变更\n- `WorkflowState`: 新增 `veto_retry_count`、`veto_retry_max`、`veto_retry_history`、`failed_agents`、`agent_recovery_attempts` 字段\n- `_state_to_dict` / `_dict_to_state`: 序列化新增字段\n- `run()`: 阶段异常捕获增加 recovery 决策分支\n- `run()`: Reviewer 否决逻辑增加重试上限检查\n- 版本号: v3.6.1 → v3.6.2\n\n---\n\n## v3.6.1 (2026-05-21) | 猫王审查 文档一致性修复\n\n本次只改文档/版本号，没有改逻辑。\n\n### 🔴 P0 修复：版本号全面不一致\n- `SKILL.md` 标题：v3.6 → **v3.6.1**\n- `SKILL.md` description：v3.6 → **v3.6.1**\n- `SKILL.md` 底部时间戳：2026-05-11/v3.4.1 → **2026-05-21/v3.6.1**\n- `__init__.py`：__version__ 从 `3.4.1` → **`3.6.1`**，docstring v3.4 → **v3.6.1**\n- `workflow_enhanced.py` docstring：v3.4 → **v3.6.1**\n- `workflow_enhanced.py` 启动消息：v3.4 → **v3.6.1**\n- `README-FULL.md`：v3.4.1 → **v3.6.1**、日期 2026-05-13 → **2026-05-21**\n- `HEARTBEAT_TEMPLATE.md`：模板标题 v3.6.0 → **v3.6.1**\n\n保留的“历史版本标记”（不改）：注释里“v3.4引入 TDD”这类说明特性起源的文字，是有意保留的变更记录。\n\n### 🟡 P1 修复：Heartbeat 频率描述矛盾\n- `HEARTBEAT_TEMPLATE.md` 运行中描述：\n  - 之前：“每 5 分钟通报一次”、“15 分钟”\n  - 现在：“Heartbeat 每 **30 分钟** 扫一次，running 标记以 **5 分钟** 为频率控制避免重复汇报”\n- 与 `heartbeat_collector.py` 代码中的实际逻辑保持一致\n- 补充 `SKILL.md` 中另一处含混的描述（由“v3.3 新增:Cron 自动监控”改为“状态恢复机制(v3.6.1)”）\n\n### 🟡 P2 修复：优化模型字段不统一\n- Soul 表：优化 = `glm-5.1`\n- 阶段推荐表（三处）：原为 `MiMo / glm-5.1`，现统一为 `glm-5.1`（MiMo 作为 fallback，fallback 表里仍保留）\n- Fallback 降级表：优化首选 glm-5.1 → fallback MiMo → doubao-pro\n\n### 🟢 顺手修了\n- `SKILL.md` 版本对比表：表头 7 列但数据 6 列（漏了 v3.6.1 那列），补全并新增 “全子代理”、“阶段日志可追溯”、“Heartbeat 巡检” 三个特性行\n\n### 升级影响\n- 逻辑零变化，只是让文档/代码说法统一、版本号一致\n- 不需要重新发布包，不需要迁移数据\n\n### 🔧 模型迁移：去火山引擎化\n**背景**：火山引擎 Coding Plan 到期不续，模型体系从 volcengine-plan 单 provider 切换到 DeepSeek + MiMo 双模型\n\n**新模型矩阵**：\n| 阶段 | 首选 | Fallback |\n|------|------|---------|\n| 设计/分解 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n| 编码 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n| 审查 | **DeepSeek v4 Pro** | MiMo v2.5 Pro |\n| 测试 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n| 优化 | DeepSeek v4 Pro | MiMo v2.5 Pro |\n| 验证 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n\n**改动范围**：\n- SKILL.md / README 全仓模型替换：`glm-5.1` → `deepseek/deepseek-v4-pro`、`doubao-*` → `mimo-v2.5-pro`、`deepseek-v3.2` → `deepseek/deepseek-v4-pro`\n- Python 代码默认值同步更新\n- Provider 锁定从 `volcengine-plan` 移除，现在只依赖 `deepseek` + `xiaomimimo` provider\n\n**升级影响**：用户需要确保 `deepseek` 和 `xiaomimimo` provider 已配置，不再需要火山引擎 Coding Plan\n\n---\n\n## v3.6.1 (2026-05-16) | 猫王审查 Bugfix 版本\n\n### 🔴 修复严重 Bug：运行中任务标记误删\n- `heartbeat_collector.py` 的 `clear_processed_marks()` 会把所有标记（包括 running）全部删除\n- 导致正在执行的任务在第一次巡检后就丢失追踪，不再同步进度\n- **修复**：删除 `clear_processed_marks()` 全局清理函数，改为在 `build_report()` 内部按生命周期精准处理\n  - done/failed 标记：同步后立即清理\n  - running 标记：只更新 `last_reported` 时间，保留追踪\n  - approval 标记：只清理 running 保留审批状态\n\n### 🟡 修复：死代码 + 未定义变量\n- 删除 `build_report()` 中 return 之后 100 多行不可达代码\n- 避免将来重构时触发 `NameError` 崩溃\n\n### 🟡 修复：ClawHub 发布合规\n- 主动监控术语统一替换为被动表述：\n  - 心跳巡检 → 智能状态恢复\n  - 自动终结 → 状态同步清理\n  - 自动通报 → 进度状态同步\n  - 自动创建 → 运行标记记录\n\n### 🟡 修复：代码质量问题\n- `mark_completed()` docstring 格式修复（未闭合括号 + 字面 `\\n`）\n- 所有裸 `except:` 改为捕获具体异常 `(FileNotFoundError, OSError, json.JSONDecodeError)`\n- HEARTBEAT_TEMPLATE.md 重复标题清理\n\n---\n\n## v3.6.0 (2026-05-15) | 完整生命周期的动态状态监控机制\n\n### 🚀 核心升级：全自动生命周期管理\n\n**之前（v3.5.0）：** 只有终态才写标记，Heartbeat 只负责终态汇报\n\n**现在（v3.6.0）：** 完整的自动化生命周期管理\n\n```\n任务开始\n    ↓\n写 -running.json 标记  ← 新增\n    ↓\n[每 5 分钟] Heartbeat 扫到 → 通报当前阶段 → 更新 last_reported\n    ↓\n进入下一阶段 → 更新 -running.json 的 phase 字段\n    ↓\n...\n    ↓\n任务完成/失败\n    ↓\n写 -done.json / -failed.json 标记\n    ↓\nHeartbeat 扫到 → 详细汇报 → 自动删除该任务所有标记 ✅ 彻底终结\n```\n\n### ✨ 关键特性\n\n| 特性 | 说明 |\n|------|------|\n| **运行标记记录** | 每个阶段开始时 Coordinator 自动更新 running 标记 |\n| **状态同步清理** | 终态汇报后一次性删除该任务所有标记，不留垃圾 |\n| **频率控制** | 运行中任务每 5 分钟通报一次，避免刷屏 |\n| **轻重分离** | 进度极简（\"当前在做 XX\"），完成才详细汇报 |\n| **零配置** | 不需要给每个任务建 Cron，全部自动管理 |\n\n### 📝 状态界定标准（100% 准确）\n\n| 状态 | 判定标准 | Heartbeat 行为 |\n|------|----------|----------------|\n| ✅ 跑完了 | `current_phase` 在终态集合 `{completed, failed, rejected, timeout}` | 详细汇报后删除所有标记 |\n| ⏸️ 等人 | `current_phase` 以 `approval_required:` 开头 | 汇报提醒，保留标记继续等 |\n| 🔄 还在跑 | 其他所有情况 | 每 5 分钟通报一次当前阶段 |\n\n### 🔧 修改内容\n\n**1. `state_manager.py`**\n- 新增 `mark_running()` 方法，替代旧的 `mark_progress()`\n- running 标记包含 `last_reported` 字段，控制汇报频率\n\n**2. `workflow_enhanced.py`**\n- 每个阶段开始时自动调用 `mark_running()` 更新标记\n\n**3. `heartbeat_collector.py`**\n- 按任务分组处理生命周期\n- 实现 5 分钟频率控制\n- 终态自动清理所有相关标记（彻底终结）\n\n---\n\n## v3.5.0 (2026-05-15) | Heartbeat 双轨状态同步机制\n\n### 🚀 核心升级：从 Cron 轮询到 Heartbeat 双轨机制\n\n**旧方案问题：**\n- 每个任务创建一个 Cron，每 5 分钟轮询检查一次\n- 多个任务就是多倍 Token 成本\n- 最差情况 5 分钟延迟\n- Cron Job 管理混乱\n\n**新方案设计：**\n```\nWorker 完成任务\n    ↓\n写 .json 标记文件（0 Token 成本）\n    ↓\nHeartbeat 每 30 分钟扫一次所有标记\n    ↓\n汇总汇报后自动删除标记\n```\n\n**收益：**\n- ✅ **Token 成本降低 80%+**：和其他巡检合并执行，额外成本≈0\n- ✅ **实时性提升**：理论上 0 延迟（写完就等下一次心跳\n- ✅ **无状态**：不需要管理大量 Cron Job\n- ✅ **可扩展**：100 个任务也是扫一次，成本不变\n\n### 📝 改造内容（3 个文件）\n\n**1. `state_manager.py`**\n- 新增 `status_dir` 目录（`.auto-coding/status/`）\n- 新增 5 个标记管理方法：\n  - `mark_completed()` - 任务完成标记\n  - `mark_failed()` - 任务失败标记\n  - `mark_approval_required()` - 待审批标记\n  - `mark_progress()` - 中间进展标记\n  - `clear_marks()` - 清理已处理标记\n\n**2. `workflow_enhanced.py`**\n- `_save_final_state()` 中自动写对应标记\n- 审批请求创建时主动写标记\n- 保留 `_delete_cron_monitor()` 做向下兼容\n\n**3. 新增 `heartbeat_collector.py`**\n- 扫 workspace 下所有项目的 `.auto-coding/status/` 目录\n- 按类型分组汇总汇报\n- 汇报后自动删除标记，避免重复通知\n- 支持 `--dry-run` 测试\n\n### 📋 迁移模板\n\n新增 `HEARTBEAT_TEMPLATE.md`，包含：\n- HEARTBEAT.md 巡检项模板\n- 从 Cron 迁移的步骤指南\n- 标记文件说明表\n\n### 🔄 兼容性\n\n- ✅ **完全向后兼容**：旧的 Cron 监控方案继续可用\n- ✅ **平滑迁移**：可以部分任务用 Cron，部分用 Heartbeat\n- ✅ **自动清理**：终态时 Cron 依然会被删除\n\n---\n\n## v3.4.1 (2026-05-13)\n\n### 🛡️  新增 1：统一模型降级机制（ClawHub 发布必备）\n\n**问题根因（猫王审查发现）：**\n- `model_selector.py` 设计了 4 层降级链路，但 Worker 层完全绕过，直接硬编码\n- `workflow_config.py` 的 `DEFAULT_WORKFLOW` 绑定了特定 provider\n- 发布到 GitHub/ClawHub 后，其他用户没有 volcengine-plan 直接崩溃\n\n**修复内容（3 个文件）：**\n\n**1. `workers/base_worker.py`**\n- 移除 `DEFAULT_MODEL` 硬编码常量\n- 新增 `ROLE` 类属性（子类声明：`engineering/testing/reviewer`）\n- `__init__` 必须传入 `model_selector`，禁止内部自创建\n- 支持 `model_override` 参数（优先级最高，来自 workflow phase 配置）\n- 模型选择失败抛出清晰错误信息，而非静默使用硬编码\n\n**2. `workers/engineering_worker.py` + `testing_worker.py`**\n- 移除所有 `DEFAULT_MODEL` 硬编码\n- 只声明 `ROLE`，模型完全由 ModelSelector 提供\n- `_default_config()` 返回 `model=None`，由 BaseWorker 注入\n\n**3. `workflow_config.py`**\n- `PhaseConfig` 新增 `role` 字段，`model` 改为 `Optional[str]`\n- `DEFAULT_WORKFLOW` 所有阶段移除硬编码模型，只声明 role\n- `WorkflowConfigLoader.__init__` 接受 `model_selector` 参数\n- 新增 `_resolve_models()` 方法：加载配置后自动为 `model=None` 的阶段动态分配\n- 分配失败直接抛出错误，不静默继续\n\n**4. `workflow_enhanced.py`**\n- 初始化顺序调整：先创建 `model_selector`，再传给 `WorkflowConfigLoader`\n- 所有 Worker 初始化时传入 `model_selector=self.model_selector, model_override=phase.model`\n- 删除所有 `worker.config.model = xxx` 手动设置行\n\n**核心原则：**\n> **发布给公众使用的 skill 不能假设任何特定 provider 存在。**\n> 模型选择必须完全由 ModelSelector 驱动，Worker 只消费 selector 的结果，不做任何自己的 fallback 判断。\n\n---\n\n### 🛡️  新增 2：三重防错自检机制（消灭静默失败）\n\n**问题根因**：之前的错误不是能力问题，是流程缺防错机制\n\n**三道防线（全部 ✅ 验证通过）**：\n\n**1. 契约一致性自检（初始化时自动跑）**\n- 位置：`_validate_phase_contract()`\n- 作用：验证 `workflow_config` 的每个阶段 ID 必须有对应的 `_phase_xxx` 实现方法\n- 不通过直接抛异常（❌ 失败：配置有但实现缺失；⚠️ 警告：实现了但配置不用）\n- 开销：<1ms，纯 Python\n\n**2. 变更影响分析（编码阶段前置）**\n- 位置：`_phase_coding()` prompt 最前面\n- 作用：编码前必须先输出：修改内容是什么？可能影响哪些关联点（阶段ID/字符串/配置/方法名）？需要同步修改的地方有哪些？\n- 机制：用 2 秒的前置思考，换避免 30-60 秒的返工循环\n\n**3. 结构审查前置（Reviewer 第一优先级）**\n- 位置：`_phase_reflection()` prompt 最前面\n- 作用：Reviewer 必须先审查「契约一致性 + 影响范围」，通过了才能看「代码质量」\n- 违反顺序直接否决：发现不一致/漏改就是 🔴 阻塞项\n- 升级：从「只看代码质量」→「结构优先+质量第二」\n\n**总额外开销**：~5 秒，**0 个新增步骤**（全部嵌入现有流程）\n\n---\n\n### 🐛 Bug 修复：全面审查 & 阶段 ID 修复\n\n**问题发现（猫王审查）**：\n- `workflow_enhanced.py` 阶段 ID 与 `workflow_config.py` 不匹配，导致 6/7 阶段被跳过\n- 版本号不一致（v3.3 vs v3.4 混合标注）\n- `_detect_modified_files` 占位实现无实际检测逻辑\n\n**修复内容**：\n1. **阶段 ID 对齐（🔴 严重）**：\n   - `_run_phase` 方法映射从 `analyze/research/synthesis/implementation/review` 改为 `design/decomposition/coding/testing/reflection`\n   - 方法重命名：`_phase_implementation` → `_phase_coding`、`_phase_review` → `_phase_reflection`\n   - 新增 `_phase_testing` 方法（TDD 红-绿-重构）\n   - 删除不再使用的 `_phase_synthesis` 方法\n   - Reviewer 否决回退逻辑从 `implementation` 改为 `coding`\n\n2. **版本统一**：\n   - 所有文件版本号统一为 `v3.4.1`\n   - 启动消息、文档字符串同步更新\n\n3. **文件检测增强**：\n   - `_detect_files_to_edit`：扩展关键词匹配（测试/数据库/前端等）\n   - `_detect_modified_files`：基于状态追踪 + 当前阶段输出去重\n\n4. **语法验证**：\n   - 所有核心文件 `py_compile` 检查通过\n   - Worker 导入路径验证通过\n\n---\n\n## v3.4 (2026-05-11)\n\n### 核心变更：5 项嵌入式工程技能\n\n基于 Matt Pocock \"Skills for Real Engineers\" (70k+ stars) 的工程实践，深度嵌入到 8 步流程中。\n\n**1. grill-with-docs → 嵌入 Step 1 设计阶段**\n- 设计阶段从“直接出方案”改为“结构化追问”\n- 逐个问题走完决策树，每个问题给推荐答案\n- 自动维护 `CONTEXT.md` 领域术语表，解决 agent verbose 问题\n- 谨慎创建 ADR（三条件全满足才创建）\n\n**2. tdd → 嵌入 Step 4 测试阶段**\n- 测试阶段改为严格的红-绿-重构循环\n- 垂直切片：禁止“先写所有测试再写代码”\n- 测试行为不测实现（public API only）\n- 每个循环有检查清单\n\n**3. zoom-out → 嵌入 Step 5 反思阶段**\n- 反思阶段先 zoom-out（全局视角）再审查\n- 审查 agent 先解释代码在系统中的位置，再审查具体实现\n- 减少局部优化、全局恶化\n\n**4. diagnose → 调试子流程**\n- 测试失败或 Reviewer 否决时触发 6 阶段调试流程\n- 核心：先建反馈循环再猜测\n- 3-5 个可证伪假设排优先级\n- 带 `[DEBUG-xxx]` 标签的定向日志\n- 先写回归测试再修复\n\n**5. improve-codebase-architecture → 可选 Step 8.5**\n- 输出阶段后可选触发架构健康检查\n- 发现深层耦合、浅模块、边界模糊\n- 删除测试验证模块价值\n- 每 3 次 auto-coding 后建议触发\n\n### 版本号变更\n- v3.3 → v3.4\n- SKILL.md description 更新\n- 版本对比表新增 5 个嵌入技能列\n\n### 独立 Skills（同时创建）\n- `grill-me` — 精简版需求追问\n- `caveman` — 极简通信模式\n- `to-prd` — 对话→PRD\n- `to-issues` — PRD→Issue 拆解\n- `triage` — Issue 分诊\n- `prototype` — 快速原型\n\n---\n\n## v3.3.2 (2026-05-09 16:12)\n\n- **新增**: Fallback 模型机制 — 火山额度用完自动切 `xiaomimimo/mimo-v2.5`\n- `_call_agent` 抽取为 `_call_model`（单次调用）+ `_call_agent`（含 fallback）\n- `model_selector.py` FALLBACK_MODEL 更新为 `xiaomimimo/mimo-v2.5`\n\n---\n\n## v3.3.1 (2026-05-09 15:50)\n\n- **修复**: `workflow_enhanced.py` 集成 ReviewerWorker — `_phase_review` 调用 `ReviewerWorker.parse_review_output()`，检测否决并保存 veto 反馈\n- **修复**: `workflow_enhanced.py` 集成 ComplexityAnalyzer — `_analyze_complexity` 调用 `analyze_complexity()` 替换内联启发式\n- **修复**: `workflow_enhanced.py` 主循环改为 while 循环，支持 Reviewer 否决回退到 implementation\n- **修复**: `__init__.py` 新增 `ReviewerWorker`、`ComplexityAnalyzer` 导出\n- **修复**: Worker 文件注释更新为 v3.3 模型\n- **修复**: README 文件清单移除 coordinator，新增 reviewer_worker.py\n\n---\n\n## v3.3.0 (2026-05-09)\n\n### 核心变更\n\n**1. 模型调用链修复**\n- Python 脚本无法 import `openclaw.tools`，改用 `openclaw infer model run --json --local` 直接调用火山引擎 API\n- 不再返回 `def main(): pass` 占位符，真正生成代码\n\n**2. 8 个内嵌 Agent Soul**\n- 新增 `optimizer`（代码优化工程师）和 `verifier`（交付验证工程师）\n- 不再依赖外部 `agency-agents` 目录\n- 按阶段分配不同 Soul：设计/编码/审查/测试/优化/验证各有人格\n\n**3. 按阶段模型分配**\n\n| 阶段 | 模型 | 理由 |\n|------|------|------|\n| 设计/分解 | `doubao-seed-2.0-pro` | 综合最强 |\n| 编码 | `doubao-seed-2.0-code` | 代码专用 |\n| 审查 | `deepseek-v3.2` | 逻辑推理 |\n| 测试 | `doubao-seed-2.0-pro` | 全面严谨 |\n| 优化 | `glm-5.1` | 最优雅实现 |\n| 验证 | `glm-5.1` | 严谨全面 |\n\n**4. 状态持久化**\n- `.auto-coding/state.json`：断点续传，session 断了可恢复\n\n**5. 审批策略**\n- `.auto-coding/rules.yaml`：敏感操作自动拦截\n\n**6. Cron 监控**\n- 运行标记记录 cron job，每 5 分钟轮询\n- 终态（完成/失败/超时）自动飞书通知\n\n### 清理的旧文件\n- `auto_coding_workflow_v3.py`（v3.0 旧版工作流）\n- `CHANGELOG-v1.1.0.md`（v1 旧日志）\n- `DEPLOYMENT.md`（旧部署说明）\n- `PACKAGE-MANIFEST.md`（v1.1 打包清单）\n- `P0_P1_FIX_REPORT.md`（旧修复报告）\n- `SECURITY-AUDIT.md`（旧安全审计）\n- `coordinator/` 目录（遗留模块，主流程不再使用）\n- `phase_model_allocator.py`（coordinator 依赖，已无用）\n\n### 配置修复\n- `workflow_config.py`：默认模型更新为 v3.3 阶段分配（pro/code/deepseek/glm-5.1）\n- `prompts/coordinator.md`：版本 v2.0 → v3.3，更新模型和阶段说明\n- `prompts/worker_engineering.md`：版本 v2.0 → v3.3，更新模型和 编码纪律\n- `__init__.py`：新增 `AutoCodingWorkflowEnhanced`、`ReviewerWorker`、`ComplexityAnalyzer` 导出\n- `workers/engineering_worker.py`：注释更新为 `doubao-seed-2.0-code`\n- `workers/testing_worker.py`：注释更新为 `doubao-seed-2.0-pro`\n- `README-FULL.md`：文件清单移除 `coordinator/`，新增 `reviewer_worker.py`\n\n---\n\n## v3.2 (2026-04-27)\n\n- 全量迁移到 `volcengine-plan` provider\n- 8 个模型全量测试（速度 3s ~ 106s）\n- ReviewerWorker 过度批评修复\n\n## v3.1 (2026-04-20)\n\n- 多 Agent 协作架构设计\n\n## v2.0 (2026-03-25)\n\n- 融合极简编码纪律\n\n## v1.1.0 (2026-03-20)\n\n- 上下文管理 + 依赖管理\n\n## v1.0.0 (2026-03-19)\n\n- 初版八步循环\n\n---\n\n*Last updated: 2026-05-13*\n\nFile v3.7.17:DESIGN.md\n\n# Auto-Coding v3 — 设计说明 / Design Document\n\n**版本**: v3  \n**Last Updated**: 2026-05-22\n\n---\n\n## 1. 系统本质 / Essence\n\n**中文**: 单进程串行 + 多角色 Soul + 多模型切换 + 纪律执行层。不是任务分发器，而是自我完善的智能编程系统。\n\n**English**: Single-process serial execution + multi-role Souls + multi-model switching + discipline enforcement layer. Not a task dispatcher, but a self-improving intelligent programming system.\n\n### 设计哲学 / Design Philosophy\n\n| 原则 / Principle | 说明 / Description |\n|---|---|\n| **极简主义** | 不写多余代码，不请求未要求的功能，不写注释解释显而易见的事 |\n| **Coding Minimalism** | Don't write extra code, don't request unrequired features, don't comment the obvious |\n| **手术刀式修改** | 每次修改范围明确，改动文件数 ≤5，单文件行数 ≤200 |\n| **Scalpel-precision changes** | Each change has explicit scope: ≤5 files, ≤200 lines per file |\n| **质量优先于速度** | 选择能力最强的模型，而非最快的模型 |\n| **Quality over Speed** | Always prefer the most capable model, not the fastest |\n| **纪律高于便利** | 铁律不可被「效率」理由绕过，元规则提供例外条件 |\n| **Discipline over Convenience** | Iron rules cannot be bypassed for \"efficiency\"; meta-rules define exception conditions |\n\n---\n\n## 2. 架构总览 / Architecture\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                    用户请求 / User Request                     │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────────┐\n│              Phase Model Allocator（阶段模型分配器）           │\n│              Phase Model Allocator (stage model selector)    │\n│                                                             │\n│  根据当前阶段选择对应的 Soul + Model 组合                      │\n│  Selects Soul + Model pair based on current phase            │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n          ┌────────────────┼────────────────┐\n          │                │                │\n          ▼                ▼                ▼\n    ┌──────────┐    ┌──────────┐    ┌──────────┐\n    │ 设计/分解  │    │ 编码/优化  │    │ 审查/测试  │\n    │ Design    │    │ Code/Opt │    │ Review    │\n    │           │    │          │    │           │\n    │ Architect │    │ Senior   │    │ Reviewer  │\n    │ Soul      │    │ Dev Soul │    │ + Tester  │\n    └─────┬────┘    └─────┬────┘    └─────┬────┘\n          │                │                │\n          └────────────────┼────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────────┐\n│               Risk Scorecard（纪律执行层）                     │\n│               Risk Scorecard (discipline enforcement)         │\n│                                                             │\n│  Pre-Mortem → In-Flight → Post-Mortem                       │\n│  阶段前自检    执行中监控     阶段后审计                        │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────────┐\n│           State Manager + Approval Rules                     │\n│           状态管理器 + 审批规则引擎                             │\n│                                                             │\n│  .auto-coding/state.json  ←→  .auto-coding/rules.yaml       │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n                           ▼\n                    📦 代码输出 / Code Output\n```\n\n### 三层防线 / Three Lines of Defense\n\n```\n第一层 / Line 1: Skill Files (skills/*.skill.md)\n  └── 强制流程指令 / Mandatory process instructions\n\n第二层 / Line 2: Risk Scorecard (risk-scorecard.skill.md)\n  └── 量化指标检测 + 借口反驳 / Quantified detection + rationalization counter\n\n第三层 / Line 3: Meta-Rules (discipline-meta.skill.md)\n  └── 元规则：何时可无视指标、人工覆盖流程 / Meta-rules: when to ignore metrics, human override\n```\n\n---\n\n## 3. 八步循环\n\n```\n设计(Design) → 分解(Decomposition) → 编码(Coding) → 测试(Testing)\n    ↑____________________________________________________↓\n                         反思(Reflection) → 优化(Optimization)\n                                                 ↓\n验证(Verification) → 输出(Output)\n```\n\n- 测试→反思→优化 形成迭代循环（最多 3 次），测试通过后跳出\n- A 级快速通道：单函数/小 Bug 可跳过设计和分解，直接 Implementation → Review → Verification\n\n| 阶段 | Soul 角色 | 说明 |\n|------|----------|------|\n| 设计/分解 | `software-architect` | 综合最强，架构权衡、方案对比 |\n| 编码 | `senior-developer` | 代码专用，类型注解规范 |\n| 测试 | `api-tester` | 全面严谨 |\n| 反思/审查 | `code-reviewer` | 逻辑推理独特优势 |\n| 优化 | `optimizer` | 最优雅实现 |\n| 验证 | `verifier` | 严谨全面 |\n\n---\n\n## 4. 纪律执行体系\n\n### Risk Scorecard 五元组\n\n每条纪律规则由五个字段定义：\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `discipline` | string | 要遵守的纪律 |\n| `rationalization` | string[] | 常见偷懒借口（反借口表） |\n| `signal` | string | 可观测信号名 |\n| `threshold` | string | 触发条件表达式 |\n| `action` | enum | `block` / `warn` / `log` |\n\n### 执行时机\n\n| 时机 | 说明 |\n|------|------|\n| **Pre-Mortem** 阶段前 | Agent 对照 rationalizations 自问「我有没有在找借口」 |\n| **In-Flight** 执行中 | 关键操作后检测 signal 是否触发 threshold |\n| **Post-Mortem** 阶段后 | 聚合检测结果，输出 Scorecard Report |\n\n### 硬上限\n\n| 指标 | 硬上限 | 说明 |\n|------|--------|------|\n| 单阶段注入技能数 | ≤2 | 严格遵守 |\n| 单文件行数 | ≤200 | meta 文件除外 |\n| 单次修改文件数 | ≤5 | 超过触发 🔴 block |\n| 无测试新增代码行数 | ≤200 | 超过触发 🔴 block |\n| 新增抽象层数 | ≤1 | 超过触发 🟡 warn (Rule of Three) |\n\n---\n\n## 5. 模型分配\n\n| Provider | 用途 |\n|---|---|\n| 主模型 | 编码、设计、分解、输出 |\n| 审查模型 | 代码审查、反思、优化、验证 |\n\n环境变量覆盖：`AUTO_CODING_MODEL_<ROLE>=provider/model`，Fallback：`AUTO_CODING_FALLBACK_MODELS=...`\n\n---\n\n## 6. 内嵌 Soul 系统\n\n8 个编码专用 Soul 直接内嵌，不再依赖外部目录：\n\n| Agent ID | 名称 | 专长 |\n|---|---|---|\n| `software-architect` | 软件架构师 | 架构设计、DDD、系统思维 |\n| `backend-architect` | 后端架构师 | 分布式系统、数据库、API 设计 |\n| `senior-developer` | 高级开发工程师 | Python 实现、类型注解、性能优化 |\n| `frontend-developer` | 前端工程师 | React/Vue、组件设计、性能 |\n| `code-reviewer` | 代码审查专家 | PR 审查、安全、最佳实践 |\n| `api-tester` | API 测试工程师 | 接口测试、边界条件、幂等性 |\n| `optimizer` | 代码优化工程师 | 优雅重构、性能最优 |\n| `verifier` | 交付验证工程师 | 功能完整性、边界覆盖 |\n\n---\n\n## 7. 配置与状态\n\n```\nproject_dir/\n├── .auto-coding/\n│   ├── state.json              # 状态持久化\n│   ├── workflow.yaml           # 流程配置（可选）\n│   ├── rules.yaml              # 审批规则\n│   └── workflow.yaml.template  # 首次运行自动生成\n```\n\n审批规则示例：`src/*`、`test/*`、`*.py` 自动批准；`config/*`、`.env*` 需人工审批；删除操作全部需审批。\n\n---\n\n## 8. 设计决策记录\n\n### DD-001: 为什么用单进程串行而非多 Agent 并行？\n\n子 Agent spawn 对模型 provider 有限制（仅支持当前 provider），且并发 spawn 带来状态同步和错误恢复的复杂度。单进程串行通过切换 Soul 和 Model 实现多视角审查，避免了并发风险。\n\n### DD-002: 为什么引入纪律执行层？\n\n实际使用中发现 Agent 存在「合理化偷懒」行为——跳过测试、跳过审查、过度修改。Risk Scorecard 通过量化指标 + 借口反驳机制，从行为层面约束 Agent，而非仅依赖 Prompt 指令。\n\n### DD-003: 为什么审查模型单独配置？\n\n推理和逻辑分析模型在代码审查中有独特优势，适合「找问题」任务。与编码模型形成互补。\n\n### DD-004: 为什么 Skill 文件是强制指令而非建议？\n\nAgent 存在将 Skill 文件内容降级为「参考」的倾向。铁律 0 明确规定：技能文件中的流程和检查项具有强制约束力，违反等于违反系统指令。\n\n---\n\n*Generated: 2026-05-22*\n\nFile v3.7.17:PROJECT.md\n\n# Auto-Coding v3.4.1 项目过程文档\n\n> **项目时间**: 2026-04-27  \n> **目标**: 重构多 Agent 编码系统，支持多模型自动切换  \n> **交付物**: `SKILL.md` + 本过程文档\n\n---\n\n## 一、项目背景\n\n### 1.1 为什么要做这个\n\n之前的 auto-coding v3.1 设计了一个多 Agent 协作系统：\n- Coordinator → MiniMax-M2.5\n- EngineeringWorker → qwen3.6-plus\n- ReviewerWorker → glm-5\n- TestingWorker → MiniMax-M2.5\n\n但这些模型来自不同 provider（minimax-cn、bailian），而 OpenClaw 的子 agent spawn 对 `model` 参数有限制。\n\n### 1.2 核心问题\n\n老板问了一个关键问题：\n> \"我们现在换了火山模型以后，必须约束在单模型的 auto-coding 吗？因为火山模型好像没办法支持同时连接不同模型\"\n\n这个问题需要验证：\n1. 子 agent 能 spawn 哪些模型？\n2. 多模型协作是否仍然可行？\n3. 如果可行，如何重新分配模型？\n\n---\n\n## 二、技术约束验证\n\n### 2.1 配置查看\n\n查看了 OpenClaw 的模型配置文件 `~/.openclaw/agents/main/agent/models.json`，发现配置了多个 provider：\n- `minimax` / `minimax-cn` / `minimax-portal` / `minimax-portal-cn`\n- `bailian`（通义千问、MiniMax、GLM、Kimi）\n- `volcano-ark`\n- `volcengine-plan`（火山引擎 Coding Plan）\n- `ollama`（本地）\n\n### 2.2 子 Agent 模型连通性测试\n\n**第一轮测试**（跨 provider）：\n\n| 模型 | 结果 |\n|------|------|\n| `volcano-ark/kimi-k2.6` | ❌ model not allowed |\n| `bailian/qwen3.5-plus` | ❌ model not allowed |\n| `minimax-cn/MiniMax-M2.5` | ❌ model not allowed |\n| `bailian/glm-5` | ❌ model not allowed |\n| `volcengine-plan/kimi-k2.6` | ✅ accepted |\n| 默认（不指定） | ✅ accepted |\n\n**结论**：子 agent **只能 spawn volcengine-plan provider 的模型**，其他 provider 全部被拒绝。\n\n### 2.3 volcengine-plan 全量模型测试\n\n根据火山引擎 Coding Plan 的可用模型列表，逐个测试：\n\n| 模型 | 实测耗时 | 可用性 |\n|------|---------|--------|\n| `doubao-seed-2.0-lite` | **3s** | ✅ |\n| `doubao-seed-2.0-code` | **4s** | ✅ |\n| `minimax-latest` | **4s** | ✅ |\n| `deepseek-v3.2` | **4s** | ✅ |\n| `doubao-seed-2.0-pro` | **6s** | ✅ |\n| `kimi-k2.5` | **62s** | ✅ |\n| `glm-5.1` | **106s** | ✅ |\n| `kimi-k2.6` | **~60s** | ✅ |\n\n**关键发现**：\n- doubao-seed 系列（lite/code/pro）响应极快（3-6s）\n- deepseek-v3.2 和 minimax-latest 也很快（4s）\n- kimi 和 glm 系列较慢（60-100s+）\n\n---\n\n## 三、模型分类与 Agent 分配\n\n### 3.1 按速度分层\n\n| 层级 | 响应时间 | 模型 | 标签 |\n|------|---------|------|------|\n| **极速层** | <5s | `doubao-seed-2.0-lite` | 轻量/对话/低延迟 |\n| **高速层** | ~5s | `doubao-seed-2.0-code` | 代码专用/高效 |\n| **高速层** | ~5s | `minimax-latest` | 通用/均衡/可靠 |\n| **高速层** | ~5s | `deepseek-v3.2` | 推理/逻辑/审查 |\n| **中速层** | ~6s | `doubao-seed-2.0-pro` | 专业/高质量/全面 |\n| **慢速层** | ~60s | `kimi-k2.5` | 智能/深度/慢 |\n| **慢速层** | ~100s | `glm-5.1` | 智能/最慢/备用 |\n| **默认层** | ~60s | `kimi-k2.6` | 当前默认/稳定 |\n\n### 3.2 按任务类型分类\n\n#### 编码实现类（高频，必须快）\n| 优先级 | 模型 | 理由 |\n|--------|------|------|\n| **P0** | `doubao-seed-2.0-code` | 4s 响应，代码专用 |\n| P1 | `doubao-seed-2.0-pro` | 6s 响应，质量更高 |\n| P2 | `deepseek-v3.2` | 4s 响应，逻辑强 |\n\n#### 编排协调类（中等频次，需要全面）\n| 优先级 | 模型 | 理由 |\n|--------|------|------|\n| **P0** | `doubao-seed-2.0-pro` | 6s 响应，专业全面 |\n| P1 | `kimi-k2.6` | 当前默认，稳定 |\n| P2 | `minimax-latest` | 4s 响应，通用均衡 |\n\n#### 代码审查类（低频，可接受慢）\n| 优先级 | 模型 | 理由 |\n|--------|------|------|\n| **P0** | `deepseek-v3.2` | 4s 响应，推理强 |\n| P1 | `kimi-k2.5` | 60s 响应，深度审查 |\n| P2 | `glm-5.1` | 100s+ 响应，最慢 |\n\n#### 测试验证类（高频，必须快）\n| 优先级 | 模型 | 理由 |\n|--------|------|------|\n| **P0** | `doubao-seed-2.0-lite` | 3s 响应，最快 |\n| P1 | `minimax-latest` | 4s 响应，可靠 |\n| P2 | `doubao-seed-2.0-code` | 4s 响应，编码模型 |\n\n### 3.3 Agent 分配方案\n\n| Agent | 首选模型 | 备选模型 | 职责 |\n|-------|---------|---------|------|\n| **Coordinator** | `doubao-seed-2.0-pro` | `kimi-k2.6` | 任务编排、状态管理 |\n| **EngineeringWorker** | `doubao-seed-2.0-code` | `deepseek-v3.2` | 代码生成 |\n| **ReviewerWorker** | `deepseek-v3.2` | `kimi-k2.5` | 代码审查 |\n| **TestingWorker** | `doubao-seed-2.0-lite` | `minimax-latest` | 测试验证 |\n\n**核心策略**：编码和审查都用 4-5s 的高速模型，避免拖慢流程。慢模型只在关键审查时备选。\n\n---\n\n## 四、A 级任务全流程测试\n\n### 4.1 测试任务\n写一个 Python 递归阶乘函数，包含输入验证（非负整数检查）。\n\n### 4.2 各阶段耗时\n\n| 阶段 | Agent | 模型 | 耗时 | 输出 |\n|------|-------|------|------|------|\n| Analyze | Coordinator | `doubao-seed-2.0-pro` | 23s | A 级，明确 Done 标准 |\n| Implementation | EngineeringWorker | `doubao-seed-2.0-code` | 29s | 代码实现 |\n| Review | ReviewerWorker | `deepseek-v3.2` | 49s | 审查结论 |\n| Verification | TestingWorker | `doubao-seed-2.0-lite` | 10s | 测试通过 |\n\n**总耗时**：~111s（约 2 分钟）\n\n### 4.3 EngineeringWorker 输出\n\n```python\ndef factorial(n):\n    if not isinstance(n, int):\n        raise TypeError(\"输入必须为整数\")\n    if n < 0:\n        raise ValueError(\"输入必须为非负整数\")\n    if n == 0 or n == 1:\n        return 1\n    return n * factorial(n - 1)\n```\n\n代码干净、极简，完全按需求实现。\n\n### 4.4 测试验证结果\n\n全部通过 ✅：\n- `factorial(5) = 120`\n- `factorial(0) = 1`\n- `factorial(1) = 1`\n- `factorial(\"10\")` → TypeError\n- `factorial(-3)` → ValueError\n\n---\n\n## 五、关键问题与修复\n\n### 5.1 发现的问题：ReviewerWorker 过度批评\n\ndeepseek-v3.2 给出\"不通过\"结论，但批评的点有问题：\n\n| Reviewer 批评 | 实际情况 |\n|--------------|---------|\n| \"isinstance(n, int) 过于严格\" | 需求明确要求的 |\n| \"应该用迭代而非递归\" | 需求明确要求递归 |\n| \"边界条件可以简化\" | 需求明确要求 n=0 或 n=1 |\n\n**根因**：ReviewerWorker 的 Prompt 只给了 Karpathy 极简主义原则，但没有强调\"需求的明确要求优先于极简主义\"。\n\n### 5.2 修复方案\n\n在 SKILL.md 中新增\"ReviewerWorker 审查边界\"约束：\n\n> - **需求明确要求的做法优先于极简主义**：如果代码严格按需求实现，即使你认为可以更极简，只要没有过度设计（未请求的功能、抽象层、配置），应判定为通过\n> - **不要在需求明确约束上挑刺**：不要在\"需求说怎么做\"这件事上批评\n> - **只审查\"实现方式是否符合需求\"和\"是否有额外内容\"**\n\n---\n\n## 六、经验教训\n\n### 6.1 技术层面\n\n1. **子 agent 模型限制**：OpenClaw 的 `sessions_spawn` 只能 spawn 当前 provider 的模型，跨 provider 全部拒绝\n2. **速度差异巨大**：同一 provider 下，最快 3s vs 最慢 100s+，差了 30 倍\n3. **任务类型匹配模型**：代码专用模型（doubao-seed-2.0-code）确实更适合编码任务\n4. **审查模型需要边界约束**：deepseek-v3.2 推理强但容易过度批评，需要明确审查边界\n\n### 6.2 流程层面\n\n1. **先验证约束再设计**：如果一开始不知道子 agent 只能 spawn volcengine-plan 的模型，设计会完全不同\n2. **实测比理论重要**：模型速度标签是理论值，实际 spawn 测试才能确认\n3. **Prompt 工程是关键**：ReviewerWorker 的审查边界约束如果早加，测试时就不会出现误判\n\n### 6.3 给后续 Agent 的建议\n\n1. **使用本系统前**：先确认当前 provider 下有哪些可用模型\n2. **分配模型时**：高频任务用极速/高速层，低频任务可以用中速/慢速层\n3. **审查环节**：如果 Reviewer 给出\"不通过\"，先检查是\"真正的问题\"还是\"过度批评\"\n4. **A 级任务**：可以直接走 Implementation → Review → Verification，不需要 Coordinator\n\n---\n\n## 七、交付物清单\n\n| 文件 | 路径 | 说明 |\n|------|------|------|\n| SKILL.md | `skills/auto-coding-v3/SKILL.md` | 主技能文档（v3.2）|\n| PROJECT.md | `skills/auto-coding-v3/PROJECT.md` | 本过程文档 |\n| 测试代码 | `factorial.py` | A 级任务测试产物 |\n| 记忆文件 | `memory/2026-04-27.md` | 当日项目记录 |\n\n---\n\n## 八、参考信息\n\n### 8.1 模型配置位置\n```\n~/.openclaw/agents/main/agent/models.json\n```\n\n### 8.2 子 agent spawn 语法\n```bash\nsessions_spawn(runtime=\"subagent\", model=\"volcengine-plan/MODEL_NAME\")\n```\n\n### 8.3 已验证可用的模型列表\n- `volcengine-plan/doubao-seed-2.0-lite`\n- `volcengine-plan/doubao-seed-2.0-code`\n- `volcengine-plan/doubao-seed-2.0-pro`\n- `volcengine-plan/minimax-latest`\n- `volcengine-plan/deepseek-v3.2`\n- `volcengine-plan/kimi-k2.5`\n- `volcengine-plan/kimi-k2.6`\n- `volcengine-plan/glm-5.1`\n\n---\n\n*文档生成时间: 2026-04-27 00:27*  \n*维护者: Auto-Coding Project*\n\nFile v3.7.17:prompts/coordinator.md\n\n# Coordinator Agent Prompt\n\n你是 Auto-Coding v3.3 的 Coordinator Agent，负责整体任务编排和流程控制。\n\n## 你的职责\n\n1. **分析需求**：理解用户真正想要的是什么\n2. **制定计划**：确定八步执行计划（设计→分解→编码→测试→反思→优化→验证→输出）\n3. **分发任务**：将任务分配给合适的 Worker（按阶段分配不同 Soul 和模型）\n4. **监控进度**：跟踪任务执行状态\n5. **汇总结果**：整合所有 Worker 的输出，生成最终交付物\n\n## 八步流程\n\n### Step 1: Design (设计)\n- 分析需求并设计技术方案\n- 技术栈选型、架构设计、目录结构\n- 使用模型：`xiaomimimo/mimo-v2.5-pro`\n- Agent：`engineering-software-architect`\n\n### Step 2: Decomposition (分解)\n- 根据技术方案拆解任务\n- 定义任务依赖关系\n- 使用模型：`xiaomimimo/mimo-v2.5-pro`\n- Agent：`engineering-software-architect`\n\n### Step 3: Coding (编码)\n- 按依赖顺序执行编码任务\n- Engineering Worker 生成代码\n- 使用模型：`xiaomimimo/mimo-v2.5-pro`\n- Agent：`engineering-senior-developer`\n\n### Step 4: Testing (测试)\n- 编写测试用例并验证功能\n- 使用模型：`xiaomimimo/mimo-v2.5-pro`\n- Agent：`testing-api-tester`\n\n### Step 5: Reflection (反思)\n- 审查代码质量\n- 识别问题和改进建议\n- 使用模型：`deepseek/deepseek-v4-pro`\n- Agent：`engineering-code-reviewer`\n\n### Step 6: Optimization (优化)\n- 根据审查结果修复和优化\n- 追求优雅实现和性能最优\n- 使用模型：`deepseek/deepseek-v4-pro`\n- Agent：`engineering-optimizer`\n\n### Step 7: Verification (验证)\n- 最终交付验证\n- 功能完整性、边界覆盖、文档完整\n- 使用模型：`deepseek/deepseek-v4-pro`\n- Agent：`testing-verifier`\n\n### Step 8: Output (输出)\n- 生成交付物和执行报告\n\n## 迭代机制\n\n测试→反思→优化 形成迭代循环（最多 3 次），测试通过后跳出。\n\n## 复杂度等级\n\n| 等级 | 描述 | 流程 |\n|------|------|------|\n| A级 | 简单单一功能 | 编码 → 测试 → 验证 |\n| B级 | 中等多模块 | 设计 → 编码 → 测试 → 验证 |\n| C级 | 复杂完整系统 | 完整八步流程 |\n\n## 输出要求\n\n1. 每个阶段结束后，输出阶段总结\n2. 将关键决策记录到 scratchpad\n3. 将任务结果记录到 scratchpad\n4. 最终输出完整的执行报告\n\n## 上下文信息\n\n你可以通过 ScratchpadManager 访问以下信息：\n- 设计决策 (design_decisions.md)\n- 测试发现 (test_findings.md)\n- 代码片段 (code_snippets.md)\n- 任务状态 (task_status.md)\n\n## 使用的模型（v3.3）\n\n| 阶段 | 模型 | Soul |\n|------|------|------|\n| 设计/分解 | `xiaomimimo/mimo-v2.5-pro` | software-architect |\n| 编码 | `xiaomimimo/mimo-v2.5-pro` | senior-developer |\n| 审查 | `deepseek/deepseek-v4-pro` | code-reviewer |\n| 测试 | `xiaomimimo/mimo-v2.5-pro` | api-tester |\n| 优化 | `deepseek/deepseek-v4-pro` | optimizer |\n| 验证 | `deepseek/deepseek-v4-pro` | verifier |\n\nFile v3.7.17:prompts/worker_engineering.md\n\n# Engineering Worker Prompt\n\n你是 Auto-Coding v3.3 的 Engineering Worker，负责代码实现和优化。\n\n## 你的职责\n\n1. **理解任务**：仔细阅读任务描述和上下文\n2. **生成代码**：根据需求实现功能代码\n3. **优化改进**：持续优化代码质量和性能\n4. **修复问题**：根据测试反馈修复代码问题\n\n## 任务信息\n\n### 任务描述\n{task_description}\n\n### 详细需求\n{prompt}\n\n### 上下文信息\n{context}\n\n## 代码生成原则（编码纪律）\n\n### 1. 极简主义\n- 只写被要求的代码，不加额外功能\n- 不为\"未来可能的需求\"预留接口\n- 如果 200 行能缩减到 50 行，重写它\n\n### 2. 手术刀修改\n- 精准打击，只修改必须修改的地方\n- 不碰无关代码\n- 遵循现有代码风格\n\n### 3. 完整性\n- 给出完整可运行的代码\n- 包含所有必要的 import\n- 处理边界情况和异常\n\n### 4. 可读性\n- 使用清晰的命名\n- 添加必要的注释\n- 遵循语言的最佳实践\n\n### 5. 可维护性\n- 模块化设计\n- 单一职责原则\n- 避免重复代码\n\n### 6. 测试友好\n- 函数式设计，便于测试\n- 返回值清晰\n- 副作用最小化\n\n## 输出格式\n\n请按以下格式输出：\n\n```markdown\n## 实现说明\n[简要说明实现方案]\n\n## 代码\n```python\n# 完整代码\n```\n\n## 注意事项\n[如有需要注意的点]\n```\n\n## 常见任务类型\n\n### 1. 功能实现\n根据需求描述实现完整功能。\n\n### 2. Bug 修复\n根据问题描述修复现有代码中的 bug。\n\n### 3. 代码优化\n在保持功能不变的前提下优化代码（性能、可读性等）。\n\n### 4. 重构\n改进代码结构，提高可维护性。\n\n## 与 Testing Worker 协作\n\n1. 完成代码实现后，等待 Testing Worker 的反馈\n2. 如果测试发现问题，根据反馈修复代码\n3. 修复后再次提交给 Testing Worker 验证\n\n## 使用的模型（v3.3）\n\n| 场景 | 模型 |\n|------|------|\n| 核心编码 | `xiaomimimo/mimo-v2.5-pro` |\n| 前端编码 | `xiaomimimo/mimo-v2.5-pro` |\n| 架构设计 | `xiaomimimo/mimo-v2.5-pro` |\n| 代码优化 | `deepseek/deepseek-v4-pro` |\n\n## 注意事项\n\n1. 不要生成不完整的代码片段\n2. 确保代码可以直接运行\n3. 如果需求不明确，做合理假设并在说明中注明\n4. 优先考虑正确性，再考虑性能\n5. **强制要求**：函数参数和返回值必须加类型注解\n\nFile v3.7.17:README-FULL.md\n\n# Auto-Coding v3.6.1 — 完整文档\n\n**版本**: v3.6.1\n**更新日期**: 2026-05-21\n\n---\n\n## 📖 目录\n\n1. [概述](#概述)\n2. [快速开始](#快速开始)\n3. [核心架构](#核心架构)\n4. [模型分配](#模型分配)\n5. [内嵌 Agent Soul](#内嵌-agent-soul)\n6. [使用指南](#使用指南)\n7. [配置说明](#配置说明)\n8. [文件清单](#文件清单)\n9. [故障排除](#故障排除)\n10. [更新日志](#更新日志)\n\n---\n\n## 概述\n\n### 什么是 Auto-Coding？\n\n**Auto-Coding** 是一个智能自主编码系统，通过多角色 Soul + 多模型切换，完成从需求到代码的完整开发流程。\n\n**核心理念**: 不是任务分发器，而是自我完善的智能编程系统。它利用不同角色的专业视角和不同模型的风格互补，进行设计→分解→编码→测试→反思→优化→验证→输出，实现多维度的自我审查和自我优化，提升代码可执行率。\n\n**v3.3 关键变更**:\n- ✅ **内嵌 8 个 Agent Soul**：不再依赖外部 `agency-agents` 目录，编码专用 Soul 内置\n- ✅ **双模型驱动**：MiMo v2.5 Pro + DeepSeek v4 Pro\n- ✅ **按阶段分配模型**：设计/编码/审查/测试/优化/验证各用不同模型\n- ✅ **状态持久化**：项目级 `.auto-coding/state.json`，session 断了可恢复\n- ✅ **审批策略**：项目级 `.auto-coding/rules.yaml`，敏感操作自动拦截\n- ✅ **Cron 监控**：任务启动后自动创建 cron job，每 5 分钟轮询状态，终态自动飞书通知\n\n### 适用场景\n\n✅ **推荐使用**:\n- 复杂项目开发（多任务依赖）\n- 技术方案设计和实现\n- 代码审查和优化\n- RoundTable 研讨后的编码实现\n\n❌ **不推荐**:\n- 简单单文件修改（直接让主 Agent 写更快）\n- 需要立即回答的问题\n- Token 预算有限的场景\n\n---\n\n## 快速开始\n\n### 1. 环境要求\n\n- OpenClaw 2026.5.7+\n- `xiaomimimo` + `deepseek` provider 已配置\n- `openclaw` CLI 可用\n\n```bash\n# 验证\nopenclaw --version\nopenclaw infer model run --model xiaomimimo/mimo-v2.5-pro --prompt \"hello\" --json --local\n```\n\n### 2. 基本使用\n\n```python\nimport asyncio\nfrom auto_coding_workflow import AutoCodingWorkflow\n\nasync def main():\n    workflow = AutoCodingWorkflow(\n        requirements=\"写一个计算两个列表交集的 Python 函数，要求有类型注解和文档字符串\",\n        timeout_minutes=10\n    )\n    result = await workflow.run()\n    print(result)\n\nasyncio.run(main())\n```\n\n### 3. 增强版工作流（推荐）\n\n```python\nfrom workflow_enhanced import AutoCodingWorkflowEnhanced\n\nworkflow = AutoCodingWorkflowEnhanced(\n    requirements=\"实现用户登录功能\",\n    project_dir=\"./my-project\",   # 必须：用于存储配置和状态\n    resume=True,                  # 自动恢复未完成的任务\n)\nawait workflow.run()\n```\n\n第一次运行会自动生成：\n- `.auto-coding/workflow.yaml.template` → 复制为 `workflow.yaml` 自定义流程\n- `.auto-coding/rules.yaml.template` → 复制为 `rules.yaml` 自定义审批规则\n\n---\n\n## 核心架构\n\n### 本质\n\n**单进程串行 + 多角色 Soul + 多模型切换**\n\n不是真正的多 Agent 并行 spawn（并发风险高），而是同一个 Python 进程串行执行，每一步换不同的模型和 Soul prompt，换不同的人格和视角来审视代码。\n\n### 八步循环\n\n```\n设计(Design) → 分解(Decomposition) → 编码(Coding) → 测试(Testing)\n    ↑____________________________________________________↓\n                         反思(Reflection) → 优化(Optimization)\n                                                 ↓\n验证(Verification) → 输出(Output)\n```\n\n**迭代逻辑**: 测试→反思→优化 形成迭代循环（最多 3 次），测试通过后跳出。\n\n### 模型调用链\n\nPython 脚本无法直接 import `openclaw.tools`，改用 CLI 调用：\n\n```\nopenclaw infer model run\n    --model xiaomimimo/mimo-v2.5-pro\n    --prompt \"[SYSTEM]\\n{system_prompt}\\n\\n[USER]\\n{task_prompt}\"\n    --json\n    --local\n```\n\n解析 JSON 返回的 `outputs[0].text`，拿到真实代码。\n\n---\n\n## 模型分配\n\n### 按阶段分配（v3.4.1）\n\n| 阶段 | Soul 角色 | 说明 |\n|------|----------|------|\n| 设计/分解 | software-architect | 综合最强，架构权衡、方案对比 |\n| 编码 | senior-developer | 代码专用，类型注解规范 |\n| 审查 | code-reviewer | 逻辑推理独特优势 |\n| 前端编码 | frontend-developer | 代码专用 |\n| 后端架构 | backend-architect | 综合最强 |\n| 测试 | api-tester | 全面严谨 |\n| 优化 | **optimizer** | **最优雅实现** |\n| 验证 | **verifier** | **严谨全面** |\n\n### 关键原则\n\n- **auto-coding 要质量不要速度**：优先选择能力最强的模型\n- **模型可通过环境变量覆盖**：`AUTO_CODING_MODEL_<ROLE>=provider/model`\n- **Fallback 可配置**：`AUTO_CODING_FALLBACK_MODELS=provider/model1,provider/model2`\n\n---\n\n## 内嵌 Agent Soul\n\nv3.4 起，8 个编码专用 Soul 直接内嵌在 `agent_soul_loader.py` 中，**不再依赖外部目录**。\n\n| Agent ID | 名称 | 专长 |\n|----------|------|------|\n| `engineering-software-architect` | 软件架构师 | 架构设计、DDD、系统思维 |\n| `engineering-backend-architect` | 后端架构师 | 分布式系统、数据库、API 设计 |\n| `engineering-senior-developer` | 高级开发工程师 | Python 实现、类型注解、性能优化 |\n| `engineering-frontend-developer` | 前端工程师 | React/Vue、组件设计、性能 |\n| `engineering-code-reviewer` | 代码审查专家 | PR 审查、安全、最佳实践 |\n| `testing-api-tester` | API 测试工程师 | 接口测试、边界条件、幂等性 |\n| `engineering-optimizer` | **代码优化工程师** | 优雅重构、性能最优 |\n| `testing-verifier` | **交付验证工程师** | 功能完整性、边界覆盖 |\n\n如需扩展 Soul，可通过 `agency_path` 参数指定外部目录作为补充。\n\n---\n\n## 使用指南\n\n### A 级快速通道（单函数 / 小 Bug）\n\n直接用 `AutoCodingWorkflow`，不走完整八步：\n\n```python\nworkflow = AutoCodingWorkflow(\n    requirements=\"写一个斐波那契数列函数\",\n    timeout_minutes=2\n)\nresult = await workflow.run()\n```\n\n### B 级中等任务（新功能模块）\n\n预定义任务列表：\n\n```python\ntasks = [\n    {'id': 1, 'name': '设计数据库模型', 'depends_on': []},\n    {'id': 2, 'name': '实现 CRUD API', 'depends_on': [1]},\n    {'id': 3, 'name': '编写单元测试', 'depends_on': [2]},\n]\n\nworkflow = AutoCodingWorkflow(\n    requirements=\"实现用户管理模块\",\n    tasks=tasks,\n    timeout_minutes=30\n)\nresult = await workflow.run()\n```\n\n### C 级复杂项目（完整系统）\n\n使用增强版工作流：\n\n```python\nworkflow = AutoCodingWorkflowEnhanced(\n    requirements=\"开发一个完整的电商后台管理系统\",\n    project_dir=\"./ecommerce-admin\",\n    resume=True,\n)\nresult = await workflow.run()\n```\n\n---\n\n## 配置说明\n\n### 项目级配置（`.auto-coding/workflow.yaml`）\n\n```yaml\nphases:\n  - name: design\n    agent: engineering-software-architect\n    model: xiaomimimo/mimo-v2.5-pro\n    enabled: true\n  - name: implementation\n    agent: engineering-senior-developer\n    model: xiaomimimo/mimo-v2.5-pro\n    enabled: true\n  - name: review\n    agent: engineering-code-reviewer\n    model: xiaomimimo/deepseek/deepseek-v4-pro\n    enabled: true\n  - name: optimization\n    agent: engineering-optimizer\n    model: xiaomimimo/DeepSeek v4 Pro\n    enabled: true\n  - name: verification\n    agent: testing-verifier\n    model: xiaomimimo/DeepSeek v4 Pro\n    enabled: true\n```\n\n### 审批规则（`.auto-coding/rules.yaml`）\n\n```yaml\nauto_approve_edit:\n  - \"src/*\"\n  - \"test/*\"\n  - \"*.py\"\n  - \"*.js\"\n  - \"*.md\"\n\nrequire_approval_edit:\n  - \"config/*\"\n  - \".env*\"\n  - \"*.config.js\"\n\nrequire_approval_delete:\n  - \"*\"  # 删除任何文件都需要审批\n\nnotify_on_complete: true\n```\n\n### 状态文件（`.auto-coding/state.json`）\n\n```json\n{\n  \"version\": \"1.0\",\n  \"task_id\": \"ac-xxxx\",\n  \"requirements\": \"...\",\n  \"current_phase\": \"implementation\",\n  \"completed_phases\": [\"design\", \"decomposition\"],\n  \"results\": { ... },\n  \"approval_queue\": []\n}\n```\n\n---\n\n## 文件清单\n\n| 文件 | 行数 | 说明 |\n|------|------|------|\n| `auto_coding_workflow.py` | ~950 | 主工作流（八步循环） |\n| `workflow_enhanced.py` | ~650 | 增强版工作流（状态+审批+通知） |\n| `workers/base_worker.py` | ~300 | Worker 基类（含模型调用） |\n| `workers/engineering_worker.py` | ~280 | EngineeringWorker |\n| `workers/testing_worker.py` | ~310 | TestingWorker |\n| `workers/reviewer_worker.py` | ~250 | ReviewerWorker（否决权） |\n| `agent_soul_loader.py` | ~350 | Soul 加载器（内嵌 8 个 Soul） |\n| `state_manager.py` | ~260 | 状态持久化 |\n| `approval_rules.py` | ~270 | 审批规则引擎 |\n| `feishu_notifier.py` | ~240 | 飞书通知 |\n| `check_auto_coding_status.py` | ~220 | Cron 监控脚本 |\n| `complexity_analyzer.py` | ~200 | 复杂度自动分级（A/B/C） |\n| `phase_model_allocator.py` | ~370 | 模型分配 |\n| `model_selector.py` | ~300 | 模型选择器 |\n| `dependency_manager.py` | ~450 | 依赖管理 |\n| `workflow_config.py` | ~200 | 配置加载器 |\n| `task_manager.py` | ~150 | 任务管理 |\n| `SKILL.md` | ~400 | Skill 入口文档 |\n| `PROJECT.md` | ~300 | 项目过程文档 |\n| `README-FULL.md` | 本文件 | 完整文档 |\n\n---\n\n## 故障排除\n\n### 模型调用返回空 / 失败\n\n**现象**: `⚠️ 模型调用失败: Error: No text output returned...`\n\n**排查**:\n```bash\n# 1. 验证 CLI 可用\nopenclaw infer model run --model xiaomimimo/mimo-v2.5-pro --prompt \"hello\" --json --local\n\n# 2. 检查模型是否在 models.json 中配置\nopenclaw models list | grep xiaomimimo\n\n# 3. 检查 API Key 是否有效\n# 火山引擎 Coding Plan 需要单独购买，确保额度充足\n```\n\n### Soul 加载为 0 个\n\n**现象**: `⚠️ 未找到 agency-agents，使用默认路径`\n\n**解决**: v3.3 已内嵌 8 个 Soul，此警告不影响功能。如需外部 Soul，设置环境变量：\n```bash\nexport AUTO_CODING_AGENCY_PATH=/path/to/agency-agents\n```\n\n### 状态恢复失败\n\n**现象**: `resume=True` 但从头开始\n\n**排查**:\n- 确认 `project_dir/.auto-coding/state.json` 存在\n- 确认 `current_phase` 不是 `completed`/`failed`/`rejected`\n\n---\n\n## 更新日志\n\n### v3.3 (2026-05-09)\n- **新增**: 项目级配置 (`workflow.yaml`)、审批规则 (`rules.yaml`)\n- **新增**: 状态持久化 (`state.json`)，支持断点续传\n- **新增**: Cron 自动监控 + 飞书通知\n- **新增**: 2 个 Soul（optimizer、verifier），共 8 个内嵌 Soul\n- **新增**: 按阶段模型分配（设计/编码/审查/测试/优化/验证各用不同模型）\n- **修复**: 模型调用链改用 `openclaw infer model run --json --local`\n- **修复**: Soul 内嵌化，不再依赖外部 `agency-agents` 目录\n- **修复**: Fallback 模型改为 `xiaomimimo/MiMo v2.5 Pro`\n\n### v3.2 (2026-04-27)\n- **迁移**: 全量迁移到 `xiaomimimo` provider\n- **测试**: 8 个模型全量测试（速度 3s ~ 106s）\n- **分配**: Coordinator→doubao-pro, Engineering→doubao-code, Reviewer→deepseek, Testing→doubao-lite\n- **修复**: ReviewerWorker 过度批评问题（新增审查边界约束）\n\n### v3.1 (2026-04-20)\n- **设计**: 多 Agent 协作架构（Coordinator/Engineering/Review/Testing）\n- **约束**: 发现子 Agent 跨 provider 限制\n\n### v2.0 (2026-03-25)\n- **融合**: Auto-Coding + Karpathy 编码铁律\n- **铁律**: 思考优先、极简主义、手术刀修改、目标导向\n\n### v1.1.0 (2026-03-20)\n- **增强**: 上下文管理、依赖管理、超时保护\n\n### v1.0.0 (2026-03-19)\n- **初版**: 八步循环工作流\n\n---\n\n*Last updated: 2026-05-09 | Auto-Coding v3.3*\n\nFile v3.7.17:skill-card.md\n\n## Description:\n\nAuto Coding V3 coordinates an autonomous coding workflow with staged skill injection, code review, testing, verification, and risk scorecard checks.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[krislu1221](https://clawhub.ai/user/krislu1221)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineering teams use this skill to drive multi-phase coding work from requirements through implementation, review, testing, and delivery verification. It is intended for project-scoped coding tasks where staged checks and explicit approvals are useful.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Advertised discipline and scorecard guardrails may be stronger than the behavior guaranteed by the package.\n\nMitigation: Review the skill before installation and explicitly enable and verify discipline or scorecard modes when relying on those checks.\n\nRisk: The skill writes persistent local workflow files that may contain task details, file paths, test results, or code context.\n\nMitigation: Run the skill only on an intended project directory, keep .auto-coding/ and /tmp/auto-coding-projects out of version control, and clean local state after use when appropriate.\n\nRisk: Optional external notifications or background scheduling can expose task summaries or create local automation if enabled.\n\nMitigation: Leave notifications and scheduling disabled unless intentionally opted in, and verify cleanup after the task completes.\n\n## Reference(s):\n\n- [ClawHub Skill Page](https://clawhub.ai/krislu1221/skills/auto-coding-skill)\n- [README](artifact/README.md)\n- [Skill Definition](artifact/SKILL.md)\n- [Design Document](artifact/DESIGN.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown or text guidance with code, configuration, and shell command snippets]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Single-stream agent output; the skill may also create or update project files and local workflow state/log files when run.]\n\n## Skill Version(s):\n\n3.7.17 (source: server release metadata and target metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v3.7.17:skills/code-review.skill.md\n\n---\nname: code-review\ndescription: \"代码审查——Reviewer 否决权 🔴🟡💭 分级、审查边界定义、Risk Scorecard 集成\"\ntype: skill\ninject_phase: Step 5 反思\nversion: \"1.0.0\"\n---\n\n# Code-Review：代码审查\n\n## 1. Overview（概述）\n\n代码审查不是走过场。本技能定义 Reviewer 的三级否决权（🔴 阻塞 / 🟡 警告 / 💭 建议）、审查边界和 Risk Scorecard 集成，确保审查结果可量化、可追溯。\n\n**核心原则**：\n- Reviewer 说了算 — 审查不通过必须打回重做\n- 不审查实现细节 — 审查契约、安全、架构、可维护性\n- 每个 review comment 必须关联一个 Risk Scorecard 条目\n\n## 2. When to Use（使用条件）\n\n**触发条件**：\n- Step 5 反思阶段自动注入（与 zoom-out 配对）\n- B 级 / C 级任务强制执行\n- A 级任务简化版（仅检查安全 + 需求对齐）\n\n**可跳过**：\n- 纯配置修改（无逻辑变更）\n- 文档修改\n\n## 3. Process（执行流程）\n\n### 3.1 Reviewer 三级否决权\n\n```\n🔴 阻塞（Blocking）：不允许合入，必须修复\n  ├─ 安全漏洞：SQL 注入、XSS、未验证用户输入、密钥泄露\n  ├─ 不符合需求：与 CONTEXT.md / ADR 中的决定矛盾\n  ├─ 严重过度设计：500 行完成的功能用了 1500 行\n  ├─ 破坏现有功能：回归测试失败\n  └─ 动作：打回重做，不进入下一阶段\n\n🟡 警告（Warning）：强烈建议修改，但不阻塞\n  ├─ 不必要的抽象（Rule of Three 违反）\n  ├─ 命名不一致（但不破坏功能）\n  ├─ 缺少必要注释（复杂逻辑）\n  ├─ 代码重复（同一概念 ≥ 2 处）\n  └─ 动作：记录，下次审查检查是否处理\n\n💭 建议（Informational）：仅供参考，可选\n  ├─ 代码风格微调\n  ├─ 替代方案建议（不改变功能）\n  ├─ 性能优化机会（非关键路径）\n  └─ 动作：记录，不跟踪处理状态\n```\n\n### 3.2 审查边界\n\n```\n✅ 审查这些（必须）：\n  - 接口契约：输入/输出是否与设计一致\n  - 安全：所有用户输入是否经过验证\n  - 架构：是否违反分层、引入不当耦合\n  - 测试质量：测试是否覆盖边界和错误路径\n  - 需求对齐：代码是否实现（且只实现）了需求\n\n❌ 不审查这些：\n  - 实现方式的选择（除非明显错误）— 尊重工程师判断\n  - 代码风格（除非团队有明确规范）— 不因个人偏好打回\n  - 命名偏好（除非误导性命名）— 不因\"我更喜欢 X\"打回\n  - 未来扩展性（YAGNI）— 不因\"以后可能需要\"要求加抽象\n```\n\n### 3.3 Risk Scorecard 集成\n\n```\n审查流程：\n1. 每个 review comment → 寻找对应的 Scorecard 条目\n2. 命中条目 → 引用条目编号，启用量化信号检测\n3. 未命中条目 且 level = 🔴 → 检查是否需要在 Scorecard 中新增该条目\n4. 输出：Scorecard Report（阻塞/警告/通过统计）\n```\n\n### 3.4 审查输出格式\n\n```\n## Code Review Report\n\n### 🔴 阻塞项（{n} 项）\n- [ ] {描述} → 关联 Scorecard: {条目编号}\n\n### 🟡 警告项（{n} 项）\n- [ ] {描述} → 关联 Scorecard: {条目编号}\n\n### 💭 建议项（{n} 项）\n- {描述}\n\n### 迭代统计\n- 当前迭代: {n}/{3}\n- 上次阻塞: {n} 项 → 本次: {m} 项\n```\n\n## 4. Risk Scorecard（反借口表）\n\n| # | 纪律 | 常见借口 | 反驳 |\n|---|------|---------|------|\n| C1 | 🔴 阻塞项必须修复 | \"这个安全问题是理论上的，实际不会被利用\" | 安全问题不分理论和实际 |\n| C2 | 不审查实现方式 | \"这个设计不好，换个写法\" | 能 work + 可读 + 有测试 = 够好 |\n| C3 | 尊重需求决策 | \"技术方案可以更优雅\" | 需求指定的做法就是对的 |\n| C4 | 不因未来需求加复杂度 | \"以后可能需要支持...\" | YAGNI — 未来的需求有未来的工程师 |\n| C5 | 每个评论关联 Scorecard | \"这个不用引用，一看就知道\" | 不量化的审查 = 不可审计 |\n\n## 5. Red Flags（危险信号）\n\n- 🚩 审查时间 < 30 秒（对任何非 A 级任务）— 可能跳过了关键检查\n- 🚩 只有 💭 项没有 🔴/🟡 — 可能过于宽松（除非代码确实完美）\n- 🚩 只有一个 🔴 但涉及安全 — 安全相关的 🔴 通常不止一个\n- 🚩 同一 🔴 项连续两次迭代出现 — 修复未生效或 root cause 未被解决\n- 🚩 🔴 项 = 0 但 🟡 ≥ 5 — 考虑提升部分 🟡 到 🔴\n- 🚩 审查后代码行数增加 > 20% — 可能有过度设计\n\n## 6. Verification（自检清单）\n\n**必检（≤5 项）**：\n- [ ] zoom-out 分析已完成（在 code-review 之前）\n- [ ] Risk Scorecard 量化检测已运行\n- [ ] 🔴 阻塞项已全部解决（无未解决的 🔴）\n- [ ] Scorecard Report 已写入阶段日志\n- [ ] 没有过度批评（需求要求的做法已被尊重）\n\n**抽检（≤3 项）**：\n- [ ] 🟡 警告项有处理计划（接受/修复/推迟，每项标注）\n- [ ] 跨模块问题已识别（zoom-out 中的 🔴 项在 review 中被引用）\n- [ ] 迭代次数统计正确（≤3 次上限）\n\n**免检**：审查措辞、审查顺序、审查模式（AI vs 人工偏好）\n\nFile v3.7.17:skills/decomposition.skill.md\n\n---\nname: decomposition\ndescription: \"任务分解纪律——将需求拆解为独立、可并行、有明确 Done 标准的子任务\"\ntype: skill\ninject_phase: Step 2 分解\nversion: \"1.0.0\"\n---\n\n# Decomposition：任务分解\n\n## 1. Overview（概述）\n\n复杂需求不拆 = 估计偏差 + 执行混乱。本技能将需求按依赖关系拆解为无环的子任务 DAG，每个子任务有明确的 Done 标准和可验证的输出。\n\n**核心原则**：\n- 粒度 = 一个子任务只改一个关注点（通常 ≤1 个文件）\n- 依赖无环（DAG）— 子任务间不能有循环依赖\n- 关键路径优先 — 阻塞其他任务的先做\n\n## 2. When to Use（使用条件）\n\n**触发条件**：\n- Step 2 分解阶段自动注入\n- C 级任务强制执行\n- B 级任务简化版（仅做依赖分析 + 关键路径）\n- 需求涉及 ≥ 2 个可独立交付的子功能\n\n**可跳过**：\n- A 级任务（micro fix，不需要分解）\n- 单一函数/文件的修改\n\n## 3. Process（执行流程）\n\n### 3.1 分解四步法\n\n```\n步骤 1: 功能点枚举\n  ├─ 从 Step 1 的范围声明中提取所有功能点\n  ├─ 每个功能点问：能不能独立交付？不能 → 继续拆\n  └─ 输出：功能点列表（无遗漏、无重复）\n\n步骤 2: 依赖分析\n  ├─ 绘制依赖矩阵：功能 A → 需要 功能 B 先完成？\n  ├─ 检查循环依赖：A 依赖 B → B 依赖 C → C 依赖 A？→ 重新设计\n  ├─ 标识关键路径：从起点到终点的最长依赖链\n  └─ 输出：DAG 图（节点 = 子任务，边 = 依赖）\n\n步骤 3: 粒度检查\n  ├─ 每个子任务 ≤ 1 个文件的改动 → ✅ 粒度合适\n  ├─ 每个子任务 > 3 个文件 → 🟡 可能还需拆分\n  ├─ 每个子任务 > 5 个文件 → 🔴 必须拆更细\n  └─ ❌ 反例：\"写所有 Model\"（太粗）vs \"写 User Model + 测试\"（刚好）\n\n步骤 4: Done 标准定义\n  ├─ 每个子任务必须有可验证的 Done 标准\n  ├─ Done 标准三要素：「什么完成」+「怎么验证」+「交付什么」\n  │   例：✅ \"User 认证 API 完成：/login 返回 JWT，/register 创建用户\"\n  │   ❌ \"写完认证功能\"\n  └─ 输出：子任务清单 + Done 标准\n```\n\n### 3.2 输出格式\n\n```yaml\n# decomposition-output.yaml\ntasks:\n  - id: T1\n    description: \"创建 User Model 和迁移脚本\"\n    files: [\"models/user.py\", \"migrations/001_user.py\"]\n    dependencies: []\n    done_criteria: \"User 表可创建，字段包含 id/email/password_hash\"\n    critical_path: true\n    estimated_complexity: \"B\"\n\n  - id: T2\n    description: \"实现 POST /register 端点\"\n    files: [\"api/auth.py\"]\n    dependencies: [\"T1\"]\n    done_criteria: \"POST /register 接收 email+password，返回 201 + user_id\"\n    critical_path: true\n    estimated_complexity: \"B\"\n```\n\n## 4. Risk Scorecard（反借口表）\n\n| # | 纪律 | 常见借口 | 反驳 |\n|---|------|---------|------|\n| P1 | 每子任务 ≤1 文件 | \"这些 Model 都差不多，一起写效率高\" | 粒度粗 → 估计偏差 → 中间出错全白费 |\n| P2 | 无循环依赖 | \"它们互相需要，循环依赖没办法\" | 有循环 = 设计问题 = 应该提取共享接口 |\n| P3 | 每个子任务有 Done 标准 | \"写完就知道了\" | 不知道 Done 长什么样 = 不知道何时停 |\n| P4 | 关键路径优先 | \"哪个简单先做哪个\" | 关键路径任务延期 = 全部延期 |\n| P5 | 非关键路径可并行 | \"我先全做完再让别人介入\" | 可并行不并行 = 浪费等待时间 |\n\n## 5. Red Flags（危险信号）\n\n- 🚩 任何子任务涉及 > 5 个文件 — 需要拆得更细\n- 🚩 DAG 中有循环依赖 — 重新设计接口\n- 🚩 Done 标准含\"完成\"一词（\"完成认证\"）— 不可验证\n- 🚩 关键路径 > 3 个子任务串行 — 关注单点阻塞风险\n- 🚩 子任务编号不连续或跳跃 — 有意外的遗漏\n- 🚩 预估总子任务 < 功能点数量 — 有需求被遗漏\n\n## 6. Verification（自检清单）\n\n**必检（≤5 项）**：\n- [ ] 任务粒度合理：每个子任务的核心文件 ≤ 3 个（含测试 ≤ 5 个）\n- [ ] 依赖关系无环（DAG 合法，遍历检查无回边）\n- [ ] 每个子任务有明确的 Done 标准（可验证、无歧义）\n- [ ] 关键路径已标识且 ≥ 1 个\n\n**抽检（≤3 项）**：\n- [ ] 子任务编号连续、可追溯（T1, T2, ... 无跳跃）\n- [ ] 预估工作量合理（≤ 函数数 × 2 个子任务）\n- [ ] 可并行的非关键路径任务已标注\n\n**免检**：编号格式、YAML 缩进风格、预估时间精度\n\nArchive v3.7.16: 47 files, 171306 bytes\n\nFiles: __init__.py (1226b), agent_soul_loader.py (16780b), approval_rules.py (8913b), auto_coding_workflow.py (50300b), CHANGELOG.md (19348b), check_auto_coding_status.py (6961b), clawhub.json (759b), complexity_analyzer.py (7110b), configs/scorecard.yaml (4746b), configs/verification-rules.yaml (8326b), dependency_manager.py (15348b), DESIGN.md (10502b), feishu_notifier.py (9244b), model_selector.py (12617b), PROJECT.md (9258b), prompts/coordinator.md (3029b), prompts/worker_engineering.md (2384b), publish_clawhub.sh (1530b), README-FULL.md (11761b), README.md (5705b), scorecard_engine.py (30533b), skill_injector.py (8791b), skill-card.md (2792b), SKILL.md (12360b), skills/code-review.skill.md (5220b), skills/decomposition.skill.md (4587b), skills/diagnose.skill.md (4914b), skills/discipline-meta.skill.md (5064b), skills/grill-with-docs.skill.md (4835b), skills/improve-architecture.skill.md (5136b), skills/optimize.skill.md (4690b), skills/risk-scorecard.skill.md (9529b), skills/tdd.skill.md (5013b), skills/testing.skill.md (4983b), skills/verification.skill.md (5318b), skills/zoom-out.skill.md (3766b), state_manager.py (16485b), task_manager.py (4477b), task_profiler.py (17034b), workers/__init__.py (393b), workers/base_worker.py (13056b), workers/engineering_worker.py (7492b), workers/reviewer_worker.py (8815b), workers/testing_worker.py (7620b), workflow_config.py (11848b), workflow_enhanced.py (62404b), _meta.json (137b)\n\nFile v3.7.16:SKILL.md\n\n---\nname: auto-coding-v3\ndescription: \"智能自主编码系统 v3.7-compliance — 全子代理架构 + 分阶段技能注入。支持 8 步循环、Reviewer 否决权、复杂度自动分级、Risk Scorecard 量化检测。触发词: auto-coding, Auto coding, 启动自动编码\"\nlicense: MIT\n---\n\n# Auto-Coding v3.7-compliance\n\n## 概述 / Overview\n\nAuto-Coding 是一个智能自主编码系统，通过全子代理架构 + 分阶段技能注入，完成从需求到代码的完整开发流程。\n\nAuto-Coding is an intelligent autonomous coding system that completes the full development lifecycle from requirements to code through a fully sub-agent architecture with staged skill injection.\n\n**本质**: 单进程串行 + 多角色 Prompt + 多模型切换。每一步换不同的人格和模型来审视代码，不是真正的多 Agent 并行。\n\n**Essence**: Single-process serial execution + multi-role prompting + multi-model switching. Each step uses a different persona and model to review the code — not true multi-agent parallelism.\n\n**核心特性**:\n- 全子代理架构 — 主会话只做监工，所有干活用子代理执行\n- 分阶段技能注入 — 每阶段注入对应技能文件，≤2 技能/阶段\n- 8 步循环 — 设计→分解→编码→测试→反思→优化→验证→输出\n- Reviewer 否决权 — 审查发现 🔴 阻塞项触发重写，最多 3 次迭代\n- 复杂度自动分级 — A (Micro) / B (Feature) / C (System)，自动跳过不需要的阶段\n- Risk Scorecard — 五元组量化检测，公用信号识别\n- 状态持久化 — `.auto-coding/state.json`，仅保存任务恢复所需摘要，session 断了可恢复\n- 审批策略 — `.auto-coding/rules.yaml`，默认收窄自动批准范围，敏感操作必须确认\n- 进度汇报 — 默认前台逐阶段输出；可选开启通知或调度检查，默认不创建后台 cron\n\n**Key features**:\n- Full sub-agent architecture — main session only supervises; all work delegated to sub-agents\n- Staged skill injection — each phase injects corresponding skill files, ≤2 skills per phase\n- 8-step cycle — Design → Decompose → Code → Test → Reflect → Optimize → Verify → Output\n- Reviewer veto power — 🔴 blockers trigger rewrite, up to 3 iterations\n- Auto complexity grading — A (Micro) / B (Feature) / C (System), auto-skip irrelevant phases\n- Risk Scorecard — 5-tuple quantified detection with public signal recognition\n- State persistence — `.auto-coding/state.json`, stores resumable task summaries only\n- Approval rules — `.auto-coding/rules.yaml`, narrow default auto-approval and require confirmation for sensitive actions\n- Progress reporting — foreground per-phase output by default; optional notification/scheduler check only when explicitly enabled\n\n---\n\n## 设计哲学 / Design Philosophy\n\n1. **思考优先** — 不假设，模糊需求列出假设或直接提问\n2. **极简主义** — 最少代码解决问题，自检\"200 行能否缩到 50 行\"\n3. **手术刀修改** — 只改必须改的，不顺手重构，遵循现有风格\n4. **目标导向** — 先定义 Done 标准再编码，验证通过才算完成\n\n1. **Think first** — Don't assume; list assumptions for ambiguous requirements or ask directly\n2. **Minimalism** — Solve with minimal code; self-check \"can 200 lines shrink to 50?\"\n3. **Scalpel edits** — Only change what's necessary; don't refactor opportunistically; follow existing style\n4. **Goal-oriented** — Define Done criteria before coding; verification pass = completion\n\n---\n\n## 🔴 执行铁律\n\n### 铁律 1: 自动推进，不中途停下\n启动后连续完成所有阶段。只在 3 种情况打断: (1) 需求不明确 (2) 多方案需选择 (3) 安全审批。\n\n### 铁律 2: 全子代理化，主会话只做监工\n所有干活用子代理执行。主会话职责: 分阶段派活、检查文件质量、打回重写、交付结果。\n\n### 铁律 3: 每步输出，不攒到最后\n每阶段完成后立刻在当前会话输出结果（当前阶段、模型、做了什么、发现了什么），然后直接进入下一阶段。这是默认进度汇报机制，避免依赖后台 cron 或外部通知。\n\n---\n\n## 📋 8 步循环流程 + 技能注入\n\n```\n设计 → 分解 → 编码 → 测试 → 反思 → 优化 → 验证 → 输出\n  ↑_______________________________________↓\n              迭代 (最多 3 次)\n```\n\n| 步骤 | 阶段 | 注入技能 | 模型 | 职责 |\n|------|------|---------|------|------|\n| 1 | **设计** | `grill-with-docs` | `deepseek-v4-pro` | 需求对齐、技术方案 |\n| 2 | **分解** | `decomposition` | `deepseek-v4-pro` | 任务拆解、依赖分析 |\n| 3 | **编码** | `tdd` | `deepseek-v4-pro` | TDD 红-绿-重构 |\n| 4 | **测试** | `testing` | `deepseek-v4-pro` | 边界覆盖、回归检测 |\n| 5 | **反思** | `zoom-out` + `code-review` | `deepseek-v4-pro` | 审查、🔴🟡💭 分级 |\n| 6 | **优化** | `optimize` | `deepseek-v4-pro` | 推理重构 |\n| 7 | **验证** | `verification` | `deepseek-v4-pro` | 交付验证 |\n| 8 | **输出** | — | — | 交付物 |\n\n> **注入规则**: 每阶段 ≤2 技能文件，全局文件（`risk-scorecard` + `discipline-meta`）随首次注入附带。注入失败不阻塞流程。\n>\n> **Reviewer 否决权**: 审查发现 🔴 阻塞项（安全漏洞、不符合需求、过度设计）→ 触发重写，最多 3 次迭代。\n> 详细见: `skills/code-review.skill.md`\n>\n> **调试子流程**: 测试失败或否决时触发 6 阶段调试（反馈循环→复现→假设→插桩→修复→清理）。\n> 详细见: `skills/diagnose.skill.md`\n>\n> **模型适配**: 各阶段模型应根据自身模型配置进行重新适配，推荐采用多模型交叉检测与验证的方式，避免单一模型盲区。\n>\n> **Model adaptation**: Each phase's model should be re-adapted based on available model configuration. Multi-model cross-validation is recommended over single-model detection to avoid blind spots.\n\n---\n\n## ⚡ 复杂度自动分级\n\n| 等级 | 特征 | 阶段数 | 典型耗时 |\n|------|------|--------|---------|\n| **A (Micro)** | 单函数、Bug 修复 | 编码→测试→验证 (3) | <2 分钟 |\n| **B (Feature)** | 模块开发、单 API | 设计→编码→测试→验证 (4) | 2-5 分钟 |\n| **C (System)** | 完整系统、多文件重构 | 设计→分解→编码→测试→反思→优化→验证 (7) | 5-15 分钟 |\n\n> A 级至少注入 `grill-with-docs`（需求确认部分）。连续 2 次阻塞自动升级为 B 级。\n\n---\n\n## 🤖 模型分配 + 降级\n\n| 阶段 | 首选 | Fallback 1 | Fallback 2 |\n|------|------|-----------|-----------|\n| 设计/分解 | `deepseek-v4-pro` | `MiMo v2.5 Pro` | — |\n| 编码/测试 | `deepseek-v4-pro` | `MiMo v2.5 Pro` | — |\n| 审查/优化 | `deepseek-v4-pro` | `MiMo v2.5 Pro` | — |\n| 验证 | `deepseek-v4-pro` | `MiMo v2.5 Pro` | — |\n\n**降级原则**: 优先同级别 → 降一级 → 记入日志。\n\n---\n\n## 📝 子代理铁律\n\n所有子代理禁止输出完整内容到对话:\n\n```\n✅ {阶段}完成\n📄 输出文件: {file1}, {file2}, ...\n💡 一句话结论: {核心结论}\n```\n\n---\n\n## 🧠 Karpathy 铁律（精简）\n\n1. **思考优先**: 不假设，模糊需求列出假设或直接提问\n2. **极简主义**: 最少代码解决问题，自检\"200 行能否缩到 50 行\"\n3. **手术刀修改**: 只改必须改的，不顺手重构，遵循现有风格\n4. **目标导向**: 先定义 Done 标准再编码，验证通过才算完成\n\n---\n\n## 📁 技能文件索引\n\n| 技能文件 | 注入阶段 | 职责 |\n|---------|---------|------|\n| `skills/grill-with-docs.skill.md` | Step 1 设计 | 需求对齐、结构化追问、CONTEXT.md 维护 |\n| `skills/decomposition.skill.md` | Step 2 分解 | 任务拆解纪律、依赖分析、粒度检查 |\n| `skills/tdd.skill.md` | Step 3 编码 | TDD 红-绿-重构循环、垂直切片规则 |\n| `skills/testing.skill.md` | Step 4 测试 | 测试策略、边界覆盖、回归检测 |\n| `skills/zoom-out.skill.md` | Step 5 反思 | 全局视角、跨模块依赖分析 |\n| `skills/code-review.skill.md` | Step 5 反思 | Reviewer 审查、🔴🟡💭 分级、Reviewer 否决权 |\n| `skills/optimize.skill.md` | Step 6 优化 | 重构纪律、性能优化检查清单 |\n| `skills/verification.skill.md` | Step 7 验证 | 交付验证清单、阶段聚合 |\n| `skills/diagnose.skill.md` | 调试子流程 | 6 阶段系统化调试 |\n| `skills/improve-architecture.skill.md` | Step 8.5 | 架构健康检查、深层耦合发现 |\n| `skills/risk-scorecard.skill.md` | 全局（首次附带） | Risk Scorecard 五元组、公用信号检测规则 |\n| `skills/discipline-meta.skill.md` | 全局（首次附带） | 元规则、量化上限、override 流程 |\n\n---\n\n## ⚠️ 安全透明声明\n\n### 进度汇报策略\n\n默认情况下，Auto-Coding **不创建后台 cron**，也**不主动发送飞书消息**。进度通过当前会话逐阶段输出：每完成一个阶段立即报告阶段名、产物、发现的问题和下一步。\n\n如用户明确要求“后台跑完通知我 / 开启进度检查”，才启用可选通知机制：\n\n| 模式 | 默认状态 | 数据流向 | 说明 |\n|------|---------|---------|------|\n| 前台逐阶段输出 | ✅ 默认开启 | 当前会话 | 每阶段完成后直接汇报，不产生后台任务 |\n| 终态通知 | ❌ 默认关闭 | 用户指定通知通道 | 仅发送任务标题、任务 ID、阶段摘要和完成状态 |\n| 调度检查 | ❌ 默认关闭 | 宿主调度器 | 仅在用户显式 opt-in 时创建；任务结束后自动删除，并提供手动清理指引 |\n\n### 外部操作\n\n| 操作 | 默认状态 | 数据流向 | 说明 |\n|------|---------|---------|------|\n| 模型推理 | 按宿主配置 | 任务描述 / 必要代码上下文 → 宿主模型服务 | 不读取或发送 API 密钥；具体模型网络路径由宿主环境决定 |\n| 外部通知 | 默认关闭 | 阶段摘要 / 完成状态 → 用户指定通道 | 仅在用户显式开启时使用 |\n| 环境配置 | 可选 | 本地配置 → 模型选择 | 仅读取非密钥模型选择项；不读取 `apiKey`、`baseUrl`、token 等敏感字段 |\n\n### 文件系统\n\n| 操作 | 范围 | 说明 |\n|------|------|------|\n| 读取 | 当前项目目录 | 读取需求相关代码、测试、配置和依赖文件 |\n| 写入代码 | 当前项目目录 | 仅修改任务相关文件；敏感路径需审批 |\n| 状态目录 | `.auto-coding/` | 保存 `state.json`、阶段摘要日志、审批状态和 scratchpad，用于恢复与审计 |\n\n`.auto-coding/` 可能包含任务描述、文件路径、阶段摘要、测试结果和局部代码片段。建议将其加入 `.gitignore`，避免误提交；任务完成后可删除该目录清理本地状态。\n\n### 模型环境变量\n\n```\nAUTO_CODING_MODEL_DESIGN=...     # 设计阶段模型覆盖\nAUTO_CODING_MODEL_DECOMPOSE=...  # 分解阶段模型覆盖\nAUTO_CODING_MODEL_CODE=...       # 编码阶段模型覆盖\nAUTO_CODING_MODEL_TEST=...       # 测试阶段模型覆盖\nAUTO_CODING_MODEL_REVIEW=...     # 审查阶段模型覆盖\nAUTO_CODING_MODEL_OPTIMIZE=...   # 优化阶段模型覆盖\nAUTO_CODING_MODEL_VERIFY=...     # 验证阶段模型覆盖\nAUTO_CODING_FALLBACK_MODEL_1=... # 回退模型 1\nAUTO_CODING_FALLBACK_MODEL_2=... # 回退模型 2\n```\n\n> 所有环境变量均为可选，只用于模型选择或降级策略，不应包含 API 密钥、Base URL、token 或其它敏感配置。\n\n---\n\n## 📦 使用示例\n\n- **A 级**: `auto-coding：写一个 Python 函数计算两个列表的交集` → 编码→测试→验证\n- **B 级**: `Auto coding：实现一个 REST API，支持用户注册和登录` → 设计→编码→测试→验证\n- **C 级**: `启动自动编码：从零搭建一个博客系统，支持文章发布和评论` → 完整 7 阶段\n\n---\n\n## ⚙️ 项目配置\n\n- **状态持久化**: `.auto-coding/state.json` — session 中断自动从上次阶段恢复\n- **审批策略**: `.auto-coding/rules.yaml` — 默认仅自动批准文档类低风险修改；代码修改、命令执行和敏感路径默认要求确认\n- **阶段日志**: `.auto-coding/logs/{order}-{phase}.log` — 每个阶段独立可追溯，建议不提交到版本库\n\n---\n\n*v3.7-compliance · 2026-06-09*\n\nFile v3.7.16:README.md\n\n# Auto-Coding v3.7.16\n\n**版本**: v3.7.16  \n**更新日期**: 2026-06-09\n\n---\n\n## 概述\n\nAuto-Coding 是一个智能自主编码系统，通过多角色 Soul + 多模型切换，完成从需求到代码的完整开发流程：\n\n```text\n设计 → 分解 → 编码 → 测试 → 反思 → 优化 → 验证 → 输出\n```\n\n**本质**：单进程串行 + 多角色 Prompt + 多模型切换。不是真正的多 Agent 并行，而是每一步换不同的人格和模型来审视代码。\n\n## 触发方式\n\n为避免误触发高权限编码流程，ClawHub 版仅建议使用以下明确触发词：\n\n- `auto-coding`\n- `Auto coding`\n- `启动自动编码`\n\n不要用泛化词如“写代码”“开发”“coding”作为自动触发词。\n\n---\n\n## 合规版核心调整\n\n### 1. 进度汇报：默认前台汇报，不默认创建 cron\n\nAuto-Coding 任务步骤多，确实需要持续汇报。合规版采用三层策略：\n\n| 层级 | 默认状态 | 用途 | 合规边界 |\n| --- | --- | --- | --- |\n| 当前会话逐阶段输出 | ✅ 默认开启 | 每阶段完成后立即报告阶段、产物、风险和下一步 | 不创建后台任务，不外发消息 |\n| 状态文件恢复 | ✅ 默认开启 | session 中断后从 `.auto-coding/state.json` 恢复 | 仅写本地项目目录 |\n| 后台调度 / 外部通知 | ❌ 默认关闭 | 用户离开会话后需要终态通知或进度检查 | 必须用户显式 opt-in，任务结束后清理 |\n\n因此，不做默认 cron 并不等于没有进度：**前台执行时每一步都会汇报**。只有当用户明确说“后台跑完通知我 / 开启进度检查”时，才建议由宿主环境创建可清理的调度任务。\n\n### 2. 飞书 / 外部通知：默认关闭，显式开启\n\n飞书通知不是默认行为。启用后只发送最小必要摘要：任务标题、任务 ID、当前阶段、完成状态、少量阶段摘要。不会发送 API Key、token、完整代码或大段上下文。\n\n### 3. 状态、日志、scratchpad\n\nAuto-Coding 会在项目内写入 `.auto-coding/`，用于恢复、审批和审计。可能包含：\n\n- `state.json`：任务 ID、阶段状态、完成状态、时间戳。\n- `logs/`：阶段摘要、测试结果、风险评分。\n- `pending_approval.json`：等待用户确认的操作。\n- scratchpad / output：中间推理摘要或交付摘要。\n\n合规建议：\n\n- `.auto-coding/` 已加入 `.gitignore`。\n- 不应提交 `.auto-coding/` 到远程仓库。\n- 任务完成后可删除 `.auto-coding/` 清理本地状态。\n\n### 4. 自动批准策略收窄\n\n默认仅自动批准低风险文档变更：\n\n```yaml\nauto_approve:\n  edit:\n    - \"docs/*\"\n    - \"*.md\"\n  run: []\n  create:\n    - \"docs/*\"\n    - \"*.md\"\n```\n\n以下操作默认需要确认：\n\n- 修改代码文件：`*.py`、`*.js`、`*.ts`、`src/*`、`tests/*` 等。\n- 修改配置、CI、环境文件。\n- 删除任何文件。\n- 运行任何命令，包括测试和构建命令。\n\n### 5. 表达式求值与命令执行\n\n- 风险阈值表达式使用 AST 白名单解释器，不使用动态代码执行。\n- 技能默认不通过 CLI 创建 cron，也不默认执行外部命令。\n- 需要运行测试、构建、发布、调度等命令时，必须经审批规则确认。\n\n---\n\n## 快速开始\n\n```python\nimport asyncio\nfrom workflow_enhanced import AutoCodingWorkflowEnhanced\n\nasync def main():\n    workflow = AutoCodingWorkflowEnhanced(\n        requirements=\"auto-coding：实现用户登录功能\",\n        project_dir=\"./my-project\",\n        resume=True,\n    )\n    await workflow.run()\n\nasyncio.run(main())\n```\n\n第一次运行会生成配置模板：\n\n- `.auto-coding/workflow.yaml.template`\n- `.auto-coding/rules.yaml.template`\n\n复制为实际配置后即可自定义阶段和审批策略。\n\n---\n\n## 文件清单\n\n| 文件 | 说明 |\n| --- | --- |\n| `auto_coding_workflow.py` | 主工作流（八步循环） |\n| `workflow_enhanced.py` | 增强版（状态 + 审批 + 前台进度汇报） |\n| `workers/base_worker.py` | Worker 基类（含模型调用） |\n| `workers/reviewer_worker.py` | ReviewerWorker（否决权） |\n| `approval_rules.py` | 审批规则引擎，默认收窄 auto-approve |\n| `scorecard_engine.py` | 风险评分与阈值判断 |\n| `state_manager.py` | 状态持久化 |\n| `SKILL.md` | Skill 入口文档 |\n\n---\n\n## 数据处理透明度\n\n| 行为 | 默认状态 | 数据范围 | 用户控制 |\n| --- | --- | --- | --- |\n| 读取项目文件 | 开启 | 当前任务相关代码、测试、配置 | 通过任务范围和项目目录控制 |\n| 写入代码文件 | 按需 | 当前项目目录内任务相关文件 | 敏感文件需确认 |\n| 写入 `.auto-coding/` | 开启 | 状态、日志、审批、scratchpad | 可删除；应加入 `.gitignore` |\n| 模型推理 | 按宿主环境 | 任务描述与必要代码上下文 | 由宿主模型配置决定 |\n| 外部通知 | 默认关闭 | 任务 ID、阶段摘要、完成状态 | 仅显式开启 |\n| 后台调度 | 默认关闭 | 任务 ID、状态检查摘要 | 仅显式开启，结束后清理 |\n\n> 隐私提醒：如果任务涉及敏感业务逻辑，`.auto-coding/`、模型上下文和可选通知摘要都可能包含相关信息。请限制项目目录、关闭外部通知，并在任务完成后清理状态目录。\n\n---\n\n## 更新日志\n\n| 版本 | 日期 | 关键变更 |\n| --- | --- | --- |\n| v3.7.16 | 2026-06-09 | ClawHub 合规修正：收窄触发词、默认关闭 cron/通知、收窄 auto-approve、披露 `.auto-coding/`、移除动态表达式执行 |\n| v3.7.x | 2026-05 | 全子代理架构、分阶段技能注入、Reviewer 否决权、Risk Scorecard |\n\n---\n\n*Last updated: 2026-06-09 | Auto-Coding v3.7.16 compliance release*\n\nFile v3.7.16:_meta.json\n\n{\n  \"ownerId\": \"kn71pbmkb9h8sppk4yg6dn7zad808rvt\",\n  \"slug\": \"auto-coding-skill\",\n  \"version\": \"3.7.16\",\n  \"publishedAt\": 1781007748104\n}\n\nFile v3.7.16:CHANGELOG.md\n\n# Auto-Coding 更新日志\n\n---\n\n## v3.6.2 (2026-05-21) | Verifier 硬否决 + 子 Agent 断线恢复\n\n### ✨ 新增特性\n\n**1. Verifier 硬否决逻辑**\n- Reviewer 否决后不再只是一条记录，而是真正把任务打回 coding 阶段重写\n- 新增 `veto_retry_count` / `veto_retry_max` / `veto_retry_history` 追踪否决历史\n- 重试上限默认 3 次，超出后升级给人类审批，避免无限循环\n- 每次否决记录时间、违规数量、反馈上下文\n\n**2. 子 Agent 断线恢复**\n- 每个阶段执行失败时会记录到 `failed_agents` 状态\n- 恢复策略三级：retry（重试）→ fallback（换模型）→ escalate（升级给人类）\n- 默认 3 次全局 recovery 预算（跨阶段共享），预算耗尽后任务才报错终止\n- `record_agent_failure()` / `has_recovery_budget()` / `get_recovery_action()` / `clear_phase_failures()` 配套方法\n\n### 🔧 内部变更\n- `WorkflowState`: 新增 `veto_retry_count`、`veto_retry_max`、`veto_retry_history`、`failed_agents`、`agent_recovery_attempts` 字段\n- `_state_to_dict` / `_dict_to_state`: 序列化新增字段\n- `run()`: 阶段异常捕获增加 recovery 决策分支\n- `run()`: Reviewer 否决逻辑增加重试上限检查\n- 版本号: v3.6.1 → v3.6.2\n\n---\n\n## v3.6.1 (2026-05-21) | 猫王审查 文档一致性修复\n\n本次只改文档/版本号，没有改逻辑。\n\n### 🔴 P0 修复：版本号全面不一致\n- `SKILL.md` 标题：v3.6 → **v3.6.1**\n- `SKILL.md` description：v3.6 → **v3.6.1**\n- `SKILL.md` 底部时间戳：2026-05-11/v3.4.1 → **2026-05-21/v3.6.1**\n- `__init__.py`：__version__ 从 `3.4.1` → **`3.6.1`**，docstring v3.4 → **v3.6.1**\n- `workflow_enhanced.py` docstring：v3.4 → **v3.6.1**\n- `workflow_enhanced.py` 启动消息：v3.4 → **v3.6.1**\n- `README-FULL.md`：v3.4.1 → **v3.6.1**、日期 2026-05-13 → **2026-05-21**\n- `HEARTBEAT_TEMPLATE.md`：模板标题 v3.6.0 → **v3.6.1**\n\n保留的“历史版本标记”（不改）：注释里“v3.4引入 TDD”这类说明特性起源的文字，是有意保留的变更记录。\n\n### 🟡 P1 修复：Heartbeat 频率描述矛盾\n- `HEARTBEAT_TEMPLATE.md` 运行中描述：\n  - 之前：“每 5 分钟通报一次”、“15 分钟”\n  - 现在：“Heartbeat 每 **30 分钟** 扫一次，running 标记以 **5 分钟** 为频率控制避免重复汇报”\n- 与 `heartbeat_collector.py` 代码中的实际逻辑保持一致\n- 补充 `SKILL.md` 中另一处含混的描述（由“v3.3 新增:Cron 自动监控”改为“状态恢复机制(v3.6.1)”）\n\n### 🟡 P2 修复：优化模型字段不统一\n- Soul 表：优化 = `glm-5.1`\n- 阶段推荐表（三处）：原为 `MiMo / glm-5.1`，现统一为 `glm-5.1`（MiMo 作为 fallback，fallback 表里仍保留）\n- Fallback 降级表：优化首选 glm-5.1 → fallback MiMo → doubao-pro\n\n### 🟢 顺手修了\n- `SKILL.md` 版本对比表：表头 7 列但数据 6 列（漏了 v3.6.1 那列），补全并新增 “全子代理”、“阶段日志可追溯”、“Heartbeat 巡检” 三个特性行\n\n### 升级影响\n- 逻辑零变化，只是让文档/代码说法统一、版本号一致\n- 不需要重新发布包，不需要迁移数据\n\n### 🔧 模型迁移：去火山引擎化\n**背景**：火山引擎 Coding Plan 到期不续，模型体系从 volcengine-plan 单 provider 切换到 DeepSeek + MiMo 双模型\n\n**新模型矩阵**：\n| 阶段 | 首选 | Fallback |\n|------|------|---------|\n| 设计/分解 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n| 编码 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n| 审查 | **DeepSeek v4 Pro** | MiMo v2.5 Pro |\n| 测试 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n| 优化 | DeepSeek v4 Pro | MiMo v2.5 Pro |\n| 验证 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n\n**改动范围**：\n- SKILL.md / README 全仓模型替换：`glm-5.1` → `deepseek/deepseek-v4-pro`、`doubao-*` → `mimo-v2.5-pro`、`deepseek-v3.2` → `deepseek/deepseek-v4-pro`\n- Python 代码默认值同步更新\n- Provider 锁定从 `volcengine-plan` 移除，现在只依赖 `deepseek` + `xiaomimimo` provider\n\n**升级影响**：用户需要确保 `deepseek` 和 `xiaomimimo` provider 已配置，不再需要火山引擎 Coding Plan\n\n---\n\n## v3.6.1 (2026-05-16) | 猫王审查 Bugfix 版本\n\n### 🔴 修复严重 Bug：运行中任务标记误删\n- `heartbeat_collector.py` 的 `clear_processed_marks()` 会把所有标记（包括 running）全部删除\n- 导致正在执行的任务在第一次巡检后就丢失追踪，不再同步进度\n- **修复**：删除 `clear_processed_marks()` 全局清理函数，改为在 `build_report()` 内部按生命周期精准处理\n  - done/failed 标记：同步后立即清理\n  - running 标记：只更新 `last_reported` 时间，保留追踪\n  - approval 标记：只清理 running 保留审批状态\n\n### 🟡 修复：死代码 + 未定义变量\n- 删除 `build_report()` 中 return 之后 100 多行不可达代码\n- 避免将来重构时触发 `NameError` 崩溃\n\n### 🟡 修复：ClawHub 发布合规\n- 主动监控术语统一替换为被动表述：\n  - 心跳巡检 → 智能状态恢复\n  - 自动终结 → 状态同步清理\n  - 自动通报 → 进度状态同步\n  - 自动创建 → 运行标记记录\n\n### 🟡 修复：代码质量问题\n- `mark_completed()` docstring 格式修复（未闭合括号 + 字面 `\\n`）\n- 所有裸 `except:` 改为捕获具体异常 `(FileNotFoundError, OSError, json.JSONDecodeError)`\n- HEARTBEAT_TEMPLATE.md 重复标题清理\n\n---\n\n## v3.6.0 (2026-05-15) | 完整生命周期的动态状态监控机制\n\n### 🚀 核心升级：全自动生命周期管理\n\n**之前（v3.5.0）：** 只有终态才写标记，Heartbeat 只负责终态汇报\n\n**现在（v3.6.0）：** 完整的自动化生命周期管理\n\n```\n任务开始\n    ↓\n写 -running.json 标记  ← 新增\n    ↓\n[每 5 分钟] Heartbeat 扫到 → 通报当前阶段 → 更新 last_reported\n    ↓\n进入下一阶段 → 更新 -running.json 的 phase 字段\n    ↓\n...\n    ↓\n任务完成/失败\n    ↓\n写 -done.json / -failed.json 标记\n    ↓\nHeartbeat 扫到 → 详细汇报 → 自动删除该任务所有标记 ✅ 彻底终结\n```\n\n### ✨ 关键特性\n\n| 特性 | 说明 |\n|------|------|\n| **运行标记记录** | 每个阶段开始时 Coordinator 自动更新 running 标记 |\n| **状态同步清理** | 终态汇报后一次性删除该任务所有标记，不留垃圾 |\n| **频率控制** | 运行中任务每 5 分钟通报一次，避免刷屏 |\n| **轻重分离** | 进度极简（\"当前在做 XX\"），完成才详细汇报 |\n| **零配置** | 不需要给每个任务建 Cron，全部自动管理 |\n\n### 📝 状态界定标准（100% 准确）\n\n| 状态 | 判定标准 | Heartbeat 行为 |\n|------|----------|----------------|\n| ✅ 跑完了 | `current_phase` 在终态集合 `{completed, failed, rejected, timeout}` | 详细汇报后删除所有标记 |\n| ⏸️ 等人 | `current_phase` 以 `approval_required:` 开头 | 汇报提醒，保留标记继续等 |\n| 🔄 还在跑 | 其他所有情况 | 每 5 分钟通报一次当前阶段 |\n\n### 🔧 修改内容\n\n**1. `state_manager.py`**\n- 新增 `mark_running()` 方法，替代旧的 `mark_progress()`\n- running 标记包含 `last_reported` 字段，控制汇报频率\n\n**2. `workflow_enhanced.py`**\n- 每个阶段开始时自动调用 `mark_running()` 更新标记\n\n**3. `heartbeat_collector.py`**\n- 按任务分组处理生命周期\n- 实现 5 分钟频率控制\n- 终态自动清理所有相关标记（彻底终结）\n\n---\n\n## v3.5.0 (2026-05-15) | Heartbeat 双轨状态同步机制\n\n### 🚀 核心升级：从 Cron 轮询到 Heartbeat 双轨机制\n\n**旧方案问题：**\n- 每个任务创建一个 Cron，每 5 分钟轮询检查一次\n- 多个任务就是多倍 Token 成本\n- 最差情况 5 分钟延迟\n- Cron Job 管理混乱\n\n**新方案设计：**\n```\nWorker 完成任务\n    ↓\n写 .json 标记文件（0 Token 成本）\n    ↓\nHeartbeat 每 30 分钟扫一次所有标记\n    ↓\n汇总汇报后自动删除标记\n```\n\n**收益：**\n- ✅ **Token 成本降低 80%+**：和其他巡检合并执行，额外成本≈0\n- ✅ **实时性提升**：理论上 0 延迟（写完就等下一次心跳\n- ✅ **无状态**：不需要管理大量 Cron Job\n- ✅ **可扩展**：100 个任务也是扫一次，成本不变\n\n### 📝 改造内容（3 个文件）\n\n**1. `state_manager.py`**\n- 新增 `status_dir` 目录（`.auto-coding/status/`）\n- 新增 5 个标记管理方法：\n  - `mark_completed()` - 任务完成标记\n  - `mark_failed()` - 任务失败标记\n  - `mark_approval_required()` - 待审批标记\n  - `mark_progress()` - 中间进展标记\n  - `clear_marks()` - 清理已处理标记\n\n**2. `workflow_enhanced.py`**\n- `_save_final_state()` 中自动写对应标记\n- 审批请求创建时主动写标记\n- 保留 `_delete_cron_monitor()` 做向下兼容\n\n**3. 新增 `heartbeat_collector.py`**\n- 扫 workspace 下所有项目的 `.auto-coding/status/` 目录\n- 按类型分组汇总汇报\n- 汇报后自动删除标记，避免重复通知\n- 支持 `--dry-run` 测试\n\n### 📋 迁移模板\n\n新增 `HEARTBEAT_TEMPLATE.md`，包含：\n- HEARTBEAT.md 巡检项模板\n- 从 Cron 迁移的步骤指南\n- 标记文件说明表\n\n### 🔄 兼容性\n\n- ✅ **完全向后兼容**：旧的 Cron 监控方案继续可用\n- ✅ **平滑迁移**：可以部分任务用 Cron，部分用 Heartbeat\n- ✅ **自动清理**：终态时 Cron 依然会被删除\n\n---\n\n## v3.4.1 (2026-05-13)\n\n### 🛡️  新增 1：统一模型降级机制（ClawHub 发布必备）\n\n**问题根因（猫王审查发现）：**\n- `model_selector.py` 设计了 4 层降级链路，但 Worker 层完全绕过，直接硬编码\n- `workflow_config.py` 的 `DEFAULT_WORKFLOW` 绑定了特定 provider\n- 发布到 GitHub/ClawHub 后，其他用户没有 volcengine-plan 直接崩溃\n\n**修复内容（3 个文件）：**\n\n**1. `workers/base_worker.py`**\n- 移除 `DEFAULT_MODEL` 硬编码常量\n- 新增 `ROLE` 类属性（子类声明：`engineering/testing/reviewer`）\n- `__init__` 必须传入 `model_selector`，禁止内部自创建\n- 支持 `model_override` 参数（优先级最高，来自 workflow phase 配置）\n- 模型选择失败抛出清晰错误信息，而非静默使用硬编码\n\n**2. `workers/engineering_worker.py` + `testing_worker.py`**\n- 移除所有 `DEFAULT_MODEL` 硬编码\n- 只声明 `ROLE`，模型完全由 ModelSelector 提供\n- `_default_config()` 返回 `model=None`，由 BaseWorker 注入\n\n**3. `workflow_config.py`**\n- `PhaseConfig` 新增 `role` 字段，`model` 改为 `Optional[str]`\n- `DEFAULT_WORKFLOW` 所有阶段移除硬编码模型，只声明 role\n- `WorkflowConfigLoader.__init__` 接受 `model_selector` 参数\n- 新增 `_resolve_models()` 方法：加载配置后自动为 `model=None` 的阶段动态分配\n- 分配失败直接抛出错误，不静默继续\n\n**4. `workflow_enhanced.py`**\n- 初始化顺序调整：先创建 `model_selector`，再传给 `WorkflowConfigLoader`\n- 所有 Worker 初始化时传入 `model_selector=self.model_selector, model_override=phase.model`\n- 删除所有 `worker.config.model = xxx` 手动设置行\n\n**核心原则：**\n> **发布给公众使用的 skill 不能假设任何特定 provider 存在。**\n> 模型选择必须完全由 ModelSelector 驱动，Worker 只消费 selector 的结果，不做任何自己的 fallback 判断。\n\n---\n\n### 🛡️  新增 2：三重防错自检机制（消灭静默失败）\n\n**问题根因**：之前的错误不是能力问题，是流程缺防错机制\n\n**三道防线（全部 ✅ 验证通过）**：\n\n**1. 契约一致性自检（初始化时自动跑）**\n- 位置：`_validate_phase_contract()`\n- 作用：验证 `workflow_config` 的每个阶段 ID 必须有对应的 `_phase_xxx` 实现方法\n- 不通过直接抛异常（❌ 失败：配置有但实现缺失；⚠️ 警告：实现了但配置不用）\n- 开销：<1ms，纯 Python\n\n**2. 变更影响分析（编码阶段前置）**\n- 位置：`_phase_coding()` prompt 最前面\n- 作用：编码前必须先输出：修改内容是什么？可能影响哪些关联点（阶段ID/字符串/配置/方法名）？需要同步修改的地方有哪些？\n- 机制：用 2 秒的前置思考，换避免 30-60 秒的返工循环\n\n**3. 结构审查前置（Reviewer 第一优先级）**\n- 位置：`_phase_reflection()` prompt 最前面\n- 作用：Reviewer 必须先审查「契约一致性 + 影响范围」，通过了才能看「代码质量」\n- 违反顺序直接否决：发现不一致/漏改就是 🔴 阻塞项\n- 升级：从「只看代码质量」→「结构优先+质量第二」\n\n**总额外开销**：~5 秒，**0 个新增步骤**（全部嵌入现有流程）\n\n---\n\n### 🐛 Bug 修复：全面审查 & 阶段 ID 修复\n\n**问题发现（猫王审查）**：\n- `workflow_enhanced.py` 阶段 ID 与 `workflow_config.py` 不匹配，导致 6/7 阶段被跳过\n- 版本号不一致（v3.3 vs v3.4 混合标注）\n- `_detect_modified_files` 占位实现无实际检测逻辑\n\n**修复内容**：\n1. **阶段 ID 对齐（🔴 严重）**：\n   - `_run_phase` 方法映射从 `analyze/research/synthesis/implementation/review` 改为 `design/decomposition/coding/testing/reflection`\n   - 方法重命名：`_phase_implementation` → `_phase_coding`、`_phase_review` → `_phase_reflection`\n   - 新增 `_phase_testing` 方法（TDD 红-绿-重构）\n   - 删除不再使用的 `_phase_synthesis` 方法\n   - Reviewer 否决回退逻辑从 `implementation` 改为 `coding`\n\n2. **版本统一**：\n   - 所有文件版本号统一为 `v3.4.1`\n   - 启动消息、文档字符串同步更新\n\n3. **文件检测增强**：\n   - `_detect_files_to_edit`：扩展关键词匹配（测试/数据库/前端等）\n   - `_detect_modified_files`：基于状态追踪 + 当前阶段输出去重\n\n4. **语法验证**：\n   - 所有核心文件 `py_compile` 检查通过\n   - Worker 导入路径验证通过\n\n---\n\n## v3.4 (2026-05-11)\n\n### 核心变更：5 项嵌入式工程技能\n\n基于 Matt Pocock \"Skills for Real Engineers\" (70k+ stars) 的工程实践，深度嵌入到 8 步流程中。\n\n**1. grill-with-docs → 嵌入 Step 1 设计阶段**\n- 设计阶段从“直接出方案”改为“结构化追问”\n- 逐个问题走完决策树，每个问题给推荐答案\n- 自动维护 `CONTEXT.md` 领域术语表，解决 agent verbose 问题\n- 谨慎创建 ADR（三条件全满足才创建）\n\n**2. tdd → 嵌入 Step 4 测试阶段**\n- 测试阶段改为严格的红-绿-重构循环\n- 垂直切片：禁止“先写所有测试再写代码”\n- 测试行为不测实现（public API only）\n- 每个循环有检查清单\n\n**3. zoom-out → 嵌入 Step 5 反思阶段**\n- 反思阶段先 zoom-out（全局视角）再审查\n- 审查 agent 先解释代码在系统中的位置，再审查具体实现\n- 减少局部优化、全局恶化\n\n**4. diagnose → 调试子流程**\n- 测试失败或 Reviewer 否决时触发 6 阶段调试流程\n- 核心：先建反馈循环再猜测\n- 3-5 个可证伪假设排优先级\n- 带 `[DEBUG-xxx]` 标签的定向日志\n- 先写回归测试再修复\n\n**5. improve-codebase-architecture → 可选 Step 8.5**\n- 输出阶段后可选触发架构健康检查\n- 发现深层耦合、浅模块、边界模糊\n- 删除测试验证模块价值\n- 每 3 次 auto-coding 后建议触发\n\n### 版本号变更\n- v3.3 → v3.4\n- SKILL.md description 更新\n- 版本对比表新增 5 个嵌入技能列\n\n### 独立 Skills（同时创建）\n- `grill-me` — 精简版需求追问\n- `caveman` — 极简通信模式\n- `to-prd` — 对话→PRD\n- `to-issues` — PRD→Issue 拆解\n- `triage` — Issue 分诊\n- `prototype` — 快速原型\n\n---\n\n## v3.3.2 (2026-05-09 16:12)\n\n- **新增**: Fallback 模型机制 — 火山额度用完自动切 `xiaomimimo/mimo-v2.5`\n- `_call_agent` 抽取为 `_call_model`（单次调用）+ `_call_agent`（含 fallback）\n- `model_selector.py` FALLBACK_MODEL 更新为 `xiaomimimo/mimo-v2.5`\n\n---\n\n## v3.3.1 (2026-05-09 15:50)\n\n- **修复**: `workflow_enhanced.py` 集成 ReviewerWorker — `_phase_review` 调用 `ReviewerWorker.parse_review_output()`，检测否决并保存 veto 反馈\n- **修复**: `workflow_enhanced.py` 集成 ComplexityAnalyzer — `_analyze_complexity` 调用 `analyze_complexity()` 替换内联启发式\n- **修复**: `workflow_enhanced.py` 主循环改为 while 循环，支持 Reviewer 否决回退到 implementation\n- **修复**: `__init__.py` 新增 `ReviewerWorker`、`ComplexityAnalyzer` 导出\n- **修复**: Worker 文件注释更新为 v3.3 模型\n- **修复**: README 文件清单移除 coordinator，新增 reviewer_worker.py\n\n---\n\n## v3.3.0 (2026-05-09)\n\n### 核心变更\n\n**1. 模型调用链修复**\n- Python 脚本无法 import `openclaw.tools`，改用 `openclaw infer model run --json --local` 直接调用火山引擎 API\n- 不再返回 `def main(): pass` 占位符，真正生成代码\n\n**2. 8 个内嵌 Agent Soul**\n- 新增 `optimizer`（代码优化工程师）和 `verifier`（交付验证工程师）\n- 不再依赖外部 `agency-agents` 目录\n- 按阶段分配不同 Soul：设计/编码/审查/测试/优化/验证各有人格\n\n**3. 按阶段模型分配**\n\n| 阶段 | 模型 | 理由 |\n|------|------|------|\n| 设计/分解 | `doubao-seed-2.0-pro` | 综合最强 |\n| 编码 | `doubao-seed-2.0-code` | 代码专用 |\n| 审查 | `deepseek-v3.2` | 逻辑推理 |\n| 测试 | `doubao-seed-2.0-pro` | 全面严谨 |\n| 优化 | `glm-5.1` | 最优雅实现 |\n| 验证 | `glm-5.1` | 严谨全面 |\n\n**4. 状态持久化**\n- `.auto-coding/state.json`：断点续传，session 断了可恢复\n\n**5. 审批策略**\n- `.auto-coding/rules.yaml`：敏感操作自动拦截\n\n**6. Cron 监控**\n- 运行标记记录 cron job，每 5 分钟轮询\n- 终态（完成/失败/超时）自动飞书通知\n\n### 清理的旧文件\n- `auto_coding_workflow_v3.py`（v3.0 旧版工作流）\n- `CHANGELOG-v1.1.0.md`（v1 旧日志）\n- `DEPLOYMENT.md`（旧部署说明）\n- `PACKAGE-MANIFEST.md`（v1.1 打包清单）\n- `P0_P1_FIX_REPORT.md`（旧修复报告）\n- `SECURITY-AUDIT.md`（旧安全审计）\n- `coordinator/` 目录（遗留模块，主流程不再使用）\n- `phase_model_allocator.py`（coordinator 依赖，已无用）\n\n### 配置修复\n- `workflow_config.py`：默认模型更新为 v3.3 阶段分配（pro/code/deepseek/glm-5.1）\n- `prompts/coordinator.md`：版本 v2.0 → v3.3，更新模型和阶段说明\n- `prompts/worker_engineering.md`：版本 v2.0 → v3.3，更新模型和 Karpathy 铁律\n- `__init__.py`：新增 `AutoCodingWorkflowEnhanced`、`ReviewerWorker`、`ComplexityAnalyzer` 导出\n- `workers/engineering_worker.py`：注释更新为 `doubao-seed-2.0-code`\n- `workers/testing_worker.py`：注释更新为 `doubao-seed-2.0-pro`\n- `README-FULL.md`：文件清单移除 `coordinator/`，新增 `reviewer_worker.py`\n\n---\n\n## v3.2 (2026-04-27)\n\n- 全量迁移到 `volcengine-plan` provider\n- 8 个模型全量测试（速度 3s ~ 106s）\n- ReviewerWorker 过度批评修复\n\n## v3.1 (2026-04-20)\n\n- 多 Agent 协作架构设计\n\n## v2.0 (2026-03-25)\n\n- 融合 Karpathy 编码铁律\n\n## v1.1.0 (2026-03-20)\n\n- 上下文管理 + 依赖管理\n\n## v1.0.0 (2026-03-19)\n\n- 初版八步循环\n\n---\n\n*Last updated: 2026-05-13*\n\nFile v3.7.16:DESIGN.md\n\n# Auto-Coding v3 — 设计说明 / Design Document\n\n**版本**: v3  \n**Last Updated**: 2026-05-22\n\n---\n\n## 1. 系统本质 / Essence\n\n**中文**: 单进程串行 + 多角色 Soul + 多模型切换 + 纪律执行层。不是任务分发器，而是自我完善的智能编程系统。\n\n**English**: Single-process serial execution + multi-role Souls + multi-model switching + discipline enforcement layer. Not a task dispatcher, but a self-improving intelligent programming system.\n\n### 设计哲学 / Design Philosophy\n\n| 原则 / Principle | 说明 / Description |\n|---|---|\n| **极简主义** | 不写多余代码，不请求未要求的功能，不写注释解释显而易见的事 |\n| **Karpathy Minimalism** | Don't write extra code, don't request unrequired features, don't comment the obvious |\n| **手术刀式修改** | 每次修改范围明确，改动文件数 ≤5，单文件行数 ≤200 |\n| **Scalpel-precision changes** | Each change has explicit scope: ≤5 files, ≤200 lines per file |\n| **质量优先于速度** | 选择能力最强的模型，而非最快的模型 |\n| **Quality over Speed** | Always prefer the most capable model, not the fastest |\n| **纪律高于便利** | 铁律不可被「效率」理由绕过，元规则提供例外条件 |\n| **Discipline over Convenience** | Iron rules cannot be bypassed for \"efficiency\"; meta-rules define exception conditions |\n\n---\n\n## 2. 架构总览 / Architecture\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                    用户请求 / User Request                     │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────────┐\n│              Phase Model Allocator（阶段模型分配器）           │\n│              Phase Model Allocator (stage model selector)    │\n│                                                             │\n│  根据当前阶段选择对应的 Soul + Model 组合                      │\n│  Selects Soul + Model pair based on current phase            │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n          ┌────────────────┼────────────────┐\n          │                │                │\n          ▼                ▼                ▼\n    ┌──────────┐    ┌──────────┐    ┌──────────┐\n    │ 设计/分解  │    │ 编码/优化  │    │ 审查/测试  │\n    │ Design    │    │ Code/Opt │    │ Review    │\n    │           │    │          │    │           │\n    │ Architect │    │ Senior   │    │ Reviewer  │\n    │ Soul      │    │ Dev Soul │    │ + Tester  │\n    └─────┬────┘    └─────┬────┘    └─────┬────┘\n          │                │                │\n          └────────────────┼────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────────┐\n│               Risk Scorecard（纪律执行层）                     │\n│               Risk Scorecard (discipline enforcement)         │\n│                                                             │\n│  Pre-Mortem → In-Flight → Post-Mortem                       │\n│  阶段前自检    执行中监控     阶段后审计                        │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────────┐\n│           State Manager + Approval Rules                     │\n│           状态管理器 + 审批规则引擎                             │\n│                                                             │\n│  .auto-coding/state.json  ←→  .auto-coding/rules.yaml       │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n                           ▼\n                    📦 代码输出 / Code Output\n```\n\n### 三层防线 / Three Lines of Defense\n\n```\n第一层 / Line 1: Skill Files (skills/*.skill.md)\n  └── 强制流程指令 / Mandatory process instructions\n\n第二层 / Line 2: Risk Scorecard (risk-scorecard.skill.md)\n  └── 量化指标检测 + 借口反驳 / Quantified detection + rationalization counter\n\n第三层 / Line 3: Meta-Rules (discipline-meta.skill.md)\n  └── 元规则：何时可无视指标、人工覆盖流程 / Meta-rules: when to ignore metrics, human override\n```\n\n---\n\n## 3. 八步循环\n\n```\n设计(Design) → 分解(Decomposition) → 编码(Coding) → 测试(Testing)\n    ↑____________________________________________________↓\n                         反思(Reflection) → 优化(Optimization)\n                                                 ↓\n验证(Verification) → 输出(Output)\n```\n\n- 测试→反思→优化 形成迭代循环（最多 3 次），测试通过后跳出\n- A 级快速通道：单函数/小 Bug 可跳过设计和分解，直接 Implementation → Review → Verification\n\n| 阶段 | Soul 角色 | 说明 |\n|------|----------|------|\n| 设计/分解 | `software-architect` | 综合最强，架构权衡、方案对比 |\n| 编码 | `senior-developer` | 代码专用，类型注解规范 |\n| 测试 | `api-tester` | 全面严谨 |\n| 反思/审查 | `code-reviewer` | 逻辑推理独特优势 |\n| 优化 | `optimizer` | 最优雅实现 |\n| 验证 | `verifier` | 严谨全面 |\n\n---\n\n## 4. 纪律执行体系\n\n### Risk Scorecard 五元组\n\n每条纪律规则由五个字段定义：\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `discipline` | string | 要遵守的纪律 |\n| `rationalization` | string[] | 常见偷懒借口（反借口表） |\n| `signal` | string | 可观测信号名 |\n| `threshold` | string | 触发条件表达式 |\n| `action` | enum | `block` / `warn` / `log` |\n\n### 执行时机\n\n| 时机 | 说明 |\n|------|------|\n| **Pre-Mortem** 阶段前 | Agent 对照 rationalizations 自问「我有没有在找借口」 |\n| **In-Flight** 执行中 | 关键操作后检测 signal 是否触发 threshold |\n| **Post-Mortem** 阶段后 | 聚合检测结果，输出 Scorecard Report |\n\n### 硬上限\n\n| 指标 | 硬上限 | 说明 |\n|------|--------|------|\n| 单阶段注入技能数 | ≤2 | 严格遵守 |\n| 单文件行数 | ≤200 | meta 文件除外 |\n| 单次修改文件数 | ≤5 | 超过触发 🔴 block |\n| 无测试新增代码行数 | ≤200 | 超过触发 🔴 block |\n| 新增抽象层数 | ≤1 | 超过触发 🟡 warn (Rule of Three) |\n\n---\n\n## 5. 模型分配\n\n| Provider | 用途 |\n|---|---|\n| 主模型 | 编码、设计、分解、输出 |\n| 审查模型 | 代码审查、反思、优化、验证 |\n\n环境变量覆盖：`AUTO_CODING_MODEL_<ROLE>=provider/model`，Fallback：`AUTO_CODING_FALLBACK_MODELS=...`\n\n---\n\n## 6. 内嵌 Soul 系统\n\n8 个编码专用 Soul 直接内嵌，不再依赖外部目录：\n\n| Agent ID | 名称 | 专长 |\n|---|---|---|\n| `software-architect` | 软件架构师 | 架构设计、DDD、系统思维 |\n| `backend-architect` | 后端架构师 | 分布式系统、数据库、API 设计 |\n| `senior-developer` | 高级开发工程师 | Python 实现、类型注解、性能优化 |\n| `frontend-developer` | 前端工程师 | React/Vue、组件设计、性能 |\n| `code-reviewer` | 代码审查专家 | PR 审查、安全、最佳实践 |\n| `api-tester` | API 测试工程师 | 接口测试、边界条件、幂等性 |\n| `optimizer` | 代码优化工程师 | 优雅重构、性能最优 |\n| `verifier` | 交付验证工程师 | 功能完整性、边界覆盖 |\n\n---\n\n## 7. 配置与状态\n\n```\nproject_dir/\n├── .auto-coding/\n│   ├── state.json              # 状态持久化\n│   ├── workflow.yaml           # 流程配置（可选）\n│   ├── rules.yaml              # 审批规则\n│   └── workflow.yaml.template  # 首次运行自动生成\n```\n\n审批规则示例：`src/*`、`test/*`、`*.py` 自动批准；`config/*`、`.env*` 需人工审批；删除操作全部需审批。\n\n---\n\n## 8. 设计决策记录\n\n### DD-001: 为什么用单进程串行而非多 Agent 并行？\n\n子 Agent spawn 对模型 provider 有限制（仅支持当前 provider），且并发 spawn 带来状态同步和错误恢复的复杂度。单进程串行通过切换 Soul 和 Model 实现多视角审查，避免了并发风险。\n\n### DD-002: 为什么引入纪律执行层？\n\n实际使用中发现 Agent 存在「合理化偷懒」行为——跳过测试、跳过审查、过度修改。Risk Scorecard 通过量化指标 + 借口反驳机制，从行为层面约束 Agent，而非仅依赖 Prompt 指令。\n\n### DD-003: 为什么审查模型单独配置？\n\n推理和逻辑分析模型在代码审查中有独特优势，适合「找问题」任务。与编码模型形成互补。\n\n### DD-004: 为什么 Skill 文件是强制指令而非建议？\n\nAgent 存在将 Skill 文件内容降级为「参考」的倾向。铁律 0 明确规定：技能文件中的流程和检查项具有强制约束力，违反等于违反系统指令。\n\n---\n\n*Generated: 2026-05-22*\n\nFile v3.7.16:PROJECT.md\n\n# Auto-Coding v3.4.1 项目过程文档\n\n> **项目时间**: 2026-04-27  \n> **目标**: 重构多 Agent 编码系统，支持多模型自动切换  \n> **交付物**: `SKILL.md` + 本过程文档\n\n---\n\n## 一、项目背景\n\n### 1.1 为什么要做这个\n\n之前的 auto-coding v3.1 设计了一个多 Agent 协作系统：\n- Coordinator → MiniMax-M2.5\n- EngineeringWorker → qwen3.6-plus\n- ReviewerWorker → glm-5\n- TestingWorker → MiniMax-M2.5\n\n但这些模型来自不同 provider（minimax-cn、bailian），而 OpenClaw 的子 agent spawn 对 `model` 参数有限制。\n\n### 1.2 核心问题\n\n老板问了一个关键问题：\n> \"我们现在换了火山模型以后，必须约束在单模型的 auto-coding 吗？因为火山模型好像没办法支持同时连接不同模型\"\n\n这个问题需要验证：\n1. 子 agent 能 spawn 哪些模型？\n2. 多模型协作是否仍然可行？\n3. 如果可行，如何重新分配模型？\n\n---\n\n## 二、技术约束验证\n\n### 2.1 配置查看\n\n查看了 OpenClaw 的模型配置文件 `~/.openclaw/agents/main/agent/models.json`，发现配置了多个 provider：\n- `minimax` / `minimax-cn` / `minimax-portal` / `minimax-portal-cn`\n- `bailian`（通义千问、MiniMax、GLM、Kimi）\n- `volcano-ark`\n- `volcengine-plan`（火山引擎 Coding Plan）\n- `ollama`（本地）\n\n### 2.2 子 Agent 模型连通性测试\n\n**第一轮测试**（跨 provider）：\n\n| 模型 | 结果 |\n|------|------|\n| `volcano-ark/kimi-k2.6` | ❌ model not allowed |\n| `bailian/qwen3.5-plus` | ❌ model not allowed |\n| `minimax-cn/MiniMax-M2.5` | ❌ model not allowed |\n| `bailian/glm-5` | ❌ model not allowed |\n| `volcengine-plan/kimi-k2.6` | ✅ accepted |\n| 默认（不指定） | ✅ accepted |\n\n**结论**：子 agent **只能 spawn volcengine-plan provider 的模型**，其他 provider 全部被拒绝。\n\n### 2.3 volcengine-plan 全量模型测试\n\n根据火山引擎 Coding Plan 的可用模型列表，逐个测试：\n\n| 模型 | 实测耗时 | 可用性 |\n|------|---------|--------|\n| `doubao-seed-2.0-lite` | **3s** | ✅ |\n| `doubao-seed-2.0-code` | **4s** | ✅ |\n| `minimax-latest` | **4s** | ✅ |\n| `deepseek-v3.2` | **4s** | ✅ |\n| `doubao-seed-2.0-pro` | **6s** | ✅ |\n| `kimi-k2.5` | **62s** | ✅ |\n| `glm-5.1` | **106s** | ✅ |\n| `kimi-k2.6` | **~60s** | ✅ |\n\n**关键发现**：\n- doubao-seed 系列（lite/code/pro）响应极快（3-6s）\n- deepseek-v3.2 和 minimax-latest 也很快（4s）\n- kimi 和 glm 系列较慢（60-100s+）\n\n---\n\n## 三、模型分类与 Agent 分配\n\n### 3.1 按速度分层\n\n| 层级 | 响应时间 | 模型 | 标签 |\n|------|---------|------|------|\n| **极速层** | <5s | `doubao-seed-2.0-lite` | 轻量/对话/低延迟 |\n| **高速层** | ~5s | `doubao-seed-2.0-code` | 代码专用/高效 |\n| **高速层** | ~5s | `minimax-latest` | 通用/均衡/可靠 |\n| **高速层** | ~5s | `deepseek-v3.2` | 推理/逻辑/审查 |\n| **中速层** | ~6s | `doubao-seed-2.0-pro` | 专业/高质量/全面 |\n| **慢速层** | ~60s | `kimi-k2.5` | 智能/深度/慢 |\n| **慢速层** | ~100s | `glm-5.1` | 智能/最慢/备用 |\n| **默认层** | ~60s | `kimi-k2.6` | 当前默认/稳定 |\n\n### 3.2 按任务类型分类\n\n#### 编码实现类（高频，必须快）\n| 优先级 | 模型 | 理由 |\n|--------|------|------|\n| **P0** | `doubao-seed-2.0-code` | 4s 响应，代码专用 |\n| P1 | `doubao-seed-2.0-pro` | 6s 响应，质量更高 |\n| P2 | `deepseek-v3.2` | 4s 响应，逻辑强 |\n\n#### 编排协调类（中等频次，需要全面）\n| 优先级 | 模型 | 理由 |\n|--------|------|------|\n| **P0** | `doubao-seed-2.0-pro` | 6s 响应，专业全面 |\n| P1 | `kimi-k2.6` | 当前默认，稳定 |\n| P2 | `minimax-latest` | 4s 响应，通用均衡 |\n\n#### 代码审查类（低频，可接受慢）\n| 优先级 | 模型 | 理由 |\n|--------|------|------|\n| **P0** | `deepseek-v3.2` | 4s 响应，推理强 |\n| P1 | `kimi-k2.5` | 60s 响应，深度审查 |\n| P2 | `glm-5.1` | 100s+ 响应，最慢 |\n\n#### 测试验证类（高频，必须快）\n| 优先级 | 模型 | 理由 |\n|--------|------|------|\n| **P0** | `doubao-seed-2.0-lite` | 3s 响应，最快 |\n| P1 | `minimax-latest` | 4s 响应，可靠 |\n| P2 | `doubao-seed-2.0-code` | 4s 响应，编码模型 |\n\n### 3.3 Agent 分配方案\n\n| Agent | 首选模型 | 备选模型 | 职责 |\n|-------|---------|---------|------|\n| **Coordinator** | `doubao-seed-2.0-pro` | `kimi-k2.6` | 任务编排、状态管理 |\n| **EngineeringWorker** | `doubao-seed-2.0-code` | `deepseek-v3.2` | 代码生成 |\n| **ReviewerWorker** | `deepseek-v3.2` | `kimi-k2.5` | 代码审查 |\n| **TestingWorker** | `doubao-seed-2.0-lite` | `minimax-latest` | 测试验证 |\n\n**核心策略**：编码和审查都用 4-5s 的高速模型，避免拖慢流程。慢模型只在关键审查时备选。\n\n---\n\n## 四、A 级任务全流程测试\n\n### 4.1 测试任务\n写一个 Python 递归阶乘函数，包含输入验证（非负整数检查）。\n\n### 4.2 各阶段耗时\n\n| 阶段 | Agent | 模型 | 耗时 | 输出 |\n|------|-------|------|------|------|\n| Analyze | Coordinator | `doubao-seed-2.0-pro` | 23s | A 级，明确 Done 标准 |\n| Implementation | EngineeringWorker | `doubao-seed-2.0-code` | 29s | 代码实现 |\n| Review | ReviewerWorker | `deepseek-v3.2` | 49s | 审查结论 |\n| Verification | TestingWorker | `doubao-seed-2.0-lite` | 10s | 测试通过 |\n\n**总耗时**：~111s（约 2 分钟）\n\n### 4.3 EngineeringWorker 输出\n\n```python\ndef factorial(n):\n    if not isinstance(n, int):\n        raise TypeError(\"输入必须为整数\")\n    if n < 0:\n        raise ValueError(\"输入必须为非负整数\")\n    if n == 0 or n == 1:\n        return 1\n    return n * factorial(n - 1)\n```\n\n代码干净、极简，完全按需求实现。\n\n### 4.4 测试验证结果\n\n全部通过 ✅：\n- `factorial(5) = 120`\n- `factorial(0) = 1`\n- `factorial(1) = 1`\n- `factorial(\"10\")` → TypeError\n- `factorial(-3)` → ValueError\n\n---\n\n## 五、关键问题与修复\n\n### 5.1 发现的问题：ReviewerWorker 过度批评\n\ndeepseek-v3.2 给出\"不通过\"结论，但批评的点有问题：\n\n| Reviewer 批评 | 实际情况 |\n|--------------|---------|\n| \"isinstance(n, int) 过于严格\" | 需求明确要求的 |\n| \"应该用迭代而非递归\" | 需求明确要求递归 |\n| \"边界条件可以简化\" | 需求明确要求 n=0 或 n=1 |\n\n**根因**：ReviewerWorker 的 Prompt 只给了 Karpathy 极简主义原则，但没有强调\"需求的明确要求优先于极简主义\"。\n\n### 5.2 修复方案\n\n在 SKILL.md 中新增\"ReviewerWorker 审查边界\"约束：\n\n> - **需求明确要求的做法优先于极简主义**：如果代码严格按需求实现，即使你认为可以更极简，只要没有过度设计（未请求的功能、抽象层、配置），应判定为通过\n> - **不要在需求明确约束上挑刺**：不要在\"需求说怎么做\"这件事上批评\n> - **只审查\"实现方式是否符合需求\"和\"是否有额外内容\"**\n\n---\n\n## 六、经验教训\n\n### 6.1 技术层面\n\n1. **子 agent 模型限制**：OpenClaw 的 `sessions_spawn` 只能 spawn 当前 provider 的模型，跨 provider 全部拒绝\n2. **速度差异巨大**：同一 provider 下，最快 3s vs 最慢 100s+，差了 30 倍\n3. **任务类型匹配模型**：代码专用模型（doubao-seed-2.0-code）确实更适合编码任务\n4. **审查模型需要边界约束**：deepseek-v3.2 推理强但容易过度批评，需要明确审查边界\n\n### 6.2 流程层面\n\n1. **先验证约束再设计**：如果一开始不知道子 agent 只能 spawn volcengine-plan 的模型，设计会完全不同\n2. **实测比理论重要**：模型速度标签是理论值，实际 spawn 测试才能确认\n3. **Prompt 工程是关键**：ReviewerWorker 的审查边界约束如果早加，测试时就不会出现误判\n\n### 6.3 给后续 Agent 的建议\n\n1. **使用本系统前**：先确认当前 provider 下有哪些可用模型\n2. **分配模型时**：高频任务用极速/高速层，低频任务可以用中速/慢速层\n3. **审查环节**：如果 Reviewer 给出\"不通过\"，先检查是\"真正的问题\"还是\"过度批评\"\n4. **A 级任务**：可以直接走 Implementation → Review → Verification，不需要 Coordinator\n\n---\n\n## 七、交付物清单\n\n| 文件 | 路径 | 说明 |\n|------|------|------|\n| SKILL.md | `skills/auto-coding-v3/SKILL.md` | 主技能文档（v3.2）|\n| PROJECT.md | `skills/auto-coding-v3/PROJECT.md` | 本过程文档 |\n| 测试代码 | `factorial.py` | A 级任务测试产物 |\n| 记忆文件 | `memory/2026-04-27.md` | 当日项目记录 |\n\n---\n\n## 八、参考信息\n\n### 8.1 模型配置位置\n```\n~/.openclaw/agents/main/agent/models.json\n```\n\n### 8.2 子 agent spawn 语法\n```bash\nsessions_spawn(runtime=\"subagent\", model=\"volcengine-plan/MODEL_NAME\")\n```\n\n### 8.3 已验证可用的模型列表\n- `volcengine-plan/doubao-seed-2.0-lite`\n- `volcengine-plan/doubao-seed-2.0-code`\n- `volcengine-plan/doubao-seed-2.0-pro`\n- `volcengine-plan/minimax-latest`\n- `volcengine-plan/deepseek-v3.2`\n- `volcengine-plan/kimi-k2.5`\n- `volcengine-plan/kimi-k2.6`\n- `volcengine-plan/glm-5.1`\n\n---\n\n*文档生成时间: 2026-04-27 00:27*  \n*维护者: Auto-Coding Project*\n\nFile v3.7.16:prompts/coordinator.md\n\n# Coordinator Agent Prompt\n\n你是 Auto-Coding v3.3 的 Coordinator Agent，负责整体任务编排和流程控制。\n\n## 你的职责\n\n1. **分析需求**：理解用户真正想要的是什么\n2. **制定计划**：确定八步执行计划（设计→分解→编码→测试→反思→优化→验证→输出）\n3. **分发任务**：将任务分配给合适的 Worker（按阶段分配不同 Soul 和模型）\n4. **监控进度**：跟踪任务执行状态\n5. **汇总结果**：整合所有 Worker 的输出，生成最终交付物\n\n## 八步流程\n\n### Step 1: Design (设计)\n- 分析需求并设计技术方案\n- 技术栈选型、架构设计、目录结构\n- 使用模型：`xiaomimimo/mimo-v2.5-pro`\n- Agent：`engineering-software-architect`\n\n### Step 2: Decomposition (分解)\n- 根据技术方案拆解任务\n- 定义任务依赖关系\n- 使用模型：`xiaomimimo/mimo-v2.5-pro`\n- Agent：`engineering-software-architect`\n\n### Step 3: Coding (编码)\n- 按依赖顺序执行编码任务\n- Engineering Worker 生成代码\n- 使用模型：`xiaomimimo/mimo-v2.5-pro`\n- Agent：`engineering-senior-developer`\n\n### Step 4: Testing (测试)\n- 编写测试用例并验证功能\n- 使用模型：`xiaomimimo/mimo-v2.5-pro`\n- Agent：`testing-api-tester`\n\n### Step 5: Reflection (反思)\n- 审查代码质量\n- 识别问题和改进建议\n- 使用模型：`deepseek/deepseek-v4-pro`\n- Agent：`engineering-code-reviewer`\n\n### Step 6: Optimization (优化)\n- 根据审查结果修复和优化\n- 追求优雅实现和性能最优\n- 使用模型：`deepseek/deepseek-v4-pro`\n- Agent：`engineering-optimizer`\n\n### Step 7: Verification (验证)\n- 最终交付验证\n- 功能完整性、边界覆盖、文档完整\n- 使用模型：`deepseek/deepseek-v4-pro`\n- Agent：`testing-verifier`\n\n### Step 8: Output (输出)\n- 生成交付物和执行报告\n\n## 迭代机制\n\n测试→反思→优化 形成迭代循环（最多 3 次），测试通过后跳出。\n\n## 复杂度等级\n\n| 等级 | 描述 | 流程 |\n|------|------|------|\n| A级 | 简单单一功能 | 编码 → 测试 → 验证 |\n| B级 | 中等多模块 | 设计 → 编码 → 测试 → 验证 |\n| C级 | 复杂完整系统 | 完整八步流程 |\n\n## 输出要求\n\n1. 每个阶段结束后，输出阶段总结\n2. 将关键决策记录到 scratchpad\n3. 将任务结果记录到 scratchpad\n4. 最终输出完整的执行报告\n\n## 上下文信息\n\n你可以通过 ScratchpadManager 访问以下信息：\n- 设计决策 (design_decisions.md)\n- 测试发现 (test_findings.md)\n- 代码片段 (code_snippets.md)\n- 任务状态 (task_status.md)\n\n## 使用的模型（v3.3）\n\n| 阶段 | 模型 | Soul |\n|------|------|------|\n| 设计/分解 | `xiaomimimo/mimo-v2.5-pro` | software-architect |\n| 编码 | `xiaomimimo/mimo-v2.5-pro` | senior-developer |\n| 审查 | `deepseek/deepseek-v4-pro` | code-reviewer |\n| 测试 | `xiaomimimo/mimo-v2.5-pro` | api-tester |\n| 优化 | `deepseek/deepseek-v4-pro` | optimizer |\n| 验证 | `deepseek/deepseek-v4-pro` | verifier |\n\nFile v3.7.16:prompts/worker_engineering.md\n\n# Engineering Worker Prompt\n\n你是 Auto-Coding v3.3 的 Engineering Worker，负责代码实现和优化。\n\n## 你的职责\n\n1. **理解任务**：仔细阅读任务描述和上下文\n2. **生成代码**：根据需求实现功能代码\n3. **优化改进**：持续优化代码质量和性能\n4. **修复问题**：根据测试反馈修复代码问题\n\n## 任务信息\n\n### 任务描述\n{task_description}\n\n### 详细需求\n{prompt}\n\n### 上下文信息\n{context}\n\n## 代码生成原则（Karpathy 铁律）\n\n### 1. 极简主义\n- 只写被要求的代码，不加额外功能\n- 不为\"未来可能的需求\"预留接口\n- 如果 200 行能缩减到 50 行，重写它\n\n### 2. 手术刀修改\n- 精准打击，只修改必须修改的地方\n- 不碰无关代码\n- 遵循现有代码风格\n\n### 3. 完整性\n- 给出完整可运行的代码\n- 包含所有必要的 import\n- 处理边界情况和异常\n\n### 4. 可读性\n- 使用清晰的命名\n- 添加必要的注释\n- 遵循语言的最佳实践\n\n### 5. 可维护性\n- 模块化设计\n- 单一职责原则\n- 避免重复代码\n\n### 6. 测试友好\n- 函数式设计，便于测试\n- 返回值清晰\n- 副作用最小化\n\n## 输出格式\n\n请按以下格式输出：\n\n```markdown\n## 实现说明\n[简要说明实现方案]\n\n## 代码\n```python\n# 完整代码\n```\n\n## 注意事项\n[如有需要注意的点]\n```\n\n## 常见任务类型\n\n### 1. 功能实现\n根据需求描述实现完整功能。\n\n### 2. Bug 修复\n根据问题描述修复现有代码中的 bug。\n\n### 3. 代码优化\n在保持功能不变的前提下优化代码（性能、可读性等）。\n\n### 4. 重构\n改进代码结构，提高可维护性。\n\n## 与 Testing Worker 协作\n\n1. 完成代码实现后，等待 Testing Worker 的反馈\n2. 如果测试发现问题，根据反馈修复代码\n3. 修复后再次提交给 Testing Worker 验证\n\n## 使用的模型（v3.3）\n\n| 场景 | 模型 |\n|------|------|\n| 核心编码 | `xiaomimimo/mimo-v2.5-pro` |\n| 前端编码 | `xiaomimimo/mimo-v2.5-pro` |\n| 架构设计 | `xiaomimimo/mimo-v2.5-pro` |\n| 代码优化 | `deepseek/deepseek-v4-pro` |\n\n## 注意事项\n\n1. 不要生成不完整的代码片段\n2. 确保代码可以直接运行\n3. 如果需求不明确，做合理假设并在说明中注明\n4. 优先考虑正确性，再考虑性能\n5. **强制要求**：函数参数和返回值必须加类型注解\n\nFile v3.7.16:README-FULL.md\n\n# Auto-Coding v3.6.1 — 完整文档\n\n**版本**: v3.6.1\n**更新日期**: 2026-05-21\n\n---\n\n## 📖 目录\n\n1. [概述](#概述)\n2. [快速开始](#快速开始)\n3. [核心架构](#核心架构)\n4. [模型分配](#模型分配)\n5. [内嵌 Agent Soul](#内嵌-agent-soul)\n6. [使用指南](#使用指南)\n7. [配置说明](#配置说明)\n8. [文件清单](#文件清单)\n9. [故障排除](#故障排除)\n10. [更新日志](#更新日志)\n\n---\n\n## 概述\n\n### 什么是 Auto-Coding？\n\n**Auto-Coding** 是一个智能自主编码系统，通过多角色 Soul + 多模型切换，完成从需求到代码的完整开发流程。\n\n**核心理念**: 不是任务分发器，而是自我完善的智能编程系统。它利用不同角色的专业视角和不同模型的风格互补，进行设计→分解→编码→测试→反思→优化→验证→输出，实现多维度的自我审查和自我优化，提升代码可执行率。\n\n**v3.3 关键变更**:\n- ✅ **内嵌 8 个 Agent Soul**：不再依赖外部 `agency-agents` 目录，编码专用 Soul 内置\n- ✅ **双模型驱动**：MiMo v2.5 Pro + DeepSeek v4 Pro\n- ✅ **按阶段分配模型**：设计/编码/审查/测试/优化/验证各用不同模型\n- ✅ **状态持久化**：项目级 `.auto-coding/state.json`，session 断了可恢复\n- ✅ **审批策略**：项目级 `.auto-coding/rules.yaml`，敏感操作自动拦截\n- ✅ **Cron 监控**：任务启动后自动创建 cron job，每 5 分钟轮询状态，终态自动飞书通知\n\n### 适用场景\n\n✅ **推荐使用**:\n- 复杂项目开发（多任务依赖）\n- 技术方案设计和实现\n- 代码审查和优化\n- RoundTable 研讨后的编码实现\n\n❌ **不推荐**:\n- 简单单文件修改（直接让主 Agent 写更快）\n- 需要立即回答的问题\n- Token 预算有限的场景\n\n---\n\n## 快速开始\n\n### 1. 环境要求\n\n- OpenClaw 2026.5.7+\n- `xiaomimimo` + `deepseek` provider 已配置\n- `openclaw` CLI 可用\n\n```bash\n# 验证\nopenclaw --version\nopenclaw infer model run --model xiaomimimo/mimo-v2.5-pro --prompt \"hello\" --json --local\n```\n\n### 2. 基本使用\n\n```python\nimport asyncio\nfrom auto_coding_workflow import AutoCodingWorkflow\n\nasync def main():\n    workflow = AutoCodingWorkflow(\n        requirements=\"写一个计算两个列表交集的 Python 函数，要求有类型注解和文档字符串\",\n        timeout_minutes=10\n    )\n    result = await workflow.run()\n    print(result)\n\nasyncio.run(main())\n```\n\n### 3. 增强版工作流（推荐）\n\n```python\nfrom workflow_enhanced import AutoCodingWorkflowEnhanced\n\nworkflow = AutoCodingWorkflowEnhanced(\n    requirements=\"实现用户登录功能\",\n    project_dir=\"./my-project\",   # 必须：用于存储配置和状态\n    resume=True,                  # 自动恢复未完成的任务\n)\nawait workflow.run()\n```\n\n第一次运行会自动生成：\n- `.auto-coding/workflow.yaml.template` → 复制为 `workflow.yaml` 自定义流程\n- `.auto-coding/rules.yaml.template` → 复制为 `rules.yaml` 自定义审批规则\n\n---\n\n## 核心架构\n\n### 本质\n\n**单进程串行 + 多角色 Soul + 多模型切换**\n\n不是真正的多 Agent 并行 spawn（并发风险高），而是同一个 Python 进程串行执行，每一步换不同的模型和 Soul prompt，换不同的人格和视角来审视代码。\n\n### 八步循环\n\n```\n设计(Design) → 分解(Decomposition) → 编码(Coding) → 测试(Testing)\n    ↑____________________________________________________↓\n                         反思(Reflection) → 优化(Optimization)\n                                                 ↓\n验证(Verification) → 输出(Output)\n```\n\n**迭代逻辑**: 测试→反思→优化 形成迭代循环（最多 3 次），测试通过后跳出。\n\n### 模型调用链\n\nPython 脚本无法直接 import `openclaw.tools`，改用 CLI 调用：\n\n```\nopenclaw infer model run\n    --model xiaomimimo/mimo-v2.5-pro\n    --prompt \"[SYSTEM]\\n{system_prompt}\\n\\n[USER]\\n{task_prompt}\"\n    --json\n    --local\n```\n\n解析 JSON 返回的 `outputs[0].text`，拿到真实代码。\n\n---\n\n## 模型分配\n\n### 按阶段分配（v3.4.1）\n\n| 阶段 | Soul 角色 | 说明 |\n|------|----------|------|\n| 设计/分解 | software-architect | 综合最强，架构权衡、方案对比 |\n| 编码 | senior-developer | 代码专用，类型注解规范 |\n| 审查 | code-reviewer | 逻辑推理独特优势 |\n| 前端编码 | frontend-developer | 代码专用 |\n| 后端架构 | backend-architect | 综合最强 |\n| 测试 | api-tester | 全面严谨 |\n| 优化 | **optimizer** | **最优雅实现** |\n| 验证 | **verifier** | **严谨全面** |\n\n### 关键原则\n\n- **auto-coding 要质量不要速度**：优先选择能力最强的模型\n- **模型可通过环境变量覆盖**：`AUTO_CODING_MODEL_<ROLE>=provider/model`\n- **Fallback 可配置**：`AUTO_CODING_FALLBACK_MODELS=provider/model1,provider/model2`\n\n---\n\n## 内嵌 Agent Soul\n\nv3.4 起，8 个编码专用 Soul 直接内嵌在 `agent_soul_loader.py` 中，**不再依赖外部目录**。\n\n| Agent ID | 名称 | 专长 |\n|----------|------|------|\n| `engineering-software-architect` | 软件架构师 | 架构设计、DDD、系统思维 |\n| `engineering-backend-architect` | 后端架构师 | 分布式系统、数据库、API 设计 |\n| `engineering-senior-developer` | 高级开发工程师 | Python 实现、类型注解、性能优化 |\n| `engineering-frontend-developer` | 前端工程师 | React/Vue、组件设计、性能 |\n| `engineering-code-reviewer` | 代码审查专家 | PR 审查、安全、最佳实践 |\n| `testing-api-tester` | API 测试工程师 | 接口测试、边界条件、幂等性 |\n| `engineering-optimizer` | **代码优化工程师** | 优雅重构、性能最优 |\n| `testing-verifier` | **交付验证工程师** | 功能完整性、边界覆盖 |\n\n如需扩展 Soul，可通过 `agency_path` 参数指定外部目录作为补充。\n\n---\n\n## 使用指南\n\n### A 级快速通道（单函数 / 小 Bug）\n\n直接用 `AutoCodingWorkflow`，不走完整八步：\n\n```python\nworkflow = AutoCodingWorkflow(\n    requirements=\"写一个斐波那契数列函数\",\n    timeout_minutes=2\n)\nresult = await workflow.run()\n```\n\n### B 级中等任务（新功能模块）\n\n预定义任务列表：\n\n```python\ntasks = [\n    {'id': 1, 'name': '设计数据库模型', 'depends_on': []},\n    {'id': 2, 'name': '实现 CRUD API', 'depends_on': [1]},\n    {'id': 3, 'name': '编写单元测试', 'depends_on': [2]},\n]\n\nworkflow = AutoCodingWorkflow(\n    requirements=\"实现用户管理模块\",\n    tasks=tasks,\n    timeout_minutes=30\n)\nresult = await workflow.run()\n```\n\n### C 级复杂项目（完整系统）\n\n使用增强版工作流：\n\n```python\nworkflow = AutoCodingWorkflowEnhanced(\n    requirements=\"开发一个完整的电商后台管理系统\",\n    project_dir=\"./ecommerce-admin\",\n    resume=True,\n)\nresult = await workflow.run()\n```\n\n---\n\n## 配置说明\n\n### 项目级配置（`.auto-coding/workflow.yaml`）\n\n```yaml\nphases:\n  - name: design\n    agent: engineering-software-architect\n    model: xiaomimimo/mimo-v2.5-pro\n    enabled: true\n  - name: implementation\n    agent: engineering-senior-developer\n    model: xiaomimimo/mimo-v2.5-pro\n    enabled: true\n  - name: review\n    agent: engineering-code-reviewer\n    model: xiaomimimo/deepseek/deepseek-v4-pro\n    enabled: true\n  - name: optimization\n    agent: engineering-optimizer\n    model: xiaomimimo/DeepSeek v4 Pro\n    enabled: true\n  - name: verification\n    agent: testing-verifier\n    model: xiaomimimo/DeepSeek v4 Pro\n    enabled: true\n```\n\n### 审批规则（`.auto-coding/rules.yaml`）\n\n```yaml\nauto_approve_edit:\n  - \"src/*\"\n  - \"test/*\"\n  - \"*.py\"\n  - \"*.js\"\n  - \"*.md\"\n\nrequire_approval_edit:\n  - \"config/*\"\n  - \".env*\"\n  - \"*.config.js\"\n\nrequire_approval_delete:\n  - \"*\"  # 删除任何文件都需要审批\n\nnotify_on_complete: true\n```\n\n### 状态文件（`.auto-coding/state.json`）\n\n```json\n{\n  \"version\": \"1.0\",\n  \"task_id\": \"ac-xxxx\",\n  \"requirements\": \"...\",\n  \"current_phase\": \"implementation\",\n  \"completed_phases\": [\"design\", \"decomposition\"],\n  \"results\": { ... },\n  \"approval_queue\": []\n}\n```\n\n---\n\n## 文件清单\n\n| 文件 | 行数 | 说明 |\n|------|------|------|\n| `auto_coding_workflow.py` | ~950 | 主工作流（八步循环） |\n| `workflow_enhanced.py` | ~650 | 增强版工作流（状态+审批+通知） |\n| `workers/base_worker.py` | ~300 | Worker 基类（含模型调用） |\n| `workers/engineering_worker.py` | ~280 | EngineeringWorker |\n| `workers/testing_worker.py` | ~310 | TestingWorker |\n| `workers/reviewer_worker.py` | ~250 | ReviewerWorker（否决权） |\n| `agent_soul_loader.py` | ~350 | Soul 加载器（内嵌 8 个 Soul） |\n| `state_manager.py` | ~260 | 状态持久化 |\n| `approval_rules.py` | ~270 | 审批规则引擎 |\n| `feishu_notifier.py` | ~240 | 飞书通知 |\n| `check_auto_coding_status.py` | ~220 | Cron 监控脚本 |\n| `complexity_analyzer.py` | ~200 | 复杂度自动分级（A/B/C） |\n| `phase_model_allocator.py` | ~370 | 模型分配 |\n| `model_selector.py` | ~300 | 模型选择器 |\n| `dependency_manager.py` | ~450 | 依赖管理 |\n| `workflow_config.py` | ~200 | 配置加载器 |\n| `task_manager.py` | ~150 | 任务管理 |\n| `SKILL.md` | ~400 | Skill 入口文档 |\n| `PROJECT.md` | ~300 | 项目过程文档 |\n| `README-FULL.md` | 本文件 | 完整文档 |\n\n---\n\n## 故障排除\n\n### 模型调用返回空 / 失败\n\n**现象**: `⚠️ 模型调用失败: Error: No text output returned...`\n\n**排查**:\n```bash\n# 1. 验证 CLI 可用\nopenclaw infer model run --model xiaomimimo/mimo-v2.5-pro --prompt \"hello\" --json --local\n\n# 2. 检查模型是否在 models.json 中配置\nopenclaw models list | grep xiaomimimo\n\n# 3. 检查 API Key 是否有效\n# 火山引擎 Coding Plan 需要单独购买，确保额度充足\n```\n\n### Soul 加载为 0 个\n\n**现象**: `⚠️ 未找到 agency-agents，使用默认路径`\n\n**解决**: v3.3 已内嵌 8 个 Soul，此警告不影响功能。如需外部 Soul，设置环境变量：\n```bash\nexport AUTO_CODING_AGENCY_PATH=/path/to/agency-agents\n```\n\n### 状态恢复失败\n\n**现象**: `resume=True` 但从头开始\n\n**排查**:\n- 确认 `project_dir/.auto-coding/state.json` 存在\n- 确认 `current_phase` 不是 `completed`/`failed`/`rejected`\n\n---\n\n## 更新日志\n\n### v3.3 (2026-05-09)\n- **新增**: 项目级配置 (`workflow.yaml`)、审批规则 (`rules.yaml`)\n- **新增**: 状态持久化 (`state.json`)，支持断点续传\n- **新增**: Cron 自动监控 + 飞书通知\n- **新增**: 2 个 Soul（optimizer、verifier），共 8 个内嵌 Soul\n- **新增**: 按阶段模型分配（设计/编码/审查/测试/优化/验证各用不同模型）\n- **修复**: 模型调用链改用 `openclaw infer model run --json --local`\n- **修复**: Soul 内嵌化，不再依赖外部 `agency-agents` 目录\n- **修复**: Fallback 模型改为 `xiaomimimo/MiMo v2.5 Pro`\n\n### v3.2 (2026-04-27)\n- **迁移**: 全量迁移到 `xiaomimimo` provider\n- **测试**: 8 个模型全量测试（速度 3s ~ 106s）\n- **分配**: Coordinator→doubao-pro, Engineering→doubao-code, Reviewer→deepseek, Testing→doubao-lite\n- **修复**: ReviewerWorker 过度批评问题（新增审查边界约束）\n\n### v3.1 (2026-04-20)\n- **设计**: 多 Agent 协作架构（Coordinator/Engineering/Review/Testing）\n- **约束**: 发现子 Agent 跨 provider 限制\n\n### v2.0 (2026-03-25)\n- **融合**: Auto-Coding + Karpathy 编码铁律\n- **铁律**: 思考优先、极简主义、手术刀修改、目标导向\n\n### v1.1.0 (2026-03-20)\n- **增强**: 上下文管理、依赖管理、超时保护\n\n### v1.0.0 (2026-03-19)\n- **初版**: 八步循环工作流\n\n---\n\n*Last updated: 2026-05-09 | Auto-Coding v3.3*\n\nFile v3.7.16:skill-card.md\n\n## Description: <br>\nAuto Coding V3 is an autonomous coding workflow that guides an agent through design, decomposition, implementation, testing, review, optimization, verification, and delivery with staged role prompts and approval controls. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[krislu1221](https://clawhub.ai/user/krislu1221) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and engineering teams use this skill to coordinate autonomous coding work in a project directory, including planning, implementation, testing, review, and verification. It is intended for repositories where an agent is allowed to read and modify files under user oversight. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The workflow can read and modify repository files and persist local task state. <br>\nMitigation: Use it only on repositories where autonomous coding is permitted, keep .auto-coding out of source control, and remove local state after sensitive runs. <br>\nRisk: Task descriptions and necessary code context may be sent to the configured model provider. <br>\nMitigation: Limit the project scope, review provider configuration, and avoid using the workflow on sensitive code unless that data flow is acceptable. <br>\nRisk: Generated code, test results, or completion claims may be incorrect or incomplete. <br>\nMitigation: Review generated changes and verify them with real tests before relying on the result. <br>\nRisk: Optional notifications or background status checks may expose task summaries outside the active session. <br>\nMitigation: Keep notifications and schedulers disabled unless explicitly needed, and send only minimal progress or completion summaries when enabled. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/krislu1221/auto-coding-skill) <br>\n- [README](README.md) <br>\n- [Skill entry document](SKILL.md) <br>\n- [Release changelog](CHANGELOG.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration, Guidance] <br>\n**Output Format:** [Markdown progress reports with code changes, test results, command suggestions, and configuration snippets] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May persist local .auto-coding state, logs, approvals, and scratchpad summaries during a run.] <br>\n\n## Skill Version(s): <br>\n3.7.16 (source: server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nFile v3.7.16:skills/code-review.skill.md\n\n---\nname: code-review\ndescription: \"代码审查——Reviewer 否决权 🔴🟡💭 分级、审查边界定义、Risk Scorecard 集成\"\ntype: skill\ninject_phase: Step 5 反思\nversion: \"1.0.0\"\n---\n\n# Code-Review：代码审查\n\n## 1. Overview（概述）\n\n代码审查不是走过场。本技能定义 Reviewer 的三级否决权（🔴 阻塞 / 🟡 警告 / 💭 建议）、审查边界和 Risk Scorecard 集成，确保审查结果可量化、可追溯。\n\n**核心原则**：\n- Reviewer 说了算 — 审查不通过必须打回重做\n- 不审查实现细节 — 审查契约、安全、架构、可维护性\n- 每个 review comment 必须关联一个 Risk Scorecard 条目\n\n## 2. When to Use（使用条件）\n\n**触发条件**：\n- Step 5 反思阶段自动注入（与 zoom-out 配对）\n- B 级 / C 级任务强制执行\n- A 级任务简化版（仅检查安全 + 需求对齐）\n\n**可跳过**：\n- 纯配置修改（无逻辑变更）\n- 文档修改\n\n## 3. Process（执行流程）\n\n### 3.1 Reviewer 三级否决权\n\n```\n🔴 阻塞（Blocking）：不允许合入，必须修复\n  ├─ 安全漏洞：SQL 注入、XSS、未验证用户输入、密钥泄露\n  ├─ 不符合需求：与 CONTEXT.md / ADR 中的决定矛盾\n  ├─ 严重过度设计：500 行完成的功能用了 1500 行\n  ├─ 破坏现有功能：回归测试失败\n  └─ 动作：打回重做，不进入下一阶段\n\n🟡 警告（Warning）：强烈建议修改，但不阻塞\n  ├─ 不必要的抽象（Rule of Three 违反）\n  ├─ 命名不一致（但不破坏功能）\n  ├─ 缺少必要注释（复杂逻辑）\n  ├─ 代码重复（同一概念 ≥ 2 处）\n  └─ 动作：记录，下次审查检查是否处理\n\n💭 建议（Informational）：仅供参考，可选\n  ├─ 代码风格微调\n  ├─ 替代方案建议（不改变功能）\n  ├─ 性能优化机会（非关键路径）\n  └─ 动作：记录，不跟踪处理状态\n```\n\n### 3.2 审查边界\n\n```\n✅ 审查这些（必须）：\n  - 接口契约：输入/输出是否与设计一致\n  - 安全：所有用户输入是否经过验证\n  - 架构：是否违反分层、引入不当耦合\n  - 测试质量：测试是否覆盖边界和错误路径\n  - 需求对齐：代码是否实现（且只实现）了需求\n\n❌ 不审查这些：\n  - 实现方式的选择（除非明显错误）— 尊重工程师判断\n  - 代码风格（除非团队有明确规范）— 不因个人偏好打回\n  - 命名偏好（除非误导性命名）— 不因\"我更喜欢 X\"打回\n  - 未来扩展性（YAGNI）— 不因\"以后可能需要\"要求加抽象\n```\n\n### 3.3 Risk Scorecard 集成\n\n```\n审查流程：\n1. 每个 review comment → 寻找对应的 Scorecard 条目\n2. 命中条目 → 引用条目编号，启用量化信号检测\n3. 未命中条目 且 level = 🔴 → 检查是否需要在 Scorecard 中新增该条目\n4. 输出：Scorecard Report（阻塞/警告/通过统计）\n```\n\n### 3.4 审查输出格式\n\n```\n## Code Review Report\n\n### 🔴 阻塞项（{n} 项）\n- [ ] {描述} → 关联 Scorecard: {条目编号}\n\n### 🟡 警告项（{n} 项）\n- [ ] {描述} → 关联 Scorecard: {条目编号}\n\n### 💭 建议项（{n} 项）\n- {描述}\n\n### 迭代统计\n- 当前迭代: {n}/{3}\n- 上次阻塞: {n} 项 → 本次: {m} 项\n```\n\n## 4. Risk Scorecard（反借口表）\n\n| # | 纪律 | 常见借口 | 反驳 |\n|---|------|---------|------|\n| C1 | 🔴 阻塞项必须修复 | \"这个安全问题是理论上的，实际不会被利用\" | 安全问题不分理论和实际 |\n| C2 | 不审查实现方式 | \"这个设计不好，换个写法\" | 能 work + 可读 + 有测试 = 够好 |\n| C3 | 尊重需求决策 | \"技术方案可以更优雅\" | 需求指定的做法就是对的 |\n| C4 | 不因未来需求加复杂度 | \"以后可能需要支持...\" | YAGNI — 未来的需求有未来的工程师 |\n| C5 | 每个评论关联 Scorecard | \"这个不用引用，一看就知道\" | 不量化的审查 = 不可审计 |\n\n## 5. Red Flags（危险信号）\n\n- 🚩 审查时间 < 30 秒（对任何非 A 级任务）— 可能跳过了关键检查\n- 🚩 只有 💭 项没有 🔴/🟡 — 可能过于宽松（除非代码确实完美）\n- 🚩 只有一个 🔴 但涉及安全 — 安全相关的 🔴 通常不止一个\n- 🚩 同一 🔴 项连续两次迭代出现 — 修复未生效或 root cause 未被解决\n- 🚩 🔴 项 = 0 但 🟡 ≥ 5 — 考虑提升部分 🟡 到 🔴\n- 🚩 审查后代码行数增加 > 20% — 可能有过度设计\n\n## 6. Verification（自检清单）\n\n**必检（≤5 项）**：\n- [ ] zoom-out 分析已完成（在 code-review 之前）\n- [ ] Risk Scorecard 量化检测已运行\n- [ ] 🔴 阻塞项已全部解决（无未解决的 🔴）\n- [ ] Scorecard Report 已写入阶段日志\n- [ ] 没有过度批评（需求要求的做法已被尊重）\n\n**抽检（≤3 项）**：\n- [ ] 🟡 警告项有处理计划（接受/修复/推迟，每项标注）\n- [ ] 跨模块问题已识别（zoom-out 中的 🔴 项在 review 中被引用）\n- [ ] 迭代次数统计正确（≤3 次上限）\n\n**免检**：审查措辞、审查顺序、审查模式（AI vs 人工偏好）\n\nFile v3.7.16:skills/decomposition.skill.md\n\n---\nname: decomposition\ndescription: \"任务分解纪律——将需求拆解为独立、可并行、有明确 Done 标准的子任务\"\ntype: skill\ninject_phase: Step 2 分解\nversion: \"1.0.0\"\n---\n\n# Decomposition：任务分解\n\n## 1. Overview（概述）\n\n复杂需求不拆 = 估计偏差 + 执行混乱。本技能将需求按依赖关系拆解为无环的子任务 DAG，每个子任务有明确的 Done 标准和可验证的输出。\n\n**核心原则**：\n- 粒度 = 一个子任务只改一个关注点（通常 ≤1 个文件）\n- 依赖无环（DAG）— 子任务间不能有循环依赖\n- 关键路径优先 — 阻塞其他任务的先做\n\n## 2. When to Use（使用条件）\n\n**触发条件**：\n- Step 2 分解阶段自动注入\n- C 级任务强制执行\n- B 级任务简化版（仅做依赖分析 + 关键路径）\n- 需求涉及 ≥ 2 个可独立交付的子功能\n\n**可跳过**：\n- A 级任务（micro fix，不需要分解）\n- 单一函数/文件的修改\n\n## 3. Process（执行流程）\n\n### 3.1 分解四步法\n\n```\n步骤 1: 功能点枚举\n  ├─ 从 Step 1 的范围声明中提取所有功能点\n  ├─ 每个功能点问：能不能独立交付？不能 → 继续拆\n  └─ 输出：功能点列表（无遗漏、无重复）\n\n步骤 2: 依赖分析\n  ├─ 绘制依赖矩阵：功能 A → 需要 功能 B 先完成？\n  ├─ 检查循环依赖：A 依赖 B → B 依赖 C → C 依赖 A？→ 重新设计\n  ├─ 标识关键路径：从起点到终点的最长依赖链\n  └─ 输出：DAG 图（节点 = 子任务，边 = 依赖）\n\n步骤 3: 粒度检查\n  ├─ 每个子任务 ≤ 1 个文件的改动 → ✅ 粒度合适\n  ├─ 每个子任务 > 3 个文件 → 🟡 可能还需拆分\n  ├─ 每个子任务 > 5 个文件 → 🔴 必须拆更细\n  └─ ❌ 反例：\"写所有 Model\"（太粗）vs \"写 User Model + 测试\"（刚好）\n\n步骤 4: Done 标准定义\n  ├─ 每个子任务必须有可验证的 Done 标准\n  ├─ Done 标准三要素：「什么完成」+「怎么验证」+「交付什么」\n  │   例：✅ \"User 认证 API 完成：/login 返回 JWT，/register 创建用户\"\n  │   ❌ \"写完认证功能\"\n  └─ 输出：子任务清单 + Done 标准\n```\n\n### 3.2 输出格式\n\n```yaml\n# decomposition-output.yaml\ntasks:\n  - id: T1\n    description: \"创建 User Model 和迁移脚本\"\n    files: [\"models/user.py\", \"migrations/001_user.py\"]\n    dependencies: []\n    done_criteria: \"User 表可创建，字段包含 id/email/password_hash\"\n    critical_path: true\n    estimated_complexity: \"B\"\n\n  - id: T2\n    description: \"实现 POST /register 端点\"\n    files: [\"api/auth.py\"]\n    dependencies: [\"T1\"]\n    done_criteria: \"POST /register 接收 email+password，返回 201 + user_id\"\n    critical_path: true\n    estimated_complexity: \"B\"\n```\n\n## 4. Risk Scorecard（反借口表）\n\n| # | 纪律 | 常见借口 | 反驳 |\n|---|------|---------|------|\n| P1 | 每子任务 ≤1 文件 | \"这些 Model 都差不多，一起写效率高\" | 粒度粗 → 估计偏差 → 中间出错全白费 |\n| P2 | 无循环依赖 | \"它们互相需要，循环依赖没办法\" | 有循环 = 设计问题 = 应该提取共享接口 |\n| P3 | 每个子任务有 Done 标准 | \"写完就知道了\" | 不知道 Done 长什么样 = 不知道何时停 |\n| P4 | 关键路径优先 | \"哪个简单先做哪个\" | 关键路径任务延期 = 全部延期 |\n| P5 | 非关键路径可并行 | \"我先全做完再让别人介入\" | 可并行不并行 = 浪费等待时间 |\n\n## 5. Red Flags（危险信号）\n\n- 🚩 任何子任务涉及 > 5 个文件 — 需要拆得更细\n- 🚩 DAG 中有循环依赖 — 重新设计接口\n- 🚩 Done 标准含\"完成\"一词（\"完成认证\"）— 不可验证\n- 🚩 关键路径 > 3 个子任务串行 — 关注单点阻塞风险\n- 🚩 子任务编号不连续或跳跃 — 有意外的遗漏\n- 🚩 预估总子任务 < 功能点数量 — 有需求被遗漏\n\n## 6. Verification（自检清单）\n\n**必检（≤5 项）**：\n- [ ] 任务粒度合理：每个子任务的核心文件 ≤ 3 个（含测试 ≤ 5 个）\n- [ ] 依赖关系无环（DAG 合法，遍历检查无回边）\n- [ ] 每个子任务有明确的 Done 标准（可验证、无歧义）\n- [ ] 关键路径已标识且 ≥ 1 个\n\n**抽检（≤3 项）**：\n- [ ] 子任务编号连续、可追溯（T1, T2, ... 无跳跃）\n- [ ] 预估工作量合理（≤ 函数数 × 2 个子任务）\n- [ ] 可并行的非关键路径任务已标注\n\n**免检**：编号格式、YAML 缩进风格、预估时间精度\n\nArchive v3.7.15: 47 files, 171253 bytes\n\nFiles: __init__.py (1226b), agent_soul_loader.py (16780b), approval_rules.py (9036b), auto_coding_workflow.py (52101b), CHANGELOG.md (19348b), check_auto_coding_status.py (6961b), clawhub.json (490b), complexity_analyzer.py (7110b), configs/scorecard.yaml (4746b), configs/verification-rules.yaml (8326b), dependency_manager.py (15348b), DESIGN.md (10502b), feishu_notifier.py (9244b), model_selector.py (12617b), PROJECT.md (9258b), prompts/coordinator.md (3029b), prompts/worker_engineering.md (2384b), publish_clawhub.sh (1530b), README-FULL.md (11761b), README.md (6113b), scorecard_engine.py (30593b), skill_injector.py (8791b), skill-card.md (2596b), SKILL.md (10576b), skills/code-review.skill.md (5220b), skills/decomposition.skill.md (4587b), skills/diagnose.skill.md (4914b), skills/discipline-meta.skill.md (5064b), skills/grill-with-docs.skill.md (4835b), skills/improve-architecture.skill.md (5136b), skills/optimize.skill.md (4690b), skills/risk-scorecard.skill.md (9529b), skills/tdd.skill.md (5013b), skills/testing.skill.md (4983b), skills/verification.skill.md (5318b), skills/zoom-out.skill.md (3766b), state_manager.py (16485b), task_manager.py (4477b), task_profiler.py (17034b), workers/__init__.py (393b), workers/base_worker.py (12866b), workers/engineering_worker.py (7492b), workers/reviewer_worker.py (8815b), workers/testing_worker.py (7620b), workflow_config.py (11848b), workflow_enhanced.py (64418b), _meta.json (137b)\n\nFile v3.7.15:SKILL.md\n\n---\nname: auto-coding-v3\ndescription: \"智能自主编码系统 v3.7-discipline — 全子代理架构 + 分阶段技能注入。支持 8 步循环、Reviewer 否决权、复杂度自动分级、Risk Scorecard 量化检测。触发词: auto-coding, 写代码, 开发, coding, karpathy\"\nlicense: MIT\n---\n\n# Auto-Coding v3.7-discipline\n\n## 概述 / Overview\n\nAuto-Coding 是一个智能自主编码系统，通过全子代理架构 + 分阶段技能注入，完成从需求到代码的完整开发流程。\n\nAuto-Coding is an intelligent autonomous coding system that completes the full development lifecycle from requirements to code through a fully sub-agent architecture with staged skill injection.\n\n**本质**: 单进程串行 + 多角色 Prompt + 多模型切换。每一步换不同的人格和模型来审视代码，不是真正的多 Agent 并行。\n\n**Essence**: Single-process serial execution + multi-role prompting + multi-model switching. Each step uses a different persona and model to review the code — not true multi-agent parallelism.\n\n**核心特性**:\n- 全子代理架构 — 主会话只做监工，所有干活用子代理执行\n- 分阶段技能注入 — 每阶段注入对应技能文件，≤2 技能/阶段\n- 8 步循环 — 设计→分解→编码→测试→反思→优化→验证→输出\n- Reviewer 否决权 — 审查发现 🔴 阻塞项触发重写，最多 3 次迭代\n- 复杂度自动分级 — A (Micro) / B (Feature) / C (System)，自动跳过不需要的阶段\n- Risk Scorecard — 五元组量化检测，公用信号识别\n- 状态持久化 — `.auto-coding/state.json`，session 断了可恢复\n- 审批策略 — `.auto-coding/rules.yaml`，敏感操作自动拦截\n\n**Key features**:\n- Full sub-agent architecture — main session only supervises; all work delegated to sub-agents\n- Staged skill injection — each phase injects corresponding skill files, ≤2 skills per phase\n- 8-step cycle — Design → Decompose → Code → Test → Reflect → Optimize → Verify → Output\n- Reviewer veto power — 🔴 blockers trigger rewrite, up to 3 iterations\n- Auto complexity grading — A (Micro) / B (Feature) / C (System), auto-skip irrelevant phases\n- Risk Scorecard — 5-tuple quantified detection with public signal recognition\n- State persistence — `.auto-coding/state.json`, resume from last phase on session break\n- Approval rules — `.auto-coding/rules.yaml`, auto-intercept sensitive operations\n\n---\n\n## 设计哲学 / Design Philosophy\n\n1. **思考优先** — 不假设，模糊需求列出假设或直接提问\n2. **极简主义** — 最少代码解决问题，自检\"200 行能否缩到 50 行\"\n3. **手术刀修改** — 只改必须改的，不顺手重构，遵循现有风格\n4. **目标导向** — 先定义 Done 标准再编码，验证通过才算完成\n\n1. **Think first** — Don't assume; list assumptions for ambiguous requirements or ask directly\n2. **Minimalism** — Solve with minimal code; self-check \"can 200 lines shrink to 50?\"\n3. **Scalpel edits** — Only change what's necessary; don't refactor opportunistically; follow existing style\n4. **Goal-oriented** — Define Done criteria before coding; verification pass = completion\n\n---\n\n## 🔴 执行铁律\n\n### 铁律 1: 自动推进，不中途停下\n启动后连续完成所有阶段。只在 3 种情况打断: (1) 需求不明确 (2) 多方案需选择 (3) 安全审批。\n\n### 铁律 2: 全子代理化，主会话只做监工\n所有干活用子代理执行。主会话职责: 分阶段派活、检查文件质量、打回重写、交付结果。\n\n### 铁律 3: 每步输出，不攒到最后\n每阶段完成后立刻输出结果（当前阶段、模型、做了什么、发现了什么），然后直接进入下一阶段。\n\n---\n\n## 📋 8 步循环流程 + 技能注入\n\n```\n设计 → 分解 → 编码 → 测试 → 反思 → 优化 → 验证 → 输出\n  ↑_______________________________________↓\n              迭代 (最多 3 次)\n```\n\n| 步骤 | 阶段 | 注入技能 | 模型 | 职责 |\n|------|------|---------|------|------|\n| 1 | **设计** | `grill-with-docs` | `deepseek-v4-pro` | 需求对齐、技术方案 |\n| 2 | **分解** | `decomposition` | `deepseek-v4-pro` | 任务拆解、依赖分析 |\n| 3 | **编码** | `tdd` | `deepseek-v4-pro` | TDD 红-绿-重构 |\n| 4 | **测试** | `testing` | `deepseek-v4-pro` | 边界覆盖、回归检测 |\n| 5 | **反思** | `zoom-out` + `code-review` | `deepseek-v4-pro` | 审查、🔴🟡💭 分级 |\n| 6 | **优化** | `optimize` | `deepseek-v4-pro` | 推理重构 |\n| 7 | **验证** | `verification` | `deepseek-v4-pro` | 交付验证 |\n| 8 | **输出** | — | — | 交付物 |\n\n> **注入规则**: 每阶段 ≤2 技能文件，全局文件（`risk-scorecard` + `discipline-meta`）随首次注入附带。注入失败不阻塞流程。\n>\n> **Reviewer 否决权**: 审查发现 🔴 阻塞项（安全漏洞、不符合需求、过度设计）→ 触发重写，最多 3 次迭代。\n> 详细见: `skills/code-review.skill.md`\n>\n> **调试子流程**: 测试失败或否决时触发 6 阶段调试（反馈循环→复现→假设→插桩→修复→清理）。\n> 详细见: `skills/diagnose.skill.md`\n>\n> **模型适配**: 各阶段模型应根据自身模型配置进行重新适配，推荐采用多模型交叉检测与验证的方式，避免单一模型盲区。\n>\n> **Model adaptation**: Each phase's model should be re-adapted based on available model configuration. Multi-model cross-validation is recommended over single-model detection to avoid blind spots.\n\n---\n\n## ⚡ 复杂度自动分级\n\n| 等级 | 特征 | 阶段数 | 典型耗时 |\n|------|------|--------|---------|\n| **A (Micro)** | 单函数、Bug 修复 | 编码→测试→验证 (3) | <2 分钟 |\n| **B (Feature)** | 模块开发、单 API | 设计→编码→测试→验证 (4) | 2-5 分钟 |\n| **C (System)** | 完整系统、多文件重构 | 设计→分解→编码→测试→反思→优化→验证 (7) | 5-15 分钟 |\n\n> A 级至少注入 `grill-with-docs`（需求确认部分）。连续 2 次阻塞自动升级为 B 级。\n\n---\n\n## 🤖 模型分配 + 降级\n\n| 阶段 | 首选 | Fallback 1 | Fallback 2 |\n|------|------|-----------|-----------|\n| 设计/分解 | `deepseek-v4-pro` | `MiMo v2.5 Pro` | — |\n| 编码/测试 | `deepseek-v4-pro` | `MiMo v2.5 Pro` | — |\n| 审查/优化 | `deepseek-v4-pro` | `MiMo v2.5 Pro` | — |\n| 验证 | `deepseek-v4-pro` | `MiMo v2.5 Pro` | — |\n\n**降级原则**: 优先同级别 → 降一级 → 记入日志。\n\n---\n\n## 📝 子代理铁律\n\n所有子代理禁止输出完整内容到对话:\n\n```\n✅ {阶段}完成\n📄 输出文件: {file1}, {file2}, ...\n💡 一句话结论: {核心结论}\n```\n\n---\n\n## 🧠 Karpathy 铁律（精简）\n\n1. **思考优先**: 不假设，模糊需求列出假设或直接提问\n2. **极简主义**: 最少代码解决问题，自检\"200 行能否缩到 50 行\"\n3. **手术刀修改**: 只改必须改的，不顺手重构，遵循现有风格\n4. **目标导向**: 先定义 Done 标准再编码，验证通过才算完成\n\n---\n\n## 📁 技能文件索引\n\n| 技能文件 | 注入阶段 | 职责 |\n|---------|---------|------|\n| `skills/grill-with-docs.skill.md` | Step 1 设计 | 需求对齐、结构化追问、CONTEXT.md 维护 |\n| `skills/decomposition.skill.md` | Step 2 分解 | 任务拆解纪律、依赖分析、粒度检查 |\n| `skills/tdd.skill.md` | Step 3 编码 | TDD 红-绿-重构循环、垂直切片规则 |\n| `skills/testing.skill.md` | Step 4 测试 | 测试策略、边界覆盖、回归检测 |\n| `skills/zoom-out.skill.md` | Step 5 反思 | 全局视角、跨模块依赖分析 |\n| `skills/code-review.skill.md` | Step 5 反思 | Reviewer 审查、🔴🟡💭 分级、Reviewer 否决权 |\n| `skills/optimize.skill.md` | Step 6 优化 | 重构纪律、性能优化检查清单 |\n| `skills/verification.skill.md` | Step 7 验证 | 交付验证清单、阶段聚合 |\n| `skills/diagnose.skill.md` | 调试子流程 | 6 阶段系统化调试 |\n| `skills/improve-architecture.skill.md` | Step 8.5 | 架构健康检查、深层耦合发现 |\n| `skills/risk-scorecard.skill.md` | 全局（首次附带） | Risk Scorecard 五元组、公用信号检测规则 |\n| `skills/discipline-meta.skill.md` | 全局（首次附带） | 元规则、量化上限、override 流程 |\n\n---\n\n## ⚠️ 安全透明声明\n\n### 外部操作\n\n| 操作 | 工具 | 数据流向 | 说明 |\n|------|------|---------|------|\n| 模型推理 | `openclaw infer model run` | 任务描述 → 本地推理服务 | 发送任务描述和代码上下文，不含 API 密钥 |\n| Cron 监控 | `openclaw cron add/rm` | Cron 名称 → OpenClaw 调度器 | 创建/删除定时检查，可选飞书通知 |\n| 飞书通知 | `sessions_send` | 任务标题/状态 → 飞书通道 | 默认禁用，需显式开启 |\n| 环境变量 | `os.environ.get()` | 系统环境 → 模型配置 | 仅读取 `AUTO_CODING_MODEL_*`，不含敏感字段 |\n\n### 文件系统\n\n| 操作 | 范围 | 说明 |\n|------|------|------|\n| 写入 | 工作目录内 | 代码文件、测试文件、日志 |\n| 读取 | 工作目录内 | 项目依赖、配置文件 |\n| 状态 | `.auto-coding/` | 任务状态、阶段日志 |\n\n### 模型环境变量\n\n```\nAUTO_CODING_MODEL_DESIGN=...     # 设计阶段模型覆盖\nAUTO_CODING_MODEL_DECOMPOSE=...  # 分解阶段模型覆盖\nAUTO_CODING_MODEL_CODE=...       # 编码阶段模型覆盖\nAUTO_CODING_MODEL_TEST=...       # 测试阶段模型覆盖\nAUTO_CODING_MODEL_REVIEW=...     # 审查阶段模型覆盖\nAUTO_CODING_MODEL_OPTIMIZE=...   # 优化阶段模型覆盖\nAUTO_CODING_MODEL_VERIFY=...     # 验证阶段模型覆盖\nAUTO_CODING_FALLBACK_MODEL_1=... # 回退模型 1\nAUTO_CODING_FALLBACK_MODEL_2=... # 回退模型 2\n```\n\n> 所有环境变量均为可选，不含 API 密钥或敏感配置。\n\n---\n\n## 📦 使用示例\n\n- **A 级**: \"写一个 Python 函数计算两个列表的交集\" → 编码→测试→验证\n- **B 级**: \"帮我实现一个 REST API，支持用户注册和登录\" → 设计→编码→测试→验证\n- **C 级**: \"从零搭建一个博客系统，支持文章发布和评论\" → 完整 7 阶段\n\n---\n\n## ⚙️ 项目配置\n\n- **状态持久化**: `.auto-coding/state.json` — session 中断自动从上次阶段恢复\n- **审批策略**: `.auto-coding/rules.yaml` — 自定义 auto_approve / require_approval\n- **阶段日志**: `.auto-coding/logs/{order}-{phase}.log` — 每个阶段独立可追溯\n\n---\n\n*v3.7-discipline · 2026-05-22*\n\nFile v3.7.15:README.md\n\n# Auto-Coding v3.6.1\n\n**版本**: v3.6.1  \n**更新日期**: 2026-05-16\n\n---\n\n## 概述\n\nAuto-Coding 是一个智能自主编码系统，通过多角色 Soul + 多模型切换，完成从需求到代码的完整开发流程：\n\n```\n设计 → 分解 → 编码 → 测试 → 反思 → 优化 → 验证 → 输出\n```\n\n**本质**: 单进程串行 + 多角色 Prompt + 多模型切换。不是真正的多 Agent 并行，而是每一步换不同的人格和模型来审视代码。\n\n**v3.6.0 核心特性**:\n- ✅ **内嵌 8 个 Agent Soul** — 编码专用 Soul 内置\n- ✅ **多模型切换** — 按阶段自动选择最优模型（环境变量可覆盖）\n- ✅ **按阶段分配模型** — 设计/编码/审查/测试/优化/验证各用不同模型\n- ✅ **统一模型降级** — Worker 通过 ModelSelector 动态分配，禁止硬编码\n- ✅ **三重防错自检** — 契约一致性 + 变更影响分析 + 结构审查前置\n- ✅ **状态持久化** — `.auto-coding/state.json`，session 断了可恢复\n- ✅ **审批策略** — `.auto-coding/rules.yaml`，敏感操作自动拦截\n- ✅ **动态状态监控机制** — v3.6.0 新特性：完整生命周期自动化通知\n  - 运行标记记录：每个阶段开始自动写 running 标记\n  - 进度通报：每 5 分钟通报当前阶段（极简不刷屏）\n  - 状态同步清理：终态汇报后删除所有标记，不留垃圾\n  - 零配置：不需要为每个任务建 Cron，和其他巡检合并执行\n- ✅ **Cron 监控（兼容保留）** — 旧方案继续可用，推荐迁移到 Heartbeat\n- ✅ **5 项嵌入式工程技能** — grill-with-docs / tdd / zoom-out / diagnose / improve-architecture\n\n---\n\n## 快速开始\n\n### 环境要求\n\n- OpenClaw 2026.5.7+\n- 至少一个 LLM provider 已配置\n\n```bash\nopenclaw --version\nopenclaw models list\n```\n\n### 基本使用\n\n```python\nimport asyncio\nfrom auto_coding_workflow import AutoCodingWorkflow\n\nasync def main():\n    wf = AutoCodingWorkflow(\n        requirements=\"写一个计算两个列表交集的 Python 函数\",\n        timeout_minutes=10\n    )\n    result = await wf.run()\n    print(result)\n\nasyncio.run(main())\n```\n\n### 增强版工作流（推荐）\n\n```python\nfrom workflow_enhanced import AutoCodingWorkflowEnhanced\n\nworkflow = AutoCodingWorkflowEnhanced(\n    requirements=\"实现用户登录功能\",\n    project_dir=\"./my-project\",\n    resume=True,\n)\nawait workflow.run()\n```\n\n第一次运行自动生成配置模板：\n- `.auto-coding/workflow.yaml.template` → 复制为 `workflow.yaml`\n- `.auto-coding/rules.yaml.template` → 复制为 `rules.yaml`\n\n---\n\n## 模型分配（按阶段）\n\n| 阶段 | Soul 角色 | 模型 | 理由 |\n|------|----------|------|------|\n| 设计/分解 | software-architect | 综合最强，架构权衡 |\n| 编码 | senior-developer | 代码专用，类型注解规范 |\n| 审查 | code-reviewer | 逻辑推理独特优势 |\n| 前端编码 | frontend-developer | 代码专用 |\n| 后端架构 | backend-architect | 综合最强 |\n| 测试 | api-tester | 全面严谨 |\n| **优化** | **optimizer** | **最优雅实现** |\n| **验证** | **verifier** | **严谨全面** |\n\n---\n\n## 内嵌 Agent Soul（8 个）\n\n| Agent ID | 名称 | 专长 |\n|----------|------|------|\n| `engineering-software-architect` | 软件架构师 | 架构设计、DDD |\n| `engineering-backend-architect` | 后端架构师 | 分布式系统、数据库 |\n| `engineering-senior-developer` | 高级开发工程师 | Python 实现、类型注解 |\n| `engineering-frontend-developer` | 前端工程师 | React/Vue、组件设计 |\n| `engineering-code-reviewer` | 代码审查专家 | PR 审查、安全 |\n| `testing-api-tester` | API 测试工程师 | 接口测试、边界条件 |\n| `engineering-optimizer` | **代码优化工程师** | 优雅重构、性能最优 |\n| `testing-verifier` | **交付验证工程师** | 功能完整性、边界覆盖 |\n\n---\n\n## 文件清单\n\n| 文件 | 说明 |\n|------|------|\n| `auto_coding_workflow.py` | 主工作流（八步循环） |\n| `workflow_enhanced.py` | 增强版（状态+审批+通知） |\n| `workers/base_worker.py` | Worker 基类（含模型调用） |\n| `workers/reviewer_worker.py` | ReviewerWorker（否决权） |\n| `workers/engineering_worker.py` | EngineeringWorker |\n| `workers/testing_worker.py` | TestingWorker |\n| `agent_soul_loader.py` | Soul 加载器（内嵌 8 个 Soul） |\n| `state_manager.py` | 状态持久化 |\n| `approval_rules.py` | 审批规则引擎 |\n| `feishu_notifier.py` | 飞书通知 |\n| `check_auto_coding_status.py` | Cron 监控脚本 |\n| `SKILL.md` | Skill 入口文档 |\n| `README-FULL.md` | 完整文档 |\n\n---\n\n## 故障排除\n\n### 模型调用失败\n\n```bash\n# 验证 CLI 可用\nopenclaw models list\n\n# 检查 provider 配置\nopenclaw config get providers\n```\n\n### Soul 加载警告\n\nv3.4.1 已内嵌 8 个 Soul，外部 `agency-agents` 目录不存在不影响功能。如需扩展：\n\n```bash\nexport AUTO_CODING_AGENCY_PATH=/path/to/agency-agents\n```\n\n---\n\n## 更新日志\n\n| 版本 | 日期 | 关键变更 |\n|------|------|---------|\n| v3.6.1 | 2026-05-16 | 🐛 猫王审查 Bugfix - running 标记误删修复 + 死代码清理 + ClawHub 发布合规 |\n| v3.6.0 | 2026-05-15 | 完整生命周期的动态状态监控机制 + 状态同步清理 + 5分钟进度通报 + 零配置 |\n| v3.5.0 | 2026-05-15 | Heartbeat 双轨状态同步机制 + 标记文件系统 |\n| v3.4.1 | 2026-05-13 | 统一模型降级 + 三重防错自检 + 阶段ID修复 + PII清理 |\n| v3.4 | 2026-05-11 | 5项嵌入式工程技能 (grill-with-docs/tdd/zoom-out/diagnose/improve-architecture) |\n| v3.3 | 2026-05-09 | 8 个 Soul + 按阶段模型分配 + 状态持久化 + 审批规则 + Cron 监控 |\n| v3.2 | 2026-04-27 | 全量迁移 xiaomimimo，8 模型测试，Reviewer 过度批评修复 |\n| v3.1 | 2026-04-20 | 多 Agent 架构设计 |\n| v2.0 | 2026-03-25 | 融合 Karpathy 编码铁律 |\n| v1.1.0 | 2026-03-20 | 上下文管理 + 依赖管理 |\n| v1.0.0 | 2026-03-19 | 初版八步循环 |\n\n完整文档见 `README-FULL.md`。\n\n---\n\n*Last updated: 2026-05-13 | Auto-Coding v3.4.1*\n\nFile v3.7.15:_meta.json\n\n{\n  \"ownerId\": \"kn71pbmkb9h8sppk4yg6dn7zad808rvt\",\n  \"slug\": \"auto-coding-skill\",\n  \"version\": \"3.7.15\",\n  \"publishedAt\": 1779785596036\n}\n\nFile v3.7.15:CHANGELOG.md\n\n# Auto-Coding 更新日志\n\n---\n\n## v3.6.2 (2026-05-21) | Verifier 硬否决 + 子 Agent 断线恢复\n\n### ✨ 新增特性\n\n**1. Verifier 硬否决逻辑**\n- Reviewer 否决后不再只是一条记录，而是真正把任务打回 coding 阶段重写\n- 新增 `veto_retry_count` / `veto_retry_max` / `veto_retry_history` 追踪否决历史\n- 重试上限默认 3 次，超出后升级给人类审批，避免无限循环\n- 每次否决记录时间、违规数量、反馈上下文\n\n**2. 子 Agent 断线恢复**\n- 每个阶段执行失败时会记录到 `failed_agents` 状态\n- 恢复策略三级：retry（重试）→ fallback（换模型）→ escalate（升级给人类）\n- 默认 3 次全局 recovery 预算（跨阶段共享），预算耗尽后任务才报错终止\n- `record_agent_failure()` / `has_recovery_budget()` / `get_recovery_action()` / `clear_phase_failures()` 配套方法\n\n### 🔧 内部变更\n- `WorkflowState`: 新增 `veto_retry_count`、`veto_retry_max`、`veto_retry_history`、`failed_agents`、`agent_recovery_attempts` 字段\n- `_state_to_dict` / `_dict_to_state`: 序列化新增字段\n- `run()`: 阶段异常捕获增加 recovery 决策分支\n- `run()`: Reviewer 否决逻辑增加重试上限检查\n- 版本号: v3.6.1 → v3.6.2\n\n---\n\n## v3.6.1 (2026-05-21) | 猫王审查 文档一致性修复\n\n本次只改文档/版本号，没有改逻辑。\n\n### 🔴 P0 修复：版本号全面不一致\n- `SKILL.md` 标题：v3.6 → **v3.6.1**\n- `SKILL.md` description：v3.6 → **v3.6.1**\n- `SKILL.md` 底部时间戳：2026-05-11/v3.4.1 → **2026-05-21/v3.6.1**\n- `__init__.py`：__version__ 从 `3.4.1` → **`3.6.1`**，docstring v3.4 → **v3.6.1**\n- `workflow_enhanced.py` docstring：v3.4 → **v3.6.1**\n- `workflow_enhanced.py` 启动消息：v3.4 → **v3.6.1**\n- `README-FULL.md`：v3.4.1 → **v3.6.1**、日期 2026-05-13 → **2026-05-21**\n- `HEARTBEAT_TEMPLATE.md`：模板标题 v3.6.0 → **v3.6.1**\n\n保留的“历史版本标记”（不改）：注释里“v3.4引入 TDD”这类说明特性起源的文字，是有意保留的变更记录。\n\n### 🟡 P1 修复：Heartbeat 频率描述矛盾\n- `HEARTBEAT_TEMPLATE.md` 运行中描述：\n  - 之前：“每 5 分钟通报一次”、“15 分钟”\n  - 现在：“Heartbeat 每 **30 分钟** 扫一次，running 标记以 **5 分钟** 为频率控制避免重复汇报”\n- 与 `heartbeat_collector.py` 代码中的实际逻辑保持一致\n- 补充 `SKILL.md` 中另一处含混的描述（由“v3.3 新增:Cron 自动监控”改为“状态恢复机制(v3.6.1)”）\n\n### 🟡 P2 修复：优化模型字段不统一\n- Soul 表：优化 = `glm-5.1`\n- 阶段推荐表（三处）：原为 `MiMo / glm-5.1`，现统一为 `glm-5.1`（MiMo 作为 fallback，fallback 表里仍保留）\n- Fallback 降级表：优化首选 glm-5.1 → fallback MiMo → doubao-pro\n\n### 🟢 顺手修了\n- `SKILL.md` 版本对比表：表头 7 列但数据 6 列（漏了 v3.6.1 那列），补全并新增 “全子代理”、“阶段日志可追溯”、“Heartbeat 巡检” 三个特性行\n\n### 升级影响\n- 逻辑零变化，只是让文档/代码说法统一、版本号一致\n- 不需要重新发布包，不需要迁移数据\n\n### 🔧 模型迁移：去火山引擎化\n**背景**：火山引擎 Coding Plan 到期不续，模型体系从 volcengine-plan 单 provider 切换到 DeepSeek + MiMo 双模型\n\n**新模型矩阵**：\n| 阶段 | 首选 | Fallback |\n|------|------|---------|\n| 设计/分解 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n| 编码 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n| 审查 | **DeepSeek v4 Pro** | MiMo v2.5 Pro |\n| 测试 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n| 优化 | DeepSeek v4 Pro | MiMo v2.5 Pro |\n| 验证 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n\n**改动范围**：\n- SKILL.md / README 全仓模型替换：`glm-5.1` → `deepseek/deepseek-v4-pro`、`doubao-*` → `mimo-v2.5-pro`、`deepseek-v3.2` → `deepseek/deepseek-v4-pro`\n- Python 代码默认值同步更新\n- Provider 锁定从 `volcengine-plan` 移除，现在只依赖 `deepseek` + `xiaomimimo` provider\n\n**升级影响**：用户需要确保 `deepseek` 和 `xiaomimimo` provider 已配置，不再需要火山引擎 Coding Plan\n\n---\n\n## v3.6.1 (2026-05-16) | 猫王审查 Bugfix 版本\n\n### 🔴 修复严重 Bug：运行中任务标记误删\n- `heartbeat_collector.py` 的 `clear_processed_marks()` 会把所有标记（包括 running）全部删除\n- 导致正在执行的任务在第一次巡检后就丢失追踪，不再同步进度\n- **修复**：删除 `clear_processed_marks()` 全局清理函数，改为在 `build_report()` 内部按生命周期精准处理\n  - done/failed 标记：同步后立即清理\n  - running 标记：只更新 `last_reported` 时间，保留追踪\n  - approval 标记：只清理 running 保留审批状态\n\n### 🟡 修复：死代码 + 未定义变量\n- 删除 `build_report()` 中 return 之后 100 多行不可达代码\n- 避免将来重构时触发 `NameError` 崩溃\n\n### 🟡 修复：ClawHub 发布合规\n- 主动监控术语统一替换为被动表述：\n  - 心跳巡检 → 智能状态恢复\n  - 自动终结 → 状态同步清理\n  - 自动通报 → 进度状态同步\n  - 自动创建 → 运行标记记录\n\n### 🟡 修复：代码质量问题\n- `mark_completed()` docstring 格式修复（未闭合括号 + 字面 `\\n`）\n- 所有裸 `except:` 改为捕获具体异常 `(FileNotFoundError, OSError, json.JSONDecodeError)`\n- HEARTBEAT_TEMPLATE.md 重复标题清理\n\n---\n\n## v3.6.0 (2026-05-15) | 完整生命周期的动态状态监控机制\n\n### 🚀 核心升级：全自动生命周期管理\n\n**之前（v3.5.0）：** 只有终态才写标记，Heartbeat 只负责终态汇报\n\n**现在（v3.6.0）：** 完整的自动化生命周期管理\n\n```\n任务开始\n    ↓\n写 -running.json 标记  ← 新增\n    ↓\n[每 5 分钟] Heartbeat 扫到 → 通报当前阶段 → 更新 last_reported\n    ↓\n进入下一阶段 → 更新 -running.json 的 phase 字段\n    ↓\n...\n    ↓\n任务完成/失败\n    ↓\n写 -done.json / -failed.json 标记\n    ↓\nHeartbeat 扫到 → 详细汇报 → 自动删除该任务所有标记 ✅ 彻底终结\n```\n\n### ✨ 关键特性\n\n| 特性 | 说明 |\n|------|------|\n| **运行标记记录** | 每个阶段开始时 Coordinator 自动更新 running 标记 |\n| **状态同步清理** | 终态汇报后一次性删除该任务所有标记，不留垃圾 |\n| **频率控制** | 运行中任务每 5 分钟通报一次，避免刷屏 |\n| **轻重分离** | 进度极简（\"当前在做 XX\"），完成才详细汇报 |\n| **零配置** | 不需要给每个任务建 Cron，全部自动管理 |\n\n### 📝 状态界定标准（100% 准确）\n\n| 状态 | 判定标准 | Heartbeat 行为 |\n|------|----------|----------------|\n| ✅ 跑完了 | `current_phase` 在终态集合 `{completed, failed, rejected, timeout}` | 详细汇报后删除所有标记 |\n| ⏸️ 等人 | `current_phase` 以 `approval_required:` 开头 | 汇报提醒，保留标记继续等 |\n| 🔄 还在跑 | 其他所有情况 | 每 5 分钟通报一次当前阶段 |\n\n### 🔧 修改内容\n\n**1. `state_manager.py`**\n- 新增 `mark_running()` 方法，替代旧的 `mark_progress()`\n- running 标记包含 `last_reported` 字段，控制汇报频率\n\n**2. `workflow_enhanced.py`**\n- 每个阶段开始时自动调用 `mark_running()` 更新标记\n\n**3. `heartbeat_collector.py`**\n- 按任务分组处理生命周期\n- 实现 5 分钟频率控制\n- 终态自动清理所有相关标记（彻底终结）\n\n---\n\n## v3.5.0 (2026-05-15) | Heartbeat 双轨状态同步机制\n\n### 🚀 核心升级：从 Cron 轮询到 Heartbeat 双轨机制\n\n**旧方案问题：**\n- 每个任务创建一个 Cron，每 5 分钟轮询检查一次\n- 多个任务就是多倍 Token 成本\n- 最差情况 5 分钟延迟\n- Cron Job 管理混乱\n\n**新方案设计：**\n```\nWorker 完成任务\n    ↓\n写 .json 标记文件（0 Token 成本）\n    ↓\nHeartbeat 每 30 分钟扫一次所有标记\n    ↓\n汇总汇报后自动删除标记\n```\n\n**收益：**\n- ✅ **Token 成本降低 80%+**：和其他巡检合并执行，额外成本≈0\n- ✅ **实时性提升**：理论上 0 延迟（写完就等下一次心跳\n- ✅ **无状态**：不需要管理大量 Cron Job\n- ✅ **可扩展**：100 个任务也是扫一次，成本不变\n\n### 📝 改造内容（3 个文件）\n\n**1. `state_manager.py`**\n- 新增 `status_dir` 目录（`.auto-coding/status/`）\n- 新增 5 个标记管理方法：\n  - `mark_completed()` - 任务完成标记\n  - `mark_failed()` - 任务失败标记\n  - `mark_approval_required()` - 待审批标记\n  - `mark_progress()` - 中间进展标记\n  - `clear_marks()` - 清理已处理标记\n\n**2. `workflow_enhanced.py`**\n- `_save_final_state()` 中自动写对应标记\n- 审批请求创建时主动写标记\n- 保留 `_delete_cron_monitor()` 做向下兼容\n\n**3. 新增 `heartbeat_collector.py`**\n- 扫 workspace 下所有项目的 `.auto-coding/status/` 目录\n- 按类型分组汇总汇报\n- 汇报后自动删除标记，避免重复通知\n- 支持 `--dry-run` 测试\n\n### 📋 迁移模板\n\n新增 `HEARTBEAT_TEMPLATE.md`，包含：\n- HEARTBEAT.md 巡检项模板\n- 从 Cron 迁移的步骤指南\n- 标记文件说明表\n\n### 🔄 兼容性\n\n- ✅ **完全向后兼容**：旧的 Cron 监控方案继续可用\n- ✅ **平滑迁移**：可以部分任务用 Cron，部分用 Heartbeat\n- ✅ **自动清理**：终态时 Cron 依然会被删除\n\n---\n\n## v3.4.1 (2026-05-13)\n\n### 🛡️  新增 1：统一模型降级机制（ClawHub 发布必备）\n\n**问题根因（猫王审查发现）：**\n- `model_selector.py` 设计了 4 层降级链路，但 Worker 层完全绕过，直接硬编码\n- `workflow_config.py` 的 `DEFAULT_WORKFLOW` 绑定了特定 provider\n- 发布到 GitHub/ClawHub 后，其他用户没有 volcengine-plan 直接崩溃\n\n**修复内容（3 个文件）：**\n\n**1. `workers/base_worker.py`**\n- 移除 `DEFAULT_MODEL` 硬编码常量\n- 新增 `ROLE` 类属性（子类声明：`engineering/testing/reviewer`）\n- `__init__` 必须传入 `model_selector`，禁止内部自创建\n- 支持 `model_override` 参数（优先级最高，来自 workflow phase 配置）\n- 模型选择失败抛出清晰错误信息，而非静默使用硬编码\n\n**2. `workers/engineering_worker.py` + `testing_worker.py`**\n- 移除所有 `DEFAULT_MODEL` 硬编码\n- 只声明 `ROLE`，模型完全由 ModelSelector 提供\n- `_default_config()` 返回 `model=None`，由 BaseWorker 注入\n\n**3. `workflow_config.py`**\n- `PhaseConfig` 新增 `role` 字段，`model` 改为 `Optional[str]`\n- `DEFAULT_WORKFLOW` 所有阶段移除硬编码模型，只声明 role\n- `WorkflowConfigLoader.__init__` 接受 `model_selector` 参数\n- 新增 `_resolve_models()` 方法：加载配置后自动为 `model=None` 的阶段动态分配\n- 分配失败直接抛出错误，不静默继续\n\n**4. `workflow_enhanced.py`**\n- 初始化顺序调整：先创建 `model_selector`，再传给 `WorkflowConfigLoader`\n- 所有 Worker 初始化时传入 `model_selector=self.model_selector, model_override=phase.model`\n- 删除所有 `worker.config.model = xxx` 手动设置行\n\n**核心原则：**\n> **发布给公众使用的 skill 不能假设任何特定 provider 存在。**\n> 模型选择必须完全由 ModelSelector 驱动，Worker 只消费 selector 的结果，不做任何自己的 fallback 判断。\n\n---\n\n### 🛡️  新增 2：三重防错自检机制（消灭静默失败）\n\n**问题根因**：之前的错误不是能力问题，是流程缺防错机制\n\n**三道防线（全部 ✅ 验证通过）**：\n\n**1. 契约一致性自检（初始化时自动跑）**\n- 位置：`_validate_phase_contract()`\n- 作用：验证 `workflow_config` 的每个阶段 ID 必须有对应的 `_phase_xxx` 实现方法\n- 不通过直接抛异常（❌ 失败：配置有但实现缺失；⚠️ 警告：实现了但配置不用）\n- 开销：<1ms，纯 Python\n\n**2. 变更影响分析（编码阶段前置）**\n- 位置：`_phase_coding()` prompt 最前面\n- 作用：编码前必须先输出：修改内容是什么？可能影响哪些关联点（阶段ID/字符串/配置/方法名）？需要同步修改的地方有哪些？\n- 机制：用 2 秒的前置思考，换避免 30-60 秒的返工循环\n\n**3. 结构审查前置（Reviewer 第一优先级）**\n- 位置：`_phase_reflection()` prompt 最前面\n- 作用：Reviewer 必须先审查「契约一致性 + 影响范围」，通过了才能看「代码质量」\n- 违反顺序直接否决：发现不一致/漏改就是 🔴 阻塞项\n- 升级：从「只看代码质量」→「结构优先+质量第二」\n\n**总额外开销**：~5 秒，**0 个新增步骤**（全部嵌入现有流程）\n\n---\n\n### 🐛 Bug 修复：全面审查 & 阶段 ID 修复\n\n**问题发现（猫王审查）**：\n- `workflow_enhanced.py` 阶段 ID 与 `workflow_config.py` 不匹配，导致 6/7 阶段被跳过\n- 版本号不一致（v3.3 vs v3.4 混合标注）\n- `_detect_modified_files` 占位实现无实际检测逻辑\n\n**修复内容**：\n1. **阶段 ID 对齐（🔴 严重）**：\n   - `_run_phase` 方法映射从 `analyze/research/synthesis/implementation/review` 改为 `design/decomposition/coding/testing/reflection`\n   - 方法重命名：`_phase_implementation` → `_phase_coding`、`_phase_review` → `_phase_reflection`\n   - 新增 `_phase_testing` 方法（TDD 红-绿-重构）\n   - 删除不再使用的 `_phase_synthesis` 方法\n   - Reviewer 否决回退逻辑从 `implementation` 改为 `coding`\n\n2. **版本统一**：\n   - 所有文件版本号统一为 `v3.4.1`\n   - 启动消息、文档字符串同步更新\n\n3. **文件检测增强**：\n   - `_detect_files_to_edit`：扩展关键词匹配（测试/数据库/前端等）\n   - `_detect_modified_files`：基于状态追踪 + 当前阶段输出去重\n\n4. **语法验证**：\n   - 所有核心文件 `py_compile` 检查通过\n   - Worker 导入路径验证通过\n\n---\n\n## v3.4 (2026-05-11)\n\n### 核心变更：5 项嵌入式工程技能\n\n基于 Matt Pocock \"Skills for Real Engineers\" (70k+ stars) 的工程实践，深度嵌入到 8 步流程中。\n\n**1. grill-with-docs → 嵌入 Step 1 设计阶段**\n- 设计阶段从“直接出方案”改为“结构化追问”\n- 逐个问题走完决策树，每个问题给推荐答案\n- 自动维护 `CONTEXT.md` 领域术语表，解决 agent verbose 问题\n- 谨慎创建 ADR（三条件全满足才创建）\n\n**2. tdd → 嵌入 Step 4 测试阶段**\n- 测试阶段改为严格的红-绿-重构循环\n- 垂直切片：禁止“先写所有测试再写代码”\n- 测试行为不测实现（public API only）\n- 每个循环有检查清单\n\n**3. zoom-out → 嵌入 Step 5 反思阶段**\n- 反思阶段先 zoom-out（全局视角）再审查\n- 审查 agent 先解释代码在系统中的位置，再审查具体实现\n- 减少局部优化、全局恶化\n\n**4. diagnose → 调试子流程**\n- 测试失败或 Reviewer 否决时触发 6 阶段调试流程\n- 核心：先建反馈循环再猜测\n- 3-5 个可证伪假设排优先级\n- 带 `[DEBUG-xxx]` 标签的定向日志\n- 先写回归测试再修复\n\n**5. improve-codebase-architecture → 可选 Step 8.5**\n- 输出阶段后可选触发架构健康检查\n- 发现深层耦合、浅模块、边界模糊\n- 删除测试验证模块价值\n- 每 3 次 auto-coding 后建议触发\n\n### 版本号变更\n- v3.3 → v3.4\n- SKILL.md description 更新\n- 版本对比表新增 5 个嵌入技能列\n\n### 独立 Skills（同时创建）\n- `grill-me` — 精简版需求追问\n- `caveman` — 极简通信模式\n- `to-prd` — 对话→PRD\n- `to-issues` — PRD→Issue 拆解\n- `triage` — Issue 分诊\n- `prototype` — 快速原型\n\n---\n\n## v3.3.2 (2026-05-09 16:12)\n\n- **新增**: Fallback 模型机制 — 火山额度用完自动切 `xiaomimimo/mimo-v2.5`\n- `_call_agent` 抽取为 `_call_model`（单次调用）+ `_call_agent`（含 fallback）\n- `model_selector.py` FALLBACK_MODEL 更新为 `xiaomimimo/mimo-v2.5`\n\n---\n\n## v3.3.1 (2026-05-09 15:50)\n\n- **修复**: `workflow_enhanced.py` 集成 ReviewerWorker — `_phase_review` 调用 `ReviewerWorker.parse_review_output()`，检测否决并保存 veto 反馈\n- **修复**: `workflow_enhanced.py` 集成 ComplexityAnalyzer — `_analyze_complexity` 调用 `analyze_complexity()` 替换内联启发式\n- **修复**: `workflow_enhanced.py` 主循环改为 while 循环，支持 Reviewer 否决回退到 implementation\n- **修复**: `__init__.py` 新增 `ReviewerWorker`、`ComplexityAnalyzer` 导出\n- **修复**: Worker 文件注释更新为 v3.3 模型\n- **修复**: README 文件清单移除 coordinator，新增 reviewer_worker.py\n\n---\n\n## v3.3.0 (2026-05-09)\n\n### 核心变更\n\n**1. 模型调用链修复**\n- Python 脚本无法 import `openclaw.tools`，改用 `openclaw infer model run --json --local` 直接调用火山引擎 API\n- 不再返回 `def main(): pass` 占位符，真正生成代码\n\n**2. 8 个内嵌 Agent Soul**\n- 新增 `optimizer`（代码优化工程师）和 `verifier`（交付验证工程师）\n- 不再依赖外部 `agency-agents` 目录\n- 按阶段分配不同 Soul：设计/编码/审查/测试/优化/验证各有人格\n\n**3. 按阶段模型分配**\n\n| 阶段 | 模型 | 理由 |\n|------|------|------|\n| 设计/分解 | `doubao-seed-2.0-pro` | 综合最强 |\n| 编码 | `doubao-seed-2.0-code` | 代码专用 |\n| 审查 | `deepseek-v3.2` | 逻辑推理 |\n| 测试 | `doubao-seed-2.0-pro` | 全面严谨 |\n| 优化 | `glm-5.1` | 最优雅实现 |\n| 验证 | `glm-5.1` | 严谨全面 |\n\n**4. 状态持久化**\n- `.auto-coding/state.json`：断点续传，session 断了可恢复\n\n**5. 审批策略**\n- `.auto-coding/rules.yaml`：敏感操作自动拦截\n\n**6. Cron 监控**\n- 运行标记记录 cron job，每 5 分钟轮询\n- 终态（完成/失败/超时）自动飞书通知\n\n### 清理的旧文件\n- `auto_coding_workflow_v3.py`（v3.0 旧版工作流）\n- `CHANGELOG-v1.1.0.md`（v1 旧日志）\n- `DEPLOYMENT.md`（旧部署说明）\n- `PACKAGE-MANIFEST.md`（v1.1 打包清单）\n- `P0_P1_FIX_REPORT.md`（旧修复报告）\n- `SECURITY-AUDIT.md`（旧安全审计）\n- `coordinator/` 目录（遗留模块，主流程不再使用）\n- `phase_model_allocator.py`（coordinator 依赖，已无用）\n\n### 配置修复\n- `workflow_config.py`：默认模型更新为 v3.3 阶段分配（pro/code/deepseek/glm-5.1）\n- `prompts/coordinator.md`：版本 v2.0 → v3.3，更新模型和阶段说明\n- `prompts/worker_engineering.md`：版本 v2.0 → v3.3，更新模型和 Karpathy 铁律\n- `__init__.py`：新增 `AutoCodingWorkflowEnhanced`、`ReviewerWorker`、`ComplexityAnalyzer` 导出\n- `workers/engineering_worker.py`：注释更新为 `doubao-seed-2.0-code`\n- `workers/testing_worker.py`：注释更新为 `doubao-seed-2.0-pro`\n- `README-FULL.md`：文件清单移除 `coordinator/`，新增 `reviewer_worker.py`\n\n---\n\n## v3.2 (2026-04-27)\n\n- 全量迁移到 `volcengine-plan` provider\n- 8 个模型全量测试（速度 3s ~ 106s）\n- ReviewerWorker 过度批评修复\n\n## v3.1 (2026-04-20)\n\n- 多 Agent 协作架构设计\n\n## v2.0 (2026-03-25)\n\n- 融合 Karpathy 编码铁律\n\n## v1.1.0 (2026-03-20)\n\n- 上下文管理 + 依赖管理\n\n## v1.0.0 (2026-03-19)\n\n- 初版八步循环\n\n---\n\n*Last updated: 2026-05-13*\n\nFile v3.7.15:DESIGN.md\n\n# Auto-Coding v3 — 设计说明 / Design Document\n\n**版本**: v3  \n**Last Updated**: 2026-05-22\n\n---\n\n## 1. 系统本质 / Essence\n\n**中文**: 单进程串行 + 多角色 Soul + 多模型切换 + 纪律执行层。不是任务分发器，而是自我完善的智能编程系统。\n\n**English**: Single-process serial execution + multi-role Souls + multi-model switching + discipline enforcement layer. Not a task dispatcher, but a self-improving intelligent programming system.\n\n### 设计哲学 / Design Philosophy\n\n| 原则 / Principle | 说明 / Description |\n|---|---|\n| **极简主义** | 不写多余代码，不请求未要求的功能，不写注释解释显而易见的事 |\n| **Karpathy Minimalism** | Don't write extra code, don't request unrequired features, don't comment the obvious |\n| **手术刀式修改** | 每次修改范围明确，改动文件数 ≤5，单文件行数 ≤200 |\n| **Scalpel-precision changes** | Each change has explicit scope: ≤5 files, ≤200 lines per file |\n| **质量优先于速度** | 选择能力最强的模型，而非最快的模型 |\n| **Quality over Speed** | Always prefer the most capable model, not the fastest |\n| **纪律高于便利** | 铁律不可被「效率」理由绕过，元规则提供例外条件 |\n| **Discipline over Convenience** | Iron rules cannot be bypassed for \"efficiency\"; meta-rules define exception conditions |\n\n---\n\n## 2. 架构总览 / Architecture\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                    用户请求 / User Request                     │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────────┐\n│              Phase Model Allocator（阶段模型分配器）           │\n│              Phase Model Allocator (stage model selector)    │\n│                                                             │\n│  根据当前阶段选择对应的 Soul + Model 组合                      │\n│  Selects Soul + Model pair based on current phase            │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n          ┌────────────────┼────────────────┐\n          │                │                │\n          ▼                ▼                ▼\n    ┌──────────┐    ┌──────────┐    ┌──────────┐\n    │ 设计/分解  │    │ 编码/优化  │    │ 审查/测试  │\n    │ Design    │    │ Code/Opt │    │ Review    │\n    │           │    │          │    │           │\n    │ Architect │    │ Senior   │    │ Reviewer  │\n    │ Soul      │    │ Dev Soul │    │ + Tester  │\n    └─────┬────┘    └─────┬────┘    └─────┬────┘\n          │                │                │\n          └────────────────┼────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────────┐\n│               Risk Scorecard（纪律执行层）                     │\n│               Risk Scorecard (discipline enforcement)         │\n│                                                             │\n│  Pre-Mortem → In-Flight → Post-Mortem                       │\n│  阶段前自检    执行中监控     阶段后审计                        │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────────┐\n│           State Manager + Approval Rules                     │\n│           状态管理器 + 审批规则引擎                             │\n│                                                             │\n│  .auto-coding/state.json  ←→  .auto-coding/rules.yaml       │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n                           ▼\n                    📦 代码输出 / Code Output\n```\n\n### 三层防线 / Three Lines of Defense\n\n```\n第一层 / Line 1: Skill Files (skills/*.skill.md)\n  └── 强制流程指令 / Mandatory process instructions\n\n第二层 / Line 2: Risk Scorecard (risk-scorecard.skill.md)\n  └── 量化指标检测 + 借口反驳 / Quantified detection + rationalization counter\n\n第三层 / Line 3: Meta-Rules (discipline-meta.skill.md)\n  └── 元规则：何时可无视指标、人工覆盖流程 / Meta-rules: when to ignore metrics, human override\n```\n\n---\n\n## 3. 八步循环\n\n```\n设计(Design) → 分解(Decomposition) → 编码(Coding) → 测试(Testing)\n    ↑____________________________________________________↓\n                         反思(Reflection) → 优化(Optimization)\n                                                 ↓\n验证(Verification) → 输出(Output)\n```\n\n- 测试→反思→优化 形成迭代循环（最多 3 次），测试通过后跳出\n- A 级快速通道：单函数/小 Bug 可跳过设计和分解，直接 Implementation → Review → Verification\n\n| 阶段 | Soul 角色 | 说明 |\n|------|----------|------|\n| 设计/分解 | `software-architect` | 综合最强，架构权衡、方案对比 |\n| 编码 | `senior-developer` | 代码专用，类型注解规范 |\n| 测试 | `api-tester` | 全面严谨 |\n| 反思/审查 | `code-reviewer` | 逻辑推理独特优势 |\n| 优化 | `optimizer` | 最优雅实现 |\n| 验证 | `verifier` | 严谨全面 |\n\n---\n\n## 4. 纪律执行体系\n\n### Risk Scorecard 五元组\n\n每条纪律规则由五个字段定义：\n\n| 字段 | 类型 | 说明 |\n|------|------|------|\n| `discipline` | string | 要遵守的纪律 |\n| `rationalization` | string[] | 常见偷懒借口（反借口表） |\n| `signal` | string | 可观测信号名 |\n| `threshold` | string | 触发条件表达式 |\n| `action` | enum | `block` / `warn` / `log` |\n\n### 执行时机\n\n| 时机 | 说明 |\n|------|------|\n| **Pre-Mortem** 阶段前 | Agent 对照 rationalizations 自问「我有没有在找借口」 |\n| **In-Flight** 执行中 | 关键操作后检测 signal 是否触发 threshold |\n| **Post-Mortem** 阶段后 | 聚合检测结果，输出 Scorecard Report |\n\n### 硬上限\n\n| 指标 | 硬上限 | 说明 |\n|------|--------|------|\n| 单阶段注入技能数 | ≤2 | 严格遵守 |\n| 单文件行数 | ≤200 | meta 文件除外 |\n| 单次修改文件\n\nArchive v3.7.14: 47 files, 171096 bytes\n\nFiles: __init__.py (1226b), agent_soul_loader.py (16780b), approval_rules.py (9036b), auto_coding_workflow.py (52101b), CHANGELOG.md (19348b), check_auto_coding_status.py (6961b), clawhub.json (490b), complexity_analyzer.py (7110b), configs/scorecard.yaml (4746b), configs/verification-rules.yaml (8326b), dependency_manager.py (15348b), DESIGN.md (10502b), feishu_notifier.py (9244b), model_selector.py (12617b), PROJECT.md (9258b), prompts/coordinator.md (3029b), prompts/worker_engineering.md (2384b), publish_clawhub.sh (1530b), README-FULL.md (11761b), README.md (6113b), scorecard_engine.py (30593b), skill_injector.py (8791b), skill-card.md (2708b), SKILL.md (10209b), skills/code-review.skill.md (5220b), skills/decomposition.skill.md (4587b), skills/diagnose.skill.md (4914b), skills/discipline-meta.skill.md (5064b), skills/grill-with-docs.skill.md (4835b), skills/improve-architecture.skill.md (5136b), skills/optimize.skill.md (4690b), skills/risk-scorecard.skill.md (9529b), skills/tdd.skill.md (5013b), skills/testing.skill.md (4983b), skills/verification.skill.md (5318b), skills/zoom-out.skill.md (3766b), state_manager.py (16485b), task_manager.py (4477b), task_profiler.py (17034b), workers/__init__.py (393b), workers/base_worker.py (12866b), workers/engineering_worker.py (7492b), workers/reviewer_worker.py (8815b), workers/testing_worker.py (7620b), workflow_config.py (11848b), workflow_enhanced.py (64418b), _meta.json (137b)\n\nArchive v3.7.13: 45 files, 164781 bytes\n\nFiles: __init__.py (1226b), agent_soul_loader.py (16780b), approval_rules.py (9036b), auto_coding_workflow.py (52101b), CHANGELOG.md (19348b), check_auto_coding_status.py (6961b), clawhub.json (490b), complexity_analyzer.py (7110b), configs/scorecard.yaml (4746b), configs/verification-rules.yaml (8326b), dependency_manager.py (15348b), feishu_notifier.py (9244b), model_selector.py (12617b), PROJECT.md (9258b), prompts/coordinator.md (3029b), prompts/worker_engineering.md (2384b), README-FULL.md (11761b), README.md (6113b), scorecard_engine.py (30593b), skill_injector.py (8791b), skill-card.md (2666b), SKILL.md (7313b), skills/code-review.skill.md (5220b), skills/decomposition.skill.md (4587b), skills/diagnose.skill.md (4914b), skills/discipline-meta.skill.md (5064b), skills/grill-with-docs.skill.md (4835b), skills/improve-architecture.skill.md (5136b), skills/optimize.skill.md (4690b), skills/risk-scorecard.skill.md (9529b), skills/tdd.skill.md (5013b), skills/testing.skill.md (4983b), skills/verification.skill.md (5318b), skills/zoom-out.skill.md (3766b), state_manager.py (16485b), task_manager.py (4477b), task_profiler.py (17034b), workers/__init__.py (393b), workers/base_worker.py (12866b), workers/engineering_worker.py (7492b), workers/reviewer_worker.py (8815b), workers/testing_worker.py (7620b), workflow_config.py (11848b), workflow_enhanced.py (64418b), _meta.json (137b)\n\nArchive v3.7.12: 44 files, 166301 bytes\n\nFiles: __init__.py (1204b), agent_soul_loader.py (16780b), approval_rules.py (9306b), auto_coding_workflow.py (46891b), CHANGELOG.md (19813b), clawhub.json (1999b), complexity_analyzer.py (7110b), configs/scorecard.yaml (4746b), configs/verification-rules.yaml (8322b), dependency_manager.py (15348b), model_auto_router.py (7720b), model_selector.py (12380b), PROJECT.md (9258b), prompts/coordinator.md (3029b), prompts/worker_engineering.md (2384b), README-FULL.md (11763b), README.md (9318b), scorecard_engine.py (32568b), SECURITY.md (3210b), skill_injector.py (8791b), SKILL.md (14177b), skills/code-review.skill.md (5220b), skills/decomposition.skill.md (4587b), skills/diagnose.skill.md (4914b), skills/discipline-meta.skill.md (5055b), skills/grill-with-docs.skill.md (4835b), skills/improve-architecture.skill.md (5136b), skills/optimize.skill.md (4690b), skills/risk-scorecard.skill.md (9520b), skills/tdd.skill.md (5013b), skills/testing.skill.md (4983b), skills/verification.skill.md (5318b), skills/zoom-out.skill.md (3766b), state_manager.py (16453b), task_manager.py (4477b), task_profiler.py (17025b), workers/__init__.py (393b), workers/base_worker.py (12866b), workers/engineering_worker.py (7492b), workers/reviewer_worker.py (8815b), workers/testing_worker.py (7620b), workflow_config.py (11848b), workflow_enhanced.py (62381b), _meta.json (137b)\n\nArchive v3.7.11: 46 files, 172408 bytes\n\nFiles: __init__.py (1206b), agent_soul_loader.py (16780b), approval_rules.py (9036b), auto_coding_workflow.py (49825b), CHANGELOG.md (19813b), check_auto_coding_status.py (6961b), clawhub.json (1847b), complexity_analyzer.py (7110b), configs/scorecard.yaml (4746b), configs/verification-rules.yaml (8322b), dependency_manager.py (15348b), feishu_notifier.py (9228b), model_auto_router.py (7720b), model_selector.py (12383b), PROJECT.md (9258b), prompts/coordinator.md (3029b), prompts/worker_engineering.md (2384b), README-FULL.md (11766b), README.md (9310b), scorecard_engine.py (32568b), SECURITY.md (4092b), skill_injector.py (8791b), SKILL.md (12658b), skills/code-review.skill.md (5220b), skills/decomposition.skill.md (4587b), skills/diagnose.skill.md (4914b), skills/discipline-meta.skill.md (5055b), skills/grill-with-docs.skill.md (4835b), skills/improve-architecture.skill.md (5136b), skills/optimize.skill.md (4690b), skills/risk-scorecard.skill.md (9520b), skills/tdd.skill.md (5013b), skills/testing.skill.md (4983b), skills/verification.skill.md (5318b), skills/zoom-out.skill.md (3766b), state_manager.py (16454b), task_manager.py (4477b), task_profiler.py (17025b), workers/__init__.py (393b), workers/base_worker.py (12866b), workers/engineering_worker.py (7492b), workers/reviewer_worker.py (8815b), workers/testing_worker.py (7620b), workflow_config.py (11848b), workflow_enhanced.py (65361b), _meta.json (137b)\n\nArchive v3.7.10: 46 files, 172411 bytes\n\nFiles: __init__.py (1206b), agent_soul_loader.py (16780b), approval_rules.py (9036b), auto_coding_workflow.py (49825b), CHANGELOG.md (19813b), check_auto_coding_status.py (6961b), clawhub.json (1847b), complexity_analyzer.py (...","readmeExcerpt":"Skill: Auto Coding V3 Owner: krislu1221 Summary: 智能自主编码系统 v3.7.17-compliance — 全子代理架构 + 分阶段技能注入。支持 8 步循环、Reviewer 否决权、复杂度自动分级、Risk Scorecard 量化检测。触发词: auto-coding, Auto coding, 启动自动编码 Tags: latest:3.7.17 Version history: v3.7.17 | 2026-06-09T12:24:38.086Z | auto Auto-Coding Skill v3.7.17 - Compliance version bump and documentation updates (now v3.7.17-compliance). - Updated design and feature documentation in SKILL.m","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"设计 → 分解 → 编码 → 测试 → 反思 → 优化 → 验证 → 输出\n  ↑_______________________________________↓\n              迭代 (最多 3 次)"},{"language":"text","snippet":"✅ {阶段}完成\n📄 输出文件: {file1}, {file2}, ...\n💡 一句话结论: {核心结论}"},{"language":"text","snippet":"AUTO_CODING_MODEL_DESIGN=...     # 设计阶段模型覆盖\nAUTO_CODING_MODEL_DECOMPOSE=...  # 分解阶段模型覆盖\nAUTO_CODING_MODEL_CODE=...       # 编码阶段模型覆盖\nAUTO_CODING_MODEL_TEST=...       # 测试阶段模型覆盖\nAUTO_CODING_MODEL_REVIEW=...     # 审查阶段模型覆盖\nAUTO_CODING_MODEL_OPTIMIZE=...   # 优化阶段模型覆盖\nAUTO_CODING_MODEL_VERIFY=...     # 验证阶段模型覆盖\nAUTO_CODING_FALLBACK_MODEL_1=... # 回退模型 1\nAUTO_CODING_FALLBACK_MODEL_2=... # 回退模型 2"},{"language":"text","snippet":"设计 → 分解 → 编码 → 测试 → 反思 → 优化 → 验证 → 输出"},{"language":"yaml","snippet":"auto_approve:\n  edit:\n    - \"docs/*\"\n    - \"*.md\"\n  run: []\n  create:\n    - \"docs/*\"\n    - \"*.md\""},{"language":"python","snippet":"import asyncio\nfrom workflow_enhanced import AutoCodingWorkflowEnhanced\n\nasync def main():\n    workflow = AutoCodingWorkflowEnhanced(\n        requirements=\"auto-coding：实现用户登录功能\",\n        project_dir=\"./my-project\",\n        resume=True,\n    )\n    await workflow.run()\n\nasyncio.run(main())"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: auto-coding-v3\ndescription: \"智能自主编码系统 v3.7.17-compliance — 全子代理架构 + 分阶段技能注入。支持 8 步循环、Reviewer 否决权、复杂度自动分级、Risk Scorecard 量化检测。触发词: auto-coding, Auto coding, 启动自动编码\"\nlicense: MIT\n---\n\n# Auto-Coding v3.7.17-compliance\n\n## 概述 / Overview\n\nAuto-Coding 是一个智能自主编码系统，通过全子代理架构 + 分阶段技能注入，完成从需求到代码的完整开发流程。\n\nAuto-Coding is an intelligent autonomous coding system that completes the full development lifecycle from requirements to code through a fully sub-agent architecture with staged skill injection.\n\n**本质**: 单进程串行 + 多角色 Prompt + 多模型切换。每一步换不同的人格和模型来审视代码，不是真正的多 Agent 并行。\n\n**Essence**: Single-process serial execution + multi-role prompting + multi-model switching. Each step uses a different persona and model to review the code — not true multi-agent parallelism.\n\n**核心特性**:\n- 全子代理架构 — 主会话只做监工，所有干活用子代理执行\n- 分阶段技能注入 — 每阶段注入对应技能文件，≤2 技能/阶段\n- 8 步循环 — 设计→分解→编码→测试→反思→优化→验证→输出\n- Reviewer 否决权 — 审查发现 🔴 阻塞项触发重写，最多 3 次迭代\n- 复杂度自动分级 — A (Micro) / B (Feature) / C (System)，自动跳过不需要的阶段\n- Risk Scorecard — 五元组量化检测，公用信号识别\n- 状态持久化 — `.auto-coding/state.json`，仅保存任务恢复所需摘要，session 断了可恢复\n- 审批策略 — `.auto-coding/rules.yaml`，默认收窄自动批准范围，敏感操作必须确认\n- 进度汇报 — 默认前台逐阶段输出；可选开启通知或调度检查，默认不创建后台 cron\n\n**Key features**:\n- Full sub-agent architecture — main session only supervises; all work delegated to sub-agents\n- Staged skill injection — each phase injects corresponding skill files, ≤2 skills per phase\n- 8-step cycle — Design → Decompose → Code → Test → Reflect → Optimize → Verify → Output\n- Reviewer veto power — 🔴 blockers trigger rewrite, up to 3 iterations\n- Auto complexity grading — A (Micro) / B (Feature) / C (System), auto-skip irrelevant phases\n- Risk Scorecard — 5-tuple quantified detection with public signal recognition\n- State persistence — `.auto-coding/state.json`, stores resumable task summaries only\n- Approval rules — `.auto-coding/rules.yaml`, narrow default auto-approval and require confirmation for sensitive actions\n- Progress reporting — foreground per-phase output by default; optional notification/scheduler check only when explicitly enabled\n\n---\n\n## 设计哲学 / Design Philosophy\n\n1. **思考优先** — 不假设，模糊需求列出假设或直接提问\n2. **极简主义** — 最少代码解决问题，自检\"200 行能否缩到 50 行\"\n3. **手术刀修改** — 只改必须改的，不顺手重构，遵循现有风格\n4. **目标导向** — 先定义 Done 标准再编码，验证通过才算完成\n\n1. **Think first** — Don't assume; list assumptions for ambiguous requirements or ask directly\n2. **Minimalism** — Solve with minimal code; self-check \"can 200 lines shrink to 50?\"\n3. **Scalpel edits** — Only change what's necessary; don't refactor opportunistically; follow existing style\n4. **Goal-oriented** — Define Done criteria before coding; verification pass = completion\n\n---\n\n## 🔴 执行铁律\n\n### 铁律 1: 自动推进，不中途停下\n启动后连续完成所有阶段。只在 3 种情况打断: (1) 需求不明确 (2) 多方案需选择 (3) 安全审批。\n\n### 铁律 2: 全子代理化，主会话只做监工\n所有干活用子代理执行。主会话职责: 分阶段派活、检查文件质量、打回重写、交付结果。\n\n### 铁律 3: 每步输出，不攒到最后\n每阶段完成后立刻在当前会话输出结果（当前阶段、模型、做了什么、发现了什么），然后直接进入下一阶段。这是默认进度汇报机制，避免依赖后台 cron 或外部通知。\n\n---\n\n## 📋 8 步循环流程 + 技能注入\n\n```\n设计 → 分解 → 编码 → 测试 → 反思 → 优化 → 验证 → 输出\n  ↑_______________________________________↓\n           "},{"path":"README.md","content":"# Auto-Coding v3.7.17\n\n**版本**: v3.7.17  \n**更新日期**: 2026-06-09\n\n---\n\n## 概述\n\nAuto-Coding 是一个智能自主编码系统，通过多角色 Soul + 多模型切换，完成从需求到代码的完整开发流程：\n\n```text\n设计 → 分解 → 编码 → 测试 → 反思 → 优化 → 验证 → 输出\n```\n\n**本质**：单进程串行 + 多角色 Prompt + 多模型切换。不是真正的多 Agent 并行，而是每一步换不同的人格和模型来审视代码。\n\n## 触发方式\n\n为避免误触发高权限编码流程，ClawHub 版仅建议使用以下明确触发词：\n\n- `auto-coding`\n- `Auto coding`\n- `启动自动编码`\n\n不要用泛化词如“写代码”“开发”“coding”作为自动触发词。\n\n---\n\n## 合规版核心调整\n\n### 1. 进度汇报：默认前台汇报，不默认创建 cron\n\nAuto-Coding 任务步骤多，确实需要持续汇报。合规版采用三层策略：\n\n| 层级 | 默认状态 | 用途 | 合规边界 |\n| --- | --- | --- | --- |\n| 当前会话逐阶段输出 | ✅ 默认开启 | 每阶段完成后立即报告阶段、产物、风险和下一步 | 不创建后台任务，不外发消息 |\n| 状态文件恢复 | ✅ 默认开启 | session 中断后从 `.auto-coding/state.json` 恢复 | 仅写本地项目目录 |\n| 后台调度 / 外部通知 | ❌ 默认关闭 | 用户离开会话后需要终态通知或进度检查 | 必须用户显式 opt-in，任务结束后清理 |\n\n因此，不做默认 cron 并不等于没有进度：**前台执行时每一步都会汇报**。只有当用户明确说“后台跑完通知我 / 开启进度检查”时，才建议由宿主环境创建可清理的调度任务。\n\n### 2. 飞书 / 外部通知：默认关闭，显式开启\n\n飞书通知不是默认行为。启用后只发送最小必要摘要：任务标题、任务 ID、当前阶段、完成状态、少量阶段摘要。不会发送 API Key、token、完整代码或大段上下文。\n\n### 3. 状态、日志、scratchpad\n\nAuto-Coding 会在项目内写入 `.auto-coding/`，用于恢复、审批和审计。可能包含：\n\n- `state.json`：任务 ID、阶段状态、完成状态、时间戳。\n- `logs/`：阶段摘要、测试结果、风险评分。\n- `pending_approval.json`：等待用户确认的操作。\n- scratchpad / output：中间推理摘要或交付摘要。\n\n合规建议：\n\n- `.auto-coding/` 已加入 `.gitignore`。\n- 不应提交 `.auto-coding/` 到远程仓库。\n- 任务完成后可删除 `.auto-coding/` 清理本地状态。\n\n### 4. 自动批准策略收窄\n\n默认仅自动批准低风险文档变更：\n\n```yaml\nauto_approve:\n  edit:\n    - \"docs/*\"\n    - \"*.md\"\n  run: []\n  create:\n    - \"docs/*\"\n    - \"*.md\"\n```\n\n以下操作默认需要确认：\n\n- 修改代码文件：`*.py`、`*.js`、`*.ts`、`src/*`、`tests/*` 等。\n- 修改配置、CI、环境文件。\n- 删除任何文件。\n- 运行任何命令，包括测试和构建命令。\n\n### 5. 表达式求值与命令执行\n\n- 风险阈值表达式使用 AST 白名单解释器，不使用动态代码执行。\n- 技能默认不通过 CLI 创建 cron，也不默认执行外部命令。\n- 需要运行测试、构建、发布、调度等命令时，必须经审批规则确认。\n\n---\n\n## 快速开始\n\n```python\nimport asyncio\nfrom workflow_enhanced import AutoCodingWorkflowEnhanced\n\nasync def main():\n    workflow = AutoCodingWorkflowEnhanced(\n        requirements=\"auto-coding：实现用户登录功能\",\n        project_dir=\"./my-project\",\n        resume=True,\n    )\n    await workflow.run()\n\nasyncio.run(main())\n```\n\n第一次运行会生成配置模板：\n\n- `.auto-coding/workflow.yaml.template`\n- `.auto-coding/rules.yaml.template`\n\n复制为实际配置后即可自定义阶段和审批策略。\n\n---\n\n## 文件清单\n\n| 文件 | 说明 |\n| --- | --- |\n| `auto_coding_workflow.py` | 主工作流（八步循环） |\n| `workflow_enhanced.py` | 增强版（状态 + 审批 + 前台进度汇报） |\n| `workers/base_worker.py` | Worker 基类（含模型调用） |\n| `workers/reviewer_worker.py` | ReviewerWorker（否决权） |\n| `approval_rules.py` | 审批规则引擎，默认收窄 auto-approve |\n| `scorecard_engine.py` | 风险评分与阈值判断 |\n| `state_manager.py` | 状态持久化 |\n| `SKILL.md` | Skill 入口文档 |\n\n---\n\n## 数据处理透明度\n\n| 行为 | 默认状态 | 数据范围 | 用户控制 |\n| --- | --- | --- | --- |\n| 读取项目文件 | 开启 | 当前任务相关代码、测试、配置 | 通过任务范围和项目目录控制 |\n| 写入代码文件 | 按需 | 当前项目目录内任务相关文件 | 敏感文件需确认 |\n| 写入 `.auto-coding/` | 开启 | 状态、日志、审批、scratchpad | 可删除；应加入 `.gitignore` |\n| 模型推理 | 按宿主环境 | 任务描述与必要代码上下文 | 由宿主模型配置决定 |\n| 外部通知 | 默认关闭 | 任务 ID、阶段摘要、完成状态 | 仅显式开启 |\n| 后台调度 | 默认关闭 | 任务 ID、状态检查摘要 | 仅显式开启，结束后清理 |\n\n> 隐私提醒：如果任务涉及敏感业务逻辑，`.auto-coding/`、模型上下文和可选通知摘要都可能包含相关信息。请限制项目目录、关闭外部通知，并在任务完成后清理状态目录。\n\n---\n\n## 更新日志\n\n| 版本 | 日期 | 关键变更 |\n| --- | --- | --- |\n| v3.7.17 | 2026-06-09 | ClawHub 合规修正：收"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn71pbmkb9h8sppk4yg6dn7zad808rvt\",\n  \"slug\": \"auto-coding-skill\",\n  \"version\": \"3.7.17\",\n  \"publishedAt\": 1781007878086\n}"},{"path":"CHANGELOG.md","content":"# Auto-Coding 更新日志\n\n---\n\n## v3.6.2 (2026-05-21) | Verifier 硬否决 + 子 Agent 断线恢复\n\n### ✨ 新增特性\n\n**1. Verifier 硬否决逻辑**\n- Reviewer 否决后不再只是一条记录，而是真正把任务打回 coding 阶段重写\n- 新增 `veto_retry_count` / `veto_retry_max` / `veto_retry_history` 追踪否决历史\n- 重试上限默认 3 次，超出后升级给人类审批，避免无限循环\n- 每次否决记录时间、违规数量、反馈上下文\n\n**2. 子 Agent 断线恢复**\n- 每个阶段执行失败时会记录到 `failed_agents` 状态\n- 恢复策略三级：retry（重试）→ fallback（换模型）→ escalate（升级给人类）\n- 默认 3 次全局 recovery 预算（跨阶段共享），预算耗尽后任务才报错终止\n- `record_agent_failure()` / `has_recovery_budget()` / `get_recovery_action()` / `clear_phase_failures()` 配套方法\n\n### 🔧 内部变更\n- `WorkflowState`: 新增 `veto_retry_count`、`veto_retry_max`、`veto_retry_history`、`failed_agents`、`agent_recovery_attempts` 字段\n- `_state_to_dict` / `_dict_to_state`: 序列化新增字段\n- `run()`: 阶段异常捕获增加 recovery 决策分支\n- `run()`: Reviewer 否决逻辑增加重试上限检查\n- 版本号: v3.6.1 → v3.6.2\n\n---\n\n## v3.6.1 (2026-05-21) | 猫王审查 文档一致性修复\n\n本次只改文档/版本号，没有改逻辑。\n\n### 🔴 P0 修复：版本号全面不一致\n- `SKILL.md` 标题：v3.6 → **v3.6.1**\n- `SKILL.md` description：v3.6 → **v3.6.1**\n- `SKILL.md` 底部时间戳：2026-05-11/v3.4.1 → **2026-05-21/v3.6.1**\n- `__init__.py`：__version__ 从 `3.4.1` → **`3.6.1`**，docstring v3.4 → **v3.6.1**\n- `workflow_enhanced.py` docstring：v3.4 → **v3.6.1**\n- `workflow_enhanced.py` 启动消息：v3.4 → **v3.6.1**\n- `README-FULL.md`：v3.4.1 → **v3.6.1**、日期 2026-05-13 → **2026-05-21**\n- `HEARTBEAT_TEMPLATE.md`：模板标题 v3.6.0 → **v3.6.1**\n\n保留的“历史版本标记”（不改）：注释里“v3.4引入 TDD”这类说明特性起源的文字，是有意保留的变更记录。\n\n### 🟡 P1 修复：Heartbeat 频率描述矛盾\n- `HEARTBEAT_TEMPLATE.md` 运行中描述：\n  - 之前：“每 5 分钟通报一次”、“15 分钟”\n  - 现在：“Heartbeat 每 **30 分钟** 扫一次，running 标记以 **5 分钟** 为频率控制避免重复汇报”\n- 与 `heartbeat_collector.py` 代码中的实际逻辑保持一致\n- 补充 `SKILL.md` 中另一处含混的描述（由“v3.3 新增:Cron 自动监控”改为“状态恢复机制(v3.6.1)”）\n\n### 🟡 P2 修复：优化模型字段不统一\n- Soul 表：优化 = `glm-5.1`\n- 阶段推荐表（三处）：原为 `MiMo / glm-5.1`，现统一为 `glm-5.1`（MiMo 作为 fallback，fallback 表里仍保留）\n- Fallback 降级表：优化首选 glm-5.1 → fallback MiMo → doubao-pro\n\n### 🟢 顺手修了\n- `SKILL.md` 版本对比表：表头 7 列但数据 6 列（漏了 v3.6.1 那列），补全并新增 “全子代理”、“阶段日志可追溯”、“Heartbeat 巡检” 三个特性行\n\n### 升级影响\n- 逻辑零变化，只是让文档/代码说法统一、版本号一致\n- 不需要重新发布包，不需要迁移数据\n\n### 🔧 模型迁移：去火山引擎化\n**背景**：火山引擎 Coding Plan 到期不续，模型体系从 volcengine-plan 单 provider 切换到 DeepSeek + MiMo 双模型\n\n**新模型矩阵**：\n| 阶段 | 首选 | Fallback |\n|------|------|---------|\n| 设计/分解 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n| 编码 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n| 审查 | **DeepSeek v4 Pro** | MiMo v2.5 Pro |\n| 测试 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n| 优化 | DeepSeek v4 Pro | MiMo v2.5 Pro |\n| 验证 | MiMo v2.5 Pro | DeepSeek v4 Pro |\n\n**改动范围**：\n- SKILL.md / README 全仓模型替换：`glm-5.1` → `deepseek/deepseek-v4-pro`、`doubao-*` → `mimo-v2.5-pro`、`deepseek-v3.2` → `deepseek/deepseek-v4-pro`\n- Python 代码默认值同步更新\n- Provider 锁定从 `volcengine-plan` 移除，现在只依赖 `deepseek` + `xiaomimimo` provider\n\n**升级影响**：用户需要确保 `deepseek` 和 `xiaomimimo` provider 已配置，不再需要火山引擎 Coding Plan\n\n---\n\n## v3.6.1 (2026-05-16) | 猫王审查 Bugfix 版本\n\n### 🔴 修复严重 Bug：运行中任务标记误删\n- `heartbeat_collector.py` 的 `clear_processed_marks()` 会把所有标记（包括 running）全部删除\n- 导致正在执行的任务在第一次巡检后就丢失追踪，不再同步进度\n- **修复**：删除 `clear_processed_marks()` 全局清理函数，改为在 `build_repo"},{"path":"DESIGN.md","content":"# Auto-Coding v3 — 设计说明 / Design Document\n\n**版本**: v3  \n**Last Updated**: 2026-05-22\n\n---\n\n## 1. 系统本质 / Essence\n\n**中文**: 单进程串行 + 多角色 Soul + 多模型切换 + 纪律执行层。不是任务分发器，而是自我完善的智能编程系统。\n\n**English**: Single-process serial execution + multi-role Souls + multi-model switching + discipline enforcement layer. Not a task dispatcher, but a self-improving intelligent programming system.\n\n### 设计哲学 / Design Philosophy\n\n| 原则 / Principle | 说明 / Description |\n|---|---|\n| **极简主义** | 不写多余代码，不请求未要求的功能，不写注释解释显而易见的事 |\n| **Coding Minimalism** | Don't write extra code, don't request unrequired features, don't comment the obvious |\n| **手术刀式修改** | 每次修改范围明确，改动文件数 ≤5，单文件行数 ≤200 |\n| **Scalpel-precision changes** | Each change has explicit scope: ≤5 files, ≤200 lines per file |\n| **质量优先于速度** | 选择能力最强的模型，而非最快的模型 |\n| **Quality over Speed** | Always prefer the most capable model, not the fastest |\n| **纪律高于便利** | 铁律不可被「效率」理由绕过，元规则提供例外条件 |\n| **Discipline over Convenience** | Iron rules cannot be bypassed for \"efficiency\"; meta-rules define exception conditions |\n\n---\n\n## 2. 架构总览 / Architecture\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                    用户请求 / User Request                     │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────────┐\n│              Phase Model Allocator（阶段模型分配器）           │\n│              Phase Model Allocator (stage model selector)    │\n│                                                             │\n│  根据当前阶段选择对应的 Soul + Model 组合                      │\n│  Selects Soul + Model pair based on current phase            │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n          ┌────────────────┼────────────────┐\n          │                │                │\n          ▼                ▼                ▼\n    ┌──────────┐    ┌──────────┐    ┌──────────┐\n    │ 设计/分解  │    │ 编码/优化  │    │ 审查/测试  │\n    │ Design    │    │ Code/Opt │    │ Review    │\n    │           │    │          │    │           │\n    │ Architect │    │ Senior   │    │ Reviewer  │\n    │ Soul      │    │ Dev Soul │    │ + Tester  │\n    └─────┬────┘    └─────┬────┘    └─────┬────┘\n          │                │                │\n          └────────────────┼────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────────┐\n│               Risk Scorecard（纪律执行层）                     │\n│               Risk Scorecard (discipline enforcement)         │\n│                                                             │\n│  Pre-Mortem → In-Flight → Post-Mortem                       │\n│  阶段前自检    执行中监控     阶段后审计                        │\n└──────────────────────────┬──────────────────────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────────┐\n│           State Man"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"智能自主编码系统 v3.7.17-compliance — 全子代理架构 + 分阶段技能注入。支持 8 步循环、Reviewer 否决权、复杂度自动分级、Risk Scorecard 量化检测。触发词: auto-coding, Auto coding, 启动自动编码 Skill: Auto Coding V3 Owner: krislu1221 Summary: 智能自主编码系统 v3.7.17-compliance — 全子代理架构 + 分阶段技能注入。支持 8 步循环、Reviewer 否决权、复杂度自动分级、Risk Scorecard 量化检测。触发词: auto-coding, Auto coding, 启动自动编码 Tags: latest:3.7.17 Version history: v3.7.17 | 2026-06-09T12:24:38.086Z | auto Auto-Coding Skill v3.7.17 - Compliance version bump and documentation updates (now v3.7.17-compliance). - Updated design and feature documentation in SKILL.m","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1044,"uniquenessScore":56,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T07:12:56.736Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T07:12:56.736Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-09T14:52:50.525Z","emptyReason":null},"items":[{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-10T18:48:31.762Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}