Skip to content

Unify repo-tidy and lfs-tidy JSON emit onto the shared write_json_flat path#199

Merged
jakebromberg merged 1 commit into
mainfrom
117f-scan-pipeline
Jun 21, 2026
Merged

Unify repo-tidy and lfs-tidy JSON emit onto the shared write_json_flat path#199
jakebromberg merged 1 commit into
mainfrom
117f-scan-pipeline

Conversation

@jakebromberg

Copy link
Copy Markdown
Owner

Summary

repo-tidy and lfs-tidy were the last two scan tools still emitting --json via a hand-rolled result.repos…map(JsonX::from).collect() + shared::write_json_pretty. Every uniform tool (remote/tag/stash/branch/worktree) already routes through the shared IntoJsonItem + write_json_flat mechanism. This change moves the two remaining tools onto it, so all seven scan-shaped tools share one JSON-emit path.

Why these two are different

They are the plan's structural exceptions (#117 §4): they keep their bespoke result types — repo-tidy's flat RepoScanResult (disk metrics + the cross-cutting dirty count) and lfs-tidy's LfsScanResult (the lfs_installed flag) — and stay on Layer 1 (parallel_classify), not run_pipeline. Because their results are bespoke, they cannot use the blanket impl<T: IntoJsonItem> FlatJsonItems for ScanResult<T> in core. So each tool:

  • implements IntoJsonItem on its item row type (RepoInfo / LfsInfo), delegating to the existing From, matching the convention of the 5 migrated tools; and
  • hand-writes a FlatJsonItems impl on its bespoke result (lfs flattens repos → items; repo maps its flat repos directly, since it has no RepoGroup).

write_json then collapses to shared::write_json_flat(out, result).

Output is byte-identical

The same JsonRepo/JsonLfsItem values, in the same order, serialized by the same write_json_pretty underneath write_json_flat. The existing json_output_valid and json_*_from_info tests pass unchanged. No result/group types, classification folds, or orchestration change; the audit runner (|r| &r.counts) is untouched.

Also

Drops the dead scan_empty_repo_no_lfs lfs test stub, which built a mock and then asserted nothing (its real coverage lives in the integration tests).

Local gate jobs green: cargo fmt --check, cargo clippy --workspace --all-targets -D clippy::all, cargo test --workspace, cargo +1.93.0 check --workspace (MSRV).

Part of #117

…t path

repo-tidy and lfs-tidy were the last two scan tools still emitting --json via a hand-rolled `result.repos…map(JsonX::from).collect()` followed by `write_json_pretty`; every uniform tool (remote/tag/stash/branch/worktree) already routes through the shared `IntoJsonItem` + `write_json_flat` mechanism. These two are the plan's structural exceptions (#117 §4): they keep their bespoke result types — repo-tidy's flat `RepoScanResult` with disk metrics and the cross-cutting `dirty` count, lfs-tidy's `LfsScanResult` with the `lfs_installed` flag — so they cannot use the blanket `FlatJsonItems for ScanResult<T>` impl in core. Instead they each implement `IntoJsonItem` on their item row type and hand-write a `FlatJsonItems` impl on their bespoke result, then call `shared::write_json_flat`.

This is a consistency-only change: the JSON is byte-identical (the same `JsonRepo`/`JsonLfsItem` values in the same order, serialized by the same `write_json_pretty` underneath `write_json_flat`), so the existing `json_output_valid` and `json_*_from_info` tests pass unchanged. No result/group types, classification folds, or orchestration change; both tools stay on Layer 1 (`parallel_classify`) per the plan. With this, all seven scan-shaped tools share one JSON-emit path.

Also drop the dead `scan_empty_repo_no_lfs` lfs test stub, which built a mock and then asserted nothing (its real coverage lives in the integration tests).

Part of #117
@jakebromberg jakebromberg merged commit 6476c7d into main Jun 21, 2026
3 checks passed
@jakebromberg jakebromberg deleted the 117f-scan-pipeline branch June 21, 2026 21:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant