Delete eight legacy modules that nothing reaches

[lamemustafa]

Why

Eight modules from the v0.1.0 extraction of the AXAL desktop sync app are still compiled into bridge_lib, and nothing reaches them. Every one of their items is pub inside a pub mod, so rustc's dead_code lint can't see that they're unused. They contain the old sync-app schema (outbox, sync_log, conflict_queue and similar tables), an outbox enqueue with no worker, an audit append, a SyncPlan, a ConflictResolution, a retry backoff table, and an ImportAction enum.

How it was measured

This used the compiler, not grep.

1. In a scratch worktree, I changed the 12 top-level pub mod declarations in src-tauri/src/lib.rs to pub(crate).
2. I added a root function referencing what the binaries and integration tests import from bridge_lib: agent::run_stdio from bridge_mcp, commands::VerifiedCompanyIdentity from tests/unit_a_live.rs, plus run and run_journal_confirmation_child_from_args, which are already crate-root pub fns.
3. I ran cargo check -p bridge --lib three ways: default features, --features lab-writes,live-calibration-harness,voucher-scan, and --lib --tests with all features.

80 items are reported unused in all three runs. This PR deletes only the files in which every item is unused:

File	Lines	Pinned
src/db/schema.rs	78	no
src/db/migrations/mod.rs	47	yes
src/db/outbox.rs	36	no
src/db/audit.rs	35	no
src/sync/engine.rs	16	no
src/tally/xml_builder.rs	13	yes
src/sync/retry.rs	10	no
src/sync/conflict.rs	8	no

git grep across the whole repository (src-tauri, tools, scripts, docs) finds no other reference to these files' paths or item names. The exceptions:

• A path listed in the historical plan docs/tally/TALLY_INTEGRATION_RESEARCH_AND_CODEX_PLAN.md.
• The surface manifest itself.
• An unrelated same-named ConflictResolution in db/tally_write_store.rs, which is untouched.

The db/migrations/*.sql files are not touched; they are still pinned.

Out of scope, on purpose. The other 72 items live in files that also contain live code. Most are in commands.rs and tally/connection.rs: the four deliberately unregistered legacy reads and their selected-read helpers. Deleting those is an owner decision, already recorded in docs/rust-module-conventions.md. The remainder are in tally/capability_packs.rs, tally/serial_queue.rs, tally/tdl_engine.rs, tally/validators.rs and reports/. Those are pinned and each needs its own decision.

Intent check: dormant foundation or leftover?

Following #476's lesson, I searched docs/adr, docs/step-by-step-roadmap.md, docs/tally/privacy-model.md, docs/tally/IMPROVEMENT_PLAN_2026H2.md, docs/tally/BACKLOG.md and the README for these modules' concepts, not just their file names. I also checked history.

• The migration runner and schema. git grep at 41485853 (v0.1.0), fddb6fee, 0100e6b2 and 56409e62 finds no caller of db::migrations::run, INITIAL_SCHEMA, audit::append or outbox::enqueue outside src/db/. It has never run since the open-source release.
  • ADR 0006 already calls the altmastid_cache helper "retired from runtime code" and says the old table "remains only for database compatibility". The only definition of that table is this unrun INITIAL_SCHEMA. Every mirror database is created by the numbered .sql migrations, which are untouched, so removing it breaks no existing database.
  • The ADR sentence is historical, so I'm leaving the ADR unedited.
• outbox. IMPROVEMENT_PLAN_2026H2.md §write substrate does plan an outbox, but the implemented one is tally_import_outbox_jobs and tally_import_outbox_items (0003_tally_safe_writes.sql, db/tally_write_store.rs). The deleted outbox table has a different shape (operation/target/payload/next_try) and no worker. It is not that plan.
• sync/conflict.rs ConflictResolution { Tally, Axal, Manual }. docs/step-by-step-roadmap.md says "Write preview, mappings, and conflict resolution remain disabled until their controlled-write roadmap slices". This enum is a three-variant stub with no consumer or tests. The live conflict type is db::tally_write_store::ConflictResolution.
• sync/engine.rs SyncPlan::gst_foundation, sync/retry.rs backoff table, tally/xml_builder.rs ImportAction. No ADR, roadmap or plan names them. The import writer builds its actions elsewhere.

So none of these is a documented dormant foundation. If the owner reads any of them as one, the natural keep is ConflictResolution, and it's a one-file revert.

Surface

• Pins removed: db/migrations/mod.rs and tally/xml_builder.rs.
• Cap: following the exact-count convention, MAX_SURFACE_FILES goes from 251 to 249 on current master (239 to 237 when first opened, before Parse password-protected bank statements into voucher proposals, through PDFium #444 added 12 pins), with a note beside it saying why.
• Reseal: I edited the file list, ran scripts/reseal.sh --pins-changed, then scripts/reseal.sh --verify (exit 0) after touching the tool source so it rebuilt from this worktree.
• Coverage report: it prints exactly the two removed pins.
• Gate: compatibility_gate_passed:unknown_claims=11:evidenced_claims=0, unchanged.
• Directory rule: src-tauri/src/db/migrations stays a required surface directory. Every file left in it is pinned.

Checks

• cargo check --workspace --all-targets, under default and all features: pass. The only warnings are the two unused bindings in tally/runtime.rs that Run the voucher-scan and calibration-harness tests in CI #453 removes.
• cargo clippy --workspace --all-targets -- -D warnings -A clippy::pedantic in src-tauri, and clippy on bridge-tally-compatibility in tools: pass.
• cargo fmt --check in both workspaces: pass.
• cargo test -p bridge-tally-compatibility, which includes the cap-versus-count assertion: pass.
• Test count: bridge lib lists 967 tests. The one test removed is db::migrations::tests::initial_schema_runs_idempotently_with_sqlx, which exercised only the deleted schema.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.