lili
9634842f2f
docs(progress): 验收债真实 IT 战役开张 + 批1(content 11 op)证据就绪待批
...
§五B:校正实际 needs_verification=content37/market28/account21=86;批1 P1rContentWorkLifecycleCompletedApprovalIT(11 content CRUD op,1/1 绿)证据就绪,completed 待人工批(加 APPROVED_COMPLETED_OPERATIONS);剩余 content26(含~15 fail-closed)+market28+account21 按批续推。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 23:43:10 -07:00
lili
2499c24272
test(p1r): content work/chapter/block 生命周期 11 op 专属真实 PG IT(验收债批1)
...
新增 P1rContentWorkLifecycleCompletedApprovalIT(@SpringBootTest + 真实 PG _test 库 + MockMvc 打真实 content app 控制器),链式覆盖 11 个 needs_verification 写 op:createWork/updateWork/deleteWork、createChapter/updateChapter/deleteChapter/reorderChapters、createBlock/deleteBlock/mergeBlocks/splitBlock。每 op 断言 HTTP 200+code:0 + 真实 muse_content_* 持久化事实(revision/内容/逻辑删/合并拆分活块数 delta/来源归因)+ muse_content_command_log 命令行。1/1 绿(mini-infra PG,独立复跑确认)。
产出方式:Codex 起草(读真实控制器/DTO/Mapper)+ Opus fork 落地纠偏(乐观锁 revision 改为运行时实读、merge/split 改为活块数 delta 真实结构效果、auth 对齐基准类、@Import 补 StructureController)+ 父独立复跑 + 逐 assert 反假绿复核(无弱化)。遵守边界:仅新增该测试文件、零产代码改动、未改 coverage 台账/APPROVED 列表(completed 仍待人工批)。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 23:42:08 -07:00
lili
888217deee
docs(p1r): 真实 PG IT 基线 23/23 全绿 + 完整跑法配方(reuseForks=false 等)落档
...
§四:23/23 P1r*IT 在 mini-infra PG 全量重跑全绿(99 用例 0F/0E,2 例 external-acceptance 跳过);补批量跑要点⑥(-DreuseForks=false 避 Market IT 属性脱敏污染复用 fork)⑦(argLine 传 p1r.flyway.*);旧硬编码版本断言需动态化TODO 已闭(MigrateResult 动态)。§五B:基线落档,指向 §四 完整配方。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 20:57:14 -07:00
lili
4d46d7ac8a
test(p1r): KnowledgeFlywayMigrationIT 版本断言动态化——消除 V→V 硬编码复发(Codex+Opus 合并方案)
...
原硬编码 TARGET_VERSION/TARGET_MIGRATION_COUNT=21,V22/V23(market 索引修复)加入后断言失败(第 2 次复发 V14→V21→V23)。改用本次 Flyway MigrateResult 的 targetSchemaVersion/migrationsExecuted 动态校验(随 sql/muse 增长自适应,无需再维护常量),并加 result.success/migrationsExecuted>0 守护;反假绿:仍校验迁移成功 + schema_history 计数与本次执行数一致 + Knowledge 表/索引/列存在(未改)。
方案来源:Codex(MigrateResult 字段,javap 验证 Flyway 11.7.2,避开 fork 指出的 info().all()/pending() 弃用)+ Opus fork(同样判定动态优于硬编码、count==executed 反假绿)双代理并行提案合并。验证:真实 PG(mini-infra)单测 1/1,target_schema_version=23 动态命中。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 20:53:06 -07:00
lili
338b33a406
docs(progress): MuseAiEventPublishOutboxMapperTest 真实 PG 实跑 5/5——ai/平台预存红三项全清
...
该测本就是真 PG focused test(自读 infra.env、隔离 schema 自建自清),原红仅缺真 PG 环境;mini-infra PG(100.64.0.8:5433)+ source infra.env + argLine SOCKS 清下实跑 5/5,零代码改动。连同 MuseAiTaskServiceTest(40/40)、QiniuSmsClientTest(5/5),§五B/§一 三项预存红全部消除。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 20:25:45 -07:00
lili
043ba0814f
test(system): 整改 QiniuSmsClientTest 时区硬编码——断言改用生产同款换算,机器无关 5/5
...
原断言硬编码 delivrd_at(epoch 1724591666)的 +8 结果 21:14:26,在非 +8 机器(本机 -07:00)必红。改用与生产 QiniuSmsClient 同款 LocalDateTimeUtil.of(epoch*1000)(系统默认时区)换算期望值→任意机器时区下稳定一致,零产代码改动,5/5 绿。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 19:41:00 -07:00
lili
4a5e1e479d
test(ai): 整改 MuseAiTaskServiceTest 预存红——11 例 NPE→40/40(补 outbox/审 服务桩)
...
「审」字段补齐(2026-06-14)后 runtimeProjectionService 新增 eventPublishOutboxService/candidateReviewService 依赖,旧测未补桩→@InjectMocks 注 null→投影路径 11 例 NPE。整改:补两 @Mock + 显式 ReflectionTestUtils 接桩 + candidateReviewService.review lenient 返回通过审(镜像 MuseAiRuntimeProjectionServiceTest)。零产代码改动,40/40 绿。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 19:37:43 -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
3e3e656424
docs(progress): e2e 可入库种子已落地(globalSetup)——20/20 一键可复现
...
更新 §五C:一次性 /tmp 种子教训已闭环为 e2e/global-setup.ts + playwright globalSetup/workers:1,source infra.env 后 pnpm test:e2e 即 20/20 零手工种子。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 18:36:25 -07:00
lili
6fd483ea1d
test(studio): e2e globalSetup 直连真实 PG 自动复位每轮 fixture(可入库,替代一次性 /tmp 种子)
...
新增 e2e/global-setup.ts:用 pg 直连真实 PG(凭据从 infra.env 环境变量读,不入库)幂等复位 graph/confirm-draft/accept(block3→rev1)/security-ack(事件→未确认+清 ack)/appeal(→supplementing)等每轮被消费的 fixture;playwright.config 接 globalSetup + workers:1(共享活体 DB 串行避竞态)。
证:消费态下 source infra.env 后 pnpm 直跑整套→globalSetup 复位→20/20 单次全绿,零手工种子(反假绿可复现)。E2E_SKIP_SEED=1 可跳过;缺 MUSE_POSTGRES_* 报清晰错。tsc -b 干净。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 18:35:51 -07:00
lili
fa64280819
docs(progress): e2e 全套 20/20 单次全绿(reseed 后,真实后端 MSW-off)
...
加 knowledge-graph 后共 20 例;reseed 三个每轮种子依赖旅程(accept happy/security-ack/market 申诉补充)后 --workers=1 串行整套 20 passed。记教训:一次性 /tmp 种子脚本每会话丢失需反推,宜落地可入库 e2e 种子/globalSetup。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 17:03:09 -07:00
lili
cefdadca6f
docs(progress): bindings 活体勘察结论——写路真实绿但读回投影 gap,不建一侧 UI
...
§五C:precheck→bind 写路 curl 证真实+绿(user_kb→bindingId 写 muse_knowledge_binding);但 local-knowledge.sourceBindings 读事件驱动投影、bind 不同步填充→无诚实读回。判定:bindings 属事件驱动副路径待投影接线,不建一侧写 UI(反一侧设计)。下一前端候选转 publish。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 08:45:58 -07:00
lili
63fd977df7
docs(progress): 总账同步——知识图谱视图 + confirm 重名 500 修复(知识库工作台收口推进)
...
§五C 知识库工作台:graph UI ✅ (仍剩 bindings/publish);confirm 重名实体 500→干净冲突 1043002004 已修;per-BC tracker(knowledge)+ §四时间线同步。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 08:36:23 -07:00
lili
3ed40a3187
feat(studio): 知识图谱视图(先审后入"正式轨"成果)rendered-UI 活体证
...
知识库工作台(/knowledge/:workId)新增「知识图谱」面板:经 GET /works/{id}/graph 读真实 muse_knowledge_entity/relation,渲染已确认入库的 Canonical 实体(节点)与关系(边)——与「待确认草稿面板」构成双轨主权闭环(候选 Shadow → 人工确认 → 正式图谱可见)。新增 useKnowledgeGraph hook;confirm 成功后失活图谱缓存联动刷新。
活体证(MSW off,chromium 直连 48080):knowledge-graph.spec.ts 绿(GET graph code:0、节点 huotituopusuqing/huotituopuqingzhou + huoti_related 边渲染);curl 实证后端真返节点/边。tsc -b 干净、vitest 47/47 无回归。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 08:34:36 -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
0bcb825290
docs(market): .agent 同步生产者飞轮端到端收口(推翻"生产侧无 UI"过时 TODO)
...
CLAUDE.md「changes land 时保持 .agent 当前」:原 TODO「生产侧发布/上架/申诉无 UI、
飞轮在 UI 层断裂」已被本会话推翻——记录飞轮端到端打通(发布→上架可视化→申诉全生命周期
+申诉态回显)、本会话新增的 3 处 app-api 契约,并留痕真实剩余 gap(资产仅 admin markListed
物化、申诉附件上传、下架/召回自助入口、验收债 IT 关台账需人工批准)。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 07:18:03 -07:00
lili
90daa3088b
feat(market): 我的发布记录回显 appealStatus(生产者飞轮端到端收口)
...
my-publish-records 经 MuseMarketAppealMapper.selectLatestByAssetIdAndUser +
resolveAppealStatus 回填该物化资产被当前发布者发起的最新申诉态到记录 appealStatus
(无物化资产/无申诉则 null;marketAssetId 与 appealStatus 两路共用各只查一次)。
前端 MarketPublish 发布记录副文本以中文徽标渲染「申诉:<待处理/审核中/已关闭…>」。
活体证(反假绿,MSW off 直连重建后单体 48080):
- market-publish.spec.ts 第 8 例 chromium 绿(recId=5/marketAssetId=2 回显 appealStatus=closed→「申诉:已关闭」)。
- 后端 MarketPublishServiceTest 14/14 回归通过(appealMapper 注入无 NPE);前端 tsc 干净 + vitest 47/47 + market-publish 8/8。
至此市场生产者飞轮端到端完整:发布(草稿→检查→提交)→上架状态可视化→
申诉(提交/补充材料/撤回)全生命周期 + 申诉态回显。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 07:08:09 -07:00
lili
ce6bbd8625
feat(market): 申诉补充材料/撤回 UI——补 app-api 我的申诉列表端点
...
同类 gap:生产者本无「自己申诉」的 app-api 列表端点(只有 admin 列表),
故 supplement/withdraw 无从取 appealId+状态。
后端(muse-module-market):新增 GET /marketplace/appeals(appListMyAppeals +
MuseMarketAppealMapper.selectListByUser + MarketMyAppealItemRespVO),
返回当前发布者全部申诉,并派生 canSupplement(supplementing 态)/canWithdraw(非终态)。
前端(muse-studio):MarketPublish「我的申诉」区列申诉 + 中文状态徽标;
- canWithdraw 放开「撤回」→ useWithdrawAppeal → POST .../withdraw(expectedStatus 乐观锁)→ closed;
- canSupplement 放开「补充材料」→ useSupplementAppeal → POST .../supplements(privacyConfirmed)→ reviewing。
活体证(反假绿,MSW off 直连重建后单体 48080):
- market-publish.spec.ts 第 6/7 例 chromium 绿(撤回→已撤回、补充→材料已补充)。
- DB 证:withdraw→muse_market_appeal status=closed;supplement→muse_market_appeal_material 追加行(e2e 点击产 material#2)。
- 后端 MarketAppealServiceTest 15/15 + AppMuseMarketAppealControllerTest 6/6 回归通过;前端 tsc 干净 + vitest 47/47 + market-publish 7/7。
- 种子 /tmp/SetAppealSup.java(置 supplementing;提交后→reviewing 故每轮重置)。
仍 ⬜ :发布记录上 appealStatus 回显(my-publish-records 未 join 申诉表)。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 06:53:55 -07:00
lili
a00c7581c9
feat(market): 申诉(appeal)写路 UI 打通——后端暴露物化 assetId 解 gap
...
根因:my-publish-records 的 assetId 是 publish-record id(草稿/申请占位),
非 submitAppeal.requireAsset 所需的物化 muse_market_asset.id(资产仅在 admin
审核通过 markListed 时物化),生产者侧 UI 取不到正确 assetId。
后端最小契约改动(muse-module-market):
- PublishRecordItem / MarketPublishRecordItemRespVO 加 marketAssetId 字段;
- MarketPublishServiceImpl.resolveMarketAssetId:request.asset_id 命中真实
muse_market_asset 且归属当前发布者才返回其 id,否则 null(fail-closed,不放开入口)。
前端(muse-studio):
- useSubmitAppeal hook(POST /marketplace/appeals,新 commandId 幂等);
- MarketPublish「我的发布记录」:仅 marketAssetId 非空 + 状态可申诉
(rejected/compliance_blocked→review_rejection、delisted→delist、recalled→recall)
的记录放开「发起申诉」→ 面板填理由 → 提交 → 申诉已提交(pending)。
活体证(反假绿,MSW off 直连重建后单体 48080):
- market-publish.spec.ts 第 5 例 chromium 绿(点发起申诉→填→提交→pending)。
- DB 证:muse_market_appeal 追加行 status=pending、commandId 为前端 UUID(e2e 点击产 appealId=3)。
- curl 正负路:自有已驳回→appealId/pending;他人资产→1044000024 无权访问;不存在→1044000003 资产不存在。
- 后端 MarketPublishServiceTest 14/14 回归通过;前端 tsc 干净 + vitest 47/47 + market-publish 5/5。
- 种子 /tmp/SeedAppeal.java(asset(pub=1)+rejected request,asset_id=物化资产)。
仍 ⬜ :补充材料(supplements)/撤回(withdraw)申诉 UI、记录上 appealStatus 回显。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 06:33:44 -07:00
lili
0ec0955779
feat(studio): 市场发布上架状态可视化(生产者飞轮进度反馈)
...
「我的发布记录」新增发布生命周期中文徽标(草稿/已提交/审核中/已通过/
已上架/已驳回/需补充材料/已撤回/已下架/已召回)+ nextAction/appealStatus
副文本。上架=审核通过自动 markListed(非生产者动作),生产者侧通过本徽标
看到 publish→review→list 进度反馈。
活体证(反假绿,MSW off 直连单体 48080):
- market-publish.spec.ts 第 4 例 chromium 绿:断言 listed→「已上架」、
rejected→「已驳回」徽标渲染(种子 /tmp/SetReqStatus.java 置 req#2→listed、#3→rejected;
curl my-publish-records 证状态反映)。
- market-publish 4/4 + vitest 47/47 + tsc 干净。
申诉(appeal)后端经 curl 验证为 real+fail-closed(自有已驳回资产→appealId/pending;
他人资产→1044000024 无权访问;不存在资产→1044000003 资产不存在),但申诉 UI 后置:
真实 gap——my-publish-records 暴露的 assetId 是 publish-record id,非 submitAppeal
所需的物化 muse_market_asset.id(资产仅在 admin 审核通过 markListed 时物化),
UI 入口取不到正确 assetId,收口需后端额外暴露物化 assetId 或经真实审核通过物化流。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 05:36:36 -07:00
lili
0cf1ef3462
feat(studio): 安全事件「确认」写路(account 深页活体切片)
...
个人中心「安全事件」区:未确认事件展示「确认」按钮,点击经
useAcknowledgeSecurityEvent(每次发新 commandId,后端按 commandId 幂等)
真打 POST /account/security-events/{id}/acknowledge(action=acknowledged)→
列表失活重取翻「已确认」、按钮消失(构成 acked→无动作 UI 不变量)。
活体证(反假绿,MSW off 直连单体 48080):
- 正路:account-security-ack.spec.ts chromium 绿(点确认→翻已确认);
curl acknowledge 真实事件→code:0 + 列表 acknowledged 翻 true。
- 负路:acknowledge 不存在 eventId→404、非法 action→400,均 fail-closed。
- DB 双证:muse_member_security_event.acknowledged 翻 true +
muse_account_security_event_ack 追加 1 行(action=acknowledged、
commandId 为前端 UUID=权威处理历史,非覆盖)。
- 种子可重置(/tmp/SeedSec.java:事件B写锚点每轮重置未确认,写路 e2e 可重复)。
- 本轮实跑:account-security-ack 1/1 + live-read 6/6 + vitest 47/47 + tsc 干净。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 05:20:50 -07:00
lili
b58a704ffa
feat(studio): 个人中心渲染真实安全事件(account 深页活体切片)
...
PersonalCenter 新增「安全事件」区,渲染 GET /account/security-events 真实摘要
(useAccountSecurityEvents→AccountPageResult<SecurityEventSummaryRespVO>),
eventType/severity 徽标 + 已确认/待确认状态。
活体证(反假绿,MSW off 直连单体 48080):
- 正路:live-read.spec.ts 第 6 例 chromium 绿,断言种子事件「活体安全事件·异地登录提醒」渲染;
curl 列表 total=1 含该事件。
- 负路:acknowledge 不存在 eventId→404「安全事件不存在」、非法 action→400 参数校验,
均 fail-closed 非许可桩。
- 种子幂等(/tmp/SeedSec.java,account_user_id=1/tenant=1,DB id=1)。
- 本轮实跑:live-read 6/6 + vitest 47/47 + tsc 干净。
security-events 后端端点本就可用(无 facade gate),本切片接通 UI 消费侧。
exports/downloads/new-api 深页仍为正确 fail-closed 外部依赖,非接线缺口。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 04:30:43 -07:00
lili
2f64397719
fix(market): 系统性修 market 残余 (tenant_id,command_id) partial-index ON CONFLICT bug + 真实 PG IT
...
续 V22。handoff_event/appeal_material/authorization_summary/appeal_event/appeal 5 表的 (tenant_id,command_id)
在 V15 被建为部分唯一索引(WHERE command_id IS NOT NULL),而对应 mapper insertIgnore 发无谓词
ON CONFLICT (tenant_id,command_id)→PostgreSQL 无法用部分索引作仲裁器→这些链路(handoff/申诉/授权摘要)
活体时 500(潜伏,流程尚无活体触达)。grep 实证仅这 5 表 mapper 确发无谓词 ON CONFLICT;其余 market 部分
command 索引未被当 arbiter,不动。
- V23__fix_market_remaining_command_unique_index.sql:5 表 部分→完整唯一索引(对齐 command/purchase 约定)。
- P1rMarketCommandIndexFlywayMigrationIT(真实 PG):clean→迁移 V1→V23→断言 V22/V23 修复的 9 个命令索引
均为完整唯一索引(可作 ON CONFLICT 仲裁器),Tests run 1/0F。与 target=V15 的 P1rMarketFlywayMigrationIT 互补。
- V23 已应用 muse_slice_live;全新 muse_p1r_cmdidx_test 库迁移验证。
进度总账 §五C/§四 就地更新。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 03:30:11 -07:00
lili
c7c65a97f2
feat(studio): 个人中心渲染真实购买/授权记录(account 深页活体切片)
...
承 account facade 活体订正(单体内 /account/{purchases,licenses,publish-records} 经 market 跨模块
MarketAccountProjectionProvider 本就可用),把已确认可用的后端接进 UI:
- PersonalCenter 新增「我的购买 / 我的授权」两区,渲染 market→account 投影真实记录;
- useAccount 加 useAccountPurchases / useAccountLicenses(GET /account/{purchases,licenses})。
- live-read.spec.ts 加第 5 例(chromium, MSW off, 真连 48080):/account 渲染真实资产「活体市场资产·测试」。
验证:整套 e2e 12/12、vitest 47/47、tsc 绿。进度总账 §五C 个人中心就地更新。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 03:11:20 -07:00
lili
4433c96d7d
docs(mvp): account facade 活体订正——单体内三端本就由 market Provider 跨模块提供(反假绿,无净代码改动)
...
user 据 §五A"account 21 端 UNAVAILABLE"选"account 后端 facade 真实化"。Explore 静态分析判
MarketAccountProjectionFacade 阻塞 purchases/licenses/publish-records;实测推翻——单体内 market
MarketAccountProjectionProvider(@Service)本身 implements MarketAccountProjectionFacade 并对
purchase/license/publish 放行,@ConditionalOnMissingBean 使其压过 member 的 Unavailable 兜底,
故这三端在单体本就可用。curl 真返投影:purchase(completed)/license(installed)/publish-records
(含 market-publish e2e 提交的 5 条 = market→account 端到端)。
曾据 Explore 加 member-local RealMarketAccountProjectionFacade + 改 autoconfig、rebuild+restart 验证;
可逆翻转测试(全局 purchase=0 仍返回空而非 UNAVAILABLE)证实活跃 facade 是 Provider 而非我的 count-gating
facade → 单体 no-op 且违背原设计意图,已回退(member 模块工作树干净)。顺带:restart 时 Flyway 真实应用
V22(market 索引修复)。单体真正 fail-closed 的 account 端=export/download + new-api recheck,均正确
fail-closed(未配置外部服务)。教训:跨 BC facade 判定须以单体实跑为准,静态分析会漏 monolith 跨模块 bean 绑定。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 03:06:36 -07:00
lili
288fce955f
feat(studio+market): 市场发布提交审核全链(草稿→检查→提交)活体绿 + V22 补 review_event 索引
...
承上一提交(草稿切片),完成创作者发布全链到「提交审核」:
- MarketPublish 加 licenseType / 权利声明字段 + 「提交审核」按钮(save→运行检查→检查通过则提交申请);
useMarketPublish 加 useRunPublishCheck / useSubmitPublishRequest。
- market-publish.spec.ts 3/3 绿(草稿正 / 缺标题负 / 提交全链),DB 证 muse_market_publish_request=submitted
+ muse_market_review_event=submitted 落库;全链测用唯一名→可重复跑。
整套 e2e 11/11、vitest 47/47 无回归、tsc 绿。
修复:submitPublishRequest 的 writeSubmittedReviewEvent 命中 muse_market_review_event 同款部分索引
ON CONFLICT 不匹配 bug(submit 500);V22 迁移 + muse_slice_live 增补 review_event 索引(部分→完整,共 4 表)。
遗留:handoff/appeal/authorization_summary 等 market 表同类部分索引待对应流程活体时收口。
进度总账 §五C 已就地更新(市场生产侧:发布草稿 + 提交审核全链 ✅ )。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 02:10:12 -07:00
lili
0b6b1e8887
feat(studio+market): 市场生产侧发布草稿活体纵切 + 修 publish 部分索引 ON CONFLICT 潜伏 bug
...
studio 生产侧首切片(创作者飞轮起点):新增 /market/publish 发布表单(MarketPublish + useMarketPublish hook),
保存发布草稿经唯一合法入口 POST /marketplace/publish-drafts → my-publish-records 真实回读;
MarketBrowse 加「我要发布资产」入口。market-publish.spec.ts(chromium, MSW off, 真连 48080)正+负绿,
DB 证 muse_market_publish_draft 落库(status=draft);命令幂等键按材料 hash 派生→自包含可重复跑、无需预种。
附带修真实潜伏后端 bug(链路从未活体跑过):publish draft/check/request 的 (tenant_id,command_id)
被 V15 建为部分唯一索引(WHERE command_id IS NOT NULL),而各 mapper insertIgnore 发无谓词
ON CONFLICT (tenant_id,command_id)→PostgreSQL 无法用部分索引作仲裁器→savePublishDraft 500
(BadSqlGrammarException: no unique or exclusion constraint matching the ON CONFLICT specification)。
修=部分→完整唯一索引,对齐 muse_market_command/purchase 既有约定(V22 迁移 + muse_slice_live 已应用,
零 Java 改动/零重启)。遗留:handoff/appeal 等 market 表同类部分索引待对应流程活体时收口。
验证:整套 e2e 10/10 绿、vitest 47/47 无回归、tsc 绿。进度总账 §五C/§四/per-BC 已就地更新。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 02:01:18 -07:00
lili
8a6c809696
test(studio): studio e2e 全套 MSW-off 自起复现 8/8 全绿 + 修 webServer/workspace 假绿
...
承 MVP#1 前端长板收口。整套 playwright(chromium)在关 MSW、直连真实单体(48080)下 8/8 全绿,
经「移开 .env.local + 无预跑 vite + playwright 自起」验证可独立复现(非仅依赖手起 vite 被 reuse)。
修复(经验证):
- playwright.config.ts webServer.command:`pnpm dev` 在 playwright 派生的 /bin/sh 下报
「pnpm: command not found」(exit 127,pnpm 不在该 PATH),改用等价 `./node_modules/.bin/vite`;
并加 `env: VITE_API_MOCK=false`,使关 MSW 在 CI/自起场景可复现(此前仅 reuse 手起 vite 才绿,潜伏假绿)。
- workspace.spec.ts:原断言 mock「星海迷途」在 MSW-off 下必红(MSW 假绿反模式),
改写为不依赖 mock 的工作台壳渲染冒烟,消除最后一处 MSW 互斥红。
覆盖(均 MSW off 真连、write 路径 DB 核验):accept-suggestion 正+负
(block3 rev1→2 + AI摘要正文 + ai_suggestion 归因落库)、knowledge-confirm
(draft→confirmed + 新建 Canonical entity)、live-read content/market/account/ai、workspace 壳。
进度总账 §五C/§四:记 8/8 里程碑;订正 suggestion 合并后留 pending 根因
(merge 不同事务回写 AI 域、靠 outbox→AI 异步翻,读 ContentSourceServiceImpl 确认,非产品 bug)。
遗留:e2e 暂依赖 muse_slice_live 预置 fixture(/tmp 助手手动 reseed),待补 playwright global-setup 自播种。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 01:29:35 -07:00
lili
3b2ec01966
docs(mvp): knowledge 工作台确认草稿前端 in-UI 证 + flag confirm 重复实体 500 bug
2026-06-15 00:43:20 -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
f63247fb8f
test(studio): live-read e2e 补 ai-agent 读旅程(4/4 绿)
...
智能体列表 rendered UI 渲染真实 agent(MSW off 直连活体)。前端 in-UI 既有页面扫描完成:
content(列表读+采纳写)/ai(agent读+采纳)/market(浏览读)/account(个人中心读)。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 00:28:18 -07:00
lili
6d3eeed068
test(studio): content/market/account 读旅程 rendered-UI 活体 e2e(3/3 绿)
...
live-read.spec.ts:MSW off 直连活体单体,chromium 验作品列表/市场浏览/个人中心均渲染真实后端数据,
证 client.ts tenant-id 修复后 studio 可跨 BC 直取活体数据、真实数据形态与渲染契约对齐。
前端 in-UI 覆盖:content(列表读+采纳写)/ai/market(浏览读)/account(个人中心读)。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 00:26:13 -07:00
lili
73355b69fa
feat(studio): MVP#1 AI候选采纳 rendered-UI 活体 e2e 打通(happy+negative)
...
main.tsx 加 VITE_API_MOCK=false 开关关 MSW、前端直连活体单体(activeb 联调/e2e 用,默认 dev 仍 MSW 开)。
accept-suggestion happy-path 用 page.route stub AI 生成(发真实 suggestionId,采纳 POST 直打真后端)→
chromium 实跑:生成→点采纳替换→真合并,DB 证 block rev1→2、正文=候选;negative-path 乐观锁拒绿。
§五C 记前端 in-UI 模式打通 + 遗留(种子状态依赖/MSW on-off 拆 project/suggestion 留 pending 待确认)。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 00:22:33 -07:00
lili
b50cd45d23
fix(studio): client 注入 tenant-id(活体集成缺口)+ MVP#1 negative-path e2e 绿
...
活体对接暴露:client.ts 只注入 Bearer/版本号、漏 tenant-id,真实后端报「租户标识未传递」(MSW 不校验故 dev 未暴露)。
新增 auth.readTenantId(mock 单租户默认 1,真实登录应写入)+ client 注入 tenant-id 头。
e2e/accept-suggestion 负路径补 tenant-id 头、填活体种子常量(work/block/suggestion=3);
playwright(chromium)实跑:rendered app→vite 代理→真后端→乐观锁 1041000002 拒,绿。tsc 0 / vitest 47。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 00:13:22 -07:00
lili
35af34a564
docs(mvp): ai-agent + events BC 活体证,核心后端产品目标实质达成
...
agent:POST 创建 agentId:1→GET 列表含之(active);events:经 AI SSE + streamEvents 双评审 IT。
§五 总评:5 个核心 BC(content+ai/knowledge/market/account/agent)端到端活体证毕(正+负),
含 market→account 跨 BC 投影;后端产品目标实质达成。仍缺前端渲染层(B3)/meta admin/市场发布 UI。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 23:38:13 -07:00
lili
6897fc2ac4
fix(base-schema): 补 member_user.register_terminal + infra_api_error_log_seq(解 account 读 500)
...
account/profile 等读 member_user 引用 register_terminal,原基座翻译遗漏→500;补列后转干净业务码。
infra_api_error_log 走 @KeySequence 但原用 IDENTITY 无序列→错误日志写入再抛。两处补入基座文件。
活体证(48080):account BC 个人中心读旅程全通,且 market 购买/安装经投影流入 account purchases/licenses
=market→account 跨 BC 端到端。§五:account BC ✅ (已 4 个 BC 活体证)。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 23:35:32 -07:00
lili
a4a49a86e9
docs(mvp): knowledge BC 活体纵切达成(确认草稿 Shadow→Canonical 实体,正+负)
...
curl 真打单体 48080:GET 待确认草稿→POST confirm→muse_knowledge_entity 落库+草稿 confirmed;
负路径 revision(1043002001)/source-stale(1043002002)被拒、草稿转 conflicted。
§五 加 per-BC 活体度量(goal 真实进度):content+ai ✅ 、knowledge ✅ 、market 进行中。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 23:27:03 -07:00
lili
7ac58ab7e4
docs(mvp): 校正 MetaImpact 判定(缺用量投影特征非接线)+ 确认 goal 主攻方向
...
勘察发现 content/ai/knowledge DAL 均未持久化 schemaKey 用量引用,MetaImpact 真实化=多模块特征工程而非 facade 接线,置后。
goal 方向定:活体纵切·每 BC 一条端到端旅程,验收=achieve the product goal。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 23:21:17 -07:00
lili
517e2b8197
fix(p1r): 修复陈旧红测试 P1rKnowledgeFlywayMigrationIT(V14→V21)+ 建 master plan 收口 backlog
...
唯一红测试硬编码 TARGET_VERSION=14/count=14,而 schema 已演进 V21(V15-V21 各域 outbox 迁移)。
Flyway 全量执行 sql/muse 所有迁移,断言应随 schema 增长;V14 知识表/索引检查保留。
真实 PG 验证绿(muse_knowledge_flyway_test,exit 0,migration_count=21/version=21)。
进度总账新增 §五:P1R-7 收口活 backlog(校正 facade 缺口清单,B2 勘察多处误判已纠)。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 23:03:17 -07:00
lili
913c8e042d
docs(mvp): 记录全栈 muse-server 史上首次单体启动 + MVP#1 活体端到端实证
...
墙3 诊断证伪(非 Feign RPC,真因=classifier/Spring条件注解/bean名冲突/codegen/SOCKS)。
全栈起法+活体 curl 命令(GET works、POST suggestion-merges accept_as_is、乐观锁负路径)
固化入 knowledge §六;进度总账追加里程碑条目。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 17:49:28 -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
d61ff79ebc
docs(knowledge): 订正全栈启动第 3 墙诊断(Feign 初判被实测推翻=classifier)
...
实测推进:"cloud→monolith Feign RPC 桥接"初判证伪。真因是 system/infra/ai-server 同 member 的
无 classifier repackage fat jar 问题(嵌入 muse-server 后类不可加载)→ 配 classifier(eea10b7)后
本地 PermissionApiImpl(PermissionApi extends PermissionCommonApi)即注册,无需任何 Feign 桥接。
随后实测打通 datasource(清 SOCKS 代理 system property)/Flyway V1-V21/security/codegen。
剩余唯一类:facade 的 @Service @ConditionalOnMissingBean 兜底在单体下未可靠注册(~21 个,逐个暴露)。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 16:56:43 -07:00
lili
eea10b736f
fix(build): system/infra/ai-server repackage 配 classifier=exec(单体可加载)
...
延续 member-server 同款修复(1f89007):被 muse-server 装配的 yudao 系 -server 模块若 repackage 无
classifier,主 jar 是 fat jar,嵌入 muse-server fat jar 的 BOOT-INF/lib 后其类不可加载,运行期模块 bean
全失踪(实测:boot 报 PermissionCommonApi/PermissionApiImpl 无法装配)。给 system/infra/ai-server 的
repackage 配 classifier=exec → 主 jar 为可嵌套加载的瘦库。
验证:clean package BUILD SUCCESS,主 jar 由 ~180MB fat 变 0.5-1.3MB 瘦库;muse-server 启动已越过
datasource(清 SOCKS 代理 system property 后 PG 连通)+ Flyway V1-V21 + security/permission 装配,
推进到 facade 条件装配阶段。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 16:53:45 -07:00
lili
038d2cf387
chore(p1-fullstack): 补 postgres 基座 schema(dev)+ 记录全栈启动 2 墙拆除与第 3 墙诊断
...
为活体 e2e 起全栈 muse-server,实测拆两墙、定位第三墙:
- 墙1(已修, commit 1f89007):member-server repackage classifier → mvn package 全项目 BUILD SUCCESS。
- 墙2(已解):本仓原无 postgres 基座 dump。新增 muse-cloud/sql/dev/yudao-base-schema-postgres.sql
(system/infra/member 测试 schema 忠实翻 PostgreSQL,49 表)+ yudao-base-seed-postgres.sql
(system_tenant id=1 等最小启动种子);实测灌库 0 失败,app Flyway(baseline-on-migrate)成功补
Muse V1-V21、Tomcat 起、Spring 初始化。
- 墙3(定位,开 chip):muse-server 卡 bean 装配——5 个 biz.system CommonApi 是 @FeignClient
(yudao-cloud RPC),单进程单体下未注册本地 bean。即项目从未以单体真正启动过(基线"未实跑"根因),
需阶段7「cloud→monolith RPC 桥接」(真实接 system 本地 impl,非 permissive stub=假绿)。
knowledge §六 记全栈启动配方 + 三墙状态;进度总账加时间线。MVP #1 纵切仍以 4 个真实 PG IT 为正确性证据。
未推送(等用户)。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 11:18:35 -07:00
lili
1f89007d41
fix(build): member-server repackage 配 classifier=exec,修复全项目 mvn package 失败
...
根因:member-server 用 spring-boot repackage 无 classifier,主 artifact 变 fat jar(class 进
BOOT-INF/classes),clean package 阶段 member 先 repackage 后 market-server 编译,致
MarketAccountProjectionProvider 引 member-server 内部接口报 "package does not exist"。
仅 test 阶段不触发(member 未到 package),故此前 CI test/-am test 全绿、是 d38260f 未做
clean-package 验证的假绿。
修法:给 member-server 的 repackage 配 <classifier>exec</classifier>——主 jar 保持可被下游
编译消费的瘦库,fat 可执行 jar 挪到 muse-module-member-server-exec.jar(微服务单独运行仍可用)。
验证:mvn -pl muse-server -am -Dmaven.test.skip=true clean package → BUILD SUCCESS,
产出 muse-server.jar + member 主 jar 810KB 瘦库 + -exec fat jar。
遗留:market-server→member-server 的 pom 依赖(BC 越界)仍在,属更深的 BC 收口(见 chip),本次只
解 package 破损。建议 CI 增加 package 阶段以防此类 repackage 依赖破损再被 test 阶段漏过。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 11:03:47 -07:00
lili
e8f616d5a5
feat(p1-ai): AI 生成候选补齐「审」字段+active+授权快照,打通生成→采纳
...
消除「经真实 AI 生成流产出的候选永远无法被采纳入正文」缺口(chip task_092cfc32):
- 新增 MuseAiCandidateReviewService:对生成正文做真实(轻量)审——输出合规扫描(空/凭据痕迹)
+ 静态检查(空白/超长)+ 许可限制快照透传;三项全过才给可追溯审结果 ID(绑定 generation+内容指纹),
任一不过则不给 → 调用方不写审字段 → Content 合并门禁如实拒绝(反假绿)。
- MuseAiRuntimeProjectionService.createRuntimeSuggestion:
· 顶层 content 写入候选 contentSnapshot(脱敏 summary,供 mergeBlockSuggestion facade 可用性检查;
完整 provider 原文按数据主权不持久化,采纳走 merge_after_edit 由用户回传所审正文)
· diff_summary 写齐三「审」字段(审查通过时)
· source_status 'verified'→'active'(原值既非来源状态机取值,又会被合并门禁拒绝)
· 数值授权快照:envelope id 为数值时落 authorization_snapshot_id(沿用 MuseSuggestionServiceImpl 的
envelope=authz 既有约定);非数值受 BIGINT 列限制,待授权快照建模收口(遗留)
验证(真实 PG,16/16 绿):
- MuseAiCandidateReviewServiceTest 5/0(真实审逻辑:通过/空/凭据泄露/许可透传/空值)
- MuseAiRuntimeProjectionServiceTest 5/0(回归:补 @Mock+stub 防 NPE)
- P1rContentMergeGeneratedSuggestionIT 1/0(机械门禁:真实 createShadowSuggestionCandidate 产候选
→ active/审/authz/content 由真实代码产出 → mergeBlockSuggestion 写入 Canonical)
- P1rContentMergeSuggestionIT 5/0(回归,未受影响)
至此 MVP #1「生成→采纳」活体闭环仅剩 1 个范围外阻塞:远端 dev 库缺 yudao 基座 schema(全栈 app 启动)。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 09:58:49 -07:00
lili
fe75b666b9
feat(p1-mvp): AI候选采纳入正文纵切——前端接 suggestion-merges + 后端 real-PG 机械门禁
...
据现状基线 §6.3 #1(前端 AI 候选闭环断链)整改:
前端(muse-studio):
- WorkspacePage 真实编辑器接入唯一合法入口 POST .../suggestion-merges(新增 useAcceptSuggestion),
去除 EditorPage 仅本地 setContent 的绕过(违背 Shadow→Canonical 主权)
- client.ts 注入 Authorization Bearer(后端 Sa-Token 鉴权);新增 auth.ts 统一令牌读取,sse.ts 复用去重
- AIPanel 透传 suggestionId;connectAIStream 复用 createEventStreamParser 对齐真后端 SSE event: 线(修旧 data.type 漂移);
sse.ts onDone 类型对齐 {taskId,suggestionId};CandidatePanel 异步采纳+防双写
- tsc / 47 单测 / build 全绿
后端(muse-cloud):
- 新增机械门禁 P1rContentMergeSuggestionIT:真实 PG + 真实 AiSuggestionMergeProjectionFacade 读真种 muse_ai_suggestion
- 5/5 绿:正向写 Canonical(rev1→2)/revision 冲突不脏写/幂等回放/非 pending/「审」字段缺失
未达(诚实):活体全栈 UI e2e 未跑——阻塞于①远端 dev 库缺 yudao 基座 schema(全栈 app 起不来)
②AI 运行时未写「审」字段(生成流候选不可合并,chip task_092cfc32);均范围外。
connectAIStream 的 SSE parser 漂移已在本提交修复。e2e/accept-suggestion.spec.ts 只写不跑。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 09:29:56 -07:00
lili
1a76a14995
docs(p1-verify): 记录 P1 后端 real-PG IT 验收(19/20 类零失败)+ 接入配方与 SOCKS 代理坑
...
接通共享远端 PostgreSQL(100.64.0.8:5433,PG17.10)真跑全部 20 个 P1r*IT:
19/20 IT 类零功能失败(~95 用例绿),覆盖 completed-approval、Flyway 迁移、
events-publish outbox 后端路径 + New-API live 调用——此前"86 个 needs_verification
须真实 PG、本地不可验/环境阻塞"的判断被实测推翻,后端获机械绿证据(非假绿)。
唯一红:P1rKnowledgeFlywayMigrationIT 硬编码断言 V14 而 schema 已到 V21(陈旧用例,
源自 commit 7155285、非本轮改动),应改为动态读取最新版本;已登记总账 TODO。
沉淀(避免重蹈):
- .agents/knowledge/external-deps-and-gotchas.md §四:跑 real-PG IT 的完整配方
(test 阶段 + -Dtest=<IT类>,避开 verify/integration-test 的 repackage 破坏跨模块编译;
库名须 _test 结尾且会被 flyway.clean;locations 恰为 filesystem:sql/muse;密码只走 env)
+ **本机 HTTP_PROXY 致 JVM socksProxyHost 破坏 PG 原始线协议**(EOF 误判为密码/pg_hba)的
判定与修复(-DargLine='-DsocksProxyHost= -DsocksProxyPort=');PG 实为 17.10。
- 进度总账:时间线 + "环境阻塞已解除"状态订正(诚实标注 FE / 唯一红 / live opt-in 仍未达)。
注:验收用共享 _test 库(各 IT 专属、isolated、flyway.clean 重建);本轮新建的 3 个
muse_it_*_test 已 DROP 清理;远端 PG 凭据由用户提供、未入库。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 08:19:01 -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