 姚章浩
|
70131c6161
|
feat(release): 批量审核 + 建批即锁定 —— 发布管理单文档交互降到 3~4 次
P0-3：
- 批量审核：新增 POST /api/v1/review-candidates/batch-decision，逐条复用单条审核的写入
路径（同一套合法性校验与"最新验收轮次"绑定），逐条回报 decided/skipped/skipped_ids；
不可审核的条目只计入 skipped，不打断整批，其他错误整批回滚（不留半成品）。
界面新增「全选可批准」「批量批准选中」「批量驳回选中」。
- 建批即锁定：建批请求加 seal 字段，服务端在创建后立即执行既有的密封（仍逐项复核门禁，
失败整批回滚），草稿态不再单独占一步；界面按钮改为「创建并锁定清单」，流程说明从 8 步改 7 步。
- 判据修正：「可批准」原先把已驳回的算进去（review_state !== 'approved'），改为只含 pending + 门禁通过。
语义边界（写进测试）：批量批准按人工身份记录，人工可推翻自己先前的驳回；system:auto 发起的
批量批准对人工驳回过的那条必须跳过（Decided=0/Skipped=1）——机器永远不覆盖人工。
测试：review_batch_integration_test.go（批量决定/跳报/重复 id 拒绝/机器不覆盖人工、
建批即锁定）、review_batch_test.go（幂等键、400/409/500/501 映射、服务端盖操作人）、
reviewRelease.test.ts（批量请求体与逐条回报、建批带 seal）。前端 181 条通过。
|
2026-10-10 15:29:31 +08:00 |
|
|
姚章浩
|
acf053faf3
|
feat(release): 建批时冻结 + 验收通过自动批准 —— 把"每份文档 8 步"砍掉两步并去掉两次卡死
背景：发布管理把"逐条核验"的仪式强加给每一份文档。实测一份文档要 9~11 次交互，
且有两处顺序陷阱（冻结后批准 → 建批 422；生成即固化 → 批准被永久钉住）。
P0-1 建批时冻结：
- CreateReleaseBatch 在未指定版本时，自己把当前实时计划冻结成一份**已确认**版本并绑定
（同一事务；同摘要复用最近版本，planned 或 confirmed 都可复用，因此同一份计划不堆版本）。
- 语义不变：批一旦建立，清单/摘要/验收轮次/目标库绑定全部不可变、回滚按它走；变的只是
"谁在什么时候按固化键"——从操作员的手动两步变成建批这一下。
- 效果：去掉「生成新版本」「确认冻结」两步；消灭"批准晚于冻结 → 422"这类顺序陷阱；
前端不再传版本 id，也不再有"所选知识不在冻结清单里"的阻断。
- 计划→清单项的映射抽成 ChangeSetItemsFromPlan 供两处共用，否则两处算出的摘要不同，
"同一计划复用同一版本"永远不命中。
P0-2 验收通过自动批准：
- 验收三项结论达发布门槛（knowledge_exists/chunks_present=passed，retrieval_hit 与门槛同
口径）时，由 worker 写入 reviewer_ref='system:auto' 的批准记录，替代"每份文档点一次批准"。
- 策略 TEST_AUTO_REVIEW_POLICY = off | internal（默认，仅对内）| all；值不认识拒绝启动。
只影响审核这一步：生产授权、双闸与发布前快照门禁不受影响。界面上只读展示当前策略。
- 安全边界（写死在审核 SQL 里）：系统只允许写"第一条"审核——人工一旦表过态，机器不得用一条
更晚的 approved 把人工结论翻回去；人工随时可再审。集成测试去掉该约束即 FAIL（已实测）。
- 自动批准自身的任何失败都不影响验收结论，只上报。
顺带（P1-1 前半，已被 P0-1 取代的部分已删除）：
- 写操作失败把服务端 {"error": ...} 的原因带出来，并对已知原因给出下一步（不再只给 HTTP 状态码）。
- 当前的"不在已冻结清单里"标注与就地修复按钮随 P0-1 一起移除（该失败模式已不存在）。
测试：bind_time_freeze_integration_test.go（绑定已确认版本/同计划复用/冻结后不可变/
动作不符仍 NotEligible）、auto_review_integration_test.go（系统只写第一条、人工可再审）、
validate_test.go（对内自动/对外不自动/策略关闭/验收未过不批/自身失败不影响验收）、
auto_review_test.go、config_test 及前端能力解析测试。
实测耗时：本机 Go 全量 26 包通过、前端 178 条通过。
|
2026-10-10 15:05:20 +08:00 |
|
|
姚章浩
|
e9a643cc33
|
fix(release): 禁止导入未被算进期望策略 —— 生产知识下不了架（计划与建批两处同源缺陷）
界面验收实测（2026-10-10）：把已发布到生产的 PDF 改为「禁止导入」后，发布通道既给不出
delete、也建不了 delete 批次。
根因：禁止导入只写 source_items.policy_state='blocked'，而"期望策略"的解析只看
source_item_scope_overrides / directory_scope_rules / source_items.visibility——
两处实现都不看 policy_state：
1) release_plan.go 的 source_truth：被禁止且生产侧存在的条目被算成 unchanged/present、
can_release=false → 永远不会出现 delete 动作；
2) release_batches.go 的 releaseDeleteReadyCTEs.source_truth：同样口径 → 计划即使给了
delete，创建封批仍被拒 422（实测原文「创建封批失败（HTTP 422）」）。
修复：两处都把 policy_state='blocked' 算进期望策略（各一行，注释写明成因）。
新增集成测试 release_plan_policy_state_integration_test.go：用 policy_state（真实路由的写法）
造"生产存在 + 已禁止"的条目，断言①计划给出 action=delete/can_release、②delete 批次可创建；
分别回退任一处修复，该测试即 FAIL（已实测两种回退都 FAIL）。
实测闭环：重新发布使生产存在（enable_status=enabled）→ 禁止导入 → 计划 delete（present/
can_release=true）→ v8 delete_count=1 → 批次 rb-8c1ad1c9…(sealed, action=delete) → 留档
20261010T033100Z + 门禁 PASS → 执行 rx-6c19232a… completed（项级 verified/delete、
production_revision=absent）→ 目标库该行 enable_status=disabled（行保留、检索停用、可恢复）。
附带：从未导入却被标为禁止的 82 条"等待测试"噪音不再占发布计划（195 → 113 项）。
证据与说明补进 docs/USER_FLOWS_ACCEPTANCE.md（C2b + F.3h）。
|
2026-10-10 11:36:08 +08:00 |
|
 zheromiku
