bug: repeated Windows host crashes; bound whole-tree snapshot memory

[2233admin]

Safety / symptom

The reporter has experienced repeated whole-host crashes during Code Intel work, including another crash during an attempted fix. Do not reproduce, build, or run the full test suite on the affected Windows host. This issue tracks a verified resource-pressure defect and a separate, unproven crash attribution.

Read-only evidence

• Earlier Windows records include Kernel-Power 41 with BugcheckCode 26 (0x1A), parameter 1 0x3F; Microsoft documents this subtype as a pagefile inpage CRC error. A separate reboot recorded bugcheck code 0. Do not conflate the two or assign either to this process without process/dump evidence.
• A roughly 5.27 MiB minidump exists from the earlier failure, but the current account cannot read it. Process-creation telemetry for the failure window was not available. The newly reported crash has not been inspected. No dump or machine-specific path is attached.
• crates/code-intel-cli/src/snapshot.rs: digest_worktree reads each scoped file with fs::read and retains framed contents in records (lines 1013-1099); hash_records concatenates those records into a second canonical buffer (lines 1610-1616). Peak allocation grows with whole-tree content, not just one file. The successful native-lite path builds snapshots repeatedly; this is a static call-path count, not a measured crash-time RSS.
• MCP get_gate_verdict calls freshness (mcp_serve/handlers.rs:50-54); committed_evidence.rs:88-120 rebuilds the current worktree snapshot per such request. The idle stdio server does not automatically perform this scan.

Upstream-owned repair and acceptance

1. In an independent, safe host/worktree, replace whole-tree retained records plus concatenated canonical buffer with incremental hashing of the same framed bytes and ordering. Keep snapshot identity and artifact-contract parity; bound peak memory by the largest file/chunk rather than the sum of all files. Review whether repeated unchanged snapshots can be avoided without weakening freshness semantics.
2. Add deterministic digest-parity and bounded-memory checks with representative large files. Run focused tests plus cargo test --workspace --no-fail-fast and relevant integration gates on safe CI/host, not on the affected computer. Have an upstream reviewer inspect results before release.
3. Treat the host crash as unresolved until a trusted, authorized dump analysis or contemporaneous command/process/commit telemetry establishes causation. A 0x1A/0x3F pagefile CRC can involve storage, controller, memory, or driver faults; Code Intel I/O/memory pressure may trigger that path but is not proven to be its sole cause.

No repository or OS changes, workload reproduction, dump upload, or new crash verification were performed for this report.

[2233admin]

2026-09-30 收敛判决 + 认领（DR-0014 / DR-0004）

Verdict: do。本会话认领。

病灶已在源码中核实（2026-09-30，非引用交接文档）

crates/code-intel-cli/src/snapshot.rs：

• digest_worktree（:1013-1100）对每个 scoped 文件做 fs::read（:1064），把内容复制进 record（:1096 record.extend_from_slice(&content)），record 本身又 push 进 records（:1097）。因此每个文件的字节在内存里存在两份：content 与 record。
• hash_records（:1610-1617）把 records 全部拼进第二个 canonical buffer 后一次性 sha256_hex：

  let mut canonical = Vec::new();
  for record in records {
      canonical.extend_from_slice(&(record.len() as u64).to_be_bytes());
      canonical.extend_from_slice(record);
  }
  sha256_hex(&canonical)

• 峰值 ≈ 2× 全树内容 + 全部 record 常驻。

认领（DR-0004）

• 分支：agent/issue-403-snapshot-incremental-hash
• 一行方案：把 hash_records 改为对同一套 framed bytes 做增量哈希（sha256::Sha256::new() 逐条 update），并让 digest_worktree 在构造每条 record 后立即喂进 hasher 而不保留 records，从而去掉 canonical 这第二份缓冲。
• 不变量：snapshot identity 不得改变。framing 格式（kind\0mode\0relative\0len_be_u64\0content、tombstone 分支、gitlink 用 oid 字节）必须逐字节不变。修复后同一工作树必须产出同一个 snapshot 字符串——这是本修复的核心验收条件，不是"应该有提升"。
• 不在范围：不改 snapshot 的语义、不改 policy、不改 canonical_scopes、不重构 #[path] 结构（AGENTS.md 声明 94 处 #[path] 重入为有意设计，不是债务清单）。

验证必须在别的机器（DR-0013 / #403）

