GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Refs #905 (step 3, slice 4; the issue stays open for the 4 files open PRs change: redirect/mod.rs, upstream/pypi.rs, vendor/yarn_classic_lock.rs, vex/discover/yarn.rs).

Summary

Eight readers spelled out "skip a leading UTF-8 BOM" themselves. Some stripped one BOM, some stripped any number, and two skipped it twice (their own strip plus the reader below them). They now all follow formats::text's rule: they call strip_bom / split_bom, or they leave the skip to a reader that already does it once (top_level_key, the TOML lexer).

Why

• #905, register row E64 (living document §4.4 / register).
• Leverage: B 0, U 0, D ≈8 (seven inline copies plus one double skip), R L. Score ≈14. Every production candidate with B ≥ 1 is blocked by file overlap with the 31 open PRs, so this was the best free item.

What changed

formats::text gains pub const BOM. PENDING_INLINE_BOMS drops 7 files: these 6, plus formats/pnpm/lines.rs, which was a stale entry (its only BOMs are in tests).

Deleted

git diff --stat origin/main: 8 files, +186/−38. Production +29/−31, tests +157/−7.

Behavior

Zero or one leading BOM: no change. A file that starts with two BOMs now reads the second one as content. That is the rule every other reader has followed since #1160 and #1191. Concretely:

• a .yarnrc first key is no longer read;
• a Bun package.json has unreadable workspaces;
• a pnpm file: directory manifest is unreadable, so the copy is left alone like any other unreadable copy;
• pyproject.toml / hatch.toml are reported unparseable;
• a .yarnrc.yml first key is no longer read.

Test evidence

• One 0/1/2-BOM test per former caller:
  • yarnrc_and_bun_workspaces_read_past_one_bom_only
  • workspace_readers_read_past_one_bom_only
  • npmrc_splice_keeps_one_bom_and_reads_a_second_as_whitespace
  • berry_scopes_probe_reads_past_one_bom_only (it also covers yaml_top_level_value)
  • pnpm_file_directory_manifest_reads_past_one_bom_only
  • hatch_toml_reads_past_one_bom_only
• The two-BOM assertions are red on main by construction: main strips every BOM, or strips twice. I did not run them against main.
• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test -p socket-patch-core --lib: 6044 passed. The 4 failures are the known root-only sandbox tests (relax_loop_must_not_traverse_symlinked_root, an_unremovable_hidden_lock_keeps_every_store_entry, wire_write_failure_maps_error_and_leaves_lock_untouched, wire_failure_rolls_back_already_written_files), and they fail on main too.
• CLI suites: e2e_vex 38, e2e_vex_redirect 33, e2e_redirect_yarn_berry_build 34 and e2e_redirect_bun_build 35 all pass.
• production_bom_handling_goes_through_the_helpers passes with the shorter allowlist.

Risk

L. These are line-local swaps. The only behavior change is for double-BOM inputs, which no package manager writes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JzD96p5wGbQt6V2yfhWEV8