zizi-al/oh-my-muse
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
312 Commits 6 Branches 1 Tag
Commit Graph

21 Commits

Author SHA1 Message Date
lili
f3f7a0962f feat(content/knowledge/ai): B 四维 VERIFIED_ZERO 贡献者 + 机械化断言[P2] 
5 维度贡献者齐全(Planning REAL_COUNT 已落,本次补四个 VERIFIED_ZERO):

- Work/Export(content):work 仅绑 schemaId 不存字段值、ExportTaskDO 零 schema 引用→VERIFIED_ZERO;机械化断言 DO 无动态字段值列(漂移即失败)。

- KnowledgeProjection(knowledge)/AIContext(ai):零 meta 引用(projection 是 CQRS 读模型、metadataFields 是向量库)→VERIFIED_ZERO;knowledge/ai-server 加 meta-api 依赖;机械化断言贡献者无数据依赖字段。

验证:content 9/9(Verified 4+Planning 5)、knowledge 2/2、ai 2/2。下一步:单体装配验证 RealMetaImpactFacade 收齐 5 维度、all-real 不再 fail-closed。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-21 01:54:06 -07:00
lili
3a7a72fa88 feat(knowledge): 补 GET bindings 读端点(作品已绑来源读回) 
AppMuseKnowledgeBindingController 加 GET /muse/works/{workId}/knowledge-bindings → bindingService.listKnowledgeBindings:先 requireWorkOwner 过信任边界防越权读他人作品来源绑定(IDOR),再 selectActiveByWorkId 读回投影读模型,id 转字符串对齐契约(防前端大整数精度丢失),X-API-Version guard 同既有端点。

至此 bindings 读回后端腿(绑定确认写投影→按 work 读回→GET 端点)闭环,仅余 FE hook。新增 AppKnowledgeBindingVO.BindingListRespVO/BindingItemVO。

测试:listKnowledgeBindings happy-path 字段映射 + 越权 fail-closed(requireWorkOwner 抛错则绝不查投影);knowledge-server 整套件 218/218 绿(clean 重编译,反假绿)。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-19 13:30:53 -07:00
lili
1c8da86e82 fix(knowledge): unbind 真软删(修 @TableLogic 空操作)+ 投影读回嵌入式 DB 坐实 
8aad7a4 的 markDeletedByBindingId 用实体 setDeleted(true) 试图软删,但 deleted 是 @TableLogic 字段,会被 MyBatis-Plus 在普通 update 剥离 → 解绑实际未生效,行仍出现在 selectActiveByWorkId 读回。改用 setSql("deleted = true") 强制写该列(H2/PG 通用)。

反假绿:新增 MuseKnowledgeSourceBindingProjectionRoundTripTest(嵌入式 H2 真往返)端到端坐实 bind 写投影→按 work 读回、unbind 后读回消失、同源绑定到其它作品的投影存活;此 bug 即由该测试挖出(此前仅 mock 写证据无法暴露)。MapperTest 改为断言 setSql 真机制(原断言 update.getDeleted()==TRUE 实为被剥离的空操作)。

附:补齐 knowledge 模块首套嵌入式 DB 测试基建(application-unit-test.yaml + create_tables.sql + clean.sql,logic-delete 对齐 muse-server 生产 true/false)。

验证:RoundTripTest 2/2、knowledge-server 整套件 216/216 绿(clean 重编译,反假绿)。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-19 10:03:09 -07:00
lili
8aad7a4b1b fix(knowledge): 绑定确认回填来源投影 + 唯一键补 work_id 
绑定确认为 source binding projection 读模型的权威回填点:bind 成功后写投影行;unbind 按 bindingId 作用域撤销,不误伤同源绑定到其它作品的投影。

唯一键补 work_id(V24):同源 KB 可被同一用户绑定到多个作品,旧唯一键缺 work_id 会把合法跨作品复用误判为冲突;改为含 work_id 的 partial unique index(WHERE deleted=FALSE)。

验证:MuseKnowledgeBindingServiceTest + MuseKnowledgeSourceBindingProjectionMapperTest 11/11,knowledge-server 整套件 214/214 绿(clean 重编译,反假绿)。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-19 09:31:56 -07:00
lili
bc63a35e88 fix(knowledge): audit impact preview owners 2026-06-19 08:18:46 -07:00
lili
8c1696c59a fix(knowledge): hide deleted installed bindings 2026-06-19 08:09:46 -07:00
lili
8963383233 test(ci-green): 清全 reactor 4 处潜伏陈旧测试,mvn test 史上首次全绿 
CI 从未在本特性分支跑过(maven.yml 仅 push/PR-to-main 触发),积累潜伏红。以 mvn -pl muse-server -am test -fae 全 reactor 逐模块解锁排查(上游 fail-fast 会 SKIP 下游),本提交清 4 处(另 2 处 market PublishRecordItem/coverage 台账已随前序 commit):