本 checkout 所在 Windows 主机被隔离，禁止 cargo build/test/check/clippy/run/nextest/clean。因此：

• 修复可以在本机写完并提交；
• 验收证据必须来自 CI 或其他主机，本机不得执行测试套件；
• AGENTS.md 要求的 cargo test --workspace --no-fail-fast 在本机挂起，由远端运行满足。

要落一条盯住不变量的回归测试（同一工作树两次构建产出的 snapshot 相等、且与修复前已知值相等），但它需要能跑——所以 PR 必须让 CI 绿，合并前不要以"本机看起来对"为准。

崩溃归因仍未定论

DR-0013 已记录：本机 6 次 Kernel-Power 41 中 3 次带 BugCheckCode 26（0x1A MEMORY_MANAGEMENT）、参数 63（0x3F pagefile inpage），但资源并未耗尽（32 逻辑核、93.7GB 内存、pagefile 峰值 1.4GB、四盘 Healthy、7 天零 WHEA）。因此"修掉这份 2× 内存就等于修掉崩溃"是未证假设。本票修的是一个已实测的内存缺陷，不应被当成 #403 崩溃的既定解法。崩溃归因需要授权的 dump 分析，本账户无法执行。

[2233admin]

2026-09-30 追加：本机无法执行 AGENTS.md 要求的 lint hardcoded-paths 闸

在准备本票实现时发现，记录下来供维护者处理。

事实

AGENTS.md 要求"Run code-intel lint hardcoded-paths before pushing (issue #275: the Rust implementation replaced legacy/tools/check-hardcoded-paths.ps1)"。

本机该命令不存在：

$ code-intel lint hardcoded-paths
Code Intel error: only one repository path may be supplied
$ code-intel lint
Code Intel error: repository path is not a directory: lint
$ code-intel --help --all | grep lint
  （只匹配到 compatibility retirement-ticket lint --ticket ...）

已安装二进制版本是 code-intel 0.7.1，checkout 声明 0.7.2-beta.6。

原因

命令在源码里确实存在（不是文档漂移）：

• crates/code-intel-cli/src/cli/command_catalog/routes/mod.rs:152-165 有 raw_route!，注册 command: "lint" + subcommand: Some("hardcoded-paths")，argument_offset: 2，exit 契约 [0, 1, 74]
• routes/mod.rs:623 派发到 hardcoded_paths::run_raw(raw)
• tests.rs:465-468 有对应契约测试
• 同处 :468-472 还定义了 verify 聚合命令（Add code-intel verify command: aggregate lint hardcoded-paths + sentrux gate + repin check-only #367/feat: add code-intel verify command aggregating lint/gate/repin (#367) #368 引入，聚合 lint + sentrux gate + repin check-only）

这些都晚于 0.7.1。也就是说本机装的是旧版本，闸随新版本一起还没到这台机器。

后果

AGENTS.md 规定的强制闸在本 checkout 所在主机无法执行，原因与 DR-0013 同源：

• 想用新闸 → 需要编译当前 checkout → DR-0013 禁止本机编译
• 用旧二进制 → 闸不存在

这两条合起来意味着：本机上任何 Rust 改动都无法满足 AGENTS.md 的推送前闸。这不是本票独有问题，是所有 Rust 改动在隔离期共同面对的。

建议（不自行决定）

两条路，二选一或并行：

1. 升级本机二进制到 0.7.2-beta.6 或更高。注意 DR-0013 禁止的是"编译当前 checkout"，不禁止"安装已发布版本"。若已有对应的 GitHub Release，安装它既不违反隔离，也能恢复闸的执行能力。
2. 在 CI 上跑该闸。既然 Rust 改动的验证本来就必须在 CI 或其他主机进行，把 lint hardcoded-paths 一并放进 CI 是自洽的。

无论哪条，都值得在 AGENTS.md 里补一句"隔离期该闸的替代执行位置"，否则下一个会话会重复撞上同一堵墙。

不做的事

本会话没有尝试用 PowerShell 版 legacy/tools/check-hardcoded-paths.ps1 代替。理由：AGENTS.md 明确说 #275 用 Rust 实现替换了它，其扫描行为与 $env: 前缀剥离规则（该文档专门警告过）是否与 Rust 版一致，需要跑起来对比才能确认，而本机跑不了。用一个行为未证等价的老实现冒充新闸，比不跑更危险。

