8 Commits

Author	SHA1	Message	Date
姚章浩	513aa9e6f5	fix(library): 收紧恢复派发真实绑定与同事务授权 ... 为什么：Astra 复核证实五组实现缺陷——正式装配缺 scope/快照且来源与 before-image 混用；激活撤销不在 CAS 事务内、lease 用事务起始时间；激活只接受任意字符串且撤销可 被 SQL 重置/删除；准入忽略绑定冲突与 prepared 矛盾、收尾只看当前 plan；prepared 已 提交但 mark-intent 未落盘时被误判 legacy。 改了什么： - 绑定来自原锚点（scope/来源快照/backup/实例/目标指纹/索引 UUID/恢复投递），每次 重建都实时重读目标身份并与冻结值比较； - activation 行锁与 CAS 同事务，lease 用 clock_timestamp()，同事务核对 job/operation/ attempt/维护窗口/恢复 queue 与 operation，同 effect 换 plan 摘要拒绝； - 激活消费带摘要的证据文件（writer 退出+排空、目标/治理库身份、有效期），撤销终局， down 在 activation 有行时拒绝； - 前置/收尾共用权威窗口全集，绑定冲突与 prepared 矛盾零写 held，合法 dispatching+ 精确 marker 仍可确认； - prepared 无 mark-intent 仅在绑定一致且无矛盾时补同内容意图，旧无台账意图仍 held。 验证：真 PG 锁等待覆盖撤销先胜/CAS 先胜/等锁跨租约/错锚点/plan 别名/恢复投递； COMMIT 已到服务端但回包丢失与未决事务分别读回；真 ES+PG+对象存储的 DS01 用例全部 通过；go test ./... 全绿。未迁移正式库、未部署、未激活。	2026-11-02 18:09:26 +08:00
姚章浩	0a7c9f8510	feat(worker): 接线恢复派发台账并按激活登记启用 ... 为什么：派发协议只在 worker 里装配却没人接，就等于只写了 store mock。同步失败的自动 rollback 与维护恢复都必须拿到同一份台账； baseline 只读装配永远不传，避免建基线顺带获得恢复写许可。 开关 LIBRARY_RESTORE_DISPATCH_V2 默认关闭，且只是"允许装配"： 治理库没有该目标的未撤销激活登记时，Prepare/Acquire 直接 fail closed。 验证：cmd/worker 单测覆盖默认关闭/显式开启/无台账三态； v071 真 ES 用例里自动 rollback 与手动恢复走的是同一个 Restore。	2026-11-02 16:28:01 +08:00
姚章浩	8d838d9cb4	feat(library): 整库发布身份、写集合与收尾边界 ... 执行时真实时钟与持久授权回读（撤销/过期即停并保留预备份）、写集合写前落盘、 租约与 attempt 身份、恢复队列与原发送身份分离、成功收尾必须释放维护后再登记终态。	2026-11-01 11:35:10 +08:00
姚章浩	d0c6d57283	fix(storage): 按提供方选择整库对象寻址方式	2026-10-31 06:22:20 +08:00
姚章浩	e6472b0ec6	feat(library): 云测试发布目标接入的角色分离、快照搬运与图谱门禁 ... 为什么改：发布执行链是"与目标同机"假设写死的（本机 docker.sock、本机 drain.json、 本机 Redis/PG），把目标换成云测试不能只改展示 URL；直接搬整套 worker 又会抢走 本机封存/QA/周报队列并按本机配置写错目标。所以先把"谁消费哪段队列"变成显式角色， 再补齐跨主机搬运与目标侧门禁。 角色（LIBRARY_WORKER_ROLE=full/release-executor/capture）不只影响 handler 列表， 还决定是否拥有 DDL（release-executor 只读校验迁移版本，落后即拒绝启动）、 收拾哪些 library_jobs.kind、是否跑 release 接管扫描、是否起 scheduler/QA/周报/探测。 capture 保留本机原有全部业务；release-executor 只挂 sync/restore/recover/baseline。 快照跨主机：新增内容寻址的 bundle（版本清单先落、blob 按 sha256 命名、清单最后 Link 作提交点），pack/unpack 幂等且拒绝覆盖与同名不同内容；执行器使用前仍逐 blob 重算 sha256，因此传输不可变有两道证据。 目标侧门禁：目标知识库 graph_enabled=true 时拒绝发布（发布只写 PG/ES/OSS，不写 Neo4j；未知也拒绝），只读检测、不改目标配置、不做图谱迁移。 云端入口：新增 drain 感知的 ingress 闸门（建连超时与读超时分离，半关闭单向传播， SIGTERM 排空后写 drain.json 并 exit 0/2）、compose 叠加片段（app 不再发布端口、 frontend 与 adapter 的入口收敛到闸门、指向真实网络 weknora-test-v071-network）、 执行器启动脚本与治理 PG 反向隧道脚本（默认 unix socket，不占 TCP）。 验证：deploy/cloud-test/test_gate.py 13 项全 PASS（含 12 秒静默流、半关闭、2MiB 完整、 排空 exit 0/active_at_close=1、排空超时 exit 2、上游不可达不挂住）；go test 相关包全绿； scripts/ci_checks.py 16 项全部 success（EXIT=0，1241 用例通过/0 失败/191 已声明可选集成跳过）； 云测试只读预检 17 项 / 6 FAIL，FAIL 项即当前部署缺口（无闸门、app 仍发布端口、 adapter 与 frontend 仍直连 app、云端归档根未建），未部署、未改云端任何状态。	2026-10-30 18:38:38 +08:00
姚章浩	98294b9583	fix(library): 统一执行身份、终态收尾、准入与数据身份 ... why：审计 19 项（12 P1 / 7 P2）来自同一批根因，逐点试错会把协议撕成十几份： · 意图与执行混为一谈（F01/F15）：`library.sync:<scope>:<快照>` 是终身幂等键， A→B→A 的第三次发布拿到第一次的历史成功作业，什么都不做； · 版本行既是实体又是事件（F02/F09）：主键只由 (kind,scope,快照) 决定、写入是 upsert，第二个作业覆盖 `source_job_id`/`evidence`/`created_at`； · 接管没有代次（F13）：两个 worker 都能认领同一 pending 作业，失租的旧执行还能 写业务状态、释放别人的维护锁； · 早退与终态没有统一政策（F03/F04/F05/F06）：半写窗口的前置检查失败会重新开门、 服务起不来也照样开入口、journal 终态后收尾不可重建、恢复成功不回写 current； · 数据身份与准入各写一套（F07/F08/F14/F17）：接管丢了复用语义、全库搬运不改 location_hash、通用入口可造 library.* 作业、目标模型从没被问过； · 存储/容量/UI/CI 判据各自为政（F10/F11/F12/F16/F18/F19）。 what：按批准的一套协议集中实施（详见 handoffs/release-consolidated-implementation/ current-contract.md）： · operation（一次明确意图）/ attempt（epoch 代次）/ 不可变版本事件 / current 指针； 治理库迁移 76，只动治理库，不碰 WeKnora Schema/源码/镜像； · 所有业务状态、阶段、版本事件、维护锁写入带 epoch 守卫（失租代次写不进去）； 心跳失租立刻取消 handler； · 半写窗口早退保持关闭；服务未全部健康绝不开入口；journal 终态可从持久事实重建 收尾；恢复成功登记 recovery 事件并推进 current； · worker 在动维护前核对业务行/kind/scope/队列关联；通用入口拒绝 library.*； · 全库搬运重算 location_hash 并与文档级导入共用实现；接管消费写集合的复用决定； 发布前核目标实时模型契约、容量门禁前置； · 存储保护闭包改为全量依赖、类型只认显式登记、保护未知则不出可删候选； · 页面核 HTTP 状态与结构、恢复纳入轮询、Wiki 差异覆盖标题/摘要/父级。 how：`make verify` rc=0（16 项必需检查全绿，含 go test 全量与前端 485 例）； `go vet ./...` rc=0；`npx tsc -p tsconfig.json --noEmit` rc=0；逐项负例见各包测试 （F03/F04/F08/F12/F13/F14/F16/F18/F19 都有先红后绿记录）。 未执行：治理库迁移到任何已有库、真实 PG/ES/S3/WeKnora 集成、故障注入、部署。	2026-10-30 16:14:54 +08:00
姚章浩	c27a0c14cc	fix(library): 基线契约读目标真实 schema/模型，演练标内容风险 ... 真实演练暴露两个只有跑起来才看得见的问题： 1. 归档要求完整兼容性契约（v0.7.1 / schema 74 / elasticsearch_v8 / 1024 维 / 映射摘要），而基线装配只填了 embedding 与映射，捕获被 "unsupported snapshot compatibility contract" 拒绝。 现在 schema 版本读目标库 schema_migrations（dirty 或版本不符直接拒）， embedding 优先读目标库模型绑定（本机目标 models 表为空、引用悬空， 此时回落部署声明并说清来源），版本/引擎用受支持栈常量，映射取目标当前值。 2. 演练在"还没写目标内容"时就允许 restore_blocked=false 的窗口以 blocked 收尾， 写出 content_risk=false + restore_blocked=true 的非法 journal（恢复器拒绝加载， 目标停在停机态）。现在写 canary 时先 MarkContentRisk，allowRestore 按 "没碰内容 ⇒ 安全恢复；碰过 ⇒ 必须恢复并校验通过"。 另外给演练工具加 -recover：只把非终态窗口按原运行状态恢复，用于演练失败后 把目标救回来（不改治理记录）。 验证：库内模拟真实目标不可得，契约分支用真实 kgseal 演练覆盖： snapshot 5cb945e6… 捕获 143ms → 基线一致 → canary 后校验如预期失败 （knowledges 1 行摘要不一致）→ 恢复后校验通过 → 窗口 succeeded、服务与入口恢复。	2026-10-29 19:41:12 +08:00
姚章浩	a42b101a7b	fix(library): 基线崩溃续作与维护原状态保留 ... 父审发现三处会让目标卡死或状态对不上实际入口，逐条修： 1. 登记成功但没来得及收尾：崩溃重入会撞上"已有生效版本"直接失败， 目标留在维护里、占用也不释放。现在按「本作业+同一快照」识别为自己的 版本，只做收尾（恢复服务/开入口/释放两把占用），不重新捕获、不重写； 别人的版本仍然拒绝。捕获完成但登记失败则明确失败并写"未对目标写入"。 2. 重入覆盖原运行状态：崩溃时服务已被停住，再读一次只会读到 stopped， 写回去会让恢复阶段永远不启动写入者。AcquireInstance/LibraryMaintenance 在 owner 相同的重入时保留已持久化原状态；新作业接管已释放窗口用自己的观察。 真实 PostgreSQL 集成用例覆盖（先红后绿）。 3. 版本登记移进维护窗口：捕获/校验/登记要么一起成立、要么目标原样恢复； 记录失败时窗口已开放，治理状态同步释放，不再"显示维护中、实际已开"。 索引映射读不到时拒绝登记，不再用空摘要写证据。 顺带： - 基线窗口统一收尾抽成 settleBaselineWindow，四种结局各有测试（成功/健康失败/ held 保持维护/已恢复则释放），并用真实 DB 用例证明 baseline 与 sync/restore 共用写互斥、幂等重试不产生第二个作业。 - 新增 cmd/librarydrill：维护隔离 → 整库预备份 → 一致性校验 → canary 漂移检测 → 按预备份恢复 → 逐类复核 → 按原状态恢复服务。用与 worker 相同的 LIBRARY_* 配置，绝不触碰封存源。 - 目标/预备份/维护栈装配收成 internal/librarystack 一份（worker 与演练共用）。 验证：go build/vet/test 全过；TEST_DATABASE_URL 指向临时 PostgreSQL 跑 TestMaintenanceReentryKeepsOriginalServiceState（修复前失败：got app=stopped） 与 TestLibraryWriteMutexCoversBaselineJobs；本地门禁 15/15。	2026-10-29 19:08:58 +08:00