- knowledge/ai Content*WorkOwnerFacadeTest: 陈旧断言 @ConditionalOnBean(2026-06-14 单体修复已去除、改 @Primary 总注册压兜底)
- ai MuseAiEventPublishOutboxMapperTest: 真 PG 用例无 PG 时硬 fail→改 assumeTrue skip(与 P1r external-acceptance env 缺失即 skip 约定一致、honest 非假绿;有 PG 仍真跑保真)
- muse-server P1rKnowledgeMigrationSqlTest: 元测试钉死 TARGET_VERSION="14"→版本无关化(被验收 IT 已按 4d46d7a 动态自适应,元测试不应自犯硬编码版本病)

验收:mvn -pl muse-server -am test -fae 全 reactor BUILD SUCCESS、0 失败/错误、所有模块 SUCCESS(真 PG 类无 PG 时 skip)。教训:跨模块重构后须跑 -fae 全量,勿只跑改动模块。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-17 15:01:41 -07:00
lili
b3922ebca7 test(knowledge): confirm 重名干净冲突单测回归守护 + publish 勘察定论(fail-closed) 
MuseKnowledgeDraftServiceTest 新增 should_failClosedWithDuplicateCodeWhenCanonicalEntityIdentityExists:预检命中既有同身份实体→KNOWLEDGE_ENTITY_DUPLICATE+markConflicted+绝不 insert(守住重名冒泡 500 的回归,task_497da70f),18/0 绿。

§五C:knowledge publish 活体勘察=正确 fail-closed(EXTERNAL_RIGHTS_PRIVACY_VALIDATOR_NOT_CONFIGURED 无条件 block);至此 knowledge 前端可建旅程已尽(confirm+graph),bindings/publish 均受阻于事件驱动投影/外部校验器→后置。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-15 19:31:05 -07:00
lili
2b42883404 fix(knowledge): 确认入库唯一身份预检——重名实体返回干净冲突而非 500 
确认草稿物化为 Canonical 实体时,若 (work+类型+规范名+范围) 命中既有实体,原 entityMapper.insert 触发 uk_muse_knowledge_entity 唯一冲突 → 未捕获的 DuplicateKeyException 冒泡成 HTTP 500(潜伏 bug,task_497da70f)。

修复:writeCanonicalEntity 前置 selectByIdentity 预检(镜像唯一约束列,不滤 deleted/status),命中则 markConflicted(REQUIRES_NEW 独立提交)+ 抛 KNOWLEDGE_ENTITY_DUPLICATE(1043002004)。必须前置预检而非 catch:PG 下唯一约束冲突会使当前事务进入 aborted 态,catch 后任何写(含 markConflicted)都会失败。

活体证(48080 真实 PG,反假绿):colliding 草稿 confirm → code 1043002004(HTTP 200,非 500);DB:草稿转 conflicted、实体数不变(无伪造重复)。正路径回归:knowledge-confirm e2e 绿。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-15 08:34:21 -07:00
lili
749c5b2471 feat(knowledge): 知识库工作台前端先审后入(确认草稿→Canonical)rendered-UI 活体证 
后端:SummaryRespVO 暴露 confirm 所需并发/源令牌(sourceSnapshotId/authorizationSnapshotId/revision),
否则前端无法构造合法 confirm 请求(非破坏性新增,不改 confirm 语义);转换器填充。
前端:useKnowledgeDrafts/useConfirmKnowledgeDraft hooks(回显令牌)+ KnowledgeDraftPanel(待确认草稿+确认入库)
+ KnowledgePage(/knowledge/:workId)接入。e2e knowledge-confirm:chromium MSW-off 点确认入库→真 confirm
→ draft confirmed+entityId(DB 证 draft5 confirmed/entity_id=3)。tsc 0。
遗留:confirm 对已存在同名 Canonical 实体抛未处理 DuplicateKeyException(500),应改干净 conflict(另 flag)。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-15 00:41:58 -07:00
lili
d09d529d11 fix(p1-monolith): facade 条件装配可靠化 + 跨模块 bean 名冲突修复(单体启动收口·进行中) 
让 muse-server 单进程单体可启动(从未装配过的单体逐层暴露问题,本提交修 facade 装配 + 名冲突两类):
- muse-server 新增 MonolithFacadeFallbackAutoConfiguration(@AutoConfiguration 末位 + @Bean
  @ConditionalOnMissingBean):为 6 个全 default 的 content facade(File/KnowledgeDraft/Meta/ParseJob/
  PlanningCandidate/StyleCheck)提供可靠 fail-closed 兜底(真实 impl 仍优先,非 stub)。
