[yeroo]

Closes #518. Test-only change. The decoder is right; the corpus test was comparing against the wrong thing.

overalloc::tests::project_assignment_and_resource_offsets failed on every snapshot of the real .mpp corpus, not just the one it named. Two problems, the second hidden behind the first.

1. Project's implicit UID-0 resource

Project's XML export always lists an implicit unassigned resource with UID 0, and read_mspdi keeps it. Since #507 the decoder reads the true resource UID (+4, as the module doc says; before, it read the row ID at +0) and skips UID 0. That skip is right: the only caller, the OverAllocated derivation, never looks it up, because unassigned work carries the binary sentinel -65535 and is skipped before any resource lookup.

So the count was off by exactly one on all 47 pairs:

01-empty            decoder=[]            oracle=[0]
34-resource-work    decoder=[1]           oracle=[0, 1]
40-assign-multi     decoder=[1, 2, 3, 4]  oracle=[0, 1, 2, 3, 4]

Every real resource matched. The test now compares only real resources and pins both halves of that design, so neither side can drift unnoticed:

• the XML still lists UID 0;
• the decoder still leaves it out.

2. checked >= 50 could never pass on the fetchable corpus

yeroo/mpp-corpus provides only snapshots/, which is 47 eligible pairs. The other folders the test walks (task-fields/, order/, manual/, lag/, progress/) are generated locally with Project and pywin32 (corpus/tools/gen_mpp_task_field_cases.py), and neither the Mac nor the Windows machine has them. The guard now counts snapshot pairs and requires a complete fetch's 47. A partial fetch still fails loudly, and generated folders are checked on top when present.

3. Sorted paths

read_dir order is whatever the filesystem keeps. macOS reached 31-calendar-hours first and Windows another file, so a failure common to every snapshot looked peculiar to 31, and #518 was first filed under that name. The paths are sorted now. No assertion changes.

Proof, on macOS with the fetched corpus (yeroo/mpp-corpus b02a8e0)

Run	Before	After
cargo test -p mppread --release --lib	1 failed	83 passed
... --no-fail-fast -- --include-ignored	3 failed	2 failed: only the two #517 tests on 44-baseline, unchanged
same, with no corpus present (CI's view)	all pass	all pass (the test returns early)

The new assertions were checked against their failure modes. Each was broken on purpose and then reverted:

decoder made to return UID 0:
  .../snapshots/01-empty.mpp decoder returned Project's implicit UID-0 resource
guard raised to 48:
  only 47 snapshot pairs checked (47 in all); a complete corpus/tools/fetch-mpp-corpus.* fetch provides 47

cargo fmt --check is clean, and cargo clippy -p mppread --all-targets -- -D warnings exits 0.

One deviation from the agreed plan, worth stating. The plan said to also assert "every eligible pair was checked". Every mismatch in this test panics, and every skip is an explicit continue before a pair is eligible, so that assertion would be vacuous. I left it out, and the snapshot minimum is the guard.

#517 (the 44-baseline baseline-work failure) is deliberately untouched.

🤖 Generated with Claude Code

https://claude.ai/code/session_018qSpykxfaLiQSDxjsqbQUm

[yeroo]

Windows (corpus b02a8e0) on a44389d: cargo test --release -p mppread --lib → 83 passed, 0 failed (was 1 failed). Full --no-fail-fast -- --include-ignored → only the two #517 tests on 44-baseline fail (project_2024_oracles, progress_survives_save_as_mspdi_when_present), unchanged. Agree with dropping the always-true "every eligible pair checked" assertion; the 47-snapshot minimum is the real guard. Merging when CI is green.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 0% with 18 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
mppread/src/overalloc.rs	0.00%	18 Missing ⚠️

📢 Thoughts on this report? Let us know!