Summary
Two maintainability items surfaced during the #194 review that were deliberately deferred to keep that PR reviewable against the finding it fixes. Neither is a bug; both are cleanups worth doing before the next change to the identity-key path.
1. Extract the identity-key machinery into its own module
crates/gitlawb-node/src/lib.rs is now 7593 lines. The identity-key publish/recovery machinery (write_key_or_cleanup at ~1058 through the end of identity_key_tests at ~7429) is roughly 1000 lines of production code plus its tests, and it is self-contained: one external entry point (load_or_create_keypair, called from run()), no cross-cutting dependencies on the rest of the file.
The crate already has a clean module layout (mod icaptcha, mod p2p, mod rate_limit, pub mod server, ...). Moving this block to crates/gitlawb-node/src/identity_key.rs with mod identity_key; and a pub(crate) re-export of load_or_create_keypair follows that pattern and shrinks the god-file substantially. Pure move plus visibility, no behavior change.
2. Extract the bounded name-probe loop
The for _ in 0..KEY_TEMP_ATTEMPTS { create_new / rename; on AlreadyExists try the next name; bail on exhaustion } pattern is duplicated across the production name generators: the quarantine-name loop (~1335), the claim-name loop (~1995), and the marker-name loop (~2134), each with the same never-clobber-a-name-you-did-not-create discipline and the same exhaustion-bail shape. A shared helper taking the directory, a name-builder closure, and the create-or-rename action would remove the triplication and give the discipline a single home. The temp-name loop on the primary path shares the shape too, though it differs enough (it opens rather than renames) that folding it in is optional.
Context
Both are the maintainability reviewer's P2 findings from the #194 review, held back so the fix diff stayed focused. They are safe, mechanical, and independently landable.
Summary
Two maintainability items surfaced during the #194 review that were deliberately deferred to keep that PR reviewable against the finding it fixes. Neither is a bug; both are cleanups worth doing before the next change to the identity-key path.
1. Extract the identity-key machinery into its own module
crates/gitlawb-node/src/lib.rsis now 7593 lines. The identity-key publish/recovery machinery (write_key_or_cleanupat ~1058 through the end ofidentity_key_testsat ~7429) is roughly 1000 lines of production code plus its tests, and it is self-contained: one external entry point (load_or_create_keypair, called fromrun()), no cross-cutting dependencies on the rest of the file.The crate already has a clean module layout (
mod icaptcha,mod p2p,mod rate_limit,pub mod server, ...). Moving this block tocrates/gitlawb-node/src/identity_key.rswithmod identity_key;and apub(crate)re-export ofload_or_create_keypairfollows that pattern and shrinks the god-file substantially. Pure move plus visibility, no behavior change.2. Extract the bounded name-probe loop
The
for _ in 0..KEY_TEMP_ATTEMPTS { create_new / rename; on AlreadyExists try the next name; bail on exhaustion }pattern is duplicated across the production name generators: the quarantine-name loop (~1335), the claim-name loop (~1995), and the marker-name loop (~2134), each with the same never-clobber-a-name-you-did-not-create discipline and the same exhaustion-bail shape. A shared helper taking the directory, a name-builder closure, and the create-or-rename action would remove the triplication and give the discipline a single home. The temp-name loop on the primary path shares the shape too, though it differs enough (it opens rather than renames) that folding it in is optional.Context
Both are the maintainability reviewer's P2 findings from the #194 review, held back so the fix diff stayed focused. They are safe, mechanical, and independently landable.