Problem
server.ts is explicitly documented as deprecated with a known CPU-starvation flaw, yet it remains the default npm run dev entry path implied by the legacy architecture section, while dev:ws also boots it. New contributors have no signal for which server to actually develop against, and "deprecated but still default-adjacent" is exactly the kind of inconsistency that makes a repo look unmaintained.
Proposed work
Either (a) fully remove server.ts and the legacy monolithic path once the microservices architecture is confirmed stable, or (b) keep it only behind an explicit --legacy flag / separate clearly-labeled script, with a runtime console warning on boot.
Update README's architecture section so only one path is presented as "the way to run this," with the other (if kept) clearly marked experimental/legacy in the table of scripts, not just in prose.
Add a migration note for anyone with local scripts/configs still pointing at the legacy server.
Acceptance criteria
Running npm run dev does not silently start a server with a documented, unresolved performance flaw.
Exactly one server path is presented as recommended in README without requiring the reader to cross-reference a deprecation notice in source.
If legacy server is retained, it prints a visible deprecation warning on startup.
Problem
server.ts is explicitly documented as deprecated with a known CPU-starvation flaw, yet it remains the default npm run dev entry path implied by the legacy architecture section, while dev:ws also boots it. New contributors have no signal for which server to actually develop against, and "deprecated but still default-adjacent" is exactly the kind of inconsistency that makes a repo look unmaintained.
Proposed work
Either (a) fully remove server.ts and the legacy monolithic path once the microservices architecture is confirmed stable, or (b) keep it only behind an explicit --legacy flag / separate clearly-labeled script, with a runtime console warning on boot.
Update README's architecture section so only one path is presented as "the way to run this," with the other (if kept) clearly marked experimental/legacy in the table of scripts, not just in prose.
Add a migration note for anyone with local scripts/configs still pointing at the legacy server.
Acceptance criteria
Running npm run dev does not silently start a server with a documented, unresolved performance flaw.
Exactly one server path is presented as recommended in README without requiring the reader to cross-reference a deprecation notice in source.
If legacy server is retained, it prints a visible deprecation warning on startup.