[2233admin]

关联：已就本票准备阶段发现的「code-intel lint hardcoded-paths 在隔离主机无法执行」单独开票 #405（已安装二进制 0.7.1 早于该命令进入 checkout 的 0.7.2-beta.6）。本票的推送前闸同样受阻，解除条件见 #405。

[2233admin]

2026-09-30 范围更正：病灶有三处，不是一处

开工前重新读了 snapshot.rs，发现票面描述的病灶只覆盖了 1/3。

票面说的（digest_worktree）

:1013-1100 逐文件 fs::read → 复制进 record（:1096）→ records 累积（:1097）→ hash_records 再拼第二份 canonical（:1611-1615）。确认无误。

同构但票面没提的两处

hash_records 在本文件有 6 个调用点：627 / 635 / 941 / 974 / 1099 / 1423。逐个核实数据规模：

调用点	所属函数	数据规模	是否同构病灶
627	head_only 身份	小（单个 vec）	否
635	head_only 身份	小（字面量数组）	否
941	—	小	否
974	digest_head	全树（records.sort() 后 framed.append）	是
1099	digest_worktree	全树	是（票面所指）
1423	digest_unversioned（:1388）	全树（同样 fs::read + 累积）	是

digest_unversioned 与 digest_worktree 结构完全一致：fs::read(&path) → record.extend_from_slice(&bytes) → records.push(record) → hash_records(&records)。

digest_head（:974）略有不同——它累积的是 git 输出的行而非文件内容，但同样是全量累积后一次性交给 hash_records。

为什么这个更正重要

只修 digest_worktree 会产生假成功。 head_only 策略走 digest_head、explicit_overlay 走 digest_worktree、unversioned 场景走 digest_unversioned——三条路径都会在树大时撞上第二份缓冲。修掉一条，另外两条的内存曲线原样存在，而票面会以"已修复"结案。

修订后的方案

不是"改一个函数"，而是把 framing 逻辑抽出来，改成增量喂入 hasher，三处共用：

• 新增一个 RecordHasher（或直接让三处各自持有一个 sha2::Sha256），提供 push(&[u8])；
• hash_records 保留原签名与行为，改为内部用同一个增量路径实现——这样那 3 个小调用点一行不改、行为可证不变；
• 三处大调用点改为边构造边 update，不再保留 records。

不变量不变：framing 格式（kind\0mode\0relative\0len_be_u64\0content、tombstone 分支、gitlink 用 oid 字节）逐字节不变，snapshot identity 必须与修复前完全相同。

验证上的额外风险（须在 PR 里说清）

本机跑不了测试（DR-0013），所以"identity 不变"只能由 CI 证明。缓解办法是在 PR 里附上修复前后对同一工作树的 snapshot identity 实测值对比——但这需要在能编译的机器上取旧值。若拿不到，退路是：加一条回归测试，断言同一工作树连续两次计算得到相同 identity（只能证确定性，不能证与旧实现一致）。

这个风险无法在本会话内消除，需要维护者决定在哪台机器取基线。

[2233admin]

Takeover (DR-0004 / DR-0014 §2).

• The existing claimed on bug: repeated Windows host crashes; bound whole-tree snapshot memory #403 (2026-09-30, XART-80 convergence session, verdict "do") names no implemented branch. Per DR-0014 §2 I verified the claim ref: no local head, no origin/*, and none of the refs/remotes/xart80/* branches synced to AU-5090 carries a bug: repeated Windows host crashes; bound whole-tree snapshot memory #403 implementation. The only partial attempt is the half-done streaming hash on origin/backup/pr409-8c525db, which was dropped from fix(pins): recover the 2026-09-03 dirty tree and close its pin chain (#393) #409 (fix(#403): finish the streaming-hash repair — snapshot.rs imports Sha256 but hash_records is unchanged #411 describes it).
• The work moves to AU-5090 (Windows Server 2025). DR-0013 forbids cargo only on the XART-80 host, so it does not cover this one.
• Branch: fix/411-streaming-snapshot-hash (worktree off origin/main b17d401).
• Approach: pin the current snapshot identity with a fixture test, then feed the same length-framed records, in the same order, into a streaming SHA-256 per file so digest_worktree/digest_unversioned stop retaining every file's bytes plus a concatenated copy; measure peak memory before/after.

The PR will close #411 and reference #403; #403's crash-causation question stays open.