lili e181669197 chore(agent-infra): 建立 agent 开发基建、清理历史 churn 并以 BC 违例整改验证

本会话三部分交付,均经 JDK21 真实构建验证(非退出码,读 BUILD SUCCESS + Tests run):

1) Agent 开发基建(机械门禁优先)
- 入口与中枢:AGENTS.md、.agents/{knowledge,rules,skills,workflows}、CLAUDE.md 订正
- 订正 .gitignore:移除对 .agent/.agents 的忽略——它们是版本化 agent 基建,须入库(此前被忽略致克隆即缺)
- 机械门禁:CI 真跑测试(maven.yml JDK21、去 -Dmaven.test.skip)、覆盖台账去硬编码、
  BC 边界 ArchUnit 门(BcBoundaryArchTest)、契约先行门(ContractFirstGateTest:Flyway 卫生 + OpenAPI 结构)
- 单一进度源 docs/mvp/进度总账.md + 7 个 BC per-module .agent + mise.toml(锁 JDK21)
- P1 增量:AiSuggestionMergeProjectionFacade(Gap A)、ContentSourceServiceImpl 事务化 outbox 回流(Gap B)

2) 过期历史文档清理(97 份 churn,git 可恢复)
- 删 docs/memorys(34)、agent-specs 审阅/执行版+迁移review(34)、superpowers/plans+specs(25)、
  design-docs/临时+memorys(4);保留 superpowers/reports/coverage(门禁依赖)
- 唯一干货蒸馏入 .agents/knowledge/external-deps-and-gotchas.md;订正大纲/映射表/基线悬空引用

3) P1 harness 验证:消除已登记 BC 违例 ContentMuseWorkOwnerFacade
- content-api 新增只读端口 MuseContentWorkOwnerApi + content-server 实现(读自有 DAL);
  AI 适配器改消费该端口、移除全部 content.dal 依赖,AI 业务规则与 4 消费者不变
- 删除 ArchUnit 豁免 → 门禁收紧(反向红 31 例 / 正向绿;适配器单测 13/0F、端口实现 7/0F)

注:muse-studio/src(SSE 相关 4 文件)与 muse-module-ai/pom.xml(移除孤儿 contract-server)
为本会话之前已存在的未提交改动,非本次工作,未纳入本提交。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-14 04:38:07 -07:00

3.7 KiB

Raw Blame History

oh-my-muse · P0 止血冻结令

版本 v1.0 · 日期 2026-06-13 · 读者全体 agent / 工程师 · 状态立即生效边界:本令冻结"刷完成度台账"这条假绿回路,并记录 P0 已落地的代码改动。依据:对抗复盘 2026-06-13-目标达成对抗复盘.md §三(P0-1/P0-2)、§四(R1/R5);现状基线 2026-06-13-项目目标与模块现状基线.md。

0. 一句话

停止"刷完成度台账"这台假绿发动机:冻结 operation completed approval 收口;完成度的唯一新定义 = 自动化绿的用户旅程,不是台账里的 completed 数。

1. 背景(为什么冻结)

对抗复盘裁决:失控根因是 「假绿」,而非仅 churn——

完成度信号可手工拨:门禁测试硬编码 assertEquals(147, completed),与 p1r-api-coverage.json 互相对着写死;
CI 用 -Dmaven.test.skip=true 跳过全部测试,且矩阵是 JDK 8/11/17(项目需 21,根本编不过);
233 条 operation 的 implementationStatus 全部自填 dedicated,从未与代码机械核对;
近 15 个提交清一色 test(p1r): 收口 X completed approval,边际价值趋零(后端覆盖已 147/233,对"用户能不能用"零贡献)。

2. 冻结内容(立即生效)

🚫 停止再产 test(p1r): 收口…completed approval 类提交;不再人工把 needs_verification 拨成 completed。
🚫 不再以"completed 数 / 合并完成度%"作为对内或对外的完成度口径(R4)。
🧊 p1r-api-coverage.json 的 completed 快照即日冻结。P1rApiCoverageReportTest 中既有的 per-operation / per-domain 断言此后充当冻结护栏:任何进一步 promote 都会让测试变红,提示"这不是定义完成的方式"。

3. P0 已落地的代码改动(本次)

文件	改动	作用
`mise.toml`(新增)	锁 `java = "21"`	本地工具链对齐项目 Java 21(此前本机默认 17)
`muse-cloud/.github/workflows/maven.yml`	矩阵 `8/11/17 → 21`;删除 `-Dmaven.test.skip=true`;开启 `pull_request` 触发	CI 在正确 JDK 下真正编译并运行测试,并对 PR 设门(此前=假绿)
`…/framework/api/P1rApiCoverageReportTest.java`	删 `assertEquals(147, completed)` → 改为 `summary.completedOperations` 自洽校验;新增 `should_back_completed_operations_with_existing_source_files`:completed 必须引用磁盘真实存在的 controller/service 文件	拆掉自证回路 + 加最小"文件存在性"牙齿(`implementationStatus 由扫描判定`的最小版)

⚠️ 牙齿边界:文件存在性只证明"引用的源码在",不证明端到端可用。真实可用性由 P1 自动化用户旅程承担。serviceFiles 当前是"整模块 service 清单"(宽松),收紧到"实际实现该 operation 的文件"留待 P1。

4. 完成的新定义(替代台账数字)

完成 = 一条用户旅程在自动化下绿(关 mock + 真后端 + 自动化端到端)。
对外/对内只报三口径(对抗复盘 P1-2),禁用合并 %:
1. 代码实现度(读代码);
2. 自动化验证度(CI 实跑通过的 operation/旅程数);
3. 端到端可用度(真实形态跑通的用户旅程数)。

5. 解冻条件

当 P1 黄金旅程(登录 → AI 生成候选 → 前端 Accept → 后端 mergeBlockSuggestion 落库+归因 → SSE 回流)在自动化下绿、且 CI 真实运行测试成为常态后:完成度口径切换到"旅程绿",覆盖台账退役为历史参考。

6. 关联文档

现状基线:2026-06-13-项目目标与模块现状基线.md
对抗复盘:2026-06-13-目标达成对抗复盘.md
agent 基建迁移(governance 层,已按对抗结论降级到 P3-2,且须挂 CI 校验):2026-06-13-agent开发基建迁移-review.md

3.7 KiB Raw Blame History