d38260fc51
market 5 类(MarketAccountProjectionProvider/AdminMarketReviewServiceImpl/MarketInstallServiceImpl/ MarketLicenseServiceImpl/MarketPublishServiceImpl)此前直接构建 member.dal 的 AccountRecordProjectionDO 并经 AccountRecordProjectionMapper upsert 进 member 表——跨 BC 写路径违例(原 BcBoundaryArchTest 单点豁免登记)。 本次整改(ultracode 工作流:设计→实现→对抗验证;JDK21 scoped 实跑验证): - member-api 新增对外写端口 MuseAccountRecordProjectionApi + MuseAccountRecordProjectionSaveReqDTO; member-server MuseAccountRecordProjectionApiImpl 实现,读写 member 自有 DAL,整体平移原 upsert 语义 (insert/update 分支、update rows!=1 抛 IllegalStateException 防伪成功)。 - 安全边界:DTO 刻意不含 tenantId,由实现侧从 TenantContextHolder 注入,杜绝调用方(他域)伪造租户。 - 事务红线:写端口为进程内 Bean、不加 @Transactional,沿用调用方(market 的 REQUIRES_NEW)事务上下文, market 业务回滚则投影一并回滚,原子性与原实现等价。 - market 5 类改消费写端口 + DTO 替代 DO,移除 member.dal 代码依赖; BcBoundaryArchTest.KNOWN_VIOLATION_EXEMPTIONS 清空 → 通用 BC 门全绿(0 Architecture Violation)。 - 测试:insert/update/租户隔离语义随实现迁移至 MuseAccountRecordProjectionApiImplTest(4/0F); provider 测试改 mock 写端口、保留"失败→写 blocked outbox→上抛 UNAVAILABLE"语义(5/0F); market 其余 4 类测试同步(AdminReview 16 / Publish 14 / License 9 / Install 5)。 附带修复 round-2 一处假绿:round-2 把 ContentKnowledgeWorkOwnerFacade 重构为消费 MuseContentWorkOwnerApi 后, 旧测试 KnowledgeWorkOwnerFacadeTest 仍断言旧 WorkMapper 行为(当时验证构建在平台 QiniuSmsClientTest 时区用例处中止、未真正跑到 knowledge 模块,故漏网=假绿)。删除该旧测试,其装配守卫 (@ConditionalOnBean 值应为 MuseContentWorkOwnerApi)与 Unavailable 兜底失败关闭两用例并入 ContentKnowledgeWorkOwnerFacadeTest(3→5/0F),覆盖不丢。 验证(JDK21;-Dtest scoped 避开预存红 + muse-server -am):BUILD SUCCESS,日志无任何 <<< FAILURE/ERROR; BcBoundaryArchTest 1/0F 且 0 Architecture Violation、AgentsInfraIntegrity 3/0F、ContractFirst 2/0F、 P1rApiCoverage 7/0F、member 4/0F、knowledge 5/0F、content 端口 7/0F、market 5 类全绿,全 reactor 模块 SUCCESS。 注:本仓存在预存红测试(非本轮引入,启用真实测试 + CI 接电后将暴露,已登记 总账/AGENTS 后续): MuseAiTaskServiceTest 桩 eventPublishOutboxService 缺失致 11 例 NPE、MuseAiEventPublishOutboxMapperTest 需真实 PostgreSQL、平台 QiniuSmsClientTest 硬编码北京时区在非 +8 机器失败。故全量 reactor / CI-on-main 当前仍会因这些预存红呈 RED——本轮只声明 market 整改切片与 BC/契约/loop/覆盖门全绿,不声称全仓全绿。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
.agents/ —— oh-my-muse 的 Agent 能力中枢
本目录沉淀项目的全部 Agent 能力、知识、规则与流程,让团队在长期 AI 驱动开发中复利式积累,持续提升 agent 编码的能力、准确率与稳定性。 项目工作入口、定位、目录见根
../AGENTS.md(项目唯一入口);CLAUDE.md是 design-docs(设计 SSOT)的写作规范,亦从属于 AGENTS.md。设计原则(本项目特有,来自对抗复盘):机械门禁优先。本项目的失控根因是"假绿"——软约束被绕过。故
.agents/的规则不止是文档纪律,必须配套机械门禁(CI/ArchUnit/契约校验),见rules/verification-and-anti-false-green.md。
一、目录结构与职责
| 子目录 | 职责 | 回答的问题 |
|---|---|---|
knowledge/ |
事实与蓝图的蒸馏(产品、架构、模块现状基线、关键决策) | 是什么 |
rules/ |
必须遵守的硬约束 + 其机械门禁 | 必须怎样 |
skills/ |
可复用操作手册 playbook | 怎么做某一类事 |
workflows/ |
元流程(如何承接→分析→评审→执行→验证→沉淀一个任务) | 如何承接任务 |
通用顺序:先 knowledge 对齐事实 → 看 rules 划红线(且红线有机械门禁兜底)→ 用 skills 落地 → 按 workflows 推进与收尾。
二、文件清单(✅ 已建 / ⏳ 建设中)
rules/
| 文件 | 状态 | 一句话 |
|---|---|---|
rules/verification-and-anti-false-green.md |
✅ | 脊柱规则:完成=机械验证、机械门禁优先、反假绿(P0 已落地首批门禁) |
rules/bc-boundaries.md |
✅ | BC 边界:禁跨域 .dal 直连,ArchUnit 机械约束(已知违例 ContentMuseWorkOwnerFacade 单点登记整改) |
rules/contract-first.md |
✅ | 契约先行:API=docs/api-contracts/*、DB=sql/muse/V* 原地 SSOT;Flyway 卫生 + OpenAPI 结构 机械门禁(openapi-diff CI 待启用) |
rules/engineering-conventions.md |
⏳ | 命名/分层/错误码/提交/PR(收敛 docs/dev-baseline/global/01,02) |
rules/security-and-reliability.md |
⏳ | 安全/幂等/超时重试/可观测(收敛 docs/dev-baseline/global/05,06) |
knowledge/
| 文件 | 状态 | 一句话 |
|---|---|---|
knowledge/project-and-architecture.md |
✅ | Muse 定位 / 意图 / 非目标、最高不变式、工程底座、7 BC 职责与约束(蒸馏 design-docs) |
knowledge/module-reality-baseline.md |
✅ | 模块真实现状指针(指向现状基线 spec + 对抗复盘)+ 基建复利进展 |
knowledge/tech-decisions.md |
✅ | 已确认架构决策蒸馏(指向 架构-03-ADR + CLAUDE.md 决策表) |
knowledge/external-deps-and-gotchas.md |
✅ | 外部依赖(New-API/RAGFlow 地址·凭据来源)+ 集成兼容坑 + 前端/构建坑(蒸馏自已清理 memorys) |
skills/
| 文件 | 状态 | 一句话 |
|---|---|---|
skills/golden-journey-vertical-slice.md |
✅ | "完成"的样板:三指标 + 关 mock(MSW dev-only)+ 真后端真库 + IT/Playwright 端到端 |
skills/add-business-module.md |
✅ | 新增 muse-module(BC)标准步骤:两子模块 + 契约 + 迁移 + 注册 + 守 BC 门禁 |
workflows/
| 文件 | 状态 | 一句话 |
|---|---|---|
workflows/ai-development-protocol.md |
✅ | 承接→分析→评审→执行→验证→沉淀;简单/全流程分流 + 证据门 + 构建纪律 |
三、维护规则(关键)
- 何时新增 vs 更新:全新主题→新增文件;已有主题补充/修正→更新现有文件(先查重,不造重复)。
- 过时即处理:信息失效立即修正或删除;与代码/文档冲突时以已验证事实为准。
- 单一主题、精炼、可检索:每文件聚焦一主题,多用表格;做蒸馏与索引,不照搬源文档大段内容。
- 同步索引:任何结构性变更(增/删/改名)同步更新本 README 清单 +
../AGENTS.md导航。 - rules 必配门禁:新增 rule 时必须说明其机械门禁落点(CI/ArchUnit/测试),否则它只是会被绕过的软约束(本项目教训)。
- 语言:一律简体中文;交叉引用用相对路径。
维护本身是任务收尾的一部分——见
workflows/ai-development-protocol.md的"沉淀"环节。