Weknora/knowledge-governance
4
0
Fork 0
Code Issues 2 Pull Requests 5 Actions Packages Projects Releases 1 Wiki Activity
151 Commits 11 Branches 57 Tags
87f97a2f9bd697fdeda952efbf178d79f78fc5d4
Commit Graph

10 Commits

Author SHA1 Message Date
姚章浩 533db535f1 feat(qaops): 接入真实模型补缺任务与总表看板
build / build (push) Successful in 1m12s
Details 
按已确认需求提供独立安全模型配置、真实探测、正式字典字段评估与原问题译中，持久批次支持只补空白、暂停恢复、有限重试、幂等和逐字段依据。覆盖固定规则、本地语言、组织关联与主表有效看板共用治理侧读模型，保留源生产和冻结历史。

验证：完整 make verify 退出0，702项Go与329项前端通过；默认118项外部/隔离集成明确跳过，另跑完整镜像及组织隔离PG竞态。12并发、输入漂移、过期租约、暂停/恢复及有限重试通过。用户授权的百炼 deepseek-v4.1-flash 完成真实后台与浏览器评估/翻译；552行、16列、11块看板及完整PNG、独立配置页测试/保存、重开恢复和零JS异常通过。仅非业务样本外发，自动处理关闭，原payload不变。

上线前治理库已做导出快照原生备份并真实恢复，60表行数与17个QA表内容哈希一致；不修改DobotAI生产或隧道。本提交时尚未部署，线上验收须独立完成。
 2026-10-19 14:29:49 +08:00
姚章浩 6e67034fbd feat(qa-ops): 交付十一项统计看板与完整图片导出
build / build (push) Successful in 1m10s
Details 
以治理库单一只读事务分开聚合累计、自然周、截止月及当前通讯录使用分母；浏览器不再读取全量长答案来构建看板。

新增迁移52与普通worker周质量冻结，保留真实冻结时点、规则和标量贡献；缺少当时快照留空。提交后冻结头与贡献不可修改、删除或追加；只读接口保留管理员、固定租户、严格JSON与输入冲突保护。

已验证：make verify退出0，686个Go用例和305个前端用例通过，必需跳过0；镜像与组织隔离PostgreSQL竞态回归退出0。真实治理副本浏览器核对第41周累计1885与新增471、十一项和完整PNG下载，390px无外溢、JS异常0；明确模拟503后不伪零且重试恢复。没有修改DobotAI原始问答、真实区域规则或生产发布门禁。
 2026-10-18 23:26:55 +08:00
姚章浩 3e7fcce0b1 feat(qa-ops): 持久本地问答副本与安全答案预览
build / build (push) Successful in 1m11s
Details 
新增迁移50与每5分钟/手动持久同步，API只读本地；同步失败保留、权限阻断、租约与质量失效原子激活。
保留全量稳定分页/固定列，已存质量批量读取，元数据不反复解压长答案；详情安全Markdown与原文。

已运行整仓 make verify、源与副本隔离PG -race、真实只读源及隔离浏览器。
实际同步2525条；固定窗口640条本地中位1.46秒，对照直接源33.10秒。
停worker、缺源凭据、重启API后仍可查询；未更新8088，未修改生产原问答。
 2026-10-18 19:10:47 +08:00
姚章浩 013ce4a24e fix(version): 补全开发快照记录与同步交付闭环
build / build (push) Successful in 1m3s
Details 
收录 main、注释开发快照和完整运行 SHA；开发说明绑定原提交，补记 0.1.1–0.1.25。
进行中同步按仓库合并，完成后重新执行；启动入队，部署脚本读回版本证据。
开发快照独立于正式标签与 Release，既有冲突标签不移动。

已运行：整仓 make verify，Go 673 通过、前端 274 通过，92 个已声明可选跳过，必需跳过 0。
隔离 PostgreSQL 重复同步队列用例及 -race 通过；未更新现有 8088、未修改生产问答。
 2026-10-18 18:11:49 +08:00
姚章浩 cc4906b6a9 feat(qaops): 接通网页通讯录持久化同步与后台接管 2026-10-17 17:36:07 +08:00
姚章浩 4cb5110845 fix(version-history): 页面链接改走公网 origin（抓取仍走内网）+ tag 补链接
build / build (push) Successful in 1m1s
Details 
现象（主人反馈）：点「查看提交」打开是空白页。原因：链接用的是**抓取用的内网地址**
（`http://192.168.50.223:3000/...`），内网外的浏览器到不了；而公网地址
`https://gitea.zheromiku.top/...` 实测 200。另外 tag 证据里**根本没有 url**，
页面渲染出空 `href`，点下去像"没反应"。

修复：

- 新增 `VERSION_HISTORY_LINK_ORIGIN`（页面链接 origin，公网；留空 = 与抓取 origin 相同）：
  抓取仍匿名走内网白名单地址，**给人点的链接**用公网 origin 拼 —— 两者本就不该共用一个地址；
  校验必须是干净的 http(s) 绝对地址。
- tag 证据补 `url`（`<link origin>/<repo>/src/tag/<name>`），并在前端**没有链接就不渲染**该按钮。
- 测试：客户端（LinkOrigin 生效 / 未配时退回 / 非法拒绝）、规则（tag 链接写入证据 / 无基址不编链接）、
  前端（有链接才渲染「查看 tag」）。

