Track B — Code Quality
The remediation phases sequenced against launch — what blocks, what runs in the background
The engineering-debt work is already fully specified in the remediation plan (phases 0–9 with acceptance criteria). Don't re-plan it — this page only sequences it against the launch milestones and separates what blocks launch from what runs as background hygiene.
Phase → milestone mapping
| Phase | What | Effort | Blocking? | Milestone |
|---|---|---|---|---|
| 0 — CI green | e2e selector fixes, lint --fix removal | ~½ day | Yes — nothing ships red | M0 |
| 1 — Secrets fail-fast | Kill default-secret, Joi prod-required | ~½ day | Yes | M0 |
| 2 — Test harness | Vitest + supertest + testcontainers, authz suites | 1–2 days | Yes — prerequisite for 3–4 landing tested | M1 |
| 3 — Auth hygiene | bcrypt hash off request.user, RequestUser type | ~½ day | Yes | M1 |
| 4 — Security patch set | OAuth fragment, ownership checks, helmet, throttler, pagination clamp | ~1 day | Yes | M1 |
| 7a — Vulnerability bumps | mailer/handlebars, multer, next; delete dead deps | ~½ day | Yes | M1 |
| 5 — Data access | PrismaService DI, migrations, transactions, mappers | per module | No — background | M2 → M4 |
| 6 — Backend quality | Promise<any> purge, Logger, service decomposition | per module | No — background | M2 → M4 |
| 7b — Ops | Health, Sentry, jobs module, Swagger, Renovate | ~2 days | Yes for beta — you can't run a beta blind | M3 |
| 8 — Frontend | Quick wins → review-queue refactor → consistency | independent | No — parallel any time | M2 → M4 |
| 9 — Production gaps | Email verification, GDPR, SEO, backups, legal | — | Yes | M3 (tracked as Track C) |
Two orderings are non-negotiable: 0 → 1 → 2 → 3 → 4 (each builds on the last), and 7a before any feature work (don't build features on vulnerable deps). Everything else interleaves freely.
Background phases: the module rhythm
Phases 5, 6 and 8 are sweeps, not gates. Run them between feature PRs, one module per PR, in the plan's order: deals → products → discussions → users (backend), and the frontend list top-to-bottom. Two rules keep them from dragging forever:
- Touch-it-fix-it: any feature PR that touches a module brings that module up to phase 5/6 standard as part of the PR (mappers, no
Promise<any>, Logger). The sweep then only has to cover untouched modules. - Ratchet, don't boil: once a grep gate (see conventions) reaches 0 repo-wide, add it to CI so it can't regress. Do this gate by gate as they hit zero.
Rules for every quality PR
- One phase step (or one module of a sweep) per PR — never mixed with feature work.
- Run the verification gates before declaring done; phases have their own Accept: lines in the plan — those are the merge criteria.
- Implementer agents get: the relevant conventions doc + the single plan/spec page for the step. Nothing else.
- After Phase 2 exists: every security-relevant change (3, 4, and anything auth/ownership) lands with a regression test that fails if the check is reverted.
What "done enough for launch" means
Launch does not require phases 5/6/8 finished. It requires:
- Phases 0–4 + 7 complete (their Accept lines green).
- Phase 9's items done via Track C.
- Background sweeps at least past the deals and auth modules — the code paths real users hit hardest on day one.