| name | harness-retrofit |
| description | 存量项目的 Harness 改造:先盘点现状形成差距表,再引导提问式确认迁移决策,基于存量逐步改造和迁移操作面、同构环境、文档体系与裁决能力,不推倒重来;每步以验证用例逐步点亮证明可用。 |
| license | MIT |
harness-retrofit
目标与 harness-init 相同(以 ${CLAUDE_PLUGIN_ROOT}/docs/harness.zh-CN.md 为权威),
路径相反:从存量出发,改与迁移,不推倒重来。改造由真实需要拉动——
下一个 feature 用不到的能力,这一轮不建。
盘点(先看后问)
先自行考察,代码里能查到的不许问人:服务怎么启动?日志什么形态?本地环境与生产差在哪
(伪平替清单:SQLite 顶 MySQL、内存 mock 顶对象存储、latest 镜像、跳过的鉴权)?
有没有 Migration,还是手工改库?测试怎么跑、绿灯信不信得过?
盘点结果做成差距表:现状 → harness 要求 → 差距 → 风险。
然后按轮次向架构师提问确认迁移决策(每轮 5-10 问,附推荐方案与理由);
难以回头的决策记入 ADR。
迁移路线(按反馈回路价值排序,小步可回退)
- 操作面包壳:不改业务代码,先给存量命令套上 run / observe 稳定入口。
- 日志改造:接入结构化日志与 trace_id 传播——通常是回报最快的一步。
- 消灭伪平替:本地对齐生产引擎与主版本;补 Migration 基线
(以当前真实 Schema 为 0001,不追溯重写历史)。
- 受保护资源与 drive:声明 protected_resources,建 clone 沙箱,
落第一条真实入口 Case 与判定四件套。
- 文档体系补课:AGENTS.md + 地图 + 规则;对存量做一次立项决策补课——
当前全景架构图、领域划分与"既成事实 ADR"(记录现状与理由,不追溯重设计)。
每一步都必须回答"缩短了哪条反馈回路",答不上来就跳过;
每步完成即用对应验证用例证明(同 harness-init 的用例集,逐步点亮),
不憋大招一次性切换。
产出
差距表、迁移决策(含 ADR 与立项决策补课产物)、逐步点亮的验证用例证据、
改造后的 harness 能力。