Hub r4 进度

第一个里程碑的进度和已定的决定，由集成者记录。目标、阶段和完成定义见 Hub r4 简报与 Hub r4 架构；各包自己的决定、限制和对其他包的需求写在包的 README 里（架构第 10 节）。这里只记做完并核实过的事：写明跑了哪些命令、结果如何；没跑的检查不算通过，Linux CI 上跳过的用例不算通过，合成环境里的通过不代表真实系统上的结果。

决定编号对照（2026-11-03 起）

所有者 2026-11-02 定了合线时的统一编号（决定 136），2026-11-03 补全（决定 137）。本页、仓库里的引用和通用模型（第 36 版）都已改用新编号；Git 历史、GitHub 上的 PR 与 issue 文字和 Circle 仓库里的引用仍是旧编号，按下表换算。

本页编号	原来的编号	内容
1–70	1–70（不变）	两条线共有的决定
71–120	私有集成主干的 71–120	主干同期的决定，本页只记脱敏摘要
121–135	本仓库原来的 74–88	原 74→121、75→122、76→123、77→124、78→125、79→126、80→127、81→128、82→129、83→130、84→131、85→132、86→133、87→134、88→135
136、137	所有者的决定	统一编号的来源；主干与本仓库在此汇合
138–143	本仓库原来的 89–94	原 89→138、90→139、91→140、92→141、93→142、94→143
144 起	—	新决定

没有改号（文字带校验和或需另行授权，引用的仍是旧编号）：

位置	文字里的旧编号	原因
hub/records/migrations.ts 迁移 7 的注释	decision 78（即 125）	已应用迁移的 SQL 带校验和，永不修改
contracts/test-fixtures/sync/v1/README.md	decision 89（即 138）	冻结的 v1 兼容样例目录，字节不变
docs/design/circle-design-system/README.md、assets/Logos/README.md、components/bundle.css	决定 82 / decision 82（即 129）	与 Circle 共用的设计规范，字节由 docs/design/circle-design-system.sha256 固定
hub/server/console/style.generated.ts	decision 82（即 129）	由 bundle.css 生成，随它不变

阶段清单

• 第 1 阶段：合约补全、records、refs、rules、platform、docs、jev（2026-10-22 完成并提交）
  • 退役旧的任务与审批服务器实现（00a5022）
  • 由通用模型第 5 版生成合约（37f4dee）；任务包、产品、表的格式和跨包接口（hub/ports.ts）
  • 架构简报与模型元素查看器（57f5c32）
  • records、refs、rules、platform、jev 各自经两位独立复核和一轮修复；docs 已改写并经复核
  • 本机 macOS 完整运行：npx tsc --noEmit 无错误；node tools/gen-contracts.ts --check 与模型一致；合约 196 项、records/config/testing/rules 267 项（1 项跳过）、refs 295 项、platform 155 项、jev 220 项、scripts 下的真实系统脚本 40 余项、文档检查 50 项，全部通过
• 第 2 阶段：knowledge、runs、connectors（已合并；全量测试记在 2026-10-22 的记录里）
• 第 3 阶段：server、packs
• 第 4 阶段：验收与集成，对照模型独立复核整体（验收场景、独立的结论参照和变异测试已合并；对照模型的整体复核记录在 docs/hub-r4-model-review.md，2026-10-23 合并）
• 第 5 阶段：持久部署与真实系统脚本（本机持久部署在跑，只监听本机；真实系统的只读脚本在 scripts/real/）

每个阶段结束时，集成者在本机 macOS 上把全套检查完整跑一遍，记下命令、各项计数和跳过的用例：CI 在 Ubuntu 上运行，需要 macOS 或 libpq 的用例（包函数沙箱的断网、钥匙串、launchd、备份恢复与部署）在那里跳过，不能作为这些路径的证据。

记录

2026-10-21

• 旧的任务与审批服务器（截至 0.2.0）整体退役：HTTP API、监督进程、worker、管理命令、开发栈、连接器、harness 适配器、包和测试都已删除（00a5022）。旧代码只在 Git 里（ca66002），复用时用 git show 读取后改写，不导入。
• 合约：contracts/model.json（第 5 版，73 个元素、53 个词表轴）和 contracts/codes.json，由 npm run gen:contracts 生成 contracts/generated（37f4dee）。
• 架构简报 docs/hub-r4-architecture.md 与 tools/show-element.ts（57f5c32）。
• 文档：AGENTS.md、两份 README、CONTRIBUTING、SECURITY、兼容矩阵和 CI 按新设计改写；旧的简报、进度和交接文档标为历史，旧的设计篇标为已被取代，均未删除。待复核。

2026-10-22

• 文档按两位复核者的意见修订，待集成者复核：模型、Circle 和凭据的规则与模型对齐；进度和所有者的决定由集成者记录，各包的决定写在各自的 README；下面的决定逐条写明来源，来源不在仓库里的标“待确认”；写清生成合约的来源、Linux CI 跳过的路径和 libpq 前提。历史页 harness-adapters-brief.md 里一处本机目录改写成“单独的工作树”，正文别处未改。
• CI：每个测试任务在任务摘要里列出计数和每个跳过的测试，一个测试都没跑的任务判失败，所以 tests/acceptance 出现之前验收任务是红的。新增文档检查 .github/checks：站点能提供的链接、词表表格与生成物一致、待定项的已定与暂缓计数、决定写明来源、没有本机路径。本机核实：修订前 node --test ".github/checks/*.test.ts" 在文档上报出 23 处站点打不开的链接、3 处待定计数、9 条没写来源的决定、1 处本机路径和 4 处 CI 缺口；修订后 50 项全部通过；npx tsc --noEmit -p .github/checks 无错误；npm run test:acceptance 现在退出 0、0 项测试，计数步骤据此判失败。CI 本身尚未在 GitHub 上跑过。
• 真实模型评审（所有者配置的千问 qwen3.7-max，经 Otty 里真实的 Circle 客户端连已部署的 Hub，Hub 只经 MCP 工具与模型交互）：
  • 第一份评审文档的前 15 例（共 62 例）：16 次工具调用，3 次提交。第一份因一处引用解析不出被整份拒收并给出修正说明，修正后受理；模型按要求只评 15 例，其余 47 例声明跳过。回执如实写“覆盖：不完整：已查 15，共 62”，未知 6，其中一处是缺陷系统里查不到文档标题里的编号。抽查发现：模型找出了一处真实的复制错误（只含 IP 的用例，期望结果却写着显示 DNS），其余发现可信，但把一类含糊的期望结果（“设备正常”）漏了。
  • 注入缺陷度量（评审对象是 16 例的副本，注入 5 处，标准答案在注入时写下，脚本 scripts/real/inject-defects.ts 与 score-injection.ts）：Hub 自己的字面检查查出 2/2（期望结果缺失、重复用例，重复的两份都被标出）；只有模型判断才看得见的 3 处，模型发现 1 处（期望结果与标题矛盾），漏掉期望含糊（写成“成功”）和用例放错分组。非注入用例上的 3 个条目有发现，全是原文档里本来就有、没改过的评审里也提出过的问题，没有新增误报。这是单次运行、单一模型，不构成统计；它说明初评的召回要靠独立复核来补。
  • 观察：千问有时把 submit_result 的 items 写成字符串，Circle 在客户端就拒绝，第一次尝试在这个错误之后没有提交就结束了，提示里写明“items 必须是数组”后第二次完成。Hub 不为这类模型习惯放宽合约。
  • 独立复核（case-review-verify）：环境配置里只有千问一个家族，Hub 不把同一家族认作独立，所以复核用所有者 Circle 里配置的 GLM（glm-5.3，驱动脚本新增 --endpoint-from circle，由 circle 终端写、监督者合并；密钥只由脚本在运行时读，屏幕上只有协议、主机和长度）。同一次真实 Circle 客户端流程：对初评的 7 条发现，6 条证实、1 条部分正确（严重程度下调）、0 条推翻；用七个探针补出 7 条初评遗漏的发现，其中有放错分组的用例（block_structure_mismatch）；含糊的期望“成功”写在一条边界用例缺口的说明里；结论 PARTIAL、等级 P6，与处置一致，Hub 认作独立（复核要求项满足，未知 0）。两轮合起来，5 处注入缺陷都被某个环节发现：Hub 字面检查 2 处、千问初评 1 处、GLM 复核 2 处。仍然是单次运行，不构成统计；真实用例发给了 GLM 的服务商，这是所有者批准的评审端点。
• 回执文字两处修正（提交 2748f58）：“未完成”后注明原因（模型声明跳过、提交未覆盖各几个），避免把声明跳过读成漏做；“部分”说明区分预算截掉的内容和字段长度上限截短的内容，不再把 200 字的字段上限说成整段回答的字符预算。
• 新能力在真实数据上的第一轮（已部署的 Hub，知识库已按新的产品包重新同步两条真实版本线（下面称甲线、乙线），用例索引在里面；同步没有调用判断服务，见下一条）：
  • 质量看板（乙线的一个 FAMX 构建，下面称构建乙）：60 个（版本线，模块）分组，用例合计 84,656 个，无期望结果 1,569 个（1.9%）、只有含糊期望 5,161 个（6.1%）、反向用例 6,534 个（7.7%）；各分组按阈值给出提示；其中 58,162 个用例没有解析出命令，作为未归位条目也计入合计。
  • 回归范围与维护巡检（甲线里相邻的两个构建，下面称甲1、甲2）：回归范围 18 个用例、7 条没有用例的变更路径（记为未知）；维护巡检 15 个用例，其中 7 个所在命令已删除、8 个所在命令的定义有变更。独立核对：另写的脚本直接读两个构建的命令树 XML 算出的差异（新增 10、删除 1、修改 1，共 12 条路径）与 Hub 的影响视图（删除 1、修改 11，共 12 条）逐条路径相同；分类口径不同：Hub 按路径上条目（定义和手册里的行为）的增减判断，手册里已有说明的新命令算“修改”，脚本只看命令定义，算“新增”。回归范围的范围不受影响（新增和修改都进范围），但报告里该写“新增命令”的地方写成了“修改”，已记下待改。
  • 质量看板的独立核对（构建乙用到的 1,332 份用例文档，另写的计数脚本 scripts/real/gold/cases.ts 直接读文档里的用例节点，不看 Hub 的任何结果）：脚本只实现“带资源标签的节点是用例”这一条规则，只能数其中 949 份文档（另 383 份没有带标签的用例节点）。按文档逐份比较用例数、无期望数、含糊数、反向数：641 份完全一致；277 份 Hub 的用例更多（Hub 的规则是“带标签或按团队模板标记的节点”，多出来的是按标记识别的用例，符合预期）；31 份有差别，原因都是两边规则的写法不同，不是计数错误：10 份是反向用例的标签写法（例如“负面测试”，Hub 的标签规范化会归到“反向”，脚本只认精确写法）；其余 21 份是嵌套结构（用例下面再嵌套带标签的节点，或步骤下面再有步骤）两边的处理不同，每份差 1 到 4 个用例，占比很小。没有发现 Hub 少数或多数的错误；这一轮的限度是脚本没有实现“按标记识别”的规则，所以总数没法逐项对上。
  • 追溯矩阵（构建乙）：只列出 1 个已修复缺陷、未追溯；用例视图被 15 MiB 的视图上限截断（编号较大的缺陷对应的用例没进视图），回答里如实写了“视图被截断”；同时运行被绑到了一个无关的构建（甲线的最新构建）。修法见任务页 index-fields.md。
  • 回归范围对跨版本线的一对构建（甲2 到构建乙）失败：投影函数在沙箱里用了约 790 MB，超过 256 MB；修法同在 index-fields.md（影响视图瘦身）。
• 数据外发事件（2026-10-22，已止损，待所有者知悉）：判断服务（api.typesafe.ai）的密钥 11:19 起在密钥库里，所有者批准发给它的只有手册片段；而知识同步把所有没有路径的条目都交给它归位。11:19 到 11:33 的那次同步里，54 个构建的生产记录显示每个构建约 290 个片段（placement.spans）发给了判断服务，其中除手册片段外还有发布说明里的缺陷条目（内部缺陷标题）；15:00 前后的再次同步在读完用例文档、开始归位时，监督者看到同步进程有到该服务的 HTTPS 连接，立即中止进程，并把密钥文件移出密钥库（放在数据根的 set-aside/ 下，可原样移回）。第二次尝试里发出了什么、多少，没有记录可查（没有判断记录落库）。现在 Hub 没有判断服务的密钥，同步不做模型归位，没有路径的条目留在根下标为未归位。根因的修法已写成任务页 jev-optin.md：生产器声明才能把条目交给判断服务，默认不交；在它做完、所有者重新决定之前不恢复密钥。
• 工作方式（所有者 2026-10-22 的指示，决定 14）：停掉全部工作流；代码由其他终端写，监督者监控结果和安排工作。已为各项任务建了工作树和任务页，见交接页。
• 全量测试（hub-redesign 的提示 ebab205，本机 macOS，node --test 全套）：3,308 项，通过 3,302、失败 2、跳过 1、todo 3。两处失败是 packs/product/famx/functions/cases-integration.test.ts 里对提示语的断言还写着旧措辞（“未归位 N 个”），代码里已经是“未归位条目 N 个，标在根下”；单独运行同样失败，与机器负载无关；已列入 candidates-times.md 的收尾项。todo 的 3 项里有 template-gap 的 author_samples_only 标记（runs-engine 还没有把 publishCheckMarks 用到主张上）。
• 所有者对五个待定事项的答复（2026-10-22 晚）记为决定 15 到 19：Jev 属于 bot 一侧、转自动化做成设备管理包、评审只提出问题、用例节点默认规则取“标签或标记”、构建候选要带制作时间和基础构建。对应的任务页：no-judgment-in-hub.md、engine-readings.md、union-case-rule.md、candidates-times.md；设备管理包的设计由监督者写在 docs/hub-r4-device-pack.md，设计定下来以后再拆实现任务。
• 设备管理包第一阶段的核心已合并（不接触设备）：租约（取得、到期接管、围栏令牌、按数据库时钟、孤儿回收）、start_run 接线和失败补偿、管理员命名文档（circle-hub doc put/list/show）、管理员租约命令、续期和释放按血缘持有，以及台架清单、台架事实和匹配函数。模型因此改了两处，需要所有者知悉：D04 加了“预订类租约按血缘持有”，动作种类加了“租约”（设备管理包设计第 4 节）。转自动化的编译半边只写了需求（hub-r4-compile-design.md），等所有者给函数合约、执行格式和台架拓扑。
• 决定 15 到 19 对应的改动都已合并：Hub 里没有判断服务；引擎三处读法；用例规则默认“标签或标记”；构建候选带制作时间和基础构建；FAMX 产品包按真实的锚点写法读修复缺陷列表；维护巡检的结论写出字段差异；追溯写明缺陷系统。
• 真实运行（已部署的 Hub，Otty 里真实的 Circle 客户端）：
  • 用例评审：第一份评审文档（62 例）按用例顺序分两段，千问初评、GLM 复核，四次运行都已受理。提交大多先因格式被拒（复核的一段 9 次提交错 7 次），随后各技能加了完整的提交样例，还没有部署验证。整体结论（各段取最差）和中文终稿报告没有做。
  • 缺陷转用例：千问为一个缺陷起草了用例，提交受理（25 次提交里 17 次先因格式被拒）；没有和已有的回归文档比对。
  • 只出事实的六项能力，用真实 Circle 客户端加脚本化模型：证明整条路和 Hub 在真实数据上的结果，不涉及模型质量。模板查缺 5/5（只核了用例数）；回归范围（同一版本线）28/28；维护巡检 18/18；用例定位（一份文档）21/21；质量看板的合计与独立计数一致；追溯 3/40，不符的多数是场景的匹配写法错了（2026-10-23 已修）。
  • 跨版本线的回归范围：影响路径 105 条，命令树差只有 30 条，多出来的是两条版本线手册里行为条目的变化。

2026-10-23

• 所有者要求先核对偏差。集成者对照计划、设计文档“评估与方案”的结论、架构第 2、6、6a、6b、10 节和 AGENTS.md 核对了一遍：方向没偏，偏差和处理如下。
  • 6b 的验收没做全：追溯没有按缺陷系统里的状态区分已关闭的缺陷；用例定位只核了一份文档；模板查缺没做蜕变核对；缺陷转用例没和已有的回归文档比对；评审第 6、7 步没做，注入缺陷少两类；跨版本线的回归范围口径不对。任务页 traceability-closed.md、review-report.md、scope-commands.md、accept-gaps.md。
  • 规矩：54 个合并提交里 28 个没有签名，以后合并一律加 --signoff；租约操作的五个值是手写的枚举；一处样例地址不在 192.0.2.0/24；测试和文档里有几个取自真实系统的编号和真实版本线的构建名（分支没有推送；文档里的已改成合成值，测试里的见 hygiene.md）；hub/rules/check.ts 对没声明档的旧包按依据回退（hygiene.md 去掉）。AGENTS.md 和架构第 2 节里的工作方式已按决定 14 改写。集成者解过两处合并冲突，也写过草稿目录里的两个核对脚本，和决定 14 不符，以后都交给终端。
  • 设计文档结论里的第三个闭环（运行结果沉淀回知识）没做：简报把它列在这个里程碑之外，七项能力也不需要它。
  • 暂按稳妥的默认处理、待所有者确认的三件事：19 份含凭据内容的用例文档继续只保留、不进索引；已有的未签名合并提交不改写历史；编译半边等所有者的三样输入。（更新：第一件已被决定 20 取代；第三件集成者 10-23 上午按目标“完成全部开发工作”先在合成合约和台架上开始了（db9b2d7），当时没有写明依据；真实合约的部分仍等所有者的输入。）
