QA Team — filed 2026-07-14 from the README audit, at spikerj's direction. Three genuinely-dead files were already deleted in the audit branch (zero references, verified by grep across all non-obj sources):
SpikerSoft.Common/Interfaces/IAsposePdf.cs — 0 refs (vestigial; Aspose now lives only in worker projects)
SpikerSoft.Common/Utilities/HolidayManager.cs — only "consumer" was a commented-out line in SpikerSoft.Data/RedisOM/CalendarDay.cs (also removed). Worth noting it only ever knew 2025 US federal holidays (GetHolidays2025), so had anything actually used it, it would have been silently wrong all of 2026 — a good argument for not leaving date-hardcoded helpers lying around.
What remains (this ticket): the pre-marker "manager" classes that still have live references and therefore need a deliberate migration rather than a delete:
Class
Refs
Note
HexatileGameManager
registered in ServiceCollectionExtensions
superseded by the MediatR/marker-based domain structure
ToolsManager
registered in ServiceCollectionExtensions; uses DBManager
ditto
DBManager
used by ToolsManager, TrailManager
pre-SpikerDbContext data access
ICacheManager / CacheManager
mutually referencing
superseded by IRedisL2CacheService
Ask: migrate the remaining consumers onto the current patterns (SpikerDbContext / MediatR handlers / IRedisL2CacheService), then delete the manager classes and their DI registrations. Coordinate with #566 (Business decomposition) — these are the same tree.
**QA Team** — filed 2026-07-14 from the README audit, at spikerj's direction. **Three genuinely-dead files were already deleted** in the audit branch (zero references, verified by grep across all non-obj sources):
- `SpikerSoft.Business/UserManager.cs` — **entirely empty class**, 0 refs
- `SpikerSoft.Common/Interfaces/IAsposePdf.cs` — 0 refs (vestigial; Aspose now lives only in worker projects)
- `SpikerSoft.Common/Utilities/HolidayManager.cs` — only "consumer" was a **commented-out line** in `SpikerSoft.Data/RedisOM/CalendarDay.cs` (also removed). Worth noting it only ever knew **2025** US federal holidays (`GetHolidays2025`), so had anything actually used it, it would have been silently wrong all of 2026 — a good argument for not leaving date-hardcoded helpers lying around.
**What remains (this ticket):** the pre-marker "manager" classes that still have live references and therefore need a deliberate migration rather than a delete:
| Class | Refs | Note |
|---|---|---|
| `HexatileGameManager` | registered in `ServiceCollectionExtensions` | superseded by the MediatR/marker-based domain structure |
| `ToolsManager` | registered in `ServiceCollectionExtensions`; uses `DBManager` | ditto |
| `DBManager` | used by `ToolsManager`, `TrailManager` | pre-`SpikerDbContext` data access |
| `ICacheManager` / `CacheManager` | mutually referencing | superseded by `IRedisL2CacheService` |
**Ask:** migrate the remaining consumers onto the current patterns (`SpikerDbContext` / MediatR handlers / `IRedisL2CacheService`), then delete the manager classes and their DI registrations. Coordinate with #566 (Business decomposition) — these are the same tree.
Board-sweep status (2026-07-22): the three verified-dead files ARE deleted on master (UserManager.cs, IAsposePdf.cs, HolidayManager.cs — confirmed absent). REMAINING: the live legacy managers the ticket targets beyond those — HexatileGameManager/IHexatileGameManager, ToolsManager/IToolsManager, base/DBManager.cs still exist in SpikerSoft.Business (HexatileGameManager still DI-registered in the API). Retiring those needs actual refactoring, not deletion — leaving open with scope now precise.
Board-sweep status (2026-07-22): the three verified-dead files ARE deleted on master (UserManager.cs, IAsposePdf.cs, HolidayManager.cs — confirmed absent). REMAINING: the live legacy managers the ticket targets beyond those — HexatileGameManager/IHexatileGameManager, ToolsManager/IToolsManager, base/DBManager.cs still exist in SpikerSoft.Business (HexatileGameManager still DI-registered in the API). Retiring those needs actual refactoring, not deletion — leaving open with scope now precise.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
QA Team — filed 2026-07-14 from the README audit, at spikerj's direction. Three genuinely-dead files were already deleted in the audit branch (zero references, verified by grep across all non-obj sources):
SpikerSoft.Business/UserManager.cs— entirely empty class, 0 refsSpikerSoft.Common/Interfaces/IAsposePdf.cs— 0 refs (vestigial; Aspose now lives only in worker projects)SpikerSoft.Common/Utilities/HolidayManager.cs— only "consumer" was a commented-out line inSpikerSoft.Data/RedisOM/CalendarDay.cs(also removed). Worth noting it only ever knew 2025 US federal holidays (GetHolidays2025), so had anything actually used it, it would have been silently wrong all of 2026 — a good argument for not leaving date-hardcoded helpers lying around.What remains (this ticket): the pre-marker "manager" classes that still have live references and therefore need a deliberate migration rather than a delete:
HexatileGameManagerServiceCollectionExtensionsToolsManagerServiceCollectionExtensions; usesDBManagerDBManagerToolsManager,TrailManagerSpikerDbContextdata accessICacheManager/CacheManagerIRedisL2CacheServiceAsk: migrate the remaining consumers onto the current patterns (
SpikerDbContext/ MediatR handlers /IRedisL2CacheService), then delete the manager classes and their DI registrations. Coordinate with #566 (Business decomposition) — these are the same tree.Board-sweep status (2026-07-22): the three verified-dead files ARE deleted on master (UserManager.cs, IAsposePdf.cs, HolidayManager.cs — confirmed absent). REMAINING: the live legacy managers the ticket targets beyond those — HexatileGameManager/IHexatileGameManager, ToolsManager/IToolsManager, base/DBManager.cs still exist in SpikerSoft.Business (HexatileGameManager still DI-registered in the API). Retiring those needs actual refactoring, not deletion — leaving open with scope now precise.