10 KiB
治理反馈闭环
老板-员工手册隐喻:用户发现子项目不足 → 告诉炼境(结构化落账)→ 炼境更新"企业文化与员工手册"(CONVENTIONS 规则 + 接入包模板)→ 批量分发给子项目 → 飞轮观测新规则是否生效。
为什么
- 现在用户发现子项目问题只能在会话里口头说(如 2026-07-06 的 group_id 探路问题),不落任何结构化通道,问题→体系改进全靠当次会话的执行力,跨会话就丢
- 治理管线已存在大半(blueprint-governance 的规则编辑与批量同步、blueprint-feedback 的梦核蒸馏、onboarding-pack 的模板版本化分发),但三处断环让"反馈驱动体系进化"没有闭合
三个缺口(待 /architect 细化)
① 治理反馈入口
- 现状:
append_project_note挂单项目、无类型标记,是"员工工作日志"而非"给老板的管理反馈" - 方向:
report_governance_feedback类入口(MCP 工具优先,UI 上报按钮可后置),记录:哪个项目、什么问题、疑似哪条规则/模板缺陷;落 project_notes 加类型字段或独立治理账本表 - 形态待定:MCP 工具 vs UI 按钮 vs 笔记类型约定(三选或组合,architect 阶段定)
② 反馈进入梦核蒸馏
- 现状:梦核吃被动数据(commit 指标、复盘笔记、停滞模块、高风险 scope)
- 方向:用户主动治理反馈作为梦核 prompt 的高权重数据段(老板亲口说的问题 > 统计推断的问题),蒸馏产出规则修订/模板修订建议
③ 接入包批量重分发
- 现状:
sync_blueprint_rules有批量,但接入包apply_onboarding_pack单项目一次一发;模板更新后无"全员换发新手册"动作 - 方向:批量 re-apply(复用 ONBOARDING_MANAGED 块安全覆写机制),输出报告:哪些项目更新了哪些块、哪些跳过/失败
闭环全景
发现问题 → ① 结构化落账 → ② 梦核蒸馏 → 更新 CONVENTIONS/模板
↑ ↓
飞轮观测生效(Rules-Applied trailer / 复盘) ← ③ 批量分发
每一环都有数据留痕,管理动作可回溯。
设计档案:agent 自验协议的辩证与务实版选择(2026-07-06)
用户确立的协作协议:需求对话 → 构建默认 agent 按钮化 → agent 自验 → 快速自修 → 结构化反馈 → 人终验。经多角度辩证后识别出五个内生张力与对应调节器,最终按"大量开发者经验(流程死于执行成本而非设计错误;检查单短才有效;机制记的留下、靠记忆的蒸发)"选择最小执行版落地,完整辩证存档于此备查:
| 内生张力 | 调节器 | 关键点 |
|---|---|---|
| 运动员兼裁判(验证与功能共享理解偏差) | 负面披露(「没验什么」一节) | 只覆盖已知盲区;未知盲区由人终验兜底——两柱互补,缺一超载。实证:mcp-single-server 自验全绿但 git-bash 层全挂,靠端到端终验抓住 |
| Goodhart(宽松断言让自己过) | 改断言需报备 | 非自觉依赖:断言修改在 diff 天然可审计 |
| 橡皮图章化(终验退化为签字) | 意外感触发深查 | 深查频率是自由参数,框架内无机制阻止衰减——最终锚是人的纪律,框架诚实承认此点方自洽 |
| 默认按钮化 vs 少而稳 | 默认分层 | 默认的是"存在可验证路径",不是"永久驻军测试";豁免需声明 |
| 不可按钮化工作(审美/体感/探索) | 显式豁免 | 强推得到仪式性假按钮 |
关键澄清(两把尺子):acceptance 由 agent 参与撰写,可能继承需求理解偏差——agent 自验对 acceptance,人终验必须对意图,否则是拿被污染的尺子量两次。
落地物(最小版,执行成本趋零):AGENTS.md / 接入包模板 / agents-meta-rules 增设「自验报告纪律」三条;用户侧两个习惯(先看「没验什么」;意外感或外部契约变更时深查)。刻意不做:新工具、强制 hook、报告模板系统——坑驱动增量,人肉版跑出疼点后再在本模块机制化。
使者回传处置台账(2026-07-18 消化,共 23 条)
已落地(本轮 3 项)
- /ship 三处模板修正(
~/.claude/commands/ship.md,全局命令即分发源):① blueprint 尾 commit 铁律改为「每轮 /ship 的最后一个 PR 末位 commit」(多 PR 场景 manifest 单文件不可能每 PR 都带);② 规模闸补两个不可拆例外(单一功能域强耦合 / 全新业务线初版)→ 警告放行不阻塞;③ MCP 连接错误注明可原地重试 2~3 次(偶发抖动非业务失败) - envoy.md 分类硬门槛(接入包全托管文件):Step 3 前置追问「任何有经验的工程师是否会提前想到?」——常识性知识与过窄 corner case 一律留本项目,堵住 2 例误回传的根因
- CONVENTIONS v1.12.0:飞轮工作流阶段 2 末新增「动工前辩证收缩」(M/L 卡必做),实证返工率对照写入
此前会话已落地(11 条,本轮核实关闭)
MANAGED 块警示(5b0b068)、Bug Fix/Feature 分类 + S 级轻量卡 + 汇总补录限定语(67bdacb AGENTS v1.5.0)、蓝图机器门控(f04eb6e blueprint-gate 双层,回应 07-09「文档约束无机器门控」假设)、lefthook API typecheck 必填项 + CONVENTIONS scope 前置提示(be2f695 v1.11.0)、Playwright 版本锁死(AGENTS tmpl)、agent_verify/human_verify 分层(AGENTS + CONVENTIONS)、/ship 阶段八 rebase 前 stash 保护(已在 ship.md)、空路径分发防护(473cf7e)
待观察(log_for_review,暂不动模板)
- verify_onboarding lefthook 键名匹配是名义非语义:等价功能不同键名会误报缺失;enterprise-system 6/7 fail 待核实是缺失还是改名
- /ship 运行期间并行开发混入变更(under_validation):建议最终报告对比第零步 status 快照、新增变更单独列出不纳入本轮——再积累 1~2 次实例后进模板
- /antirot 命令模板化:enterprise-system 实现的文档防腐命令(机器验+文档一致性+蓝图健康三步),候选纳入接入包标配
- Loop 模型路由(Haiku=Observer / Sonnet=Actor)与种子层/土壤层分工:enterprise-system 特有 Loop 体系,尚不构成跨项目通用约定,观察其长期效果
- OpenAI SDK tool_calls 联合类型守卫:可作 AI 代码审查检查项候选(project_type:web)
遗留尾巴
src-tauri/ 下空路径污染残留→ 2026-07-18 辩证收缩后三步收官:①9 个污染文件已移出(暂存%TEMP%\liangjing-pollution-20260718);②两条空路径僵尸登记(agent编排界面(opencode)/银龙集团应用)已 unregister(磁盘无对应目录,实为死登记);③辩证挖出 inject 链路漏拦同一空路径洞(project_root()对空串 win_path 穿透写 cwd,正是 settings.json/liangjing.json 污染的来源)——已单点补validate_registered_path(拒空+拒相对路径)+ 2 条回归测试。空路径事故至此两链路(apply/inject)全堵- envoy.md 硬门槛已进模板,需重建安装炼境后 apply 才会分发到子项目(模板打包在二进制资源)
开发侧世界模型透镜(2026-08-23 辩证收敛)
源头:enterprise-system 使者回传「炼境=开发侧世界模型容器」(2026-08-23)+ 业务侧四载体 (vision-world-model.md / estate1-world-model.md / hub-relation-catalog.md / hub-matrix-biz-ecology.md)回顾。 合题:世界模型是透镜,不是工程——用透镜照出真实病灶就修,其余全部挂闸门。
同构映射(业务侧 ↔ 开发侧)
R 规则层=CONVENTIONS 规则库(炼境强项,业务侧反而隐式)|E 实体层=项目/模块/任务卡/服务器(实体丰富、跨项目关系贫乏)|A 资产层=接入包(唯一模式雏形)|地图=单项目蓝图画布(无全局)|可拆除性=资产纯文件 git(notes 是唯一违规点)。
两处判断修正(辩证结论,防后续会话重新推演)
- 「独立世界仓库」被否:现在只有一个住户(notes 档案),为一个住户建仓库违反晋升阶梯(第二个场景才晋升)。炼境自身仓库本来就是事实上的元仓库,跨项目资产先住这里。
- 可拆除性缺口比直觉窄:飞轮数据可从 git 历史重生(ingest_git_history=重生配方),不违规;唯一硬违规是 project_notes(复盘笔记+使者回传,原创不可再生,只活在 SQLite)——即下方 A 卡。
三个闸门(等真实场景敲门,禁止提前建设)
| 候选 | 闸门条件 | 备注 |
|---|---|---|
| 跨项目 edges | 第一个真实跨项目查询需求(最可能从梦核来) | 方案已定:自省派生 ∪ 显式声明(继承 hub-relation-catalog) |
| 全局地图视图 | edges 落地之后 | 开闸时先辩证「矩阵 vs 画布」——manage-multi-view 已承载一半需求,勿撞车;节点须双承载(入口+健康度) |
| 模式库 | 第三个模式候选出现(满三建制) | 接入包=第一个模式,库=接入包机制泛化;现有候选:DSH 接入模板、子主题规范 |
三投影准入律(新资产类型的验收清单)
任何新世界模型资产类型,三投影不齐不算入模:文件形态(git 可拆除)+ MCP 工具(agent 可消费)+ UI 投影(人可终验)。
任务卡
📋 notes 档案落地(可拆除性修复:双写 + 存量回填)
- status: todo
- complexity: M
- files: src-tauri/src/mcp_tools.rs, src-tauri/src/db.rs
- acceptance: agent_verify: [Tauri command] append_project_note(pid, content) → DB 有记录且
.blueprint/notes-archive.jsonl尾行 JSON 可解析出同一 content;存量回填命令执行后 JSONL 行数 = project_notes 表行数;cargo test 覆盖双写 + 并发追加不交错 - 备注:project_notes 是全系统唯一不在 git 的原创资产(飞轮全部原料)。格式选 JSONL 而非 md——机器可重放重建 DB,才是真「重生配方」。归宿:炼境仓库
.blueprint/notes-archive.jsonl,沿 usage.json「炼境自动写文件 + chore commit」先例。这即本模块缺口①「结构化落账」的地基
(其余 concept 阶段,L 级——待 /architect 设计确认后由 /splitter 拆卡)