• 追溯包 1.0.3（结论列出前 5 个用例）和追溯场景的多行匹配已合并（d30028e）。合并后 npx tsc --noEmit 无错误；node --test --test-concurrency=2 对追溯包和 scripts/real 共 205 项，全部通过。
• 全量检查（hub-redesign 的提示 e64fdfa，本机 macOS）：npx tsc --noEmit 无错误；node tools/gen-contracts.ts --check 一致；单元测试 node --test --test-concurrency=3（合约、hub、packs、scripts、生成器）3,272 项，通过 3,268、失败 0、跳过 1（“没有 sandbox-exec 时默认拒绝运行”，本机有 sandbox-exec）、todo 3（两个是回归范围和维护巡检经真实知识读取器的生产测试，并入 scope-commands.md；一个是“仅作者样例”标记，任务页 check-marks.md）；文档检查 90 项、验收 74 项、存档 7 项全部通过，verify:references 通过。上一次全量里两处旧措辞的失败已不再出现。
• 部署 e64fdfa（部署前自动备份，健康检查正常），发布 case-review 1.0.2、case-review-verify 1.0.2、defect-to-case 1.0.2、traceability 1.0.3，样例各自全部通过，并分配给评审用户。
• 追溯的真实客户端验收重跑：40 项核对 39 项相符。剩下 1 项是场景解析错了：结论文字列出的前 5 个用例都在独立依据里（集成者逐个对过），场景把“根据：”后面的 tree: 引用也当成了用例号；已交给追溯场景的分支修。
• 新部署上其余五项只出事实的能力重跑真实客户端验收，全部相符：模板查缺 5/5、回归范围 28/28、维护巡检 18/18、用例定位 21/21、质量看板 7/7。
• 评审第二段重跑（千问，真实 Circle 客户端）：第一次模型不知道包参数该放进 parameters，三次写错位置被客户端按模式拒掉，最后停下来问人；提示写成完整的 JSON 以后，第二次开出了正确的 31 个条目的运行，但四次提交都把条目编号写错（序号、只写节点号、加前缀），回执只说“不是本运行的条目”；提示里再写明编号照条目清单第一列原样写，第三次一次提交即受理（31 个条目全部交付，没有格式错误）。两处通用的改进记进任务页：start_run 的 parameters 没有任何说明（hygiene.md 第 5 条），条目编号错时修正说明不给写法也不给提示（check-marks.md 第 4 条）。
• 追溯按缺陷系统状态区分已关闭的缺陷，合并发布（a5ca1c5；PLM 1.0.1 加批量详情，追溯 1.0.4）。真实运行发现核心缺口：运行绑定了 plm:bugs 并读回了原件，检查却看不到——引擎只把提交里引用过的来源原文交给检查，只出事实的运行没有提交。任务页 check-sources.md：检查按声明读运行上绑定的来源。
• 台架包（search、facts、acquire、续期与释放，清单里声明的装机版本按“声明，未核对”参与构建判定）合并（1949551）；核心一处：投影看到的租约视图按血缘标出 mine。合并前在分支上跑过：单元 474 项、两个租约验收文件 9 项，全部通过。
• 评审终稿包（case-review-report，方法第 6、7 步）合并发布（541ea58、cfd5a99；1.2.0）：各块的复核结果作输入，Hub 按“各块取最差”算出整体结论和等级，报告的结论主张照复核包的写法用 code 写结论、rank 写等级，Hub 直接比对；证实、部分正确和新增的发现一条不漏，推翻的不能引，建议三段齐全；两块重叠时开始运行被拒。真实运行：第二段由千问按正确的分段重跑（一次受理）、GLM 复核（结论 PARTIAL、等级 P2），第一段沿用先前的复核（PARTIAL、P5）；千问写终稿一次受理，Hub 算出整体 PARTIAL、P5 并核对报告一致。两段的发现、处置和终稿全文给所有者判断，只放在本机。同一段两次初评的结果差别很大（21 条与 3 条），这是模型判断的波动；Hub 只核位置、引文和机械检查。
• 检查按声明读运行上绑定的来源，合并（6a36255）：检查声明 reads（来源角色、外部对象类型、字节上限），引擎按运行用户的真实角色读，读不到或超限的列进 unread_sources。追溯包据此读 PLM 状态。
• 全量检查（hub-redesign 的提示 6a36255，本机 macOS）：npx tsc --noEmit 无错误；合约生成物一致；单元测试 3,370 项，通过 3,366、失败 0、跳过 1（同前）、todo 3（同前，随后由 check-marks.md 清零）；文档检查 92 项、验收 86 项、存档 7 项全部通过，verify:references 通过。部署 cfd5a99（部署前自动备份，健康检查正常）。
• 追溯的真实客户端验收：独立答案由 scripts/real/gold/trace.ts 从导出的修复缺陷页、用例文档和 PLM 原件算出，79 项核对全部相符，含每个缺陷的缺陷系统状态和已关闭计数。这个构建 37 个缺陷里已关闭 25 个，没有一个追溯到已索引的用例（索引按构造不完整，有列出的来源没读到，所以只能说没找到）。答案命令第一次把文档清单里 agile:case: 前缀的条目原样比对，所有文档都被滤掉了；集成者把清单转成不带前缀的写法后重算，解析的修正已交给终端。
• 台架包的真实客户端验收（合成清单 synthetic-bed-topology，地址都在 192.0.2.0/24，不接触任何设备）：搜索、预订、经运行血缘续期 1 小时、释放，11 项核对全部相符；释放后租约表里没有剩下的键。第一阶段证明的是 Hub 的逻辑，装机版本是清单里的声明。
• 模板查缺的蜕变核对（6b）在真实文档上完成：评审过的那份 62 例的脑图，对“有”的三类（功能、反向、压力）各做三种副本，经 upload_file 上传后各开始一次查缺运行，15 项核对全部相符：删掉覆盖某类的用例，这一类变成缺、其余类别不变；加回一个，这一类变回有；每层兄弟节点倒序，摘要和报告与原件完全相同。
• 用例定位的全树核对（6b）第一轮：独立答案从 FAMY 根的子树原件算出（文件夹的 cases 是累计的，一份文档取列出它的最深那层；答案脚本第一版取了根，修正后重算），和用例索引的分面视图（按文档、版本线、模块分组；视图最多 6 个分组字段，火车不在其中）比：两边都有的 751 份文档版本线和模块全部相等，不等 0 份；只在一边的（答案 372 份、视图 493 份）多是路径不全的文档，答案把它们判为不符合约定，Hub 给出部分位置。答案改为对每份文档给出部分位置、逐字段比对的任务已交给终端。
• 回归范围和维护巡检只按命令定义算，合并发布（8f34850；两包 1.1.0）：同一版本线那一对在真实客户端上回归范围 28/28、维护巡检 18/18（这次逐条核了变更种类）。跨版本线那一对（相隔一条版本线）的独立命令差是 30 条路径（新增 14、删除 11、修改 5）；集成者当时写了“口径与 Hub 一致了”，但没有逐条路径核过，后来核对发现不一致（见本日稍后一条）。两个包的真实运行超出投影输出上限（每个条目重复带了路径的变更详情），任务页 scope-size.md。
• 用例定位的全树核对完成：独立答案对每份文档给出部分位置（按约定认得出的层），和分面视图逐字段比：Hub 视图里的 1,244 份文档版本线和模块全部相等，不等 0 份，只在视图里的 0 份；火车不在视图的分组字段里，集成者直接读 Hub 存的用例条目比对，1,546 份文档的火车全部相等，每份文档只有一个位置。真实客户端的多文档场景（5 份，分属五条版本线）：版本线、火车、模块全部相符；关联编号 16 项不符，原因在答案：定位包按写明的约定把“bug to case”后面的编号记为未分类（团队标题里它后面也会跟需求编号），答案却当成缺陷；答案和场景改按同一约定、按完整结果比对的任务已交给终端。场景里“在缺陷系统里找到”那条核对是空的（只抄答案），已要求改成人工抽查的记录。
• 用例定位的关联编号：结论改为按类别（需求、缺陷、未分类）全部列出，超过 20 个才写“另有”（29d0358，case-location 1.3.0）；场景只从编号那几段取数（不再把位置引用里的十六进制数字当编号）。真实客户端的多文档场景 46 项核对全部相符：5 份文档分属五条版本线，版本线、火车、模块和全部关联编号都和独立答案一致。
• 评审注入缺陷补两类（6b）：一份 14 例的真实文档副本里，把一条用例的命令词换成构建里没有的词，再删掉一组只含反向用例的分组；千问初评发现了不存在的命令（归为字面问题，引文逐字核对通过），漏掉了被删的反向组；非注入用例上另有 3 条发现，这份文档没有未改动版本的评审可比，要人工判断。命令目录检查只核模型在发现里引用的命令，引用的命令在目录里解析不出时记为跳过并写明（被评审的用例里可能有故意写错的命令），所以这类缺陷只能靠模型发现。
• 缺陷转用例与既有回归文档的比对（6b）：比对脚本（独立地从回归文档取命令头和参数，读 Hub 对引文和查重的判定）在三个缺陷上跑过。一个配对有效的（PLM 里缺陷标题和回归文档标题对得上）：既有文档用到的 3 个命令头草稿全部覆盖，草稿另多 2 个；7 条期望结果的引文都被 Hub 判为逐字；和既有用例完全相同的草稿两边都为空。另两个暴露了真实数据的问题：一个缺陷号在 PLM 和更早的 Bugzilla 里撞号，标题写着这个号的回归文档讲的是另一个缺陷（命令头重叠为 0，如实反映）；一份回归文档只有团队模板的标记、没有资源标签，答案脚本要改用“标签或标记”的规则（已交给终端）。另一个缺陷的起草七次因 commands 的每一项写成字符串被拒，修正说明不具体；同一轮里出现 Hub 内部错误，见下一条。
• Hub 的一个缺陷：在绑定了大来源（约 2.7 MB 的手册、十几 MB 的用例索引视图）的运行上，resolve_reference 只要走“在来源里检索原文”这条路径就栈溢出，Hub 回内部错误；submit_result 检查引文时多半也走同一条路。集成者在已部署的 Hub 上能稳定复现（参数只有一百多字节）。任务页 submit-robustness.md，同时要求内部错误记下调用栈、递归加上限和环检测、结构错误的修正说明给出要求的形状。
• 回归范围和维护巡检的投影瘦身第一轮合并发布（303a4f6，两包 1.2.0；circle 的模型端点被限流，后半段由另一个终端照它的补丁接着做完）。跨版本线那一对仍不够：回归范围 2,096 个用例投影约 7.9 MB；维护巡检 1,147 个用例投影装下了，但两个检查函数的输出超过沙箱上限，Hub 把 1,147 个条目的两个要求项如实记为未核对（检查出错）。第二轮写在 scope-size.md。
• 一处疏漏：集成者给终端的任务消息里贴了一段真实的追溯结论，终端照着把一个真实文档号和两个节点号写进了 scripts/real/accept/traceability.test.ts；已列入 hygiene.md 的替换清单（清单本身只在终端消息里，不进 Git）。以后给终端举真实例子，先换成同形状的合成编号。
• 规矩的修正合并（26d7245）：租约操作的五个值改由词表轴 lease_op 生成；样例地址改到 192.0.2.0/24；没声明档的检查记为检查出错，不再按依据回退；测试里取自真实系统的编号和构建名换成合成值；start_run 的 parameters 加了说明。
• 栈溢出的根因找到并修好（3675350）：不是递归。hub/runs/engine/exact.ts 在来源里检索原文时，用展开参数把一份来源的全部候选一次压进数组；大来源的候选数超过 V8 单次调用的参数上限（约 65,536 个），抛出的 RangeError 写着“超过最大调用栈”。改为逐个加入，候选检索加了上限。按任务页同时加上：内部错误在管理员记录里写调用栈（只有函数名和仓库内的相对位置）；提交的 JSON 嵌套超过 64 层，整份不受理；引用解析带访问集合，遇到环就停；结构错误的修正说明按槽位模式给出要求的形状，核心里没有字段名。
• 全量检查（hub-redesign 的提示 3675350，本机 macOS）：npx tsc --noEmit 无错误；合约生成物一致；单元测试 3,476 项，通过 3,475、失败 0、跳过 1（同前）；文档检查 95 项、验收 87 项、存档 7 项全部通过，verify:references 通过。部署 3675350（发布 367535075be3，部署前自动备份，健康检查正常）。在已部署的 Hub 上重放先前稳定复现的三种输入：管理员记录里没有新的栈溢出；检索原文的那一种返回“有歧义”和 10 个候选，另两种返回“未解析”和修正说明。
• 缺陷转用例比对的答案改为按这个构建的命令目录拆命令头（e2d0b12）：两份配对有效的回归文档，既有文档的命令头草稿全部覆盖；草稿的命令头里既有文档也用到的，一份 50%、一份 60%（只报告，不判通过）；分组标签和写法不成命令的行单列为未识别；期望结果的引文 7/7、7/7 都被 Hub 判为逐字；和既有用例完全相同的草稿两边都为空。草稿一侧还按启发式拆，两边统一拆法的第三轮交给了终端（accept-gaps.md C 第 5 条）。
• 第三轮合并（c45d85a）：两边都按目录拆以后，两份对比的数字不变，草稿里没有目录找不到的命令行。
• 回归范围和维护巡检的瘦身第二轮合并发布（84a5ca9，两包 1.3.0）：每个条目只带原因在运行级详情表里的序号和变更种类，检查函数的每条判定只带一条依据。合并前在分支上跑过两包和 scripts/real 共 337 项，全部通过。跨版本线那一对的回归范围在已部署的 Hub 上跑完了：2,096 个条目全部交付，静态层全部通过。
• 但变更路径对不上：Hub 的影响视图（changed=definition）给出 137 条变更路径，独立的命令树比较是 30 条；30 条都在 Hub 的 137 条里，其中 10 条独立比较是“删除”、Hub 是“修改”。两边读的命令树原件逐字节相同。集成者把两边的解析放在同一份原件上一次性对比，查出三处原因（任务页 impact-catalog.md）：手册的签名段落也是“定义”条目，而手册按版本线，跨版本线时混了进来；命令树条目的签名带参数说明，只改说明的也算“修改”；独立比较不读直接挂在作用域下的顶层命令。只按命令树、只比语法时，同一版本线那一对与独立比较逐条相同，跨版本线那一对只多出一个独立比较漏读的顶层命令。修 Hub 的 A 部分已交给终端，修独立比较的 B 部分待指派。同一版本线那一对先前的“逐条相同”不受影响：两个构建用同一份手册。
• 独立比较补读顶层命令、重载按集合比，合并（a9c223f，scripts/real 233 项通过）。在同一份原件上重算：跨版本线那一对新增 14、删除 11、修改 6（多出的一条是一个顶层命令加了可选参数）；同一版本线那一对新增 10、删除 1、修改 1，和先前相同。这就是 Hub 修好以后要逐条对上的答案。
• 同一版本线那一对在 1.3.0 的两个包上经真实客户端重跑：回归范围 28/28、维护巡检 18/18，瘦身没有改变结论。跨版本线那一对的维护巡检在 1.3.0 上也跑完了：1,147 个条目全部交付，两个检查函数的输出不再超限。
• 条目核对脚本 scripts/real/accept/scope-cases.ts 和 hub-call.ts --structured 合并（d1571e2，scripts/real 242 项通过）。修 Hub 之前先跑了一次作基线：后一个根里，独立命令差的新增和修改路径（20 条）上的用例是 490 个，都在 Hub 的回归范围里，但 Hub 另多出 1,606 个；前一个根里，删除和修改路径（17 条）上的用例是 110 个，都在维护巡检里，Hub 另多出 1,037 个。多出来的就是手册签名和说明文字的变化带进来的。脚本因此判“存在不一致”。
• 影响视图按命令目录比（catalog=commands@1：只比目录成员，去掉说明字段、引用和签名编号以后按语法比，重载按集合比；根里没有这个目录时视图不回答）合并（bac93e6；带目录的视图标识在运行来源里照样带上根对修订）。词表补四个轴（样例来源、目标种类、度量、归位方式，模型版本 7，58 个轴，c269181）；“词表不手写”的扫描把编号范围对象的两个键误判成度量，加了带理由的例外表（21362c8）。全量检查：合并后的提示 bac93e6 上类型检查、合约生成物、文档 99 项、验收 87 项、存档 7 项全部通过，单元测试那一处误报修好以后在 21362c8 上 3,527 项，通过 3,526、失败 0、跳过 1（同前）。部署 21362c8（发布 21362c8492bb，部署前自动备份），发布回归范围和维护巡检 1.4.0。
• 跨版本线那一对在已部署的 Hub 上（6b 的两句都核了）：
  • 影响视图的变更路径和独立比较逐条相同：31 条，新增 14、删除 11、修改 6，种类也逐条相同；另有 6 条路径只有说明文字或重载顺序不同，视图如实写明没算变更。
  • 回归范围 490 个用例、维护巡检 110 个用例，和条目核对脚本从两个根的变更节点算出的期望完全相等，两边都没有多出或缺少的条目。维护巡检里 12 个用例所在的命令已删除，98 个所在命令的定义有变更。
  • 同一版本线那一对用新的标识经真实客户端重跑：28/28、18/18。跨版本线那一对经真实客户端：24 项核对 23 项相符，修复前错误进范围的 20 个用例都不在回答里；不符的一项是回答文字只列出了 20 条变更路径里的 13 条：490 个条目只显示前 235 个，其余要按引用翻页，变更路径只作为条目的原因出现。结果本身是对的，要改的是回答的呈现：任务页 scope-summary.md，回答总能看到整个命令差。
• 两个包加了一条运行级的事实结论，列出整个命令差（每条路径一行：路径、种类、用例数，删除的标“不进范围”），排在条目前面；回答里单条陈述以 1,500 个字符为限，所以按 1,400 个字符分成几部分（5e40edc、6bd5675，两包 1.6.0）。全量检查（提示 6bd5675，本机 macOS）：npx tsc --noEmit 无错误；合约生成物一致；单元测试 3,540 项，通过 3,539、失败 0、跳过 1（同前）；文档检查 100 项、验收 87 项、存档 7 项全部通过，verify:references 通过。部署 6bd5675（发布 6bd56755a4fb，部署前自动备份）。
• 最终验收（已部署的 6bd5675，Otty 里真实的 Circle 客户端）：跨版本线那一对 24/24，回答里 20 条变更路径都在，修复前错误进范围的用例都不在；同一版本线那一对 28/28、18/18；新开的两次运行再经条目核对，回归范围 490/490、维护巡检 110/110。核心代码自 bac93e6 以后没有再改，所以影响视图与独立比较逐条相同的结论（31 条）照旧成立。
• 按决定 20 处理带凭据的数据并更新知识库：接受 29 份只保留来源的扫描命中后同步，用例文档仍被跳过，因为生产器读的是系统包从原件派生的文档，派生出来的字节同样命中，而接受只对那一份字节有效（知识包 README 记着的缺口）；再接受 19 份派生文档、一条版本线换了字节的应用手册，以及第二次同步新读到的 4 份，共同步三次。现在没有一个构建跳过列出的来源；失败的 9 个是构建站上取不到命令树的旧构建（HTTP 403、404），和先前一样。跨版本线那一对的两个根各多了约 600 个条目，视图的“列出的来源没有用上”降为 0。
• 数据更新以后重新验收（已部署的 6bd5675，真实 Circle 客户端）：跨版本线那一对变更路径仍和独立比较逐条相同（31 条），回归范围 491/491、维护巡检 111/111（各多出的一个用例来自新进索引的文档）；模板查缺 5/5、用例定位 46/46、追溯 79/79、台架 11/11、同一版本线 28/28 和 18/18、跨版本线 24/24；质量看板先是 4/7，因为独立答案是按旧的文档集合算的，把 19 份新能读的文档导出、用同一个计数脚本重算以后，用例 86,187 个、无期望 1,570 个、含糊 5,384 个、反向 6,601 个，与 Hub 完全相同，7/7。
• 缺陷转用例在已部署的 6bd5675 上经真实客户端重跑（千问，同一个缺陷）：9 次提交，2 次因形状、4 次因引文不逐字被整份拒收，第 7 次受理；但受理的那份把引文放在了用例一级，每个期望结果都被判“缺少逐字引文”，两轮修复用完，条目记为未完成，一个都没交付。Hub 的处理是对的（没有逐字依据的期望一条都没放过），这次的结果却不能算缺陷转用例做成了。查出两个原因：包的槽位模式里 expected 只写了“数组”，没写每一项要带 quote: {text, reference}，所以按模式给出的修正说明说不出该放在哪里，那句“缺少逐字引文”也不写位置和形状（交给终端修）；集成者的提示里用例索引的标识少了包要求的 fields=document,node,title，视图超出预算，查重只能记未决（集成者的错，重跑时改正）。
• 缺陷转用例的包修好以后（1.2.0：槽位模式写明每个期望结果要带 quote: {text, reference}，缺引文的修正说明写出位置和形状）用改正的提示重跑（千问，同一个缺陷）：4 次提交，1 次因引文不逐字被拒，之后受理，条目交付。和既有回归文档比：草稿用到 3 个命令头，既有文档用到 3 个，两边全部相同（双向 100%，上一轮是草稿一侧 60%）；7 条期望结果的引文全部被 Hub 判为逐字；和既有用例完全相同的草稿两边都为空。查重这一项 Hub 记为未决：用例索引视图即使只带 document,node,title 三个字段也有 14.7 MB，按视图的字节预算只放下约 45,000 个条目里的 27,102 个，所以“不重复”说不出来，Hub 如实记未知（6b 对缺陷转用例的验收不含查重）。要在真实规模上判重复，得让索引按草稿用到的命令收窄，留作后续；包的期望来源函数另绑了一份不带 fields 的同一索引，白白多占一份预算，一并留作后续。
• 用例评审整条流程在已部署的 6bd5675 上经真实客户端重跑（同一份 62 例的文档，分两块）：第一块千问初评受理、GLM 复核受理；第二块千问第一次把条目编号写成了脑图里的节点号，两次提交都因结构被拒、修复轮数用完，提示里写明三处要点后第二次受理，GLM 复核受理。终稿（千问）被受理，但 Hub 的检查判它不对：漏引 22 条发现、错引 21 条、等级写成 P3（Hub 按最差那块算出 P4，整体结论 PARTIAL 写对了）。原因在终稿包：开始运行的回答只有 63 个条目的标题，没有给出 Hub 算出的整体结论和等级，也没有给出要引用的发现清单，模型只能自己翻复核结果、自己拼引用；前两次提交又因引用解析不出被整份拒收，两轮修复先用完了，检查给出的准确修正说明没机会用上。改法交给终端（任务：终稿包把整体结论、等级和每个条目要引的发现写进回答）。
• 终稿包 1.3.0 合并发布（7e5fef8）：每个条目的摘要写出要引用的发现（证实、部分正确、新增）和推翻了几条，终稿那一项写出 Hub 算出的整体结论码和等级；包的测试 11 项、验收场景 26 的 5 项通过。用同样两块已受理的复核重跑终稿（千问，真实客户端）：一次提交即受理，63 个条目全部交付，没用修复轮数；终稿的两项检查都是支持（发现一条不漏、没引推翻的，结论 PARTIAL 和等级照算出的写），另有 4 条建议。至此用例评审整条流程（两块初评、两块不同模型族的复核、终稿）在已部署的 Hub 上经真实客户端走通，结果经 Hub 核对一致。
• 留下的缺口：接受不会自动带到派生的字节和派生的条目上，所以文档改过以后要再手动接受一次（作为日常的数据更新照做）。通用的修法要扫描器给每处命中记下所命中文字的摘要，派生内容的命中全在已接受原件的命中里才算接受；排在后面。
• 对照模型的整体复核（阶段 4，任务页 model-review.md，34a6782）。第一版被集成者退回：引用的 77 个文件里 27 个不存在，61 个测试名里 46 个在所写的文件里找不到。重做后集成者逐条机械核对：引用的 129 个文件都存在，130 处测试名都在所写的行上，28 行字面量枚举都对得上。结论：
  • 73 个元素里，8 个不在这个里程碑（B06、B07、V08、P07、P09、P10、D07、R03）；在范围的 65 个里，落实 55 个，部分落实 7 个（A05、K03、K04、C06、D03、P11、P05），没落实 3 个（W04、W10、V07）。P05 原判落实，集成者更正为部分落实（562cc85）：核心没有生成步骤和出件存储，编译包在自己的检查函数里生成执行计划并回读。
  • 硬规则：核心代码里没有产品名、命令名、客户名；hub/ 里没有手写的 z.enum；未知从不映射成错误；记录只追加；精确值都解析到引用。三处已定的引擎读法和代码一致。
  • 给所有者的偏离 7 条：架构第 1 节仍把租约和常设义务列为不做，决定 9 和 16 以后没跟着改；W10、V07、W04 没落实，这一轮七项能力都用不到（静态检查不需要重复，固定的任务包没有台账以外的判定形状，没有改判据的补丁工作），架构第 1 节也没把它们列为不做；K03 和 K04 的候选层写入、bot 归位提议没开通；D03 和 P11 的效果前边界没装配（这个里程碑没有对外写）；合约里有 5 处模型概念是手写的枚举，没有进词表：检查的对象和作用范围（条目或运行）各一处、度量的聚合方式、生产器的归位策略、反例来源。
• 转自动化的编译半边（任务页 case-compile.md）：包 1.0.0（064fbf2，合并 d820a9a）和 1.1.0（27f647d，合并 97a52db）合并发布；合成合约和合成台架作为命名文档发布，字节与包里的 examples/ 相同。1.1.0 把执行计划改由包的检查函数从槽位确定性生成（exec-plan@1 的规范 JSON），再用另一个读取函数回读比对；支持结论写出计划文本的 sha256，data 里带计划全文；槽位里不再有模型写的计划。P05 因此在包内落实，核心的生成步骤仍是后续。独立核对（scripts/real/gold/compile-check.ts，e3dcb3c、0629d2f）只读公开格式，不读包的函数：自己解析命令树原件，按台架清单算地址，照规则从槽位生成一份计划比 sha256，再逐项比 Hub 的结论。npx tsc --noEmit 无错误，scripts/real 的测试 313 项通过（e3dcb3c 时）。
• 编译的第一次真实试跑（已部署的 6bd5675，Otty 里真实的 Circle 客户端，千问）：对象是一份 2 例的真实用例文档，用合成合约和合成台架，目标构建是一个有命令树的已发布构建。两次提交都受理：第一次有一例把 IPv6 地址填进了只收 IPv4 的参数，被合约检查驳回；模型改正后重交，两例全部交付。独立核对的结果：
  • 两份计划的 sha256 和 Hub 的逐字节相同；合约、地址、命令三项和 Hub 一致。
  • 期望来源一项不一致：Hub 判通过，独立核对判不通过。查下来是包的缺口：两例的期望结果都是模型自己写的英文句子，附的引文是用例标题（逐字）。包只核引文在不在来源里，不核期望文字是否出自引文，违反了设计第 2 节“不能是模型自己写的”。
  • 另有一例把用例里在客户端上跑的 dig 换成了被测设备上的 nslookup。计划忠不忠于用例是判断，Hub 的静态核对管不到，要评审或人来看。
  • 对照独立核对还查出包有几处和设计不符：后端只认服务器设备的地址、地址按数值比较、每条驳回带位置。这几处连同期望文字的问题一起交给终端（case-compile 1.2.0）。
• case-compile 1.2.0 合并发布（aa67b2b，合并 01aba48）：期望文字必须出自它的引文，后端只认服务器设备的接口地址，地址按数值比较，每条驳回带位置（README 的 Pointers 一节）。独立核对按这些位置逐项比，合并 cc7a6c4，scripts/real 的测试 326 项通过。
• 编译的正式验收（1.2.0，已部署的 6bd5675，真实 Circle 客户端，千问，合成合约和合成台架，目标构建同试跑）：
  • 2 例那份：第一次提交两例的槽位形状不对，被合约检查驳回；改正后重交，两例全部交付。这次期望结果引的是用例里期望结果节点的原文，期望文字是引文的片段。独立核对的 22 项判定和 Hub 全部一致，两份计划的 sha256 逐字节相同。
  • 5 例那份（命令行带引号参数和取值范围）：一次提交即受理，5 例全部交付。独立核对的 41 项判定和 Hub 全部一致，5 份计划的 sha256 逐字节相同。
  • 判断层的问题 Hub 管不到：IPv6 那例的客户端请求仍指向 IPv4 地址，因为合成合约的客户端方法只收 IPv4，表达不了这一例；期望结果的原文本身笼统（例如“显示正确”），这是用例的问题，评审能力会标出。
  • 查出的缺口：第一次提交里两例的合约检查不通过，却没有修复轮数。五个事实要求项都没有声明错误处理，SKILL 写了修复轮数，实际是 0，驳回只记成交付的判定。交给终端（1.3.0：模型能改正的驳回码都修复 2 轮，用完记未完成）。集成者起初把这件事说成“不合规的计划进了已交付”，说错了：按模型 V05、V06，记账型运行里“已交付”只说明条目有了终态，不说明通过；计划合不合规看要求项的满足状态，以后上机只取全部必需要求项都满足的计划（门禁型）。1.3.0 合并后重跑这两份。
• case-compile 1.3.0 合并发布（794dafd，合并 4a04761）：模型能改正的驳回码都给 2 轮修复，用完记未完成。命令目录检查的范围从“只核解析得出的命令”改为“每条命令都要解析”，解析不出就是不在目录里；原来这种命令会被静默放过（终端自己查出来的）。
• 编译的正式验收（1.3.0，已部署的 6bd5675，真实 Circle 客户端，千问，同样两份真实用例文档，合成合约和合成台架）：
  • 2 例那份：一次提交即受理，没用修复轮数，两例的要求项全部满足。独立核对的 18 项判定和 Hub 一致，两份计划的 sha256 逐字节相同。
  • 5 例那份：第一次提交里 5 例的期望文字都是模型自己写的，引文是用例标题，5 例都被判“期望文字不是引文的片段”，回执给出剩余 2 轮。模型改成引用例里期望结果的原文后重交，5 例的要求项全部满足，用了 1 轮。独立核对的 25 项判定和 Hub 一致，5 份计划的 sha256 逐字节相同。
  • 至此转自动化的编译半边（E1 到 E3）在合成合约和合成台架上做完：模型编译真实用例，Hub 的核对和独立算法一致。所有结论都标“按合成合约核对”和“不证明在真实设备上跑得通”。上机（E4、E5）要所有者另行批准；真合约、执行格式和台架拓扑等所有者给。