- 4 个真实 impl facade 去掉 @Component 上不可靠的 @ConditionalOnBean(单体内依赖恒在,@Primary 总注册):
  AiSuggestionMergeProjectionFacade(ContentAiSuggestionFacade,slice 关键)、ContentMuseWorkOwnerFacade、
  ProjectionSecurityRuntimePermissionFacade、ContentKnowledgeWorkOwnerFacade。
- 4 个 source-owner + SecurityToolGrant + MetaImpact 的 Unavailable 去掉 @Component/@Service 上不可靠的
  @ConditionalOnMissingBean(全仓单实现,直接总注册;fail-closed 不变)。
- 跨模块 bean 名冲突:AccountExportServiceImpl 的 @Resource 字段 exportTaskMapper(类型 AccountExportTaskMapper)
  按名撞 content 的 ExportTaskMapper bean → 改名 accountExportTaskMapper。

背景:Spring 对 @Component/@Service 上的 @ConditionalOnBean/@ConditionalOnMissingBean 不保证可靠(官方仅
@Bean 方法),"从未以单体装配过"的本仓在单进程下顺序混乱致漏注册。build 验证编译通过;启动仍在逐层推进中。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-14 17:37:52 -07:00
lili
d38260fc51 feat(p1-market): market 写路径整改——member 暴露写端口,消除 market→member.dal BC 违例(BC 门全绿) 
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>
 2026-06-14 06:22:09 -07:00
lili
2cff86b808 chore(agent-infra): round-2 加固——据 Opus 评审堵 harness 漏洞 
独立 Opus 评审发现、并经我核验为真的关键漏洞,本轮整改(JDK21 实跑验证全绿):

- P0-1 CI 接上电:maven.yml 触发分支 master→main(此前误配 master、仓库无该分支 → CI 从不运行,
  所有门禁形同离线)、checkout/setup-java 升 v4。
- P0-2 BC 门通用化:ArchUnit 改为通用条件,覆盖全部业务 BC 间 .dal 方向(原仅守 AI 单向);
  整改 knowledge 同构违例(ContentKnowledgeWorkOwnerFacade 改消费 MuseContentWorkOwnerApi);
  market→member.dal 写路径违例单点登记待整改(KNOWN_VIOLATION_EXEMPTIONS + bc-boundaries §三)。
- loop 机械牙:新增 AgentsInfraIntegrityTest(每业务 BC 有 .agent、README 索引每篇 .agents 文档、总账在),
  把写回/索引同步从自觉变机械。
- P1-1 去魔法数:覆盖门分域计数 28/21/37 改为派生自 APPROVED_*_COMPLETED_OPERATIONS.size()。
- openapi-diff materialize 为独立 workflow(待首跑验证)。
- 文档诚实化:AGENTS/总账/bc-boundaries 订正"已验证绿"等过度声称为与实际相符(BC 门 market 待整改、契约门仅存在性/结构)。

验证:JDK21 mvn -pl muse-server -am 实跑 7 类门禁/单测全绿(BcBoundary 1/0F 且 0 Architecture Violation、
AgentsInfraIntegrity 3/0F、ContractFirst 2/0F、P1rApiCoverageReport 7/0F、knowledge/ai/content 适配器单测全绿),BUILD SUCCESS。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-14 05:39:16 -07:00
zizi
e55618f1fb test(p1r): 收口 Knowledge 事件传播真实链路门禁 2026-06-07 10:00:20 +08:00
zizi
cef686b968 feat(p1r): 接入 Knowledge 事件传播真实链路 2026-06-07 10:00:04 +08:00
zizi
48c750bbd7 test(p1r): 补齐 AI 与 Knowledge 外部端到端验收 2026-06-03 14:10:21 +08:00
zizi
77e0d9b317 test(p1r): 固化 New-API 与 RAGFlow 外部验收 2026-06-03 02:30:29 +08:00
zizi
7155285940 feat(p1r): 实现 Knowledge RAGFlow dedicated gate 
将 P1R-5 Knowledge 59 个 operation 从合同兜底推进到专用 Knowledge controller/service/DAL/DDL 与 gate 测试，状态保持 dedicated / needs_verification，不标记 completed。
 2026-06-02 19:36:02 +08:00
zizi
6410604e88 feat(muse-cloud): 持久化 Muse 合同入口 2026-05-25 12:11:27 +08:00
zizi
3544a6d4b3 feat(muse-cloud): 补齐 Muse P1 API 合同入口 2026-05-25 01:36:19 +08:00
zizi
43d6806434 feat(muse-cloud): 纳入主仓库并搭建 P1 后端基座 2026-05-24 23:15:08 +08:00