remove-feature

To safely delete a feature, exhaustively map all static, dynamic, string, config, and persisted-data references before removal, then apply leaf-first deletion ordering and run multi-pass orphan re-sweeps until stable. This prevents broken builds and silent regressions.

When removing a feature boundary, you must make an explicit persisted-data safety decision for existing rows: backfill, preserve as historical, or purge via a new database migration. This ensures schema changes do not silently orphan or corrupt data.

A standard grep misses orphaned references because feature deletion involves dynamic, string-based, i18n, analytics, and persisted-state mappings. You need reference classification beyond grep, including config and codegen registries, to catch all dead code.

Yes, you can remove routes, UI pages, exported functions, modules, endpoints, and jobs in one process. The deletion applies phase-gated boundary confirmation and leaf-first ordering to ensure aggregators and entry points are deleted only after leaf modules.

To verify feature deletion hasn't broken adjacent functionality, run final verification checks and targeted runtime smoke tests on adjacent features. This catches integration breakage that static reference mapping might miss during the dead code sweep.