• 缺陷转用例 1.3.0 合并发布（查重按草稿要用的命令收窄索引，合并 1dfcd4d）。在真实客户端上重跑（千问，同一个缺陷，索引收窄到三个命令）：6 个草稿交付，结构和命令两项满足；查重和期望来源两项都记未知。查出两个问题：
  • 查重拿草稿的整条命令行去比索引的键（命令路径），两边永远对不上：收窄范围的判定把每条草稿都判在范围外；按命令集合分桶，草稿也落不进任何桶，不收窄时同样找不出重复。交给终端（1.4.0：命令行先按锁定构建的命令目录解析出命令头，再按命令头集合比）。
  • 期望结果的引文只写在草稿数据里，没有照抄进主张顶层的 quotes，边界就没有解析它们；quote@1 拿不到片段，记成“没有绑定到本次运行”的未知。这句说明不对（来源是绑定了的），而且记未知不给修复轮。上一次交付的运行里模型照抄了顶层 quotes，所以通过。这是核心的缺口：检查时应当能按引用读出绑定在本次运行上的任何来源的片段，不依赖边界预先解析；另开任务。
• 缺陷转用例 1.4.0 合并发布（ad09be9，合并 bd662a0）：草稿的每条命令行先按锁定构建的命令目录解析出命令头（目录里最长的前缀），收窄范围的判定和分桶都按命令头集合算；SKILL 写明期望结果的 quote 也要照抄进主张顶层的 quotes（核心修好以前）。真实客户端重跑（千问，同一个缺陷，索引收窄到三个命令）：5 次提交，2 次因形状被整份拒收，之后受理，用了 1 轮修复。6 个草稿交付，五个要求项全部满足：期望结果的引文都被判逐字（修复说明和手册），查重判出“未发现与已索引用例重复”。独立核对：6 个草稿的命令头集合在全部用例里各有 33、58、46 个命令集合相同的已有用例，其中标题（规范化后）和反向标记都相同的是 0 个，和 Hub 的结论一致。这次查重真比过了，不是空集：同命令集合的已有用例是有的，标题不同。至此缺陷转用例的查重在真实规模上判得出来。
• 凭据命中的受理跟到派生的字节上（任务页 derived-acceptance.md，5bd44ca、e1dc9a3、bedaa16，合并 09474a0）：Hub 读到或生成的派生字节里，每处命中的文字都在它所派生自的来源里、且那份来源的受理此刻有效，就算受理。
  • 命中文字只在内存里比，不存，也不存摘要。
  • 每次读都重核受理，撤回立刻生效，读时不重扫字节。
  • 知识视图在整份扫描不被截断的范围内留下被覆盖的条目。
  • 第一版每个条目都要走一遍整个根组成，真实规模上会慢到不能用；集成者退回后改成每个视图准备一次。合成规模（3,000 份来源、20 份已受理、200 个命中条目）：生成视图 42 次查询，读取 7 次查询、0 次扫描。
  • 另一家族的终端独立复核，六条硬约束都成立；补了派生路径读取不重扫、整份截断回退的测试。数据更新以后不必再手动受理派生文档。
• 索引视图回显 only 和被截断的键 cut_keys，作为机器可读的字段（0fb352c，合并 dc3fd06）；缺陷转用例 1.5.0 读这两个字段，老视图才按 URI 和上限推断（89e88aa，合并 ad14450）。
• 检查读得到绑定来源的任何片段（任务页 check-fragments.md，9778f4a、a8fcd58、b8d0e5f，合并 a94c383）：
  • 引用只写在槽位数据里也能核对。src: 引用要求源文件是本次运行的输入；tree: 引用要求根是锁定的根。
  • 源文件不是输入、或者片段不存在，记驳回（沿用 QUOTE_MISMATCH，说明写明原因），模型可以修。真读不到才记未知。
  • 检查函数的未知原因里加上 output_failed：编译包回读失败时，条目记未完成，不再被判成“未核对”。
  • 这件任务原由 circle 终端做，它的模型端点被限流（429）后停住，由 codex 终端接手补完。
• 终稿包 1.4.0 合并发布（3c85cd3，合并 357124f），修投影的四处错：
  • 不是“已交付”的分区都算没交付，原来比的是不存在的分区名 unfinished，所以缺漏条目从来不会被列出；
  • 块结论只采信 Hub 支持了的那条；
  • 块结论带真实引用；
  • 缺块结论时记未知。有缺漏条目时整体记未知，并列出缺漏条目。

  全量检查（提示 357124f，本机 macOS）：npx tsc --noEmit 无错误；合约生成物一致；单元测试 3,825 项，通过 3,824、跳过 1（同前）；文档检查 106 项、存档 7 项通过，verify:references 通过。验收 88 项里场景 26 失败 4 项，查下来有两个原因：

  • 包把提交里的指针当成了结果记录里的数组下标，引用会指错主张（Hub 的事实排在模型主张前面）；
  • 场景里合成的 PASS 块没有复核方自己的引文，Hub 本来就不支持它的结论，旧的投影照单全收，新的投影如实记未知。

  终稿包 1.4.1 改用结果记录里的实际下标；场景改成产生被 Hub 支持的块结论，并断言支持和引用，断言没有放宽（aae30a1，合并 8ac22c5）。重跑验收 88 项全部通过（提示 8ac22c5）。

• 部署 baea45c（发布 baea45c8a598，部署前自动备份），带派生字节的受理、索引视图的回显字段、检查读片段和检查的出件失败原因。健康检查正常。部署后经真实 Circle 客户端（脚本化模型）重跑八个场景，全部相符：
  • 模板查缺 5/5、用例定位 46/46、追溯 79/79、质量看板 7/7、台架 11/11；
  • 同一版本线回归范围 28/28、维护巡检 18/18，跨版本线 24/24；
  • 每个场景 5 到 39 秒，派生受理以后视图没有变慢。
• 部署后的真实模型复查（千问，真实客户端）：
  • 终稿（1.4.1，同样两块已受理的复核）：一次提交即受理，63 个条目全部交付，没用修复轮，两项检查都是支持。整体结论 PARTIAL、等级 P4，引用指向那一块复核结果里模型的结论主张（记录里的下标 1；Hub 的支持事实排在下标 0），对过记录。
  • 缺陷转用例（1.5.0，同一个缺陷，索引收窄）：6 次提交，模型几次把命令写成字符串、把步骤放错地方，按修正说明改完，用满 2 轮修复后五个要求项全部满足，查重判出不重复。
  • 编译（1.3.0，2 例那份）：两例都在修复轮用完后记未完成。追下来有两层原因：
    • 模型把期望结果的文字配上了用例标题节点的引用，边界整份拒收（QUOTE_MISMATCH），这是对的；
    • 整份不受理时，引擎把这两个条目排除，再跑检查给修正说明，可被排除条目的槽位是空的，核对待判定产物的检查照样跑，报出“槽位数据不是对象”“bucket 不是字符串”这些假驳回，混进修正说明，还记了一轮修复。模型照着假说明把字段挪出了 plan，下一次更坏。

    这是引擎的缺陷，各包都会碰到；交给终端（任务：不受理时被排除的条目一条检查都不跑）。

• 不受理时被排除的条目不再跑检查（0e9be2f，合并 ac1be54）：修正说明只来自边界错误和其余条目的检查，空产物检查不再造成修复轮。全量检查（提示 ac1be54）：单元测试 3,830 项，通过 3,829、跳过 1；文档检查 107 项、验收 88 项、存档 7 项全部通过。部署 7984c87（发布 7984c87ea6c1，部署前自动备份），健康检查正常。
• 在新发布上重跑编译（千问，2 例那份）：
  • 第一次提交受理，有一例把 IPv6 地址填进只收 IPv4 的参数，被驳回、给出修复轮；
  • 第二次模型只重交了改好的那一例，漏交的一例按 W07 R[3] 记“提交未覆盖”、计一轮；
  • 第三次两例都交，要求项全部满足，用了 1 轮。

  独立核对的 18 项判定和 Hub 一致，两份计划的 sha256 逐字节相同。修复回路在真实运行里按规则走通。

• 受理的提交里没交产物的条目不再被假驳回（f5b0ddb，合并 003f518）：
  • 声明跳过和未覆盖的条目，核对待判定产物的检查不再拿空槽位去跑；
  • 覆盖的记账照 W07 R[3]，未覆盖照旧在 errors 里点名、计入修复轮。

  终端核实了改前的现状：跳过的条目会留下假驳回；只有事实要求项的未覆盖条目会产生修正说明、消耗修复轮，还会进“已交付”。几个包里对空槽位的分支因此不会再走到，引擎 README 列出，包没改。

  全量检查（提示 003f518）：单元测试 3,846 项，通过 3,845、跳过 1；文档检查 107 项、验收 88 项、存档 7 项全部通过。部署 deb2eb4（发布 deb2eb4c16e7，部署前自动备份），健康检查正常。部署后八个真实客户端场景重跑，全部相符（5/5、46/46、79/79、7/7、11/11、28/28、18/18、24/24）。

• 知识库改造加进计划（所有者 10-23 下午定的方向，docs/hub-r4-kb-direction.md，deb2eb4）：
  • 四项调研：asciidoctor.js 能否在生产器沙箱运行，交终端；章节路径与命令路径共存一棵树、适用条件三字段够不够、自由文本占比，由集成者只读调研，真实内容只在本机。
  • 三件并行开发：章节挂树和交叉链接（kimi，kb-sections.md）、候选层写入通道和归位提议核验（codex，kb-candidates.md，调研 1 之后）、解析时算有效条件状态和矛盾打标（circle，kb-validity.md）。
  • 核对到的事实：手册库里只有转换后的 md 和 catalog.json，没有 adoc 原件；要直接接 adoc，先要所有者给出 adoc 的来源。
• 终端还报了同一类的另一半：受理的提交里，声明跳过、未覆盖的条目也可能把空槽位交给核对产物的检查（任务页 empty-slot-checks.md）。终端问到修复轮怎么记时，集成者按模型更正了任务页：提交未覆盖照 W07 R[3] 计入修复轮，只去掉空产物检查造成的轮次。
• 核心生成步骤（P05）提议的核实（docs/hub-r4-p05-review.md，edec79f）：方向和模型一致，建议先在编译上试点；先后次序等五件事待所有者定。核实中查出终稿投影的几处错，交给终端（case-review-report 1.4.0）。
• 终审（独立核对，对照计划、设计文档、模型和 AGENTS.md）：七项能力都还是“部分完成”，没有一项能说已按预期得到正确结果。主要缺口：
  • 用例评审：没在当前发布上重跑注入缺陷的度量；没有“规格与手册冲突”的金标准；含糊期望和命令核对靠模型；精确率没有计分。
  • 模板查缺：蜕变核对没经过 Circle，只核了一份文档；关键词类别没测。
  • 用例定位：构建候选没和独立的构建金标准比；缺陷的抽查没记录；按文档的回退位置不对。
  • 回归范围与维护巡检：用例一侧没有独立的命令金标准；索引里还有大量没解析出命令的用例。
  • 缺陷转用例：参数没有独立核对；引文可能是改写，来源也没限制。
  • 追溯与看板：已关闭缺陷的连接只在“没有”的一侧核对过；看板只核了总数；需求到用例的矩阵和控制台页面没做。
  • 转自动化：要设备，真实合约未给，P05 核心步骤没做。
• 终审查出的规矩问题：文档里的真实构建名、版本线、一个缺陷号和一条内部文档路径已改成说明性文字（e59a093）；代码、测试和运维脚本里的几处交给终端（hygiene-2.md），并加宽仓库检查。这些值仍在分支更早的提交里；分支从未推送，推送之前要不要改写历史由所有者定。
• 终审查出的、先前没写进进度的偏差：
  • 阶段次序倒了：第一次真实评审（cfcd9d9，10-22 12:51）早于合成验收套件（10125f2，14:27），引擎的修正在后。历史只追加，没有改写。
  • 第一份文档按用例次序拆块，没有按模块子树拆。
  • 缺陷转用例在追溯和看板之前合并，和计划的次序不同。
  • 架构第 6a 节的追溯和质量控制台页面没做，按生产运行交付。
  • 条目身份在没有稳定 data.id 时按位置编号（#n、@index），不是计划里的“祖先文本加子树摘要”。
  • 连接器在令牌声明的过期之前续期，模型写的是收到明确的“登录已过期”才登录一次；这一偏离只写在连接器 README 里。
  • 计划第 0 步模型第五版的独立复核没有记录；第 3 步没有钉住已应用迁移字节的测试；第 12 步的演练（另一个数据目录、钥匙丢失后重新导入、切换失败回滚、重启恢复）没有记录，circle-hub secrets import 没有实现。
  • 第 13 步 PLM 的构建存在核对没有实现，各连接器的只读冒烟没有记录；第 15 步评审所用构建由所有者选定这一点没有记录。
  • GLM 的密钥是从所有者的 Circle 设置里读的，计划写的是从环境配置文件读。
  • Circle 一侧的完成只记在 10-22 的交接页里，没有提交号；docs/compatibility.md 还写着“规划中”。
  • ops/knowledge-sync（d79db78，10-21，另一个会话）记下了在文档主机上新加的定时任务和一个 Python 暂存脚本。进度里没有授权来源；AGENTS.md 只允许读真实系统，也不用 Python 运行依赖。留着还是按 README 回滚，由所有者定。
• 知识库调研 2–4 做完（集成者只读，docs/hub-r4-research/kb-real-sources.md）：
  • 按章节挂能覆盖应用手册的全部块；章节和命令多对多，要在同一个根下分两棵子树；交叉链接存作者标出的字面，读的时候精确匹配。规则已转给 K1。
  • 同一版本里 125 处按条件分叉，只有 7% 能装进型号、平台、构建三个字段；建议三字段保持窄，装不下的留在原文，作为目标前提显示“未核对”。
  • 自由文本只占已读内容的 0.75%（按条数），不进树；派生数据机制可以推迟。真正的缺口是一个根里两万多条未归位的用例条目。
• adoc 原件：所有者 10-23 给了 SVN 只读账号（只放在环境配置文件里，脚本运行时读，不显示、不落盘）。集成者只读取回一个版本线的两份手册：
  • 每份一个主文件，按固定次序 include 各章；条件只切换品牌和版本；
  • 现在的 md 链不经主文件，所以属性没解析、条件全按未设置；
  • 服务器支持按修订号成批读，字节和最新的一致。

  据此写了 K4 的两件任务：SVN 只读系统包（kb-svn.md）和 adoc 生产器（kb-adoc.md，等 K1 和 kb-svn 合并）。

• K3（circle，a7784c3）复核：规则已撤回的判法对。要改的几处已交回 circle：
  • 被引片段已变要比“所引的根”和“读者的根”，现在比的是同一根的另一份组成，真实数据上不会触发；
  • 矛盾标记没有按读者的可见性过滤，别人私有的关系会显示给所有人；
  • 无声的 10 条上限；
  • 每个条目一次查询。
• codex 在 K2 里问的五件事，集成者按模型答了（见决定 21 到 23）；K2 草稿里的手写枚举改为进词表。
• 傍晚交回的几件：gold-location、gold-d2c、plan-evidence（PLM 那两条按约定后做）、d2c-pack-fixes（缺陷转用例 1.6.0）、hygiene-2 的 7 条复核修正。四件已交另一家族复核。
  • hygiene-2 加宽的全仓检查还剩 9 处：
    • 3 处在 hub-redesign 上已改，合并时消失；
    • 6 处在 FAMX 包里，和 K1 改的文件重合，等 K1 合并后再改。
  • manual-store、openkm 两个包换了示例，各升一个补丁版本重签。
• 新开三件：
  • xlsx-parser：核心的通用 xlsx 解析器，上真实台架第 2 件的通用部分；
  • plm-fields：PLM 包回传修复说明的字段名，按名字读构建列表；
  • gold-catalog：评审里目录类标记的独立答案。
• 未知全量普查做完（docs/hub-r4-research/unknown-sweep.md）：
  • 103 个位点，没有一个必须停在未知：缺陷 31，设计缺口 16，缺动作的过渡未知 28，已自动解决的 8，数据缺口 10，等所有者决定 10。
  • 普查发现，10-23 那轮真实验收 79 项里有 37 项是在未知上判的通过，掩盖了追溯的一个缺陷。早上记的“六项能力在真实数据上验收通过”因此不成立，修完以后要重跑。
  • 修法拆成六件：hub-unknown-model（模型文字由集成者先改）、hub-unknown-exits、hub-retry-split、hub-read-absence、hub-view-scope、hub-pack-findings。这一批合并以后从 hub-redesign 开出。
  • 新的所有者决定见下面“待所有者定”第 23 到 27 项。

模型第 10 版（集成者 2026-10-24 凌晨提交，合并了三份修订草稿、两轮独立批评和变量与密钥的提案）：20 项待定事项，18 项已定，2 项暂缓；本地工具下发按决定 35 单列在末尾，不移动原条目。下列历史决定不改写。

2026-10-24 夜至 2026-10-25

• 七项能力在 Otty 真实 Circle（GLM 5.3、千问 3.8）上走流程：定位、查缺、回归范围与巡检、看板、追溯、评审（初评，换不同模型族复核，再到终稿）走通；缺陷转用例起草与命令核对走通，期望身份与去重已修；转自动化完成网关升级、换钥、执行器登记、一致性检查与预检通过。派发待合约 @2 补齐命令身份，并等网关时钟追上。

决定

每条写明来源。来源不在仓库里的条目标“待确认”，由集成者补上日期和出处；确认之前，按仓库里有出处的规则做。

1. 部署（来源：模型 decisionNote，决定表第 1 行选 a；细节见架构第 1、3、5 节）：持久部署在一台机器上，只监听本机；持久的数据库、对象库和密钥库，配置只用 CIRCLE_HUB_*；每次部署前备份（来源：所有者 10-21 批准的计划，背景一节和“决定在计划里的落点”第 1 行）。
2. 先前临时部署的历史（来源：模型 decisionNote，决定表第 2 行选 b）：记为丢失，不迁移。
3. 决定表其余各行按推荐（来源：模型 decisionNote；决定表本身不在仓库里）。落到这个里程碑的：
   • 每个阶段完成后按模型和架构独立复核，修完再进下一阶段（架构第 7 节）。
   • 记录只追加；已应用的迁移从不修改，要改就加新迁移（架构第 2 节）。首次持久部署之后，已部署的历史也不再改写（来源：所有者 10-21 批准的计划，“决定在计划里的落点”决定表 9）。
   • 五要素作设计检查单和记录页布局，不作存储分区；恢复“回执”一词，留给 Hub 对一次提交或请求的应答（模型待定第 3 项，决定表第 11 行）。
   • 模型默认逐例作答（模型待定第 4 项，决定表第 18 行）。
   • 这个里程碑不删任何原件（来源：所有者 10-21 批准的计划，“决定在计划里的落点”决定表 10）。

   其余各行不在这个里程碑，或已被 10-21 的重新设计取代。

4. 通用模型的 19 项待定（来源：模型 pendingDecisions，用 node tools/show-element.ts --pending 查看）：都按推荐处理，17 项已定，2 项按推荐暂缓到第一个需要它们的工作流接入时再定（新增工具与命名；人工接管受管会话的通道、块语言编辑界面、本地工具的下发）。影响这个里程碑的是第 1 到第 4 项：Hub 不用 Circle 内核构建；知识树细化照做（根摘要只算树本身，运行开始时锁定当前根，当前根指针按比较并交换移动）；五要素与“回执”；默认逐例。
5. Hub 是标准 MCP 服务器，不用 Circle 内核构建（来源：模型待定第 1 项与 D06）：本地 Circle、bot 和其他客户端共用同一组工具；只有规划中的 bot 用 Circle 内核。
6. FAMX 与 FAMY 是同一产品的两个名字（来源：架构第 8 节）：产品线以名称集合标识，两族名字下的版本和构建都归这一条产品线；FAMY 名下的构建是它所基于的 FAMX 构建的别名。
7. 真实系统与真实模型（来源：所有者 2026-10-21 夜在确认计划时选定：第一个里程碑只读接入真实业务系统、现在就调用真实的类型化判断模型、评审用所有者自己配置的模型端点；2026-10-22 目标扩大为七项用例能力，并要求最后用 Otty 里真实的 Circle 客户端完成）：只读接入真实业务系统，只经已部署的 Hub 和 scripts/real/ 下所有者的脚本。Hub 从不调用通用模型，也不生成内容：当时已部署的 Hub 只调用 K04 的类型化判断模型（手册片段会发给其服务商）；这一句已被第 15 项取代，Hub 不调用任何模型。评审用的模型（初评和独立复核）只在 Circle 一侧运行（模型分类规则 classificationRules[8]）：第 5 阶段的真实评审在所有者的专用 Circle 主目录里用真实 Circle 客户端进行，连接已部署的 Hub，模型密钥只由脚本在运行时从所有者的配置读取并显示打码值，不经过任何 agent；真实用例和知识片段会发给所选模型的服务商。模型的 resolvedConflicts[20] 已按这项授权改写。测试、CI 和各包的开发检查始终只用脚本化模型，Jev 也用脚本化的。报告必须分开写明合成夹具证明了什么、真实运行证明了什么。
8. Circle（来源：所有者 2026-10-21 夜给出的目标“给你 Circle 整个平台的权限”，2026-10-22 再次确认；设计依据是架构第 1 节与 D06 R[1]）：Circle 整个平台（命令行、桌面、扩展机制、文档、测试）都可以改，在单独的工作树和分支上本地提交，不推送、不建 PR。范围是 D06 R[1] 的六项通用 MCP 客户端改进，以及删去 Circle 现有的 hub 扩展（D06 R[1] 要求 Circle 里不出现 Hub 专用界面）；不加 Hub 专用的界面或标签，Hub 在 Circle 里只是一个普通的 MCP 服务器。
9. 知识同步（来源：架构第 6 节，所有者 10-21 的要求）：知识库要从两族名字、每个版本建，而不是只从一个构建建。由 Hub 执行的常设义务 knowledge sync 每个已发布构建产出一个根，幂等、可续跑，按构建报告产出、跳过和失败。架构简报第 1 节仍把常设义务整体列为不做，知识同步是其中的例外。
10. 七项用例能力与真实客户端（来源：所有者 2026-10-22 的目标）：除里程碑 1 的用例评审外，还要做按模板 v3 查缺、用例定位、回归范围与维护巡检、缺陷转用例、追溯矩阵与质量看板，最后是转自动化（要设备，动设备前先和所有者确认台架、账号和允许的命令类）；每项能力都要有带预期答案的验收。事项最后用 Otty 里真实的 Circle 客户端完成。能力的做法见架构第 6a 节。
11. 词表补三个轴（来源：模型 K02 R[3]、K01 R[2] 与 K01 R[1] 的原文，集成者 2026-10-22）：K02 R[3] 列出的知识条目种类（定义、行为、用例、缺陷、观察）、K01 R[2] 的节点位置（干、枝、叶）和 K01 R[1] 的版本差（新增、删除、修改）在词表里没有轴，代码里只能手写枚举，违反“枚举只来自词表”。模型补 entry_kind、node_level 与 change_kind 三个轴，取值和标签照元素原文，共 53 个轴。产品包的目录声明加可选的 producer，使目录可以只取一个生产器的条目：命令目录只取命令树生产器的“定义”条目，不把手册里的条目算进去。
12. FAMX 与 FAMY 产品包的条目种类（来源：K02 R[3]，集成者 2026-10-22）：命令树给“定义”，手册按命令挂的文字给“行为”，发布说明给“缺陷”；更细的区分（签名或正文、已修复或已知）写在条目的 data 里。
13. 用例节点规则的默认值（来源：集成者 2026-10-22；已被第 18 项取代）：默认沿用架构第 6 节的规则（带 resource 标签的节点才是用例）；参数 caseRule: marked 另取按团队模板的标记识别的用例。真实样本上，前者在 51 份中的 37 份能评审（2706 例），后者 48 份（6045 例）；默认规则下，第一份评审文档是 62 例、6 组。
14. 分工（来源：所有者 2026-10-22 的指示）：停掉全部多代理工作流；以后的代码全部由 Otty 里的其他终端（circle、agy、kimi、grok）写，监督者只监控结果、安排工作、复核和合并、发布部署，并用真实 Circle 客户端做验收。每项任务一个工作树和分支，任务页在 docs/hub-r4-tasks/，进度见交接页。目标不变。
15. Hub 不调用任何判断模型（来源：所有者 2026-10-22 对待定事项 1 的答复）：Hub 本身没有 LLM 能力，所以也没有类型化判断服务（Jev/TypeSafe）的能力；它在部署形态上是插件里的技能，属于 bot 一侧。知识库里需要判断的归位以后由 bot 提议、Hub 用确定性规则核验（路径存在、引文逐字出自原件）；这条流程尚未实现。Hub 里对外调用的客户端、密钥库条目和配置按任务页 no-judgment-in-hub.md 拿掉，数据外发事件的根因因此改为“Hub 不再有这个能力”，不再只靠生产器的声明防（声明保留，表示哪些条目以后可以交给 bot）。
16. 转自动化由 Hub 里的设备管理包提供（来源：所有者 2026-10-22 对待定事项 2 的答复）：转自动化需要的是真实设备管理能力，做成 Hub 的一个任务包：硬件设备的占用、IP 地址管理、版本管理等组合起来用。台架、账号和允许的命令类成为这个包的登记内容和策略，由所有者在第二阶段给出；第一阶段不接触真实设备（设计见 docs/hub-r4-device-pack.md）。
17. 评审只提出问题（来源：所有者 2026-10-22 对待定事项 3 的答复）：评审提出问题；就算人要追加修改，也只能改自己本地 Circle 里的东西，不能改 Hub 里的文件。据此，引擎维持“修复只用于待判定产物上的检查，评审主体上的反驳停在不通过”的读法，改参照、不改引擎；另两处读法（记未知保留不通过、检查必须声明档）按集成者的建议处理，所有者没有异议；见任务页 engine-readings.md。
18. 用例节点规则的默认值（来源：所有者 2026-10-22 对待定事项 4 的答复，取代第 13 项）：各包统一为“带标签或带标记”，保留只认标签的开关；评审写明用了哪条规则、靠标记多找出多少个用例（任务页 union-case-rule.md）。
19. 构建候选带制作时间和基础构建（来源：所有者 2026-10-22 对待定事项 5 的指正，依据是构建站的列表页）：列表页上每个构建都有制作时间（“build on …”），FAMY 的构建写明基于哪个 FAMX 构建；候选列出每个构建的制作时间和基础构建，按制作时间从新到旧，发布状态另写，Beta 构建照列（任务页 candidates-times.md）。集成者先前说“只有少数构建有日期”，是把发布日期当成了制作时间，错了。
20. 带凭据的数据照常处理，数据更新不用问（来源：所有者 2026-10-23）：Circle 本身有传凭据的处理办法；有用的数据就应当处理，数据更新本来就是该做的事，不需要所有者决定。据此，集成者接受了 29 份因凭据扫描命中而只保留的来源（20 份用例文档里的实验室测试凭据，各版本线应用手册和命令手册里的示例密钥与示例地址），记下决定，并重跑知识同步，让它们进入知识库和用例索引。先前“19 份含凭据内容的用例文档继续只保留、不进索引”的默认因此作废。
21. 候选的根据（已被第 25 项取代；来源：模型 K03 R[4]、R[5] 的原文，集成者 2026-10-23 答终端）：
    • 候选可以直接引用文档，被引的文档要过和边界同一套范围核对；
    • 根据里有会话中的说法时，那一段作为源文件上传：只本人可见，管理员也读不到；来源类型是声明；出处是会话 id 和消息 id，客户端没送消息 id 就记缺，不收模型自报的；
    • 上传用已有词表轴 knowledge_layer 的 candidate 值标明用途，不带这个字段的上传行为不变；
    • 模型只看工具返回的文本，所以这两件也写进 upload_file 和 submit_result 的文本。
