🔍 Phase 1 — Codebase Inventory Component Type Production Criticality API Application 🔴 Critical Worker Background service 🟠 High Payments Library/module 🔴 Critical Notifications Library/module 🟠 High Utils Shared library 🟡 Medium Legacy Payment Compatibility module 🟡 Medium Admin Application 🟡 Medium Finding: Payment functionality is the highest-risk cleanup area. --- 🔎 Phase 2 — Entry-Point Analysis Identified roots: API startup ↓ PaymentService ↓ Dynamic Provider Loader ↓ Stripe Provider And: Worker ↓ Notification Job ↓ EmailNotifier Important: StripeV1Adapter cannot be considered dead simply because it has few references because migration scripts can execute it. --- 🧩 Phase 3 — Dead-Code Findings Candidate 1: formatLegacyDate() Evidence: No direct source references. No runtime usage in 90-day telemetry. Not used by known entry points. No configuration reference discovered. Utility has no known registration mechanism. Classification: 🟢 Likely unused Confidence: 95% Risk: 🟢 Low Recommendation: REMOVE Required validation 1. Repository-wide search 2. TypeScript/compiler validation 3. Utils test suite 4. API/admin build 5. Application smoke test --- 📦 Phase 4 — Dependency Audit moment Evidence: Present in dependency manifest. No obvious application imports. No production runtime usage found. Need to check build scripts, configuration and transitive assumptions. Classification: 🟡 Possibly unused Confidence: 80% Recommendation: VALIDATE FIRST Do not immediately remove it. Required checks: npm/yarn/pnpm dependency analysis Build plugin inspection Configuration search Test/build execution Lockfile regeneration Application startup test --- 🧩 Phase 5 — Hidden Dependency Analysis Payment Provider The code contains: loadProvider(process.env.PAYMENT_PROVIDER) Therefore static references may not reveal the complete dependency graph. Configuration currently contains: PAYMENT_PROVIDER=stripe but an old staging configuration contains: PAYMENT_PROVIDER=paypal Finding: PayPal appears unused in production, but its runtime capability cannot yet be classified as removable. Classification: 🟡 Validate First Risk: 🔴 Critical Reason: Configuration-driven dynamic loading can bypass static dependency analysis. --- 🕰️ Phase 6 — Legacy Component Analysis StripeV1Adapter Evidence: Only referenced by migration tooling. No production calls in 90 days. Migration scripts are not part of normal deployment. Migration completion status is not explicitly provided. Classification: 🟡 Potentially obsolete Confidence: 75% Recommendation: DEFER / VALIDATE Do not remove yet. Required evidence: - Confirm migration completion - Confirm no remaining data requires migration - Execute migration test in isolated environment - Verify rollback procedure - Search CI/CD for migration execution --- 🔄 Phase 7 — Redundant Implementation Analysis Suppose the audit discovers: packages/utils/formatCurrency() packages/payments/formatPaymentAmount() Both appear to perform currency formatting. Comparison: Factor formatCurrency formatPaymentAmount Consumers 8 1 Tests High Low Production use High High Behavior Generic Payment-specific Risk Low Medium Recommendation: KEEP formatCurrency() MIGRATE formatPaymentAmount() Then remove the second implementation only after regression tests pass. --- ⚠️ Phase 8 — Blast-Radius Assessment Candidate Risk Action formatLegacyDate() 🟢 Low Remove moment 🟡 Medium Validate StripeV1Adapter 🟠 High Validate migration PayPal provider 🔴 Critical Preserve until proven unnecessary PaymentService 🔴 Critical Do not remove EmailNotifier 🟠 High Preserve --- 🧪 Phase 9 — Verification Tests Before Removal - Repository-wide reference scan - Dependency graph analysis - Build validation - Relevant unit tests - Configuration search - Runtime telemetry review During Removal For formatLegacyDate(): 1. Delete function. 2. Run utility tests. 3. Run API build. 4. Run admin build. 5. Run integration tests. After Removal - Deploy to staging - Execute application smoke tests - Verify API health - Verify worker startup - Monitor errors - Compare runtime behavior --- 🪜 Phase 10 — Safe Removal Order Step 1 — Remove formatLegacyDate() Reason: Isolated No known consumers No runtime usage Low blast radius Step 2 — Validate moment Determine whether it is genuinely unused. If validation confirms no usage: Remove moment ↓ Regenerate lockfile ↓ Build ↓ Run tests ↓ Deploy staging Step 3 — Consolidate duplicate utilities Migrate consumers first. formatPaymentAmount() ↓ formatCurrency() ↓ remove old implementation Step 4 — Validate StripeV1Adapter Only remove after migration completion is proven. Step 5 — Reassess PayPal Require evidence that: Production = no usage Staging = no required usage Config = obsolete Migration = complete Rollback = unnecessary Only then consider removing it. --- 📊 Final Cleanup Priority Matrix Candidate Dead-Code Confidence Risk Priority Recommendation formatLegacyDate() 95% Low 🔥 Remove First REMOVE moment 80% Medium 📌 Validate First VALIDATE Duplicate formatter 90% Medium 🚀 High MIGRATE + REMOVE StripeV1Adapter 75% High 🕐 Defer VALIDATE PayPal provider 60% Critical 🛑 Do Not Remove PRESERVE PaymentService 0% Critical 🛑 Do Not Remove PRESERVE EmailNotifier 0% High 🛑 Do Not Remove PRESERVE --- 🛣️ Cleanup Roadmap Phase A — Low-Risk Cleanup Target: formatLegacyDate() Action: Remove Verification: Unit + build + smoke tests Risk: 🟢 Low Rollback: Git revert --- Phase B — Dependency Cleanup Target: moment Prerequisite: Confirm no dynamic/build/config usage Action: Remove dependency and regenerate lockfile Risk: 🟡 Medium Rollback: Restore manifest + lockfile --- Phase C — Redundancy Reduction Target: Duplicate currency formatter Prerequisite: Consumer migration Action: Migrate → test → remove duplicate Risk: 🟡 Medium --- Phase D — Legacy Removal Target: StripeV1Adapter Prerequisite: Migration completion evidence Action: Remove migration-only adapter Risk: 🟠 High Rollback: Restore adapter from version control --- Phase E — Architectural Cleanup Target: Dynamic provider architecture Action: Simplify provider registration only after proving which providers are genuinely required. Risk: 🔴 Critical Recommendation: Perform last. --- 📈 Expected Benefits These are estimates based only on the sample data, not measured results: Lines of code: Small reduction initially Dependencies: Potentially 1 fewer production dependency Maintenance: Reduced legacy utility and duplicate implementation burden Build complexity: Potentially lower after dependency cleanup Upgrade benefits: Fewer obsolete packages to maintain Operational benefits: Simpler code paths and fewer legacy components Final Audit Verdict The safest strategy is not to aggressively delete everything that looks unused. The recommended sequence is: formatLegacyDate ↓ moment validation ↓ duplicate formatter migration ↓ StripeV1Adapter migration validation ↓ PayPal/provider reassessment ↓ high-risk architectural cleanup Key lesson from this test: static reference absence is evidence of possible dead code, not proof of dead code. Dynamic loading, migration scripts, configuration, plugins, and runtime behavior must be checked before removal.