任务：凭据命中的受理跟到派生的字节上

决定 20 定了：带凭据的数据照常处理，数据更新不用问。现在管理员受理凭据扫描命中（records 决定 18）只对那一份字节有效，绑定的是 scanDigest（命中的位置和检测器）。系统包从原件派生出来的文档、知识视图从知识树生成的回答，字节不同、命中位置不同，于是又成了只保留。每次数据更新以后，集成者都要手动再受理一遍派生文档；知识视图还会把自身文字里有命中的条目剔掉（知识包 README 的 Needs、records 第 1 条）。目标是让受理在派生这一层自动带上：派生的字节里每处命中，在它所派生自的、受理仍有效的来源里都有同样的命中文字，这份派生字节就算受理。

  • 分支和工作树：hub-derived-acceptance，目录 circle-hub-derived-acceptance（依赖已装好）
  • 可以改的路径：hub/records/**、hub/knowledge/**、hub/connectors/**（只在派生文档的写入处）、hub/server/cli-admin.ts（只改 source held、source findings 的显示，10-23 补授权），以及对应的测试和 README。别的路径不动；合约缺什么先回报，不自己改 contracts/。
  • 规则：同前（不推送、不建 PR、不发布、不部署，不碰 7420、钥匙串、环境配置文件和任何真实系统；测试只用合成数据，样例凭据一律是假的；git commit -s）。
  • 验证：npx tsc --noEmit；node --test --test-concurrency=2 对 hub/records/**、hub/knowledge/**、hub/connectors/**；需要临时 PostgreSQL 的测试照现有写法起，不和别的终端同时跑验收套件。

要守住的

  1. 命中文字只在内存里比，绝不存、不记日志、不返回，和现在的 scanWithContexts 一样是包内的。记录里可以存的只有“由哪几份来源的受理覆盖”（来源的 sha256 和它的受理），不存文字，也不存文字的摘要：短口令的摘要可以被穷举。
  2. 只有 Hub 读到或生成的字节能这样带上受理（B02 R[4]）：上传、以人为作者的记录照旧不能被抬起，派生链里只要有一环是人提供的就不算。
  3. 每次读都重新检查（B04 R[1]）：派生字节所依的每一份来源，受理此刻仍有效才算；管理员撤回来源的受理，派生字节立刻回到只保留。
  4. 覆盖是逐处的：派生字节里有一处命中的文字不在来源已受理的命中里，整份就不算受理（照旧只保留，等管理员单独受理）。扫描被截断的，既不能当来源，也不能被覆盖。
  5. 来源只认真正的派生关系：派生文档的来源是 origin.generated.inputs 里的原件；知识视图的来源是所读的根的组成记录里列出的原件和派生文档。不能用“全 Hub 任何一份已受理的字节里有这段文字”来覆盖。

要做的

  1. records：扫描器给一个包内的入口，在内存里给出每处命中的确切文字；ingest 增加可选的派生来源（sha256 列表，由调用方给出，records 逐个核对：记录存在、是 Hub 读到或生成的、受理有效）。覆盖成立时，记录上写明由哪几份来源的受理覆盖，读档照常抬起；不成立时照旧只保留。source held、source findings 要分清“直接受理”“由派生覆盖”“没有受理”三种。
  2. knowledge：系统包派生文档的写入处，把原件作为派生来源传进去；知识视图生成回答时，把所读根的组成里有受理的来源传进去。覆盖成立时视图不再剔掉那些条目，说明里写明有几个条目的命中是由来源的受理覆盖的。
  3. README：records 写成新的决定（决定 18 的延伸），说明它和 B02 R[4]、B04 F[0] 的关系，交给模型所有者记下；knowledge 把 Needs 里 records 第 1 条改成已做，写明怎么做的。
  4. 测试（全部合成，假凭据）：派生文档的命中全在原件已受理的命中里，算受理；派生文档多出一处原件里没有的命中，不算；撤回原件的受理以后再读，回到只保留；上传和以人为作者的记录不能被抬起；被截断的扫描不能当来源；视图里命中被覆盖的条目不再被剔掉、没被覆盖的照旧剔掉；记录、日志和返回值里都找不到命中文字。每条规则有正例和反例。

完成后在终端里回报：提交号、测试数量、没做完或拿不准的地方。做完以后会请另一家族的终端独立复核这一处，因为它管的是凭据。