HarnessSmith CLAUDE.md

CLAUDE.md — HarnessSmith 项目守则

Agent 进入本项目（vibe coding 模式）入场必读。本文件是 Agent 工作的硬约束。 项目定位 / 范围 / 决策 / 开发节奏与切片门禁见 docs/02-development/00-overview.md。

Tradeoff：偏向"先把事情做对"。显然小到不值得讨论的操作自己判断,别让流程把简单任务搞复杂。

0. 协作模式与角色边界

本项目主要由 Agent 开发,人只负责决策、验证、以及"只能人做"的环境配置。

角色	负责	不做
Agent(你)	写生成器与模板代码、写/跑测试、调试、维护文档与变更记录、按 slice 自驱推进、测试全绿后直接 commit + push main、写完成报告	不替人拍板产品决策、不动用钱/联网批量/破坏定位的事、不 --force push、不在测试未绿时推 main
人	方向与验收、slice 关键决策点签字、环境与密钥配置(见 §0.1)、对外发布	不写代码、不做 Agent 已能自动化的事

一句话:Agent 负责"怎么做",人负责"做不做、装环境、给 key、何时发布"。 开发文档里写"开发者要做 X"一律理解为"你(Agent)要做 X,由人按切片节奏验收"。

0.1 只能由人配置的环境(Agent 不代劳)

• 安装本机工具链:uv、docker(Agent 不改系统级配置、不装系统包)。
• API key / .env 真实值:Agent 只维护 .env.example,绝不写入真实 .env、绝不把 key 写进任何被 git 跟踪的文件。日常开发用 mock LLM,不需要真 key;只有"真实 LLM 冒烟 / 对外演示"才需要人提供 key。
• PyPI 发布凭证、GitHub 仓库设置、对外发布。

Agent 需要某个 key / 环境时:在 plan 阶段列出所需 .env key 名与用途,停下来请人配置,不要自己编造或跳过。

1. Think Before Coding

不要假设。不要藏起困惑。把权衡显式说出来。 动手前:声明假设,不确定就问;多种合理解读时列出来让人选;有更简单的方案先说一声。宁可开工前多问 1 个问题,不要跑了 30 分钟才发现方向错了。

2. Thin First(薄优先 —— 本项目核心卖点,硬约束)

• 默认产物模板保持极薄:核心循环目标 150–300 行,整体远小于一个框架。
• 不做没要求的功能;一次性代码不先抽象;不为"以后可能要"加灵活性。
• 高级能力(RAG / MCP / context 策略 / Web)只通过 spec 开关生成,不塞进默认产物。
• 200 行能压到 50 行就重写。

3. Surgical Changes

只动该动的,只清理自己制造的烂摊子。不"顺手优化"无关代码或格式;不重构没坏的东西;沿用现有风格;发现 dead code 提一句,别擅自删。

4. 两层心智:生成器 vs 生成产物(本项目特有)

你写的是一个生成器,它渲染出独立的生成产物仓库。任何时候分清你在改哪一层:

• 改 harnessmith/(生成器本体):spec / 渲染引擎 / CLI / 向导 / catalog / presets。
• 改 harnessmith/templates/(产物模板):渲染后才是用户拿到的代码。
• 测试必须覆盖"生成产物"本身:生成 → uv sync → pytest → mock LLM 跑通一次工具调用,而不只是测生成器。

5. 目标驱动 + 测试硬门槛(按生成器项目定制)

"完成"的硬门槛见 §5.1,没达到 = 没完成,别用"逻辑简单不用测"或"先合后补"做借口。 例外:纯文档 / 纯注释 / 纯重命名(改名工具已覆盖全部引用)可不加测试,但要在完成报告里点名说明。

5.1 黄金测试是"完成"的硬门槛

任何被宣称完成的功能必须:

• 新增 / 改动的生成器或模板代码有自动化测试(unit 或 integration)。
• 黄金路径绿:用示例 / preset spec 生成项目 → uv sync && pytest 全绿 → mock LLM 跑通一次 function-calling(含一次工具调用)。
• 断言生成的 pyproject.toml 不含 langchain/langgraph/adk。
• 可运行性自检绿:生成后冒烟(uv sync + import + mock 跑一步 + pytest -q)。
• ReadLints(IDE 诊断)无新增 error / warning。