|
dcdc8d1ddd
|
feat: 知识治理平台(含已验证发布/回滚契约)
全栈知识治理平台首次入库（P1-P10 + 发布链路模拟验证闭环）：
- 治理核心：源目录/变更集/人工审核/发布批次/发布执行（fail-closed 闸口）
- 测试通道：WeKnora 测试 KB 上传/轮询/验收；poll 完成时写入
parser_generation/index_generation，修复 manual/seed 路径发布闸口永久拦截
- 发布适配器 v071（本地 source=测试角色 / 云端 target=生产角色 模拟验证通过）：
* ES 导出/导入 mapping 自适应（.keyword 子字段、可选 tenant_id）
* OSS locator 支持嵌套 scheme；chunks.seq_id 由目标序列分配
* bundle 归档同身份重试原子替换；verifier 按 bundle chunk_type 计数
* 回滚 job payload 支持 prior_execution_id（strict 解码）
- 三通道发布+回滚演练实测：publish 4/4 verified，检索命中，
rollback 4/4 rolled_back，目标端 PG is_enabled=false、ES is_enabled=false
- 前端 A·Data-console 风格全站统一，120 用例通过
- 门禁：go vet / go test 全包通过，gofmt 干净
|
2026-09-30 10:54:06 +08:00 |
|