22. 提交摘要不含候选（已被第 25 项取代；来源：W07 定义的原文“提交摘要覆盖除候选部分以外的全部内容”，集成者 2026-10-23）：候选另按“本人、内容和根据引用”做幂等。主提交去重时，带来的新候选照常核验入层。候选的核验结果不改条目终态，也不计修复轮数。
23. 词表新增三个轴（来源：所有者 10-23 的知识库方向第二节，集成者 2026-10-23 定名）：
    • document_output_kind：分类、归位提议、声明、关系；
    • task_output_kind：排序、取舍、分数；
    • relation_kind：说的是同一件事、互相矛盾。same_subject 只表示两段说的是同一议题，不表示内容等价。
24. 手册落点的细则（来源：所有者 10-23 方向第三节，集成者按调研 2、3 定，docs/hub-r4-research/kb-real-sources.md）：
    • 手册章节和命令在同一个根下分两棵子树，最近公共祖先不跨子树；得到命名空间的根本身不算落点；
    • 交叉链接存作者标出的命令字面，读时精确匹配；
    • 适用条件三字段保持窄，手册条目的构建字段留空；
    • 章节开头的条件先不往子节继承，等所有者定。
25. 候选留在 Circle 本地，成为事实后回注（来源：所有者 2026-10-23 傍晚，取代第 21、22 项）：
    • Hub 里没有按人私有的候选层。
    • Circle 的整合技能（autodream，模型里的 P10）判定某条已成事实时，提交一次回注运行。
    • Hub 只做确定性核验，通过的进回注层，产品的读者可读：引文逐字、路径可解析、不越过声明、关系只记关系。
    • 只有会话说法作根据的，要负责人署名才入层；这一版先不入。
    • 模型的 K03、W07 R[4]、P10、K02 F[6] 在 K2 里照改；任务页 kb-candidates.md 已改。
26. 生成在客户端，Hub 只核验（来源：所有者 2026-10-23 傍晚；理论文档 docs/design/truth-docked-architecture.md 第 3 节 R7：候选的生产和独立检查分开，可信的检查核心尽量小）：
    • P05 不做成 Hub 的核心步骤。任务包随技能带确定性的 TypeScript 生成脚本，Circle 在本地生成执行计划、工作簿这类产物，像 SyntheticReference 的 IDE 那样，然后上传、提交。
    • Hub 回读解析上传的产物，查合约、台架、命令，再按声明的生成规则从槽位重算一遍比对，记下摘要；执行器只执行通过核验的那份。
    • “Hub 不生成内容”这句不改。编译包要按这个改。
    • P05 剩下的“几块并列最差时等级怎么取”仍待所有者定，集成者建议取最差的。
27. 上真实设备（来源：所有者 2026-10-23 傍晚）：
    • 用所有者指定的 SyntheticReference 那套测试环境验证；地址属于部署数据，不进 Git。
    • 编译并上机所有者指定的一个用例。
    • AGENTS.md 里 SyntheticReference 只读的规定，只在这一件上放开到：读这套环境的接入方式和这个用例，作为部署数据用。不运行 SyntheticReference 的代码，不进 Git，不显示凭据。
    • 先只读核对，再执行用例，不重启设备。
28. SVN 同步（来源：所有者 2026-10-23 傍晚）：Hub 用所有者给的 SVN 账号只读同步 adoc，凭据存进 Hub 的密钥库。
29. 推送和建 PR（来源：所有者 2026-10-23 傍晚：合并完成就推送和建 PR）：
    • 这一轮合并完、全量检查通过后，推送并建 PR。
    • 分支更早的提交里有真实值，仓库是公开的，所以推一个压缩成新提交的干净分支，先过全仓检查。
    • Circle 的 hub-mcp-client 查过后同样处理。

    （第 44 项：推送要等 FAMX 包里的真实约定先变成变量，也就是等 hub-variables 第二步和 famx-deployment-conventions 的 FAMX 那一步）

30. 工作簿读取分两层（来源：docs/hub-r4-device-run.md 第 3 节；集成者 2026-10-23 答终端）：
    • 核心的 xlsx@1 解析器只因通用理由整份拒绝（zip 上限、路径、加密、重复成员、部件或关系缺失、XML 被修复过），结构如实给出；
    • “只认生成器写的子集”由 case-compile 包的核验检查判。
    • 任务页 xlsx-parser.md、hub-case-workbook.md 已照改。
31. 派发的接口（来源：同一设计第 4 节和第 8 节的接口；集成者 2026-10-23 答终端）：
    • 执行器定义声明证明用的包名、要求项名和各字段的 JSON 指针；
    • 本轮要租用的资源键由管理员显式配置，等于 test-bed 预订这个台架时的设备集合；
    • bed 是 {id, manifest_sha256}，两个字段都和执行器定义里的期望值比；不等就拒绝，写明下一步是用当前清单重跑核验运行。（第 44 项：期望的清单摘要可以写成 ${var:BED_MANIFEST_SHA256}，重发台架清单以后执行 var set，不用 executor update；资源键照旧只经 executor update 改）
    • 证明里带 plan_run（工作簿据以生成的已满足计划运行），派发时和核验运行自己的 predecessor 比；不等就拒绝，写明下一步是用计划运行作 predecessor 重开核验运行。
32. 编译包 2.0（来源：决定 26；集成者 2026-10-23 答终端）：
    • Hub 侧生成计划的要求项随 2.0 移除；
    • 槽位写替换后的最终执行文字，替换表记原地址到台架地址；
    • Hub 重算引文的替换并核对，拒绝漏替换的原地址，不替模型改写。
33. 记录的规范写法（来源：codex-e 在 hub-job-dispatch 里查到，集成者 2026-10-23 在持久部署上只读核实）：
    • 租约服务绕过记录库直接写动作记录，正文没用规范 JSON；持久部署里有 15 条这样的租约动作。按规范 JSON 重算，内容和摘要都一致，但读记录时的逐字节核对会把它们报成“存储被改动过”。
    • 改法：
      • 写入改走记录库，正文规范、size 记字节数；
      • 读取时先逐字节核对，不过再把正文严格解析、规范化后按摘要核对。摘要本来就按规范化的内容定义，所以这样核的正是摘要的定义，不算放宽。对得上照常读出，并记一条“正文不是规范写法”的说明；对不上照旧报完整性错误。
    • 历史不改写。
34. 读时交叉链接（来源：K05 R[2]，集成者 2026-10-23 答终端，任务页 kb-links.md）：
    • 链接规则由产品包声明：字段、命名空间、匹配方式。匹配方式是新轴 link_match（K05）：
      • exact：整个字面就是路径；
      • longest_prefix：从头取最长的命令词，剩下的是参数。
    • FAMX 用 longest_prefix，种类是 definition，和生产时、catalog@1 查命令的规则一致。
    • 声明的快照放进组成记录（tree_root），不进根节点的摘要。读时用锁定的那份组成里的声明，同一份组成、同样的请求，字节相同。
    • 没有快照的旧组成给确定的结果“这份组成没有链接声明”，下一步是重新生产。
    • 备选字面组（10-23 晚补，kb-links 首轮复核第 1 条，集成者答 codex-b）：像 <命令> {甲|乙|丙} 这样写着几种备选的字面，同组先精确核主干。主干在目录里有定义就算链上，不再看展开的变体（甲、乙、丙可能只是参数值）；主干没有定义，才逐个精确核展开的变体，查不到的变体才算漂移。这是声明里的一个通用字段，生产时的漂移警告和读时的视图用同一个函数，和 K1 判挂点的做法一致。
35. 待定各项按“能用全用、能做全做”定（来源：所有者 2026-10-23 晚对“待所有者定”整节的答复）。 底线不变：AGENTS.md 的安全规矩（真实系统只读、不重启设备、真实数据不进 Git、凭据不显示），以及所有者先前明确的设计（Hub 不调用任何模型、Hub 是通用平台）。下面按原来的编号写结果。
    • 知识库：
      • 2：没有发布记录的规格类文档，挂进产品线“不分版本”的范围，构建字段记未声明，各版本都读得到。普查 5.2 第 6 条那 762 份没有版本线的用例文档也这样处理。
      • 3：adoc 按名称族各设本族的品牌属性，两族各产出一份，属性集进组成记录。属性名由集成者从源里只读整理，作为部署数据。
      • 4：章节开头的条件继承给子节，标明“继承自章节开头”，并带出处位置。
      • 5：适用条件加部件、内存、许可、部署形态几个字段，只从闭集和明写的文字里取。模型 K01 由集成者改。
      • 6：只有会话说法作根据的回注不入库，因为确认不了说的对不对（所有者 10-23 晚）。要入库，就先在 PLM 或敏捷平台上登记，再由 Hub 同步进来。
      • 9：FAMX 包里的真实版本线约定挪进部署数据（资源设置），包里只留合成的默认值。（第 44 项改为：挪进 FAMX 包声明的变量，见 hub-variables）
      • 10：文档主机上的 ops/knowledge-sync 和 Hub 无关，Hub 不管它（所有者 10-23 晚）。它从 circle-hub 仓库里移出去，文档主机上不动。
      • 27：Bugzilla 先不接（所有者 10-23 晚），记确定的“缺陷在 Bugzilla，状态未读”。
    • 能力：
      • 1：几块并列最差时，取最差的。
      • 18：用例定位的五个约定都取“用上”：
        • 自相矛盾的版本层，两个值都留，记成确定的冲突；
        • 目录名里的构建名，算这一层的版本；
        • 混在别的字里的版本作引用，单独的版本标签作版本；
        • “bug to case”后面的编号按缺陷号读，并在 PLM 里核对，没有就记“PLM 里没有”；
        • 版本层以下目录名里的编号，关联到它下面的每一份文档。
      • 19：24 个类别都必选，另外按命令出覆盖。
      • 20：按原因计数，不算不符，照现在。
      • 21：需求按原样状态计数，另按 PLM 自己的阶段字段分组，不自造映射。
      • 22：追溯和看板的结果，分享给能用这个包的用户。
      • 13、16：W04（判定台账）、W10（判据变更声明）、V07（重复策略）都做，D03 和 P11 的边界也装配上；D04 R[0] 的修订确认。
      • 14：设备归登记它的用户（所有者 10-23 晚：谁的环境就是谁登记的）。设备的主人看得到谁占着、占到几点，也能释放；别的用户看得到“被占用，到几点”，看不到是谁。
      • 15：不要预约时长的限额（所有者 10-23 晚）。租约只在运行期间持有；用户读得到哪套台架正被哪个运行占用。
      • 23：要求独立复核的提交不带会话 id 就拒收，修正说明写明怎么带。
      • 24：跳过或未覆盖的条目上，事实要求项用 Hub 自己算出的终态。
      • 25：不加工具（所有者 10-23 晚问这类请求从哪来，集成者答：是 Hub 自己卡住、要人做一步的时候，比如修复轮数用完要运行者选续跑还是放弃，登录被锁要管理员重置）。这些用现有的工具和命令就能做，Hub 只在回答里写明下一步该谁做什么。
      • 26：Hub 自己评估运行时，按运行开始时的授权读冻结的输入；别人查看时，按读者当前的权限。
    • 运维与记录：
      • 7：推送时压缩成新提交（决定 29）。
      • 8：Hub 不用 Jev（决定 15）。给 Circle 客户端做一个 Jev 的技能，密钥只在 Circle 一侧，由技能脚本在运行时读（所有者 10-23 晚）。
      • 11：真实评审改用 Qwen（所有者 10-23 晚），密钥照旧由脚本从环境配置文件读，不再读 GLM 的设置。
      • 12：第一次真实评审用的构建是基线，要记（所有者 10-23 晚）。真实构建名不进公开仓库，记在部署数据里（Hub 的资源设置），这里只写“基线构建见部署数据”。（第 44 项改为：记在变量 REVIEW_BASELINE_BUILD 里，没有包读它）
      • 17：10-22 的外发结案，不再处理（所有者 10-23 晚：发就发了）。
    • 新需求（所有者 10-23 晚）：用例评审的输出按测试子项分表格，每行对上原始用例和评审意见；现在的输出不好看，也对不上。
    • 上真实台架（docs/hub-r4-device-run.md 第 6 节）：
      • 第 1 问：指定脑图里 5 个 auto:YES 的用例全编全上。先查它在敏捷平台上有没有文档号，有就按号绑定，没有就上传文件。
      • 第 2 问：合约、台架清单和运行环境配置都算接入方式，由转换脚本生成，管理员发布成部署数据。
      • 第 3 问：合约身份取网关钉住的那份。
      • 第 4 问：合约启用的（对象，方法）全开，拒绝表照旧：设备上拒绝重启、清配置、升级、HA，主机上拒绝重启、关机、格式化。
      • 第 5 问：设备命令行里可以出现本台架其他设备的地址；台架外的地址照旧只能经替换表换进来；在用和保留的地址段，从网关拓扑只读取得。
      • 第 6 问：用只读探测逐台看版本和接口地址，命令取合约里的只读命令。
      • 第 7、8 问：改网关（所有者自己的服务）。上机前记请求 id，按它去重，提供只读查询；拒绝时写明阶段和是否已上机。网关改好以后，结果按派发身份归属并认证。
      • 第 9 问：运行器在 Hub 之外的动作照常接受，作为观察记进结果。
      • 第 10 问：不通知别人，结论带“未排除本地操作”。
      • 第 11 问：TLS 加固定的实验室 CA，沿用只有运行权限的那把密钥。密钥由集成者先在现有部署和环境配置里只读找，找不到再请所有者经标准输入给。（第 44 项：hub-variables 第一步部署以后，钥匙经标准输入交给 circle-hub secret set --name GATEWAY_RUN_KEY，执行器定义按名字引用它，先登记执行器再交；在那之前照旧经 executor add 交，部署以后 executor update 加上 credential 时迁移过去，不用重交）
      • 第 12 问：这一轮由集成者把脚本放进所有者 Circle 的技能目录，并核对摘要；Hub 的通用下发也做。
36. 片段读取状态轴 fragment_read（来源：集成者 2026-10-23 下午作为模型负责人授权 core-fixes 加这个轴，T04，原因是检查时的片段分级不能手写取值；当时只发给了终端，没记进这里，10-23 晚复核查出后补记，并按复核把取值分细）：
    • bound：已绑定可读。
    • not_bound：不是这次运行的输入。src: 和 tree: 引用照原来记的决定判驳回，修正说明写该引哪份输入。
    • not_groundable（新加）：这类记录不能作根据（B01 R[4]），驳回；修正说明写改引结果、动作或效果记录。
    • entry_unaddressed（新加）：知识条目单独引用了，没写树地址（B01 R[5]），驳回；修正说明写 tree:<根>/<路径>@<条目>。
    • malformed（新加）：引用写法不对，驳回；修正说明写对的写法。
    • no_fragment：找不到片段，驳回。
    • too_large：超过大小上限，驳回；修正说明写改引更小的片段。
    • retain_only：只保留、不可读。记未知，缺的事实是管理员接受这份来源，下一步给管理员发请求，接受后自动重评。
    • unavailable：暂时读不到。只留给真正的暂时故障，记未知，下一步是重读。
    • integrity_unproven（10-23 晚补，core-fixes 收尾核对第 2 条，集成者答 codex-d）：记录或原件的字节和摘要对不上，是永久的，不是暂时取不回。标签沿用 V03 原因轴里同码的「完整性未证明」。记未知，缺的事实是一份和摘要对得上的字节，下一步是管理员从可信备份恢复记录或原件，再重新核验；不提示重读。
37. 解析失败的原因和中文换行处的引文（来源：xlsx-parser 的交接和未知普查第 2 节，集成者 2026-10-23 晚按决定 35 的原则定，任务页 refs-diagnostics.md）：
    • 所有解析器都拒收一份上传时，上传和开跑的回答写出最后那条确定的原因和改法；新协议码 SOURCE_UNPARSEABLE。
    • 合法编码照收：带 BOM 的 UTF-16、GB18030、GBK、Big5；不带实体的 DOCTYPE 照常解析。
    • 引文比对：一段空白两侧有一边是东亚宽字符或全角字符，就去掉这段空白；两边都是拉丁字母、数字或符号时，照旧折成一个空格。中文手册硬换行处的引文因此不用补空格。
38. 回注准入的拒收码登记成核心码（来源：K2 收尾核对第三轮第 6 条，集成者 2026-10-23 晚作为契约负责人答 codex-e）：
    • 回注层的准入核对在 hub/knowledge 里，是核心发出的，原因码登记进核心码表 contracts/codes.json，写成 core.contribution.<规则>，各带 when 和 fix，照生成器重新生成。不再挂在声明回注的那个包的名下。
    • 凭据命中照用已有的协议码 CREDENTIAL_IN_UPLOAD。
    • 回注包里那份没人核验的码表删掉，包升版、重签。码表的 interpreter 字段要是只认已安装的解释器，先回报集成者改登记表，不硬塞。
    • 10-24 凌晨补（K2 合并后收尾核对第 4 条）：码表照旧不加字段，interpreter 写的是发出这个码的核心部件，contribution 是回注准入，不是可装的解释器（码表的 note 已这样写）。包校验判一行错误处理“用得上”时按发出部件分两种：解释器发出的码，看这个要求项的检查有没有用到那个解释器；回注准入发出的 core.contribution.*，看 workflow.contribution.requirement 是不是这个要求项。docs/design/generic-model.md 讲错误码登记的那段同改。
39. 记录库加一个事务级锁（来源：K2 收尾核对第三轮第 4 条，集成者 2026-10-23 晚答 codex-e）：
    • RecordStore.lock(key, tx)：事务级的 advisory lock，只在给定事务里持有，提交或回滚就释放；照 artifacts.ingest 内部已有的写法。键先按类型加前缀再取哈希，不和别的锁撞。不改迁移。
    • 第一个用处：内容相同的回注并发提交只存一份。几个条目按内容键排序依次取锁，免得互相等。
    • hub-job-dispatch 上另有“唯一业务键”（37577e99）。那件合并以后，集成者再看这里的去重要不要改用它，两套不长期并存。
40. 派发方式能配哪些角色（来源：hub-case-runtime 收尾核对第三轮第 3 条，集成者 2026-10-23 晚答 codex-c；依据是运行器的派发机制：F 列就是在 E 对象上取同名方法，用 G 解析出的参数调用）：
    • 这张表写在 case-compile 的格式表里，每行写明依据：
      • cmd_primitive：把 G 原样当命令文字转发，设备和主机上都有，只许设备命令行、主机 shell 两种角色，都过目录和拒绝表；
      • checkpoint_two_argument：只许字面断言；
      • builtin_special_case：只许等待；
      • direct_method_call：直接调一个组合方法，方法里做什么，参数的角色和拒绝表都核不了。参数照四种角色配，方法本身由集成者只读看过以后逐个显式开，和零参数的方法一样。草稿里先列成待定，写明缺的事实和下一步；
      • 动作注册表和三参数检查点：没有能配的角色，这一轮不开。
    • 决定 35 上台架第 4 问“启用的组合全开”照旧，拒绝表照旧；这一条只是把核不了的那部分交给显式决定，守住不重启设备的底线。
41. 手写枚举扫描的边界（来源：core-fixes 收尾核对第 3 条，集成者 2026-10-23 晚答 codex-d）：
    • 对象只认“键是某个轴的码、值是字符串标签”的映射表，比如手抄的标签表；Record 和 satisfies 约束的照旧豁免。结构字段名恰好和码同名（run、item、min、max 这类）的不算。
    • 比较链：被比较的值没有生成的轴类型，又比了同一个轴的两个以上的码，就算手抄的子集，不论是不是全集；值已经是生成的轴类型或它的 Extract 子集的，照常放行。
    • 正反例写进扫描的自测，README 写明边界。
    • 10-24 凌晨补（core-fixes-2 收尾核对，集成者答 codex-a）：两处都按类型判，不按名字或路径，扫描不加路径例外。
      • 比较链里，被比较的值是某个声明的结构类型的键（keyof 那个类型，比如范围规格的 min、max）也放行。不按 run、item、min、max 这些名字豁免，免得把真正手抄的轴比较一起放过；误报的地方给值加上类型。
      • 上面“Record 约束的豁免”收窄为：键是生成的轴类型、或 satisfies 生成的类型的才豁免；Record<string, string> 不证明键受约束，不豁免。命令说明这类结构表给它一个声明的结构类型，按类型放行。