验证：make verify 15/15；真实链路重同步后库里 commit_url = `https://gitea.zheromiku.top/...`（200）、
release_tags 带 url。
 2026-10-14 11:06:13 +08:00
姚章浩 0974d8dfa2 feat(version-history): 「版本记录」页 —— 追踪远端 main 全部提交（只读 + 管理员手动同步）
build / build (push) Successful in 57s
Details 
按已确认的契约实现（口径见 docs/VERSION_HISTORY.md）：

- **版本号口径（只给有证据的）**：注释 tag + tag 指向该提交 + 该提交内 CHANGELOG 顶部三者一致 ⇒ 正式版本；
  tag 之后的提交按 `<主>.<次>.<自该 tag 的提交数>` 显示开发号（与 scripts/version.py **同规则**）；
  证据不足 ⇒ 「历史提交 · 短SHA」+ 原因码，**不补造版本号**。完整 SHA 是唯一身份、版本号不是唯一键
  （tag 之后两条并行分支各自的第 1 个提交都算 0.1.1 ⇒ 两条都保留，用短 SHA 区分）。
- **迁移 000046**：version_history_commits（提交记录，主键 repo_key+commit_sha）+ version_history_sync_runs
  （同步状态）。快照 = 一次同步：抓完并与 X-Total-Count 对账通过才切换；失败不切换快照、不清空历史、
  last_success_at 不动（页面显示"上次同步失败（原因）· 仍展示上次成功数据"）；「同步成功」≠「历史完整」。
- **只读客户端（匿名，不使用任何凭据）**：白名单 origin + 固定仓库、拒绝任意 URL 与跨主机重定向、
  响应上限 5MB / 超时 15s、仅 5xx/429 退避重试（最多 3 次）；逐页抓到短页为止；每次全量扫 tag
  ⇒ 旧提交后补的 tag 会更新既有记录（不新增第二行）。
- **接口**（三个都登记进 api/openapi.yaml）：GET /api/v1/build-info（viewer）、
  GET /api/v1/version-history（viewer；游标绑定快照，过期返回 409 cursor_expired；不返回伪造 total）、
  POST /api/v1/version-history/sync（admin；并发同步复用同一作业，靠 IdempotencyKey）。
- **「当前运行」只认精确匹配**：产物注入的完整 SHA 命中某条记录才标该条；开发构建显式标注"开发构建"；
  没有可用标识 ⇒ "当前运行版本未知"；**不拿最新 main / 最新 tag 顶替**，CI 成功不等于已部署。
- **前端**：一级菜单第 5 项（版本记录）+ 时间线页面（全部/正式/开发/历史四段筛选、正文展开、
  加载更多、760px 单列无横向溢出、提交正文与变更记录按纯文本渲染）；无打 tag / 发布 / 部署入口。

新增配置（留空即未接线，页面降级）：VERSION_HISTORY_GITEA_BASE_URL / _REPO / _ALLOWED_ORIGINS /
_HTTP_TIMEOUT / _MAX_PAGES。

验证：`make verify` 15/15 success（tests-go 578 通过 / 0 失败；tests-web 209 通过 / 0 失败）；
新增 Go 用例 30（版本口径与图遍历 12、客户端守卫 6、同步编排 5、接口 7）；前端新增 18（组件 10 + 客户端 8）；
真实仓库匿名快照拉取（`VERSION_HISTORY_LIVE_BASE_URL=… go test -run TestLiveSyncAgainstRealRepository`）：
抓到 113 条与 X-Total-Count 一致、v0.1.0 是注释 tag 且目标与 `git rev-parse v0.1.0^{commit}` 一致、
开发号逐个等于 `git rev-list --count v0.1.0..<sha>`（正式 1 / 开发 22 / 历史 90）。
 2026-10-13 19:40:19 +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
姚章浩 63f3b2c503 feat(governance): policy-driven ingestion from catalog annotations 
Annotation in 来源与目录 is now the only import decision surface:
- migration 000033: catalog_import_intents (durable, rescan-proof per-file
  intent with locator snapshot + fetch lifecycle), source_items.policy_state,
  planned publication state, ui_setting_revisions.ingestion_concurrency
- marking fans a folder decision out to per-file intents, materializes
  versioned items, reuses already-verified local bytes (compare, don't pull),
  and plans one publication per routed KB; blocked retires planned rows
  while live publications stay untouched (需下架 shows in the KB diff)
- artifact.fetch worker lane (scripts/artifact_fetch.py): DingTalk export
  tree/live box API, AList /api/fs/get direct download with SSO-redirect
  fail-closed, PP ledger via locator hash; content-level dedupe on sha256
- 开始处理 promotes planned->pending inside the claim-time concurrency budget
  from system settings; claims enforce it in SQL
- monitor overview rebuilt as knowledge-base diff: planned/needs_removal per
  KB + fetch pipeline summary; frontend lanes 待入库/需下架 replace the
  deprecated snapshot change-set confirmation
- spool: images (png/jpg/gif/bmp/webp) accepted, ppt/pptx rejected in favour
  of PDF twins; DingTalk PPT resolves its converted PDF pair
 2026-09-30 10:54:07 +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