Unblinded after review: A = Mercury 3, B = GPT-6 Luna, C = Claude Haiku 5.5. Written by a reviewing agent (Opus) and published unedited. # Review: c05-dir-mtime All three candidates found the root cause: `status` hashed each added directory's mtime into the fingerprint, and the conversion went through `mtime_to_nanos`, the range check meant for persisted regular-file mtimes. All three kept the dir mtime in the fingerprint with a range-safe encoding, which the grading notes accept. Each passes 6 of 7 hidden tests and fails only `soft_fingerprint_ignores_added_directory_mtime`, as expected for that design. Own suites, fmt, clippy (0 new diagnostics) and dprint are clean for all three. How I checked: I copied each tree, ran `cargo clean -p treeward`, rebuilt it, and drove the binary from scratch dirs with two Deno probes. They cover the headline repro, far-future dirs, new pre-epoch dirs under status, `status --verify`, verify, `update --dry-run` and `update --verify --fingerprint`, file-to-dir type changes, `init --fingerprint`, regular files that must stay fatal (pre-epoch, 2300, a tracked file backdated later), and fingerprint behavior when a dir mtime changes or a child is created and deleted during review. I used timezone-independent `touch -d @` for sub-second pre-epoch values. ## Candidate A: overall 8/10 Verdict: correct and well tested. `FingerprintPayload::Dir { mtime_nanos: Option }` keeps a representable mtime and turns an out-of-range one into a tagged `None`. The tag bytes (`[1]`/`[0]`) keep the encoding unambiguous. `mtime_to_nanos` delegates to the new `mtime_to_nanos_opt` and keeps its exact error messages. | Requirement | Verdict | Evidence | | ------------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------- | | Dir mtime never fails init | met | 1960 and 2300 dirs: init / --dry-run exit 0 | | Never fails status/update/--fingerprint/--dry-run/verify, new or tracked | met | probe: status 1, verify 1, dry-run 0, update --verify --fingerprint 0 | | Both bounds | met | None for both; hidden far-future test passes | | Regular files still fatal, naming the file | met | exit 255 with the original messages; hidden guards pass | | Fingerprint workflow with new dirs | met | hidden workflow, type change, and init --fingerprint all succeed | | EVAL_SUMMARY | met | thorough and accurate | Bugs: - minor (verified): all out-of-range dir mtimes become the same `None`. A new dir at `@-0.5` whose mtime moves to `@-100` after `status` is still accepted by `update --fingerprint` (exit 0). The same change between two in-range mtimes is rejected. The grading notes treat this kind of value collapsing as a mild deduction. Scope: SPEC got a new bullet saying directory mtimes never fail. The old bullet still says "Files" and was not narrowed to "Regular files". The README note was narrowed, which is justified. New tests sit directly after the previous ones with no blank line between them, which is cosmetic. Tests are the broadest of the three: unit tests for both bounds and for an in-range value, plus CLI tests for init (both bounds), status, the update fingerprint workflow, `update`/`--dry-run` on new and tracked dirs, and verify. ## Candidate B: overall 7/10 Verdict: correct and exact. The payload carries a `SystemTime`. `hash_directory_mtime` hashes a sign tag, then seconds and subsec nanos, using the `hashing::` helpers. The encoding is unambiguous over the full range. | Requirement | Verdict | Evidence | | ------------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------- | | Dir mtime never fails init | met | 1960 and 2300 dirs: init / --dry-run exit 0 | | Never fails status/update/--fingerprint/--dry-run/verify, new or tracked | met | same probe results as A | | Both bounds | met | full SystemTime range encoded | | Regular files still fatal, naming the file | met | logic untouched; exit 255 naming the file | | Fingerprint workflow with new dirs | met | hidden workflow passes; own test asserts that an mtime change mismatches | | EVAL_SUMMARY | partial | accurate but thin; design rationale and alternatives barely discussed | Bugs: none found. Scope: it hand-added an `[Unreleased]` entry to `CHANGELOG.md`. That file is generated by git-cliff from commit messages (see `cliff.toml` and the CLAUDE.md PR-title rules), so the edit is unjustified. SPEC was narrowed to "Regular files", and a new bullet mentions fingerprint internals, which is borderline implementation detail. The CLI test is one long scenario inserted at the top of `tests/status.rs`. It does cover status --verify, verify, dry-run, fingerprint mismatch and match, and plain update. There is also an init test covering both bounds. ## Candidate C: overall 8/10 Verdict: correct and well reasoned. `Dir { mtime_nanos: i128 }` holds exact signed nanos. In-range values hash with the same `dir` + u64 bytes as before, so existing fingerprints for ordinary directories do not change. Out-of-range values hash under `b"dir_wide"` plus the i128 bytes. | Requirement | Verdict | Evidence | | ------------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------- | | Dir mtime never fails init | met | 1960 and 2300 dirs: init / --dry-run exit 0 | | Never fails status/update/--fingerprint/--dry-run/verify, new or tracked | met | same probe results as A | | Both bounds | met | exact i128; unit test covers both | | Regular files still fatal, naming the file | met | unchanged; new unit test plus hidden guards | | Fingerprint workflow with new dirs | met | hidden and own update tests pass | | EVAL_SUMMARY | met | clear; one test claim is slightly overstated | Bugs: none found. A hygiene note: `b"dir"` is a prefix of `b"dir_wide"`, and the i128 is hashed with raw `to_be_bytes()` rather than a `hashing::` helper, which breaks the prefix-free tag scheme. A real stream collision would need the next record's path length to be at least about 8 MB, so it cannot happen in practice. Scope: the SPEC change mirrors the reference ("Regular files" plus a sentence exempting directories). The README note was narrowed, which is justified. Doc comments explain why directories bypass `mtime_to_nanos`. Tests: unit tests for added dirs at both bounds, payload distinctness, and "file still fatal next to a pre-epoch dir", plus a single CLI fingerprint workflow test. There is no CLI init test. The summary says `test_file_pre_epoch_still_fatal_while_dir_is_not` proves the dir is accepted, but it only asserts that the error names the file. ## Ranking 1. C (8) 2. A (8) 3. B (7) None of the three has a critical or major bug. C and B use exact, unambiguous encodings. C also keeps in-range fingerprint bytes unchanged and makes the cleanest SPEC/README/doc updates. A has the best tests and summary, but its `None` collapse means a change from one out-of-range dir mtime to another does not change the fingerprint, while an in-range change does. B is technically sound but hand-edited a generated CHANGELOG and wrote the weakest summary. All three kept the old behavior the reference removed. A child created and then deleted inside a new directory between `status` and `update --fingerprint` causes a fingerprint mismatch even though the reviewed state is unchanged. I reproduced this for all three, and none of them mentioned it.