42. 控制台运行页显示投影的字符串字段（来源：review-output 首轮复核第 8 条，补记集成者当时的答复：完整的表放在控制台运行页）：
    • 运行页加一节“投影字符串字段（只读）”，原样显示运行投影里的字符串字段，做转义，不写任何工作流的字段名。这是通用的核心改动，在 review-output 分支上做（ea5328d1），任务页的可改路径补上 hub/server/console/**。
    • 当时只答了终端，没记进这里，10-23 晚复核查出后补记，和决定 36 同一种疏漏。
43. 执行器的时钟偏差（来源：hub-job-dispatch 首轮复核第 11 条，集成者 2026-10-24 凌晨答 codex）：
    • 执行器定义加 clock_skew_ms，默认 0，只由管理员显式登记。
    • 只用在网关查得到这次请求的记录时，比对投递时间窗。
    • “查无记录就是没执行”的时刻条件不因它放宽：网关时间 > not_after > gc_before ≥ journal_since，几个时刻都按网关自己的时钟比。网关按同一个时钟拒收过期的请求，所以这条证明与两边的时钟偏差无关。
44. 变量和密钥（来源：所有者 2026-10-23 22:40：“Hub应该和circle一样，可以写变量然后引用才对”；任务页 hub-variables.md）：
    • 管理员用 circle-hub var set、secret set 写有名字的变量和密钥；名字规则同 Circle，一个名字一种，每次写理由，记成只增的资源配置决定。
    • 资源的设置和凭据项、执行器定义的期望值和 credential、产品包的同步选项和生产器参数，用 ${var:名字}、${secret:名字} 整值引用；Hub 不解析客户端的输入。
    • 密钥只从标准输入读，每一版只发往设置时登记的使用者和地址；列表里只有名字、第几版、摘要规则和长度。普通变量是部署数据，列表默认不显示值。
    • 产品包声明它读的变量，名字属于第一个发布时声明它的包；真实同步时没设置就拒绝并写明命令，默认值只给样例和试运行。
    • famx-deployment-conventions 第一步取消，由 hub-variables 第二步取代；kb-adoc 的接线挪到 famx-deployment-conventions 的 FAMX 那一步。
    • 集成者默认（所有者可改）：
      • 模型在工具参数里按名字用 Hub 变量，这一版不做。
      • 在 Circle 一侧给指定 MCP 服务器关掉密钥替换，这一版不做；Hub 一侧先扫描 start_run 参数，以后作为通用 MCP 改进另开一页。
      • 决定 29 的推送照原计划放在最后，等变量两步和 FAMX 那一步做完。
45. 有权读者面前的确定读取结果码（来源：集成者（模型负责人）2026-10-24 凌晨答 codex/codex-b，06:20–07:59）：

    • 五个读取协议码只给已经通过读取身份与权限校验的调用者；无权或身份未定的读者仍只看到中性的 SOURCE_UNAVAILABLE，不披露来源是否存在、状态、重定向地址或真实失败原因。只保留来源的字节隔离照旧，不因有这些码而放开。

      码	用途与确定的事实	只给谁	下一步
      SOURCE_RETRYABLE	有界退避重试仍失败，回执带下次可重试时间	已确认有读权的调用者	到给定时间重读；仍失败则按缺失事实转交具名负责人，不以未知结束
      SOURCE_INTEGRITY_UNPROVEN	原件或记录缺失、字节与摘要不符，完整性未证明，不是暂时读不到	已确认有读权的调用者；恢复交管理员	管理员从可信备份恢复与摘要相符的字节后重新核验，不用反复重读代替恢复
      SOURCE_REDIRECT_REFUSED	已观察到但未获声明允许的重定向，带应答状态和脱敏后的 Location	已确认有读权的调用者；路由核对交资源管理员	资源管理员核对路由；同源且已声明的跳转由规划函数发下一条请求，不自动跟随未声明的跳转
      SOURCE_READ_LIMIT	内部 READ_LIMIT 的对外映射，路由页数或读取预算已到上限	已确认有读权的调用者	指明哪项上限，由管理员调整或由调用者缩小范围后重读，不把部分读取当完整结果
      SOURCE_READ_FAILED	已确认的非重试读取故障：应答格式不合法、投影或规划输出失败、修订不匹配	通过读取身份校验且有读权的调用者	按具体故障修正应答、包的投影/规划或修订绑定后重读，不再退回没有改法的中性码

    • 同次授权还登记两个处置/运行协议码；它们不是读取故障，不扩大运行和效果记录的可见范围：

      码	用途	只给谁	下一步
      EFFECT_UNKNOWN_DISPOSED	效果原结局仍未证明，运行者已具名选择标记失败处置，按 V05 归入已拒收	有权查看该运行、处置与效果记录的读者；处置仍由有权操作者作出	依处置请求继续核对或重证基线、开新修订；原结局和冻结/解除许可仍按原记录，不能把处置当作已证明未执行
      RUN_ABANDONED	运行已被管理放弃；其后的新提交仍原样保存，但不受理	该运行的有权提交者及有权查看回执的读者；放弃仅运行者本人或管理员可作出	用 start_run 以本运行为前驱开新修订，不改写已放弃运行、旧结果或远端状态

    • 动态层 fail 的 code 可选：有真实失败观察却没有专用码时仍可记失败，不编造码，也不因无码退回未知。只向有权查看该运行的读者披露真实失败及依据，下一步按失败事实核对、修复或开新修订；效果仍未证明的不能借此记成技术失败。
    • 新码写进模型的协议码源和变更记录，照生成器重新生成。各任务的最小接线授权见 hub-read-absence.md 和 hub-unknown-exits.md。
46. FAMX 命令树的 limit 写法（来源：集成者 2026-10-24 07:45 凌晨答终端；集成者只读核对了 12 份真实命令树，非空 limit 全是区间，length 全空）：
    • 这一轮只实现区间写法（[N - N]），不从空的 length 推出长度约束，也不为其他写法猜含义。
    • 其他非空 limit 不推约束，给出确定的诊断；该约束记未核对，缺的事实是“写法含义”，下一步由包作者在 README 声明含义后重新生产，再核对使用它的内容。不能因解析器不认识写法就反驳被判内容。
    • 参数带未核对约束的 missing、原因和修复动作；目录匹配器对此返回 unknown 与顶层 missing，不报反驳。契约和目录分支的授权见 hub-view-scope.md。本记录不写真实构建名或原件内容。
47. 网关的认证和改动交给集成者（来源：所有者 2026-10-24 上午：“那你改吧 网关随意改”，此前所有者问了运行密钥和认证的通用性）：
    • 认证的分法：Hub 和每个执行器之间只用一种认证，TLS 加 Bearer 令牌（MCP 授权规范的形式），令牌按名字存成密钥，只给运行权限，执行器那边只存摘要；执行器和产品设备之间用设备自己的认证，设备口令只在执行器上，Hub 不碰也不直连设备。
    • 运行密钥换新：集成者在本机生成，明文只经标准输入进 Hub（circle-hub secret set --name GATEWAY_RUN_KEY），跳板机上的摘要文件换成新摘要。
    • 跳板机上的网关升级到这次改过的版本（请求号、日志身份、拒绝写明阶段等）由集成者做，放在 Hub 持久部署之后、上台架之前；网关仓库的推送和打 tag 照旧不做，除非部署必须。
48. 复核类前驱的缺省绑定（来源：集成者（模型负责人），2026-10-24；分支 verify-predecessor-default）：
    • 复核类的包绑前驱，只在 artifact_under_verification 槽上显式声明了默认来源才绑：绑该槽前驱最新已受理的结果；不从 accepts 推断缺省绑定。
    • 没有已受理的结果可绑时，复用 SUBMISSION_SCHEMA_VIOLATION，path /inputs/<槽>，附缺的事实（该槽没有已受理的前驱结果）和下一步（先取得已受理的前驱结果，或显式给该槽输入）。
49. 不分版本的根（来源：集成者（模型负责人），2026-10-24；分支 kb-unversioned）：
    • 来源清单完整、生产器正常返回空时，允许产出空根：组成记录写明“清单完整、选中 0 份”，报告不计失败，读者读到空结果时带同一句说明。
    • 失败情形照旧拒绝：清单读不到、生产器报错等不因这条变成空根。
50. 知识计数的口径（来源：集成者（模型负责人），2026-10-24；分支 sync-report-counts）：
    • 加一根 knowledge_count 轴（K05），把“未挂到树上位置的条目”与“未归位（没有命令归属的用例）”分开计数。
    • 两个数口径不同，不必相等；同步报告两者都写，不互相折算。
51. W04 的落地口径（来源：集成者（模型负责人），2026-10-24）：
    • 运行内的表格式合法但样例不过、缺样例或只有作者样例：受理运行，结论加 conditional_on_judgment 与 discrimination_not_established 两个限定标记，不整份拒收；结构错误（表格式不合法）才整份拒收。
    • 运行级的要求项沿用已有边界：只出跨条目主张，不落成条目终态。
    • 运行内 catalog@1 的目录：继承同一要求项模板检查声明的唯一目录；声明的目录不是恰好一个（零个或多个）时记未知，下一步由包作者声明唯一绑定后重开。
52. V07 的模型条文（来源：集成者（模型负责人），2026-10-24）：
    • 模型 R[0]–R[2] 保留原有更细的条文：首因不丢、混合结果记确定的“间歇”、缺判定列明缺哪几轮并重跑；不用粗版文字覆盖。
    • 纯函数汇总核心已合入（hub/runs/engine/repetition.ts）。
53. 部署变量的空集（来源：集成者（模型负责人），2026-10-24）：
    • 适用条件的三个闭集（部件、许可、部署形态）没有收集之前显式设为空集：字段不省略，也不填占位值。
    • 收集这三项是数据工作，不需要所有者决定；收进来的值按部署数据处理。
54. 性能修复（来源：集成者（模型负责人），2026-10-24；分支 hub-view-perf）：
    • 三处列为性能修复：大视图读取的内存和耗时、派生视图的数据库往返、沙箱每次调用的预检扫描。
    • 修完仍要求同输入同字节；每项预算写成测试，钉住不随负载抖动的量（查询次数、峰值内存），墙钟只作宽松上限；不在文档里写经验数字。
55. 导出工具的文档键（来源：集成者（模型负责人），2026-10-24；分支 export-facets）：
    • 大构建的文档键改由分面视图一次枚举，再按恒等式核对（分面枚举的并集等于全量键集），不逐键全量扫描。
56. 能力 7 的上机与网关（来源：集成者（模型负责人），2026-10-24）：
    • 台架用所有者已定的自动化环境；地址和账号只在部署数据里，不进文档或 Git。
    • 网关升到 0.4.1：运行钥匙的重叠切换（上一把摘要文件与当前并存、显式删除即撤下）、结果的完整性（complete）和提交时间（submitted_at）字段。
    • Hub 侧的执行器定义登记 result.complete 与 result.submitted_at 两个指针；版本声明和前提认证用 0.4.1 的新证据，不沿用旧认证。
57. 验收工作文件的存放（来源：集成者（模型负责人），2026-10-24）：
    • 集成者的验收工作文件放在不进 Git 的本机持久目录；临时目录重启会清掉，不能当存放处。
58. 判据变更声明（W10）的裁定（来源：集成者（模型负责人），2026-10-24；分支 w10-criterion-change）：
    • 冻结形态：运行记录只存引用（声明、复核结果、复核人账号的 rec:），运行上下文冻结全文加引用交给检查（B03 R[0]）。
    • 作者账号取运行者，没有运行者取配置者，与请求受众路由同口径；代跑的运行运行者不变，仍算作者；只写在一处并测试。
    • 同一运行重交同一声明按（运行、条目、判据引用）去重，后者取代前者；旧请求只追加一条回答，新请求等复核。
    • 过期与冻结以 start_run 时刻判断：那时已过期或未答的不带；之后才接受的进下一次新修订。被取代判据是条目级字段，每次开新修订重新冻结并列出。
    • 声明分散在多份受理提交里时，每份各开请求、各要一次复核运行。
    • 请求记录加“声明位置”字段（进 model.json 生成）；只放宽 start 的可见性门；复核包显式绑定声明所在的提交，不与决定 48 的缺省绑定混用。
59. 重复执行汇总（V07）的裁定（来源：集成者（模型负责人），2026-10-24）：
    • 效果表那一行的“写的次数”用显式字段 repetition（进 model.json 生成）；budget.count 只作上限。
    • 时间窗起点和“一轮开始”以该轮派发意图写盘的时刻为准。
    • 网关结果 complete=false 的轮：仍在跑的记 pending（过渡，出口是等待或对账），丢失的记 no_verdict；都按缺判定规则进汇总（取最弱、列缺哪几轮、出口重跑这几轮）。
    • 首次通过提前停：剩下的轮不写效果记录，分母仍是冻结的次数，写明“首轮通过，按策略提前停，剩 N 轮未跑”。
    • 包声明的重复次数超过允许效果表那一行的预算时拒绝发布。
60. 关键词整改的口径（来源：所有者 2026-10-24 规矩；集成者（模型负责人）裁定 R1–R10）：
    • 所有者：编译与评审过程中的关键词、词典、同义词、前缀表、自由文本正则一律禁止；候选来源的关键词检索也禁止；版本线写法差异（10.5 与 10.5.0、前导零）由产品包声明为同一条线的命名规则。
    • 允许的只有三种：按权威源的真实语法解析并完全相等（命令树、目录结构、编号语法、构建名语法）；作者在闭集字段上的显式声明（不等即结构违规，不做同义映射）；模型主张带逐字引文，由 Hub 机械核验（引文存在、路径可解析），另有独立复核保证查全。
    • R1 模板类别只留 id、label、group 与说明，类别来源只有作者声明和模型主张；R2 标签变体记结构违规；R3 含糊期望交模型主张，看板只聚合已受理评审并写明分母；R4 命令只按锁定命令树的完整语法认定，参数类型只取结构化声明，没有就记“类型未声明”；R5 地址类型只来自合约的 typed 声明，没有就阻止派发；R6 定位只认声明的目录结构语法，认不出记未知并给出口；R7 fixed/known 只取结构化字段，查重按规范化结构；R8 凭据扫描保留为只会收紧的防护，命中只表示“可能含凭据”；R9 金标准同样不许关键词，语义标签由冻结的人工或独立模型标注；R10 已有结果不删不改，标“旧规则（关键词）”，新包和模型版本重产。
    • 整改分十个任务页（docs/hub-r4-tasks/kw-*.md），由终端在各自分支完成后合并。
61. 标签字段的规则（来源：集成者（模型负责人），2026-10-24）：
    • 用例标签仍读 KityMinder 的 resource 字段；包的模板表为每个标签 id 声明一个精确字面，另给允许字面的闭集；不等于任何声明字面的值记结构违规（提示档，写明应改成哪个声明值），不做同义映射。
62. 知识库定稿（修订 2）（来源：所有者 2026-10-24 定方向；细节由集成者（模型负责人）2026-10-24 夜按所有者“你定”定下，可回退）：
    • 每条产品线 × 版本线一棵树苗，只由 APP adoc、CLI adoc 和该版本线已发布构建的命令树 XML 合成；/commands、/manual/cli、/manual/app 三组节点；CLI 章节只在签名与路径完全相等时挂命令节点；同输入同字节；旧的每构建根不删不加。
    • 用例、缺陷、需求/规格、构建、自由文本不进树苗，进挂在树苗旁、不算根摘要的喂入层，只在 Circle 用到时进来（运行里经 Hub 连接器读到或上传为输入），不再整批生产。结构化来源的槽位由 Hub 程序读到时按来源系统 schema 与产品包解析规则填；Circle 只经回注运行补语义（分类闭集、归位提议、声明、关系、适用条件），带逐字引文，Hub 核引文、路径、闭集值。身份按内容摘要。结构契约由模型与产品包声明生成，随包下发。
    • 版本绑定是对象与版本线之间的主张，出处只有来源结构（程序按声明语法解析目录版本层、PLM 版本字段、构建站修复清单、目录名、构建名）和人的声明（case-location 的 line 参数、回注里的版本声明）；模型读内容推断版本禁止；运行目标只记使用记录；继承只按产品包声明的规则（沿用 min_line）。
    • 版本不清不问人、不阻塞：进产品线不分版本范围，标“版本未声明”，照常参与回归范围、巡检、追溯、看板，单列计数、不进版本差；控制台每份文档一条待办，目录改好后自动绑定。唯一的问人在 start_run：包要求版本而没给、结构也定不出时拒绝并列候选。
    • 冲突：结构问题按产品包声明的权威源判（命令存在看命令树，缺陷状态看 PLM，发布看构建站，版本看目录再看声明）；语义矛盾不裁决，建 contradicts 关系两边都返回，引用了有矛盾主张的结果自动带限定；矛盾只靠设备测试、来源新修订、记录系统登记消解。
    • 伪造：喂入层一切陈述的根据必须是 Hub 自己经连接器读到的原文；上传只对上传者和管理员可见、不作团队根据；闭集、命令、路径解析不出即拒；Circle 的语义只能是判断，不抬高等级，知识条目不能单独作 Hub 判定的根据；每次被用到重核并记漂移；管理员可追加撤回记录使条目失效。不设审批。
    • 集成者定的七项：组成依据加“来源结构”一档；沿用产品包的继承规则；每类结构问题的权威源表写进产品包；关系种类加 covers；自由文本分类闭集为对象种类加工单、纪要，其余记未分类；管理员撤回记录是唯一的事后纠正；旧每构建根不动。
    • 分工：方向 1（树苗生产）由 circle 在 kb-seedling 分支做，任务页 docs/hub-r4-tasks/kb-seedling.md 按本决定修订；方向 2（喂入层、绑定、契约）另写任务页 kb-feeding.md，在合并浪潮之后做。
63. 运行中不问人的落实（来源：集成者（模型负责人），2026-10-25）：
    • 评审复核按前驱缺省绑定评审对象，终稿按血缘取复核结果。
    • 追溯按构建修复清单自动收窄用例索引。
    • 缺陷转用例的期望引用身份和去重键由 Hub 从解析结果推出。
64. PLM 修复说明（来源：集成者（模型负责人），2026-10-25）：
    • 禅道类缺陷没有单独的修复说明字段。
    • 资源设置 bug_fix_actions 声明哪些动作码的备注算修复说明；集成者选了解决、SVN 提交、Git 提交。
    • fix_notes 只收动作码完全相等的备注。
65. 平台页与点名构建（来源：集成者（模型负责人），2026-10-25）：
    • 产品包变量 FAMX_INCLUDE_PAGES 选入平台页。
    • FAMX_PINNED_BUILDS 按完整构建名点名，选入页上完全相等的条目照样成根。
    • 设备显示写法由产品包命名语法（单一字符替换）声明为构建的已核实别名，执行器提取式只去掉厂商前缀。
66. 发布说明缺结构化状态（来源：集成者（模型负责人），2026-10-25）：
    • 发布说明缺结构化状态时，缺陷条目记未声明，不再让整个构建生产失败。
67. 能力 7 的网关（来源：集成者（模型负责人），2026-10-25）：
    • 跳板机网关升到 0.4.2：源码发布目录，原子切换，旧发布与状态已备份。
    • 运行钥匙按重叠方式轮换后撤下旧钥。
    • 跳板机时钟偏快 6 小时半且 NTP 不同步，已校正。
    • 网关请求记录的时钟下限只进不退；期间的提交会判过期；不重置记录，等真实时间追上。
68. 能力 7 的台架（来源：集成者（模型负责人），2026-10-25）：
    • 执行器只探测派发目标（负载均衡座位），其余清单设备只参与拓扑和地址绑定。
    • 真实合约按原格式读入（对象名在 e）；工作簿标记写钉住的原合约身份；@2 增补作为部署声明。
    • 检查点 result 由执行器提供。
    • profile 里永不传入的参数豁免类型化授权。
    • 自动用例选择支持集成者显式列出 5 个编号。
69. 整批用例索引按定稿关闭（来源：集成者（模型负责人），2026-10-25）：
    • 新树苗不带用例，旧每构建根保留。
    • 新根上的用例由喂入层在运行读到时投影。
70. 真实数据不进 Git（来源：集成者（模型负责人），2026-10-25）：
    • 给终端的任务说明一律用合成名。
    • 推送前整体压成干净分支。

决定 71–120 是私有集成主干同期记下的决定，这里是脱敏摘要：真实产品按公开身份写作 FAMX，真实参考实现写作 SyntheticReference，真实主机、账号、构建、缺陷号、运行号和提交号都已去掉；原文留在私有存档里，不进本仓库。这些条目里引用的决定编号都是本页的统一编号。

1. 信息归 Hub，操作归 Circle（来源：所有者，2026-10-26）：
   • Hub 给知识、方法、核对和平台原件；SSH、页面操作、文件和工具调用由 Circle 自己做，Hub 不为这些加执行器。已核验工作簿经 Hub 派发给网关的受控移交保留。
   • 新工作用现有的知识、方法和通用技能包组合完成，不按工作类型无限加包。
2. 四层分法（来源：所有者定方向，集成者定判断标准并获同意，2026-10-26）：
   • Hub 核心只放真相保证所依赖的部分：引用语法、原件、逐字比对、主张模型与依据等级、发布许可（模型 T02、B04，不另设审批流）、至多一次派发。
   • 通用技能包解释公司工件格式（脑图、工作簿、命令树 XML、adoc、设备回显），可安装，不随 Hub 发布，运行锁定其摘要；产品包只放事实，工作技能包只放单一工作类型的规则，系统包保留已对接平台的路由与结构。
3. 决定 62 的修订：Circle 做过的事进喂入层（来源：所有者，2026-10-26）：
   • Circle 的操作记录和整合技能提炼的事实、步骤、教训经回注契约进喂入层，挂在树苗相关节点旁，树苗根不变；等级一律为声明，可检索、带标记，不单独作 Hub 判定的依据，管理员可追加撤回。
   • 两条通道：工具后钩子自动上传原始输出（出处 client_captured，模型不参与）；整合技能提交带逐字引文的语义。版本绑定取运行锁定的构建或环境在装的构建，不由模型推断；对象种类补 procedure、pitfall。bot 暂不做。

4. 写回范围与 WebUI、SSH 运维（来源：所有者，2026-10-27）：Circle 做的事只写回 Circle 本地；除 Hub 外不上传到任何现有系统，Hub 也不写回系统。设备 WebUI 的凭据只放在 Circle 本地密钥库。WebUI 测试、SSH 运维和问题复现不另设方法包，用来源读取、环境预订、知识与回注组合完成。

5. 开放文本格式留在核心（来源：集成者收窄，所有者未反对，2026-10-27）：通用技能包只承担公司工件格式；json、text、markdown 是通用开放格式，逐字引文依赖其最基础的文本视图，留在核心。脑图、工作簿、命令树 XML 和 HTML 的解析已迁出到技能包。

6. 真实层的问题单由 Circle 经 Hub 自己找（来源：所有者，2026-10-27）：验收场景要的可复现问题单不由所有者或集成者指定，由 Circle 用 Hub 的读取和搜索能力去找，这本身是对搜索能力的考验；找不到如实记为能力缺口，写明缺的事实和下一步。后由决定 96 修订。

7. 没有接线的端口场景不跑（来源：所有者，2026-10-27）：自动化测试环境上没接线的端口相关用例不跑，其余用例照常，不需要接线事实，也不换用例。

8. Hub 迁到一台 Linux 内网服务器（来源：所有者，2026-10-28）：
   • Hub 在这一台部署上直接监听内网地址（只对这台批准；默认配置仍只监听本机，非本机监听须显式配置）；包函数的隔离在 Linux 上用 bubblewrap 等价实现，不降级。
   • 密钥库主密钥只经平台命令的管道传，不显示、不落盘；操作令牌不搬，目标上另建管理员；数据经 backup/restore 搬运。所有者随后答复：用专用密钥登录，切换前核对没有未结作业和租约占用，防火墙只放行内网网段，当时不加 TLS，原部署保留作回滚。和决定 121（Hub 自带 HTTPS）的先后由决定 136 ⑧ 定。

9. 发布平台统一为三平台（已暂缓）（来源：所有者，2026-10-28）：Hub 的发布平台曾定为与 Circle 一样覆盖 macOS、Windows、Linux，并授权 Windows 适配引入固定版本的 koffi 作为依赖规则的唯一例外；沙箱规则不放宽。由决定 88、92 暂缓，Windows 现在不支持。

10. 验证按风险分级（来源：所有者，2026-10-28）：日常改动只跑类型、契约、docs 检查和受影响的测试；整套只在影响面广的改动（契约、端口、依赖、沙箱、记录表结构、共享夹具）、部署前和公开 PR 的 CI 跑；独立复核只留给安全相关的分支。

11. 先把防篡改和身份类机制瘦下来（来源：所有者，2026-10-28）：先写一页威胁模型（所有者签字），把现有机制分成保留、简化、推迟三类，逐包瘦身并给量化目标。推迟或拆掉的功能连同测试，须所有者对具体清单明确决定后记成决定，不得悄悄放松断言或删测试；以后加功能不默认加这类机制，独立复核只留给凭据、真实系统写入和设备操作。

12. 按请求复用许可、按会话复用模型身份、推迟逐次沙箱证明（来源：所有者，2026-10-29）：
    • 同一次请求使用开始时的权限，请求中撤权在下一次请求生效；不同请求、读者和消费者不复用许可。
    • 开始运行时显式声明模型身份和模型族，同一 Circle 会话的后续提交可以沿用；提交明确声明时以提交为准，不从模型名称猜家族。
    • 移除 Linux 每次包函数调用的隔离证明和它专属的测试；保留 bubblewrap、AppArmor、Node 禁网禁写禁启动以及实际隔离测试，隔离不可用时生产不回退。

13. 测试并发按可用核数和负载动态调整（来源：所有者，2026-10-29）：取消固定两个测试进程的上限，按可用核数、CPU 使用率、内存和共享内存自动增减；有时间预算、并跑会改变测量意义的测试仍单独执行。测试范围和断言不放宽。

14. 集成者直接改代码并跑验收（来源：所有者，2026-10-30）：每个改动仍是一页任务页、一个工作树和分支、签署提交，由集成者用 --no-ff --signoff 合并；互不相干的有界任务可交给子代理，合并前审差异。生产写操作、公开推送与合并、改工作流不因此预先授权（决定 87）。

15. 瘦身和三平台并入当次交付（来源：所有者，2026-10-30）：交付包括威胁模型、机制清单的逐项决定和量化的前后对比；删除或推迟任何机制仍须对具体清单明确决定。其中 Windows 部分由决定 88 推迟。

16. 不做第二个模型家族的独立复核（来源：所有者，2026-10-30）：一个模型家族能把完整流程跑完即可；真实层止于设计内的反向分支，正向分支列为限制。这条不改变 A04：Hub 仍只在不同会话加不同模型家族时判定独立。

17. 生产动作不预先授权，逐门请示（来源：所有者，2026-10-30）：建账号、备份、发布部署重启、环境独占窗口、公开推送与合并及工作流改动、删迁移密钥、防火墙，每次动手前请示。同日答复：备份加恢复演练当即做（已恢复到临时目录并核验）；部署在整套检查和复核通过后立刻做。

18. 先不做 Windows，macOS 和 Linux 先跑起来（来源：所有者，2026-10-30）：决定 79 暂缓，决定 85 的 Windows 部分推迟；Windows 的准备工作留在本地分支，不合并，不改公开工作流；验收的平台矩阵改为 macOS 与 Linux。

19. 先测通 Circle、Hub、任务包对接的主流程（来源：所有者，2026-10-30）：监控日志、Windows 和其余不影响主流程的事项记入暂缓清单，裁完之后给出一版工作量评估。

20. 主流程之后：瘦身，再删字段（来源：所有者，2026-10-30）：先合并瘦身内容、缩短单元测试时间，不删断言；契约、视图、记录里的字段除非非加不可一律删除，不再为单个任务包新增平台字段。删除机制或它的测试仍按决定 81 处理。

21. 裁剪用清单和标注，不回退、不改代码（来源：所有者，2026-10-30）：不在主流程里的模块靠模块边界排除（质量看板和只有它读的字段进暂缓清单，已发布版本不动），已合并的改动不回退；做不到的地方记入删字段和边界整理的待办。

22. Windows 整体列为待定，发布只含 macOS 与 Linux（来源：所有者，2026-10-30）：Windows 的服务、沙箱、密库、安装包和工作流都不做，代码只加说明注释不删除；兼容矩阵写明平台范围。同一答复授权了一次部署。

23. 一次部署（来源：所有者，2026-10-30）：读取恢复在没有常设管理员时取启用的管理员、回归范围大差异不再内部错误等修复，整套检查全过后部署。

24. 追溯的缺陷来源按“用时喂入”补齐（来源：所有者，2026-10-30）：生产上缺陷索引为空，因为视图读的树苗根只有手册和命令树，逐构建的修复清单只进同步根。做法：Circle 在产品已知的读取里读一次构建的修复清单页，产品包把它投影成该构建的缺陷记录，缺陷索引像用例一样读喂入层；文件名语法认产品前缀；核心不出现产品名。

25. 第二批开工并放行三项生产动作（来源：所有者，2026-10-30）：知识回注、模板查缺、追溯、环境设备和演练开工；放行一个包的发布、一次约 3 小时的自动化测试环境独占窗口，以及窗口内的重启与回滚演练。

26. 真实层的问题单改由集成者只读挑选（来源：所有者，2026-10-30）：从 PLM 只读挑一条现象写得清楚、已解决的，先把编号和标题告诉所有者，再上自动化测试环境。修订决定 76。

27. 整套检查通过即部署（来源：所有者，2026-10-30）：追溯的用时喂入和单元测试提速，整套检查全过后部署，并发布相应的任务包。

28. 运行器合约的补齐由集成者直接发布；启动慢现在修（来源：所有者，2026-10-30）：用例编译要用的函数补上新版合约的类型权限（原合约身份不变），用用例编译自己的解析器校验后发布为命名文档的新版本。启动慢的修复：服务先监听，维护在后台跑，停服时叫停进行中的一轮；维护的请求和账号改为批量读。

29. 一次部署（来源：所有者，2026-10-30）：整套检查全过后部署；用例编译的派发等下一次自动化测试环境窗口。

30. 保留读记录时的完整性校验，改为少读（来源：所有者，2026-10-30）：读时校验（通用模型 B05 R[5]）不动；进程里记下已校验的记录副本，同一摘要、元数据和正文逐字相同就沿用结论。定时维护跳过没有变化、期限也没跨过的运行；启动后第一轮和每半小时一轮仍看全部运行。同日授权部署。

31. 发给在职管理员的升级请求到期后不再升级（来源：所有者，2026-10-30）：到期未答的请求照旧升级给具名管理员一次；升级请求本身到期时，受众仍是在职管理员就不再新建请求，只有那位管理员被停用或不再是管理员时才转交。此前每条未答请求每天多一条升级；已写入的升级记录不动，相应测试断言按本决定改。

32. 一次部署，PLM 资源切到新版系统包（来源：所有者，2026-10-30）：整套检查全过后部署并发布模板查缺的新版本；生产 PLM 资源改绑已发布的 plm 新版本后，构建列表读取完成。

33. 脑图编译对齐参考实现的处理方法（来源：所有者，2026-10-30）：编译参考 SyntheticReference 与它的编译技能：作者未标号的多动作步骤，期望不按逗号拆，整体绑定该步骤，断言由编写阶段的模型放置并逐字引文，Hub 照常核对；自动化测试环境的授权照参考实现的做法在运行器合约 Hub 侧补齐，原合约身份不变；作者笔误按适配处理，不可解析的作者命令不计义务。

34. 脑图编译改为整份脑图一次编译（来源：所有者，2026-10-30）：此前一次运行只认一个用例，逐条编译、逐条上机。顺序：先补齐共用能力（证书导入、确认应答成对拆除、先建后删相抵的净效果清理）；一次运行收整份脑图的全部自动用例、出一份多用例工作簿；派发由使用者的运行触发（决定 105）；客户端直接从 Hub 取生成所需的原字节和记录；在 Circle 里一句话重跑整份脑图作为验收，由所有者判。

35. 核验满足后由使用者自己的运行派发（来源：所有者，2026-10-30）：使用者持有执行器声明的全部环境键且全部要求项满足时，由运行自己派发已核验的工作簿（通用模型 D06 的 hub_template，按运行与提交摘要去重）；效果预算、放行检查、环境前后检查不变，管理员命令保留为备用。

36. 整份脑图上机两轮后上线返工能力（来源：所有者，2026-10-31）：几次整套检查全过后部署；Hub 自己的派发接上知识端口，设备回显的构建别名能过版本探测；派发结果给没通过的条目附证据（日志与各设备会话，运行者可读）；返工步骤照参考实现。真实层第二轮在新会话里一句话起手、无人介入，整份脑图的自动用例全部通过。限制：用的是集成者的验收主目录。

37. 按只读检查的结论修复（来源：所有者，2026-10-31）：修复派发重试把到达目标之后的边界拒绝当作可重试、作业提示超过答复上限使 submit_result 内部错误、运行者的进展里出现管理员命令和别人的作业号、计划运行也去试派发、换了提交后再也派发不出；以及用例编译里重复节点编号串号、编号形状不对被悄悄跳过、寄存器唯一性的范围不对、超限要到核验才报。

38. 只上线 Hub 修复，补跑未测场景（来源：所有者，2026-10-31）：只换代码、不发包；补跑的场景多数通过，未过和部分通过的记入暂缓清单。验收用的合成包发布后已下架，测试令牌已撤销。

39. 修复补跑发现的四项并上线（来源：所有者，2026-10-31）：①工作包声明了技能依赖而没有安装时，start_run 在冻结依赖时就拒绝并点名；②直接引命令树条目的回注可按回注记录撤回，按运行撤回会连带该运行回执里的回注，读侧显示已撤回，历史引文保留；③判据变更的依据可以取期望来源，也可以引被判对象原文（A03 R[3]），放错的片段在它自己的指针处报出角色；④被扣留来源的内容页给出下一步（请管理员核看），凭据误报经管理员接受后用同一引用重读。中性“对你不可用”的统一下一步写在通用模型里，这次不改。

40. “台架”改称“自动化测试环境”（来源：所有者，2026-10-31）：面向人的中文一律改称“自动化测试环境”；英文标识（test-bed、bed、租约键、清单 schema）和行为不变，已存的记录不改，引号里的原话保留；相关任务包升版。这一改称目前只在主干，合线时带进本仓库。

41. Hub 自己的回答也按主张给出（来源：所有者，2026-11-01）： - 通用模型 D05 加 R[8]：错误与修正也是主张，写明根据、规则@版本（任务包的拒绝缺省写包@版本和函数）、限定（声明、观察还是投影，采集时刻，查过的范围与覆盖）；候选清单写明共几个、列出几个、其余在哪里，截断不当全量；修正写明由谁、用哪项现有能力做；原因没定时列出已知假设并固定留“其他”，只有被观察反驳的才排除。 - 据此改了协议错误和包错误的字段、构建候选不再静默截断、环境包和缺陷转用例包里不实的修正；PLM 系统包加只读的缺陷列表路由，只放行少数过滤参数。留下的三项合线后再定（决定 136 ⑭）。

42. 亲测余下问题的四条答复（来源：所有者，2026-11-01）： - 缺陷详情只给开出构建的编号时，系统包再读一次单个构建给出名字（编号只许数字）；包没给出版本是包的问题。 - 管理员不再在清单里声明在装构建，以设备上实际显示的为准：执行器的只读版本探针每看一次就记一条设备观察，预订成功后看一次；没观察过的写未知，从不算不一致。 - 运行器自带清理覆盖的配置命令不再要求逆命令；清理规则从参考实现的规则源码机械抽取（只读源码，不运行），规则外的照旧要逆命令。 - 读不到时分清两种形态：确定没有答 SOURCE_ABSENT，存在而无读权答新码 SOURCE_NOT_PERMITTED，只有凭据和登录两类仍答中性的 SOURCE_UNAVAILABLE；主干的通用模型 D05 R[3] 随之改写。本仓库的 D05 R[3] 与此相反，合线后的规则由决定 136 ③ 定。

43. 正常回答也完整披露（来源：所有者，2026-11-01）：list_task_packs 先给同样筛选下全部任务包的索引（不受分页和字数影响），并给运行上下文的此刻摘要（租约前缀、占用中的键、每台设备最近一次观察）；分段读取没读进的应答写进覆盖说明；start_run 列出接受这种来源类型的任务包输入；本地工具下载按 D05 R[3] 分清不存在、无权和不可用。通用模型 R02、T01 改为引用 D05 R[3]，A05 R[1] 补“供读者从中选的清单先列全部选项，只有详情可以分页”。

44. 拒绝照实说，设备命令照参考实现放行（来源：所有者，2026-11-01）： - 沙箱这一次不能运行或观测函数时，Hub 在服务内重试一次（包函数没有副作用），仍失败时用 Hub 自己的码，写明不是函数的错；参数模式核对不过时写出位置、要求和给的值。 - 用例编译放行命令文法认得的全部设备命令，只无条件禁破坏性命令（重启、重载、关机、断电、整机清配）；破坏性命令由运行器合约的封闭补充声明按解析出的命令身份锁定，不按文字。 - 仍缺只有维护者能补的事实时，按补证请求交给具名维护者，不让用户替维护者选；D05 R[8] 补一句：修正的执行者不是读者时，不写成读者要做或要选的事。

45. 作者写的地址照留（来源：所有者，2026-11-01）：地址核对按出处分：作者用例命令里经锁定命令树解析出的地址照留并在结论里披露，只拒编译模型自己编的、不在环境可达范围的地址；替换的来源可以是作者命令里的任一地址；逆命令接受几种合法写法之一。读内容时附的喂入说明改为“投影进行中，运行的检查只用冻结的输入，不用等它”。

46. 沙箱一次看不全进程树不算故障（来源：所有者，2026-11-01）：沙箱要连续 5 次读数看不全才停，看全一次或进程已退出就清零，超出内存上限照旧立即停；包函数调用没看住进程树时再运行一次。派发前重核里有检查没出结论又没有驳回时，关口写明不是计划、工作簿或包被驳回、什么都没发出。本仓库对沙箱观测有另一种修法，合线时选一种。

47. 自动化测试环境装构建（来源：所有者，2026-11-02）：照参考实现接上框架自己的升级用例：只有整台预订的用户能触发，已是目标构建就跳过，失败时写明哪台并附日志，环境保持预订。网关新增装构建动作；新工作流包 bed-install 以整台预订为前驱，核对镜像名、构建和在装构建后经执行器派发（决定 105）；环境包在没有所需构建时提示先整台预订再装。

48. 清理配对按设备逆序（来源：所有者，2026-11-02）：逆序只在同一设备内约束，设备之间先后不限；运行器自带清理覆盖的配置，显式逆命令放在本设备清理段的任何位置都接受。归因先对照回显，说明不了的推断写成预测，下次加只读观察来区分。运行配置为设备的配置方法开放运行器读超时（只是等提示符的上限）。

49. 运行数据照方法语义开放，预订做完即释放（来源：所有者，2026-11-02）：用例编译和装构建包沿用已持有的整台预订，作业都有终态后释放；装构建包照用例编译归因，说得出不同才重装。运行配置转换器另出复核清单，角色按合约的类型权限核对；同类方法照兄弟方法补类型权限，读超时声明上下限；不是 CLI 的方法不补。

50. 自动化测试环境不带版本基线（来源：所有者，2026-11-02）：执行器定义不带构建，写入时拒收；只有运行锁定的构建才和设备自述比，没有锁定构建的独立预检只记设备观察、答“未对照”，不判断。环境装哪个构建由下一个用例决定，装构建包已是目标构建就跳过。

决定 121–135 是本仓库原来的决定 74–88，138–143 是原来的 89–94（页首对照表）；正文照原样，只改了引用的编号。

1. Hub 自带 HTTPS（原 74；来源：所有者 2026-10-31）： - 网页管理要在内网直接安全访问，Hub 自己提供 HTTPS，不再要求另配 TLS 反向代理。决定 1 的“只监听本机”改为：HTTP 默认仍只监听本机；HTTPS 可以监听回环或明确的内网地址，非回环时必须声明允许主机；通配地址和公网地址照旧拒绝。 - 证书由每个数据根自己的本地证书颁发机构签发（circle-hub tls init），浏览器和 Circle 信任它的证书；证书颁发机构的私钥不出 tls/ 目录，也不进备份。 - 内置 HTTPS 与 HTTPS 代理二选一。

2. 网页控制台用来管理 Hub（原 75；来源：所有者 2026-10-31）： - 控制台不再只读：管理员在网页上建用户、签发和撤销令牌，上传、发布、分配、下架和启停任务包，添加和启停资源，设置和撤回密钥，触发知识同步。第一位管理员用安装时给出的一次性设置码在网页上建立。 - 每个网页操作都执行对应的 circle-hub 命令，以登录的管理员身份执行，检查、记录和提示与命令行完全一样，不另写一套。 - 备份、恢复、部署和回滚会停掉 Hub 自己，仍只在命令行执行。

3. 一键安装，只支持 macOS 和 Linux（原 76；来源：所有者 2026-10-31）： - 按平台预编译发布包（macOS、Linux 的 arm64 和 x64），自带 Node 24、Hub 的依赖和 PostgreSQL；curl … | bash 下载、按发行版的 SHA256SUMS 核对后，用 Hub 自己的命令完成初始化、证书、部署、服务和设置码。 - 发行工作流在版本标签上生成草稿发行版，由所有者核对后发布；拉取请求在新的 Ubuntu 机器上真实跑一遍安装。 - 安装后的管理在网页控制台（决定 122），对外用内置 HTTPS（决定 121）。

4. 控制台按设计稿改版，界面只用界面用语（原 77；来源：所有者 2026-10-31 在《circle-hub 简化提案》决策事项中勾选第 3、6 项；2026-11-01 的目标“按照 hub 最新 PR 和主线代码将后端接入前端”；任务页 console-frontend.md）： - 控制台按设计稿第 25 版改为七个入口：总览、任务、知识库、任务包、连接、记录、设置。“运行”和“结果”合并为“任务”，每个任务先显示执行过程，再显示原运行页的完整记录（显示规则 17 不变）。 - 词表的取值和轴可带界面用语（ui），控制台只显示界面用语，返回给模型的文字仍用模型标签；任务结果轴 task_result 进词表，推导写进显示规则 20。六个工具的中文名写在工具定义的 label 里，不发给模型；不做成词表轴，因为现有代码、包和冻结夹具里的工具名清单都会被手写取值检查判为手写。 - 控制台只保留四种管理操作：添加成员、接入业务系统、发布任务包、导入知识。其余操作生成命令，由管理员在 Hub 所在主机上的 Circle 中执行；这一条收窄了决定 122 在网页上开放的操作面，决定 122 的命令桥和表单接口不变。 - 仍是服务端渲染、不带脚本。接口文档的只读 /console/api 已实现（所有者 2026-11-01 选择先做只读部分），数据与页面同源、可见范围相同，不提供写接口；MCP 标准授权、邀请码、一次性登录链接和实时推送等接口文档的 7 条待定事项定下后再做。

5. MCP 标准授权、邀请码、一次性登录链接、实时更新与写接口（原 78；来源：所有者 2026-11-01 合并 #118 后选择“全部按文档假设确认，开始实现”，即《circle-hub 控制台前端：模块与接口》末尾的 7 条待定事项全部按文档的假设定下；任务页 console-auth.md）： - Hub 自己是 /mcp 的授权服务器（按 MCP 授权规范：OAuth 2.1 与 PKCE）。客户端从 401 发现元数据、自行登记、在浏览器中授权后换得普通的 Hub 令牌；令牌不过期、不发刷新令牌，每次请求都对照存储核验，断开 Circle 就是吊销它的令牌。 - 授权页的身份确认用邀请码或浏览器已登录的控制台会话，不设密码。邀请码由“添加成员”或 circle-hub user invite 签发，只存哈希，24 小时内有效，仅可使用一次；授权请求 10 分钟内有效，一次性登录链接 5 分钟内有效。 - 断开 Circle、停用成员仍生成命令在管理员的 Circle 中执行，管理员的 Circle 不可用时在 Hub 所在主机上执行同一命令。知识同步完成后本来就把当前根移到最新构建。任务包先以 pack publish --dry-run 校验并暂存，再由“发布”一步发布。成员的记录页只列本人的调用。 - 四种管理操作另有 JSON 写接口，执行与表单相同的命令；其余操作经 /commands 只返回命令，不执行。实时更新经 GET /console/api/stream（服务器推送事件），事件只带编号、只发给有权查看的账号；登录后的页面带一段按哈希放行的内联模块脚本，不引入构建步骤，关闭脚本时页面照常可用。业务系统与运行环境配置的变化（添加、修改、启用、停用）发送 system.status、environment.status（只发给管理员）；运行环境的占用与冻结由派发记录推出并同样发送（见决定 126）；运行环境的响应时间没有任何记录，不发送。 - 与文档的出入：合约里没有“令牌签发”这一记录类型，令牌与邀请码的签发、使用和吊销仍记在可变存储里（迁移 7）。Circle 基线的 MCP 客户端还没有 OAuth，也不会请求登录链接；这两项属 Circle 仓库的通用 MCP 客户端改进，需所有者另行授权。在此之前 Circle 以访问令牌连接，支持标准授权的客户端已可用邀请码连接。

6. 补齐接口文档中“需新增”的后端数据，Circle 端标准授权（原 79；来源：所有者 2026-11-01 在问答中选择“现在继续做”与“授权，另开 Circle 分支实现”“推送并在 Circle 仓库建 PR”；任务页 console-data.md）： - 搜索：/console/api/search 与侧栏的搜索，在读者可见的范围里查任务、任务包、知识、记录与成员；按最近的有限范围扫描，不是全文索引，没扫完时写明。 - 知识条目近 30 天被引用次数：受理的提交从现在起按所引的知识节点与条目建索引（不加迁移，不回填）；索引开始之前的部分只给下限并写明起点。出处只给条目的依据，不解析原文。 - 测试连接：用填写的系统包、地址、环境与凭据内容只读试读，不保存任何东西，不打开写路由，失败的登录不重试，只试不需要参数的接口；业务系统近 24 小时的读取次数与耗时取自已有的读取清单。 - 运行环境的状态：由派发记录推出可用、使用中、已冻结、已停用，推不出时为未知；状态词进入词表（environment_state，D07），不在页面里手写。 - Circle 端：在 Circle 仓库实现通用的 MCP 标准授权（circle-platforms/circle#396，由所有者合并）；一次性登录链接是 Hub 专用的，不加进 Circle（D06 R[1]）。 - Hub 状态：最近一次完整备份的时间与份数取自数据根下的备份清单，数据库大小取自 PostgreSQL；读不到时为未知。 - 没有的：运行环境的响应时间、测试连接的审计记录（需合约增加记录类型）、早于索引的引用回填。

7. 补完决定 126 留下的三项（原 80；来源：所有者 2026-11-01 在问答中选择“改为在本机做完”与“推送，不建 PR”；任务页 console-finish.md）： - 业务系统的一次读取结束（写下读取清单）也发送 system.status：近 24 小时的读取次数与耗时随之变化。 - 被引用次数回填：运行引擎的维护在后台给索引之前受理的提交补上所引知识的索引，可中断，下次接着补，记录不变；补完后近 30 天被引用次数是准确值，不再写“更早的提交未计入”。 - 测试连接失败过的登录记在密钥库条目 login-stop.trial（加密保存，只有摘要），重启后同样的凭据也不再发送；这份记录读不出时不登录。 - 仍待所有者定：测试连接的审计记录用什么形式记（合约里没有对应的动作种类或记录类型）；运行环境的响应时间按什么口径统计（派发记录对每次调用执行器都记了发出请求与收到应答的时间，决定 126 说“没有任何记录”不对）；login-stop.trial 怎样清除（账户解锁后要用同样的凭据再试时）。

8. 尝试读取记录、运行环境的响应时间、按凭据清除失败登录（原 81；来源：所有者 2026-11-01 在问答中选择“新增动作种类‘尝试读取’”“调用应答时长，近 24 小时”“按这组凭据清除”“现在单独建 PR”；任务页 console-remaining.md）： - 界面用语“测试连接”改为“尝试连接”，“试读”改为“尝试读取”；动作代码 trial、接口路径与动作名保持不变（来源：所有者 2026-11-01 经 Claude 转达的补充）。 - 尝试连接每次记一条尝试读取记录：动作种类加“尝试读取”（action_kind 的 trial，B05），记成 action 记录，schema 单独一种；只记谁、何时、系统包与版本、环境、登录与各接口的结果、状态码、错误码和耗时，不含凭据、地址和来源原文。 - 运行环境的响应时间：Hub 向执行器发出请求到收到应答的时长（派发记录已有这两个时间），每个运行环境给近 24 小时的调用次数、中位与最慢，与业务系统读取耗时同一口径；不新增记录。 - 失败登录按这组凭据清除：在尝试连接页用同样的内容清除这一条，只限管理员，凭据不经命令行。 - console-finish（决定 127）现在单独建 PR，合并另定；这三项在新分支上做。 - 已实现第 1 项：B05 的 trial 与生成合约、trial-report@1 的保存前校验和追加记录、管理员记录页及准确的保存说明；记录写入失败只记连接器事件，不重发请求。实现与本机验证见任务页（来源：本任务的本机代码与合成测试）。 - 已实现第 2 项：从已有调用的发送、应答时间统计近 24 小时调用次数、中位与最慢；同一调用的应答记录和读取记录不重复计数，扫描受限时注明下限；页面和接口提供 calls_24h，新的调用记录触发合并后的 environment.status。不新增测量请求或记录，验证见任务页（来源：本任务的本机代码与合成测试）。 - 已实现第 3 项：管理员在原表单重新输入同一组凭据，清除对应失败记录；JSON 接口为 /console/api/systems/test/forget，与原测试相同的管理员、Origin 和 CSRF 检查。共用登录摘要计算，密钥库与本进程记忆同步清除，其他凭据和并发新失败保留；不联系业务系统、不自动重试、不加命令行命令。验证见任务页（来源：本任务的本机代码与合成测试）。

9. circle-hub 自己的标志（原 82；来源：所有者 2026-11-01 指出控制台的标志与 Circle 相同，在标志方案画布中先选 E（辐射），再从按 E 设计的五个变体中选定 E1（轨道））： - 标志为中心的 Hub 与轨道上的四个 Circle，颜色沿用 Circle 的蓝、紫、红、橙；中心与轨道取文字颜色，浅色和深色界面都适用。 - 控制台各处（侧栏、登录与初始化页、登录页的提示、接入页的连接图）改为内联 SVG，不再用 Circle 的圆环；浏览器标签图标为 GET /console/favicon.svg，页面的 img-src 由 'none' 改为 'self'。

10. 控制台走查修改、团队入口与密码登录（原 83；来源：所有者 2026-11-02 逐页走查控制台，经 Claude 整理为任务页 console-walkthrough.md，及同日在本任务中经 Claude 转达的补充）： - 新决定：导航由七项改为八项，在设置前增加团队。团队管理成员、权限、任务包分配与 Circle；设置保留系统设置，成员的“我的 Circle”仍在设置（来源同上）。 - 第 5 项显示轴经所有者在本任务内明确授权：B07 增加 request_status（等待回应中、已逾期、已回答），模型升为 15，生成合约并同步两个版本断言；只用于显示推导，不改变请求记录和处理规则。 - 按任务页第 4–11 项调整任务空状态、请求列表、知识库入口与流程说明、团队导航和 Circle 设备展示，并把只解释“怎么看”的说明统一放到标题悬停提示；第 1–3 项及已有机制保留。 - 第二轮第 1 项：所有者 2026-11-02 同意增加 R01 的 account_status 显示轴（enabled 已启用、disabled 已停用），与 request_status 同记在尚未合并的模型 15；团队、账户列表及其他账户状态显示使用生成标签。“使用中”只指运行环境被作业占用。来源：任务页“第二轮：所有者答复与审查意见”。 - 第 12 项追加批准直接实现：安装时用户名必填、密码可选；随机密码只显示一次且首次登录必须修改。成员也用密码登录，账户只能由管理员添加，成员的 Circle 令牌绑定到该成员账户，后续在团队页管理。 - 第 12 项实现取舍：保留管理员备用令牌与管理员一次性链接，成员一次性链接转到密码登录；MCP 标准授权与邀请码继续用于 Circle。迁移 8 只追加密码摘要、首次修改及会话期限字段；重置或修改终止控制台密码会话，Circle 令牌仍绑定原账户；旧成员未设置密码时由管理员在团队页重置。来源：本任务实现与临时数据库中的合成验证，详细命令和结果见任务页；未操作现有部署。 - 导入按钮本次仍叫“导入知识”，只加悬停说明；知识库先调研需求和同类项目，第一轮草稿已被决定 131 取代，完整方案由所有者定稿后再写入设计；本次不改其模型和业务代码。定时任务与机器人以后使用各自页面，本次不实现。

- 第二轮第 2 项：所有者明确授权发布工作流对齐密码登录初始化；首次安装只用合成账户与标准输入密码，检查用户名、密码表单。本地检查不代表发布工作流已运行。来源：任务页“第二轮：所有者答复与审查意见”（2026-11-02）。

- 第二轮第 3 项：所有者原用词为“密码”，第一轮任务转述写成“口令”是笔误；当前界面、安装与 CLI 用词及本决定改正为“密码”。来源：任务页第二轮所有者答复（2026-11-02）。

- 第二轮第 4 项：所有者批准新增 `circle-hub user password-reset <用户>` 并由团队页桥接执行，恢复首次修改前丢失初始密码的管理员；初始密码只显示一次、须首次修改，撤销控制台会话、复用原历史。备用令牌失败按来源地址分别计数，用户名账户锁定保留。来源：任务页第二轮所有者答复（2026-11-02）。

- 所有者 2026-11-02 追加，原话：“管理员创建的用户或者其他管理员也得用用户名密码登录”。改动如下，取代上面第 12 项实现取舍与第二轮第 4 项中关于备用令牌和管理员一次性链接的部分：
  - 所有账户都只用用户名和密码登录控制台，包括首位管理员、其他管理员和管理员创建的成员。
  - 控制台不再接受访问令牌登录，管理员备用登录取消；访问令牌只用于连接 Circle。
  - Circle 的一次性登录链接一律转到密码登录页。
  - 初始化页建好首位管理员后不再直接登录。
  - 团队页的“签发令牌”统一为“签发 Circle 访问令牌”。
  - 忘记密码时由管理员在团队页重置；唯一的管理员可在 Hub 主机上执行 `circle-hub user password-reset`。
  - 由 Claude 在 PR #124 上实现并补测试。
- 所有者 2026-11-02 在本机部署上报告“改了密码后提示登录失败”。服务端记录显示修改已生效（须修改标记已清除），之后没有成功登录；在临时数据库中按相同步骤（命令行重置两次、初始密码登录、修改、新密码登录）经 HTTP 和 HTTPS cookie 复现均成功，判断为浏览器在登录页填入了旧密码。修复：
  - 修改成功后直接以新的密码版本开启新会话并继续，不再要求再次登录；该账户其他的控制台会话照常失效。修改与开会话之间若有重置，仍回到登录页。
  - 修改表单带隐藏的用户名字段（`autocomplete="username"`），浏览器把新密码记到该账户名下。

- 第二轮第 5 项：按所有者批准的审查意见，安装中途失败后重跑仍读取数据库中的管理员，缺失时重新询问并初始化；无终端、无 `--admin-user` 时明确指出 `init-admin` 或 `setup-code`。账户检查放在部署迁移之后，以兼容旧数据库升级；已有账户不重置。来源：任务页第二轮审查意见及本任务脚本测试（2026-11-02）。

- 第二轮第 7 项追加：Claude 2026-11-02 应所有者要求在本机部署主线 8a9cfa3 时发现，同版本、不同提交的本地包因同名解包目录已存在而被跳过，安装脚本误报“这一版已经在运行”。修复为按提交区分解包，且部署成功前不修改 `runtime/node` 或当前发布；旧 Node 必须可供恢复。本项只用合成包和临时目录复现、修复，没有操作真实部署。

1. 知识库与工作流：个人与团队（原 84；来源：所有者 2026-11-02 的决定，由 Claude 转达并写入任务页 console-walkthrough.md“第二轮：所有者答复与审查意见”第 6 项）： - 个人知识在 Circle 本机和 Hub 两边都放，双向同步，多客户端共用，方式由本人选择。 - 提交共享不审核。 - 个人空间由本人设权限，可共享给管理员或其他人。 - 所有者随后更正名称，原话：“用工作流”“工作流标签里面分为两种，一种是通用的skill 一种是我们的packs”。工作流页面分为通用技能（不验收）与工作流（现有 packs，有验收）。本轮不实现改名，另立任务。来源：所有者在本任务中的追加更正，由 Claude 转达（2026-11-02）。 - 所有者 2026-11-02 随后答复：方案文档末节的 14 个待定问题全部按建议办。即：
   • 产品线改为可选（改 K01 R[4]）；团队知识全体成员可读，产品目录沿用产品线读者的规则。
   • 依据须对结果的全部读者可读；上传文件经上传人署名后可作团队依据，来源类型记为“声明”。
   • 任务中仍按地址读取，全文检索只给人和 Circle 的问答使用。
   • 从“同步到 Hub”切回“仅本机”时，清除 Hub 上的内容，记录只留哈希，相关授权失效。
   • 提交人可撤回自己提交到团队的条目；成员删除后清除 Hub 上的个人空间内容，记录只留哈希。
   • 个人空间每人默认 1 GiB，管理员可调整。
   • 导入按钮分“导入团队知识”（管理员）与“导入个人知识”（成员）。
   • 产品包放到知识库，称“产品知识来源”；系统包放到连接，称“业务系统接入”。
   • 个人空间先开放工作流与通用技能；个人工作流发布到团队沿用发布权；个人工作流跑出的结果只对发起人和被授权使用该工作流的人可见。
     • 改造包括 Circle 端：本机知识库、个人工作流与技能、双向同步，在 Circle 仓库另开分支。由 Codex 实现，Claude 审查。
     • 完整方案写入 docs/design/，作为实施的第一步。本轮只记录决定，不改知识库模型或代码。
     • 第一轮个人知识只留在 Circle 本机的建议已失效；personal-team-knowledge.md 文首注明取代关系，正文保留作调研记录，以保留需求核对和资料来源，不再作为现行方案。

2. 工作流改名的实施（原 85；来源：所有者 2026-11-02，决定 131；任务页 workflow-rename.md，设计页 knowledge-workflows.md 第一阶段）： - 第 1 项：模型升为 16，pack_kind 的界面用语改为工作流、通用技能、产品知识来源、业务系统接入；同步查询工作流、工作流分配与相关错误提示，代码、协议、记录种类及目录名不变。 - 范围补充（来源：Claude 2026-11-02 作为协调者，依据所有者对决定 131 的持续授权）：增加仅供显示的 pack_status，按既有发布、退役和启用字段推导，不改记录与权限规则；允许同步四个通用技能的生成协议镜像和发布清单，html-format／mindmap-format 升为 1.0.3，xml-format／workbook-format 升为 1.0.4，业务代码不变。 - 第 2 项：导航与页面改称工作流，保留 /console/packs 以维持原有链接；工作流与通用技能分两栏，标题承载约定的悬停说明；工作流详情在上方单列验收要求，移除节点图。依据决定 131 与任务页第 2 项。 - 第 3 项：产品知识来源移至知识库，业务系统接入移至连接，详情面包屑返回对应页面。名称、版本与状态来自既有可见目录，产品线与系统绑定只补充已有元数据；缺失显示破折号，不扩大成员权限。依据决定 131 已采纳的归属方案与任务页第 3 项。 - 第 4 项：任务筛选、团队分配、记录、搜索、命令与答复等服务器持有的文案改用相应名称；发布入口保留同一命令桥与权限检查，按入口和已校验清单的实际种类显示标题与返回位置，API 与协议不变。依据决定 131 与任务页第 4 项。 - 第 5 项：控制台桥接重置密码成功后，仅清除该账户 account:<用户名> 的失败计数；失败请求与失败命令不清除，其他账户和来源计数不变。依据任务页第 5 项的审查遗留要求。 - 第 6 项：同步导航设计与包说明，记录当前目录权限、缺失元数据和现有技能安装方式的边界；保留已获采纳的知识库与工作流设计原文，个人／团队空间等后续阶段另行实施。依据决定 131 和任务页第 6 项。 - 验证：各项运行类型检查与受影响的定向用例，合约校验与文档检查通过；隔离浏览器核对桌面和窄屏工作流页及来源入口。命令、计数、首次失败后的修复与未运行项详见任务页“验证”。按所有者要求未运行全量回归、来源相关检查或部署验证；只在本机提交，未推送或建 PR。

3. Hub 个人与团队空间的实施（原 86；来源：所有者 2026-11-02 的决定 131；任务页 kw-spaces.md，设计页 knowledge-workflows.md 第二阶段；所有者经 Claude 要求先写实施方案后直接实施）： - 模型升为 17，产品线为新条目适用条件的可选维度；生成空间种类、条目核验状态、搜索范围、授权对象与授权动作。个人与团队采用共用内容、目录对象和不可变版本格式；旧产品树不迁移、不改摘要，按现有指针挂载到团队空间。 - 追加迁移 9，以 PostgreSQL GIN 双字索引投影空间与已有产品内容，按授权先过滤再分页；不新增依赖。缺失投影从追加记录重建，旧迁移 SQL 保持不变。 - 本人经现有 MCP 工具写个人条目或导入原文，Hub 核对路径与逐字引文，不生成内容；缺依据为未核验。本人授权整个空间或目录给成员／全体管理员只读并可收回，管理员没有默认个人读权。团队现阶段只有管理员导入与产品包同步；个人凭据来源不可授权，上传署名与提交共享留待后续。 - 新运行锁定团队与发起人个人版本，读取重新检查发起人及当前账户授权；个人引用统计按本人隔离，不计入团队条目。个人空间默认 1 GiB，管理员可调整，超限拒收；计量含内容与历史快照逻辑字节，不冒充磁盘占用。 - 依协调者补充（Claude 2026-11-02），分支变基纳入 36d691d；仓库技能测试从 repositorySkillVersion 取当前版本。模型 17 同步生成镜像与发布清单，html-format／mindmap-format 1.0.4，xml-format／workbook-format 1.0.5，业务代码未改。 - 控制台三栏显示个人、团队和共享给我的内容；本人在目录中管理条目、私有原文、授权与收回，历史选择知识版本差异，搜索分四种范围。团队管理员导入与容量调整独立检查权限；说明以悬停呈现，包含服务器备份与收回后无法追回已读内容的事实。 - 本机实现为 cab0033（核心）与 3e8ee67（控制台及模型文本）。定向验收 34 项通过；合约、迁移／冻结回放、相关包、模型可见文本与控制台检查通过，已执行分组均 0 跳过，完整命令和未运行项见任务页。窄屏长摘要溢出已修复；截图只作为合成页面布局证据。 - 分步本机提交；只跑类型、合约、受影响包和相关跨包验收，测试与跳过项记在任务页。不执行全量回归，不推送、不开 PR。第三阶段 kw-share.md 未开始。

- 决定 133 安全审查修正（来源：Claude 2026-11-02 的独立审查及所有者随后要求立即修复八项、第二阶段完成后先报告再继续第三阶段）：私有副本不改变已有采集权限，运行内引文解析仅用声明的输入；个人历史与统计只给本人；共享目录导入重新完整检查原文字节，无法检查使用专门代码。模型 18 的临时拒收阻止个人依据进入普通或自动事实结果，第三阶段改为完整读者检查。团队目录登记署为 Hub，不署为随机读取成员。
- 追加迁移 10 归并词项文档，版本只留引用；单条 1 MiB、空间历史 64 MiB 的逻辑索引上限独立于数据容量。读取不等待生产／空间写队列；导入完整预查下一快照容量后，文件元数据、来源与版本使用同一事务。旧记录、根、引用及既有迁移 SQL 保持原字节。四个技能同步模型 18 协议和补丁清单，业务代码不变。定向检查及未运行项见任务页；没有推送或创建 PR。
- 本轮收尾：相关包 278 项、受影响跨包验收 32 项、文档 287 项及系统署名合约 3 项通过，均 0 跳过；类型与生成物检查通过。没有全量回归、Linux 作业、备份／恢复／部署或来源归档检查；未运行项目不算通过。第三阶段改动保存在 `kw-share-local` 的 stash，先报告第二阶段结果，再变基继续。

- 决定 133 第二轮复核（来源：Claude 2026-11-02 的独立复核与所有者指定的修复顺序）：启动普通及事实运行前拒收个人导入输入，阻止保存私有文件名和投影标签；自动结果重新评估同样执行阶段性防护。个人导入事务结束后保留恰好一条安全拒收动作，含已授权目录的预查拒收。进程写队列按空间隔离，同一空间仍串行。
- 第二轮索引修正追加迁移 11：按当前版本引用维护累计值，撤回及替代释放当前额度，历史仍保留；产品挂载独立计量，管理员可配置单条与当前版本限额。模型 19 的搜索警告明确哪些范围未检索，保留可用匹配，控制台据实降级。四个通用技能只同步协议镜像和补丁清单。数据库磁盘与逻辑额度分开说明，不增加数据 SHA 校验或全量回归。第 4 项被拒原始提交的读权交第三阶段完整读者检查处理，已写入第三阶段任务页；本轮先报告提交再继续。

- 第二轮验收 14 排查：初次构建断言附带逐构建结果与原因，保留失败语义，不加重试。单跑与和场景 42 并行三轮均通过，但缺失原 SyncReport、未复现，根因仍未知，不能标为已修复；后续失败会给出构建级诊断。所有权整组因 PG 18 客户端缺失跳过，未算通过；完整命令、结果及未运行项见任务页。

- 第二轮收尾：索引／迁移／配置及运行角色 20 项、知识与页面相关 93 项、合约与指定检查 378 个叶测试、受影响验收 29 项、文档 287 项均通过；场景 14 与 42 并行三轮每轮 7 项通过。检查组有重叠，不相加作总数。所有权整组缺 PG 18 客户端而跳过；原间歇同步失败未复现，未标为修复。只作本机分步提交，由协调者推送。之后变基第三阶段，保留协调者在第三阶段分支新增的决定 135，继续后端与验收。

1. 提交共享与个人工作流的实施（原 87；来源：所有者 2026-11-02 的决定 131；任务页 kw-share.md，设计页 knowledge-workflows.md 第三阶段；所有者经 Claude 要求先写实施方案后直接实施）： - 第二阶段八项安全修正已先行完成、提交并报告；本分支随后变基到 1b14f5e。原始来源权限、运行输入范围、个人历史与统计隔离、索引上限和系统署名保持有效。 - 模型 20 增加提交共享回执与个人包发布／授权／退役／转入团队的追加记录，以及注册拒收码。仍是六个 MCP 工具，现有工具增加共享、撤回、包空间和包文件读取参数；不改已应用迁移。四个通用技能只同步协议镜像及补丁清单，HTML／思维导图 1.0.7、XML／工作簿 1.0.8，业务代码不变。 - 本人对当前已核验个人条目提交共享，依次重查依据解析、逐字引文、来源资格、团队去重和完整凭据扫描；不跨个人空间比较。个人凭据来源与未署名上传拒收。通过后同一事务追加团队条目、来源、版本与具名回执，个人原条目保留；拒收回执只对本人显示安全代码和原因。提交人可撤回自己的团队提交，管理员可撤回任意团队条目，读取派生撤回依据。 - 结果的依据及底层来源须对全部实际读者可读，含自动事实结果、重新核验和缓存回执。缺权限返回 RESULT_GROUNDS_UNREADABLE，明确先共享或补授权；读取故障保留为 Hub 未完成核验，不计模型修复轮。授权收回后重新检查查询、引用与记录输入，不能把不可读的旧结果转存成新任务输入。历史结果不改字节，撤回使用 grounds_withdrawn 读取标记。 - 成员可在本人空间发布工作流与通用技能，沿用结构、引用、沙箱、样例和凭据检查，无需团队发布权。个人版本、包文件、技能依赖和运行锁保留空间；本人可授权指定成员或全体管理员并收回，管理员没有默认个人读权。同摘要的团队与个人包不会混用作者、请求或修复回答。 - 发布到团队仍需原发布权并重新核验，新团队运行按分配共享，旧个人运行不扩大读权。控制台只增加必要的共享回执、来源与个人发布／授权／转入团队操作，仍为所有账户的用户名加密码登录，并检查同源、CSRF 与首次改密；测试使用 testConsoleCredentials。 - 展示范围的后续更正：所有者指出“个人和团队不应该设计成这样”，Claude 2026-11-02 转达将先调研同类产品，再另立个人／团队知识库与工作流页面的重做任务。本阶段继续后端、合约与验收，只保留最小页面功能，不打磨布局，不移除“知识入库流程”卡片；阶段结束先报告，不开始第四阶段或页面重做。 - 按步骤本机签署提交；只跑类型、合约、受影响包与验收。完整命令、结果、初次失败后的修正及未运行项见任务页；没有推送或创建 PR，没有操作现有部署或 Circle 仓库。 - 协调者随后要求变基到第二阶段草稿 PR #128 的 kw-spaces-pr；已按 git rebase --onto kw-spaces-pr 1b14f5ed 无冲突继承 9716a3b7 的轴值、锁命名空间、运行表权限列及迁移列表修正。第三阶段没有新表或迁移，个人发布页面用生成的授权动作守卫；撤回视图的类型使用生成有效性状态的受检子集。来源：Claude 2026-11-02 的补充及本机变基／定向检查。

- 第二轮修复先行报告后，第三阶段从实际共同基点 `9716a3b7` 变基到 `kw-spaces-pr` 的 `3b0c7b2a`，保留决定 135；第三阶段模型顺延为 20，四个技能为 1.0.7／1.0.8。完整读者规则与二轮队列／索引／审计修复合并，生产维护重查及空间验收 9 项通过。此前场景 33 的原文拒读夹具显式关闭团队原文授权后 1 项通过；其余收尾另记，不把旧 49／50 说成整组通过。

- 决定 135 的第 6～8 条并入：个人修订只取代本人同源的团队前件，保留撤回事实及前后关系；共享可选团队目录并在回执明确目标；记录页按参与人／全体管理员索引及正文受众过滤授权，管理员可见全部安全共享回执。MCP、密码表单和被拒原始参数的专项边界已验证；类型、合约及相关 23 项通过，完整命令见任务页。

- 第三阶段最后承接 `kw-spaces-pr` 的 `8e513d2e`：平台限额变量转发清单纳入；临时防护文件保留删除，完整读者包装与输入绑定容忍缺省知识端口。新增采集身份回归复现并修正同字节副本借用私有文件名的问题，每份冻结采集均检查实际授权；明确原采集授权可用于新输入，撤销后重新拒读。
- 本阶段收尾：15 文件受影响验收 55 项通过，缺省端口修正后的 36 项复查通过；相关包首跑 655 项中 654 通过，残留模型版本断言修正后该文件 8 项通过。类型、151 文件生成核对及文档 288 项通过。分组不累加；`ownership` 真实平台整组缺 PG 18 客户端而跳过，不算通过。没有全量回归、部署、真实业务系统或来源归档检查；只作本机签署提交，没有推送或创建 PR。提交、命令及限制见第三阶段任务页。先报告本阶段，再按决定 135 的新任务页处理页面与记忆协议方案，第四阶段尚未开始。

- CI 修正补充（来源：Claude 2026-11-02 依据所有者上传声明规则作出的协调答复，非所有者原话）：普通本人上传绑定为输入即向该次运行的实际读者声明，固定精确采集并在运行展示；管理员用本人普通上传导入团队即为声明。个人空间原文和个人凭据来源不适用，不新增全局授权。模型 21 记录可选上传声明及 Hub 观察到的不可读取引用元数据；缺失与无权限在提交者面前保持同形。权限检查不重新解析片段，不改变已有静态反驳、未知和字节读取重试；当前真实依据仍检查所有实际读者。按协调者后续要求运行工作流／引擎全部文件及完整验收，实际失败、复查与跳过单列于任务页，不把首跑失败算通过。

- 第三阶段独立安全复核补充（来源：Claude 2026-11-02 的 [`kw-share-review.md`](/circle-hub/hub-r4-tasks/kw-share-review/) 及本轮修正要求）：模型 22 限定个人工作流／技能只使用上传、当前可读知识和 Hub 生成文件，发布与启动拦截命名文档、业务系统、租约和外部效果；旧版本和动态输出同样检查。受理原始提交按当前依据读权重新把关；团队核验只接受团队解析器并重查间接引文。撤回提示只列可读上级引用，其余给数量；目标目录执行凭据扫描，拒收历史不保存敏感路径。提交者自身不可读时保持 SOURCE_UNAVAILABLE 同形，不能用缺失元数据绕过已核对成功的引文读权。七项均有合成回归；完整命令、首轮失败、最新复查与跳过分别记在任务页，没有推送或创建 PR。

- 本轮 macOS 验证：按 Claude 扩大范围的明确要求，完整工作流／运行引擎 349 文件 2761 项通过、0 跳过；完整验收并发 1，首跑 222 项中 220 通过、2 个旧夹具失败，修正后两个文件 9 项通过，没有把首跑计为全绿。补充检查组修正后 236 项通过；首轮未配置客户端而跳过的 ownership 整组，在 Claude 指明现有 PG 18 目录后实际补跑 3 项通过。技能协议补丁版本收尾另跑 238 项通过、0 跳过，最终 HTML／思维导图 1.0.9、XML／工作簿 1.0.10，业务代码未变；类型、151 文件合约核对及修正后的文档 289 项通过。本轮要求范围无遗留跳过，各轮重叠不累加；完整命令、初次失败和复查见第三阶段任务页。

1. 知识库与工作流页面的个人与团队设计；记忆纳入（原 88；来源：所有者 2026-11-02；任务页 kw-console.md，第三阶段相关部分见 kw-share.md） - 所有者否定知识库页的“知识入库流程”卡片：“这不是我想要的，个人和团队不应该设计成这样”，并要求先调研：“你先找找类似的知识库管理项目的UI设计，同时兼容工作流设计，个人和团队的”。Claude 调研 16 款知识库与工作流产品的个人／团队界面（导航、范围显示、授权、转入团队、审核），据此绘制草图；调研报告与草图不入库。 - 所有者在草图上补充“不要斜线”，询问条目种类和“团队 he 个人记忆呢”，随后选定：记忆纳入并放在知识库页内；采用左侧空间栏；三条细则全部采纳。 - 定下的设计：
   1. 知识库页与工作流页共用页内空间栏：全部、个人、共享给我的、团队。个人与团队展开为目录树，产品知识来源作为团队的“产品 › 产品线 › 版本线”目录，窄屏收为页首标签。撤掉“知识入库流程”卡片，说明进入悬停提示。
   2. 每行显示受众措辞的范围，由服务器按实际受众计算：知识为“可见范围”，工作流为“使用范围”。核验或发布状态另列。
   3. 界面上的目录不显示斜线，层级以“ › ”连接；内部路径与接口参数不变。
   4. 知识与工作流共用一个授权对话框：对象只有指定成员与全体管理员，知识只读，工作流仅可使用；不设“全体成员”，团队可见只经提交共享或发布到团队。
   5. 提交共享与发布到团队分两步：预检页列出范围变化和逐项自动检查，全部通过才可确认，确认时重新检查；不设申请或人工审核。
   6. 修改后的个人条目再次提交共享时，取代本人先前由该条目提交的团队条目，旧条目显示“被取代”。
   7. 提交共享时可选择团队目录，默认与个人目录同名。
   8. 管理员在“记录”页只看到授权给全体管理员的授权记录和全部提交共享记录，看不到成员之间的授权。
   9. 记忆纳入：知识库页内切换“知识 / 记忆”，共用空间栏，全局导航仍为 8 项。记忆是 Circle 会话加载的偏好与约定，不要求出处，不参与运行核验。个人记忆默认仅本人可用，随本人的 Circle 同步；团队记忆供全体成员的 Circle 加载，由管理员维护，成员可提交共享（不审核，只做凭据扫描和大小检查）。
   10. 条目“种类”沿用模型的条目种类（定义、行为、用例、缺陷、观察、步骤、教训）；原文单独列出，不作为条目。 - 实施：第 6 至 8 项并入第三阶段；其余由新任务 kw-console.md 在第三阶段之后实施。Circle 端加载团队记忆、同步个人记忆并入第四阶段。新界面用语由模型词表生成，不在控制台手写。 - 编号说明：原先为 Hub 同步、Circle 端和收尾预留的决定编号顺延，正式记录时从 89 起编（合线后的统一编号为 138）。 - 页面核对补充（来源：Claude 2026-11-02 对已确认草图的 12 项核对，kw-console.md）：修正他人包误列个人、团队范围误用个人措辞、共享记录显示摘要三项错误；补齐树、数量、状态、大小／时间、标题操作、单一授权表单和窄屏滚动。模型 23 只补团队成员分配的显示模板，权限不变；管理员分配详情保留。重新拍摄隔离合成页面，检查结果、首轮失败及复查见任务页，本机提交后先报告，由协调者推送至 #132。 - Hub 端实施补充（来源：Claude 2026-11-02 对 kw-console.md 记忆协议的审查及恢复第 5、6 步的协调要求，非所有者原话）：模型 23 保留第三阶段的上传声明及安全边界，在原六工具内提供独立记忆读写与共享；单篇默认 24,000 字节、每空间有效正文默认 48,000 字节，可配置。再次共享取代本人前件，管理员已改过则新建副本；个人工作流只提供隔离输入，不提供命名文档、业务系统、租约或派发入口。空间栏、统一授权和两步预检已完成，知识与记忆权限分开，管理员成员页只显示批准的容量和全体管理员授权数。第 5、6 步的检查及布局证据见任务页，Circle 自动加载与同步尚未开始。协调者告知第 2、3 阶段已合并至 main，本分支当前基线 412110e5 无需再变基；只作本机签署提交。

2. 审计后的十五条建议全部照办（来源：所有者，2026-11-02，答集成者按实际排序列出的十五条建议；审计记录不在仓库里。脱敏摘要）： - 编号：主干的决定 71–120 保留；本仓库原来的 74–88 改为 121–135，并在页首放对照表；新决定从 136 起（决定 137 补上 89–94 改为 138–143）。 - ① 生产先补本仓库的三个修复（拒收正文里含调用方自己令牌的请求，#106；绑定的生成记录按最新扫描定读取档位，#107；喂入与回注的追加在加锁前读完，#108），检查过即部署。 - ② 以公开 main 为唯一代码线合线：主干的功能脱敏后分批搬入，真实产品数据与部署约定放部署数据，此后生产从 main 部署；版本号撞车的包，生产已发布的保留原号，main 改号；#88 关闭后按新做法重出。 - ③ 读不到时，团队、产品和业务系统的内容分开答不存在与无权；别人个人空间的内容仍答中性的“对你不可用”。 - ④ 本地工具披露上线，技能说明不点名任何客户端工具；Circle 的本地技能工具改成任何 MCP 服务器都能用的通用名称，不带 Hub 字样。 - ⑤ #132 修好知识库页的回归和 CI 后合并；合线期间两条线只修问题、不加新功能（由决定 137 解除）。 - ⑥ 先改 README，合线后再发一键安装版本。 - ⑦ 被凭据扫描扣下的来源由所有者亲自核看；误报扣留和未答请求由集成者出清单，所有者批量确认。 - ⑧ 定时备份现在开；HTTPS、防火墙来源限制、删除迁移专用密钥、异地备份副本合线后做。 - ⑨ 核心调用产品包代码的地方按研究页的方案二（通用技能包加产品布局声明）改，合线时做。 - ⑩ AGENTS.md 写明按风险分级验证、每次部署前跑一次全量。 - ⑪ main 设必需检查。 - ⑫ 令牌与邀请码的发放和吊销加追加记录。 - ⑬ 确认协调者代定的规则：上传文件绑定为运行输入即向该运行的读者公开；记忆不算依据，授权与知识分开管，每个空间默认 48,000 字节与 20 篇。 - ⑭ 决定 111 留下的三项（产品包默认选构建的规则文字、喂入生成件出处那条下一步的执行者、按命令在用例索引里找用例的读法）合线后再定。 - ⑮ 即时通讯机器人等用到时再定。另：没有 Homebrew 的 Mac 不打包 PostgreSQL 工具；旧的管理页面删除；文档库系统的专用账号不再需要；合线后写一份当前状态报告，代替里程碑的最终报告。 - 主干随即上线：整套检查全过后部署，迁移 0、重启 0；定时备份已开（每天一份，保留 14 份）。

3. 知识与记忆共享层按中立协议做，连同三端界面和 GitHub 积压（来源：所有者，2026-11-03，先提出团队与个人记忆、个人记忆可共享为团队使用、Circle 本身也有知识库和记忆、跨平台，随后在计划的选择题里逐项作答并批准计划。脱敏摘要）： - 三方插件先不做，同步协议保持中立：任何客户端、任何服务器照规范就能实现；Circle 里不出现 Hub 字样，线上的模式值 hub 保留，只改显示。 - 顺序：知识线（本仓库 #136–#140、Circle #405、#406，均已合入）先进 main，再合线；决定 136 ⑤ 的冻结全部解除。 - 一次桌面会话按需求号查对应的脑图用例答不出，暴露的知识库缺陷（换树苗后不重算投影、与版本无关的键判为未知、提示不点名原件、按取值查询判不了查全）先在主干修并上线。 - 通用存储层放在合线之后，先出模型草案；网页控制台、Circle 桌面、终端三端的界面设计一并做，每次先出设计稿。 - GitHub 上已有的 PR 和 issue 一并处理：#141 的六条协调者裁定逐条再定；#126 补齐通知写槽、查询参数凭据、派发通知分支三项能力后合入；Circle #408 关闭；Circle #407（execute 的系统沙箱）不做，关闭并在安全文档里写明风险。 - 不再使用 macOS 钥匙串：Hub 在 Mac 上也用文件存密钥库主密钥和操作令牌（和 Linux 一样）；Circle 桌面的私有凭据改成和终端版一样的仅本人可读文件。 - 编号：本仓库原来的 74–88 改为 121–135，89–94 改为 138–143；136、137 是所有者的决定；新决定从 144 起；带校验和的文字不改号（页首对照表）。 - #141 的六条裁定，所有者逐条定：①仅本机模式下，连着同步服务器且条目带团队标记的可以分享（只上传这一条及其来源），否则留在本机；②默认同步，首次连上时明示；③清除时，运行引用过的个人上传一并清掉，引用它的运行依据标为不可用；④删除成员时，私有工作流和技能转给管理员；⑤团队空间默认 10 GiB；⑥“正在××”“等待××中”照现状。 - 主干第一阶段上线：整套检查全过后部署，迁移 0、重启 0；按需求号查追溯一次给出已追溯和未追溯的数目，未知 0。

4. 个人知识与个人记忆双向同步的 Hub 端实施（原 89；来源：所有者的决定 131、135；任务页 kw-sync.md 第 13 节 Claude 2026-11-02 的审查结论、2026-11-03 逐步实施及收尾验证要求；协调答复不写成所有者原话）： - Hub 提供独立的 /api/sync/v1 HTTP 协议，同步本人知识、原文、文件夹与记忆；个人工作流／通用技能只同步清单版本，不安装或执行。MCP 保持六工具，模型看不到同步 API。HTTP 只认访问 Bearer（含 OAuth），控制台仍只认用户名与口令会话，方式切换走控制台的同源／CSRF 路由。 - 编辑文本按 LF、去头部 BOM 和 NFC 规范化；来源与逐字引文以保真字节对象传输。固定对象身份、批次和续传清单、按账户计量、CAS、确定性冲突与服务器重新核验均已实现。并发不同修订同时保留；有冲突的记忆不自动载入，明确选择是覆盖全部冲突前件的新修订。无法核对的知识显示待验证，客户端结论不能代替 Hub 核验。 - 按第 13 节协调决定，既有与新账户默认同步到 Hub。本人改为仅保存在本机时，预检确认后原子清除本人代次的私人载荷、目录授权及暂存内容，团队知识／记忆副本保留，依赖已清除个人来源的部分按待验证处理；本机副本不受影响。旧备份可恢复旧内容。恢复同步经所有者函数创建新代次，不给运行角色个人空间 UPDATE 权限；旧清除回执不能清除新代次。 - 私人正文经迁移 14 的一次性、仅迁移所有者可用的限定转换进入可清除存储，逐行保持逻辑摘要；无按代次加密。独立运行持有的个人上传只保留既有读取资格，不产生普通上传署名或管理员隐含读权。以所有者身份执行的函数固定搜索路径，运行角色不能有临时对象权限；调用者身份的记录读取函数保持可内联、按摘要走索引。迁移 14、15 已冻结，后续只追加。 - 两个已批准配置变量为 CIRCLE_HUB_SYNC_MAX_BATCH_BYTES 与 CIRCLE_HUB_SYNC_REQUESTS_PER_MINUTE；按账户跨令牌／设备限流，两个监听共享请求／答复字节预算，安全审计只记身份、时间、计数和状态等元数据。控制台个人页与管理员成员详情显示批准的同步方式／上次同步，不暴露私人标题或设备。 - 模型 26、176 个生成文件，通用技能镜像／业务代码未改。共享 v1 样例在 contracts/test-fixtures/sync/v1/ 冻结；验收 49 用相同字节实测 HTTP 竞争、冲突、引文重新核验以及 MCP 读取。实现范围为 Hub；Circle 本机存储、自动加载和同步客户端留独立任务。只作本机签署提交，推送／PR 由 Claude 后续处理，未部署。最终定向、完整 unit／acceptance 的实际结果与所有失败／跳过另记任务页，本条不把正在进行的审查写成通过。 - 本阶段完整 macOS 验证（来源：Claude 2026-11-03 明确要求两套完整检查各跑一次、顺序执行）：unit 首跑 8,783 项中 8,682 通过、92 失败、9 跳过；92 项均由 CLI 夹具的 PUBLIC TEMPORARY 默认权限触发，修正四处合成建库入口并保留生产拒绝后均已定向通过，新增 CLI 拒收不安全权限的回归也通过。定向首轮 126 通过／4 失败，补齐独立桥接夹具后其 4 项通过；没有把原全量 unit 写成通过，也没有复跑整套。完整 acceptance 随后并发 1，一次运行 236 项通过、0 失败、0 跳过；macOS 沙箱项实际运行。定向协议／场景 49 与指定基线组 33 项通过，176 文件合约核对通过。全部失败、跳过名称与原因、修正、命令和最终复查见任务页；Linux 专用用例未另行补跑，不当作通过。第四轮独立复核的审计准入问题留独立提交处理，令牌作用范围的 v1 协调决定另记。 - 第四轮复核补充（来源：Claude 对 5509e847 的 kw-sync-review.md 附录）：同步 HTTP 在任何审计追加前执行账户准入，未知路径／方法也计入频率；这些拒收及超额请求只使用有界内存计数，有效已准入操作保留元数据审计，防止换路径让只追加记录无限增长。Claude 同时接受 v1 访问令牌没有路由作用范围：MCP Bearer 也能操作本人同步与经确认的清除，模型仍没有同步工具；作用范围后续再做，本机副本不受影响。修正与验证另作独立提交，不回写第 6 步两套完整检查的首跑结果。

5. Circle 本机知识库、个人记忆与双向同步的实施（原 90；来源：所有者的决定 131、135；任务页 circle-knowledge.md；Circle PR #406） - 本机版本化存储与全文搜索；同步协议镜像固定到 Hub 已提交状态并逐项核对。写入工具须本人批准；只有受支持的解析器核对引文才算已验证；个人工作流明确确认后才安装。 - 后台同步复用所选 MCP 连接的授权与刷新，用数据库租约与操作日志，丢失应答先查回执再重放；冲突保留双方，不自动解决；401 暂停且不在后台登录。会话记忆按团队、个人、文件顺序在 48,000 字节内转义加载。 - 桌面知识、记忆、工作流与同步设置页面按《Circle 设计规范》实现。未连接 Hub 时只显示“我的”，侧栏显示“未连接 Hub”（所有者 2026-11-03）；连接 Hub 后显示团队内容，“仅保存在本机”时不能分享到团队（待确认，见 issue #141）。 - 隔离 Hub 的真实往返（OAuth、两边修改的冲突、映射分享、未署名上传拒收、清除与恢复、401 重新登录）与开发版、打包版验收通过。

6. 个人与团队知识的收尾实施：成员删除边界（原 91；来源：决定 131、135，Claude 2026-11-03 批准第五块提案 d437875f 的 B1～5、D、E，并转达独立复核补充；完整前四块及本块实施、验证见 kw-finish.md）： - 永久删除使用与仅保存在本机方式相同的可清除存储／purge，清除私人知识、原文、署名、归档、记忆、同步与私人工作流／技能。身份留不可恢复墓碑；不转归管理员，明确发布的团队副本和既有运行精确持有者按原权限保留，仅依赖已清除私人来源的当前内容待验证。保留最后一名启用管理员，旧令牌、会话、邀请与代次不能复活；新同名账户是新身份。 - 本轮独立复核要求明确记录的实现例外：迁移 20 的 append-only 触发器仅允许真实表所有者删除已清除私人采集的 artifact.object 索引（包括本机方式清除），以及已具删除意图／墓碑成员的已清除私人包 personal.pack.id／personal.pack.grant／personal.pack.retired 索引。其他索引、记录外壳仍只追加，运行角色没有 DELETE／UPDATE 权限。新增迁移 23 冻结墓碑整行与令牌撤销历史，并由所有者函数从数据库核对删除清单和计数；未改旧迁移。 - 界面私人内容用“私人”，记录用语仍为“个人”，labelOf 与 uiLabelOf 分别测试。已删除身份显示生成的“已删除的成员”，不再提供恢复动作或作为新授权目标。这里只登记本轮已批准边界及复核要求，不代替 Claude 的最终阶段集成、合并或真实部署结论；本机失败、修正与跳过逐轮保留在任务页。

- 第五块显示完善补充（来源：Claude 2026-11-03 对 57b7566e 的四项要求）：模型 32 将状态“已删除”与身份名称“已删除的成员”分开注册，类型标签旁使用中性状态徽标；预检按实际私人内容范围显示六类数量，技术数量仅在折叠摘要中，命令说明明确在 Hub 所在主机上的 Circle 执行。只是显示及只读统计，不改删除审计、权限、迁移或依据规则；回归和重拍结果见任务页。性能分支先集成，本分支等待后续变基通知，本轮不提前集成。

1. 控制台视觉统一（石墨）（原 92；来源：所有者 2026-11-02 选定主题版本 A“石墨”；任务页 console-visual.md；PR #136）：控制台各页按《Circle 设计规范》（docs/design/circle-design-system/）的组件、颜色和用语实现，深浅两套主题，主题切换不闪烁。

2. Circle 工作台视觉统一（石墨）（原 93；来源：所有者 2026-11-02“同样的方案也要让circle保持相同设计感”；任务页 circle-visual.md；Circle PR #405）：桌面调色板与设计规范的设定一致，三栏结构、会话元素、输入区四种状态和中文用语按规范，终端界面不在范围内。

3. 控制台性能（原 94；来源：Claude 2026-11-03 作为协调者，依据所有者“完成前后端所有设计和优化”；记录见 console-visual.md 的“控制台性能修正”；PR #138、#140）：每页查询数以显示数量为界（总览由 59,502 降到 55～62 条），静态样式与脚本按内容寻址并长期缓存，脚本用逐响应 nonce 与 SRI 放行；请求内只读作用域共享冻结结果。完整规模（5 名成员、2,000 条知识、200 个任务）下各页 p95 低于 300 ms。两轮独立审查无权限回归。

4. 合线收尾的四项（来源：所有者 2026-11-04 对集成者四条建议答“按你的建议来，继续”）： - 第 1 批（#166）带进 main 的一个参考实现缩写和一个真实构建号，已在 #167 改成中性写法；不改写已推送的历史。 - bed-install 整包先不进 main：升级用例号、镜像扩展名、执行器的收尾标记改成部署数据，包本身中性化后再进 main；生产已发布的版本照常可用。 - 客户端不加“对一个非回环主机放行明文 HTTP”的开关；生产在合线第 6 步切换时一并开启内置 HTTPS（决定 121），不再放到第 7 步。 - 合线第 6 步的迁移演练在生产服务器上对备份副本做，放在所有者不用的时段；不动生产库。

5. 合线第 6 步：生产改由 main 部署（来源：所有者 2026-11-04 “直接开始吧，别等了”，把决定 144 第 4 条的演练从夜间提前到白天；看过演练和性能检查后答“可以，前两项都做，然后进行正式迁移”）： - 演练在生产服务器上对当天的备份副本做，没有动生产库：恢复 905 秒，迁移 7–24 共 232 秒（迁移 14 回填 object_holds 占 217 秒），168 万条记录按 main 的合约逐条解析；92 条旧的校验结果主干的合约同样不认，不是回退。两边都跑的视图标识一致。 - 切换前合入两项性能改动：CLI 管理员命令结束时关掉自己开的连接池（#175，lease list 由 31 秒降到 1.4 秒）；自带 PostgreSQL 按主机内存定缓存和排序内存，带 pg_stat_statements 时预加载并只在 postgres 库建扩展（#176）。 - 切换：新备份后部署 main 63e15782d，数据库用新发布的程序重启，迁移到 24，停服 3 分 52 秒；随后开启内置 HTTPS（决定 121），HTTP 监听保留，已连接的客户端不受影响。发布 main 上版本高于生产的 28 个包、覆盖层生成的产品包和装构建档案（命名文档），两个执行器只改认可版本后更新；执行器预检完成，冻结 0。 - 主干封存：此后生产只从 main 的提交部署，主干不再合入。

6. 性能调优的目标和方法（来源：所有者 2026-11-04“做一轮专门性能调优，尤其是内存和多终端多平台并行使用，考虑最大并发用户数和响应时间”，问答定 50 人；“感觉不是好的调优方法哦，再想想？”“这也是我们的 hub 应该能记录和显示的内容，方便 debug”“抄一抄 langfuse 的设计”“4个问题都同意，123全部都做”；设计页 observability.md）： - 目标：50 人同时在线，每人约 3 个终端会话、1 个同步客户端、1 个控制台页面。交互类调用 p95 低于 2 秒，内存有上限、不崩，重计算不拖慢别人。 - 方法：Hub 自己记录和显示每次调用的步骤与用量、后台任务、资源和崩溃；按资源算容量，一次只改占用最大的一项；修的原则是代价只随答案大小变，不随历史增长；用确定性测试守住；最后压测一次作验收。 - 追踪部分照 Langfuse 的设计，资源和崩溃 Hub 自己补。诊断数据保留 14 天，不进记录链，不作依据。成员能看自己调用的用量。转发到外部的开关保留，默认关闭。 - 集成者撤回先前“读记录时同一进程校验一次就缓存”的建议：它拿完整性换 CPU，还多占内存。读取时的完整性校验不变，账本显示校验仍是大头时再议。 - 生产进程不留内存转储（里面有密钥），崩溃证据用 Node 的诊断报告和在途请求日志。

待所有者定

10-23 晚所有者定了原则：能用全用、能做全做。原来列在这里的 27 项和上机前的 12 个问题，都已按这条原则定下，结果见决定 35；原来的清单留在 Git 历史里。

网关的运行密钥和跳板机上的网关升级，所有者 10-24 上午已交给集成者，见决定 47。

截至 2026-11-03：上述决定 138～143 对应的 PR 均已合并或在合并中。协调中作出的六项裁定（issue #141）已由所有者在决定 137 里逐条定下；派发异常返回 Circle（所有者 2026-10-31 的要求）尚未开工，两项决定待定，见 issue #142。