``` INPUT STATUS: ASSESSABLE Component: AuthService.ts / UserRepository.ts (getUserById, validateSession, createToken) Test coverage: 45% → PROCEED ``` --- ### CHAIN 1 — BLAST RADIUS ANALYSIS **Pre-emit gate — basis for dependent count:** No static analysis was run. The estimate below combines the four named dependents (Authentication middleware, BillingService.ts, UserProfile endpoints, daily CSV export job) with an inference from the description itself — `getUserById`, `validateSession`, and `createToken` are core identity primitives in a 150-file monolith, which almost always means many unnamed call sites across route handlers, middleware, and background jobs beyond the four flagged. This is a count estimate, not a confirmed measurement. ``` CHAIN 1 — BLAST RADIUS ────────────────────────────────────────────────────────────────── Direct dependents: 4+ named, likely 20+ unnamed — WIDE Basis: 4 named in input + inferred from role (core auth primitives in a monolith are rarely called from only 4 places) Critical paths: AUTH_ACCESS (direct), API_CONTRACT (direct), PAYMENT_BILLING (via BillingService — partial), DATA_EXPORT (via CSV export job — partial) — DIRECT (multiple paths, at least one direct hit) Migration needed: HIGH — schema re-index of user IDs to tenant-scoped keys, plus a breaking signature change (mandatory tenant_id param) that every caller of these 3 methods must update ────────────────────────────────────────────────────────────────── Blast radius score: 6/30 (WIDE dependents + DIRECT critical path exposure + HIGH migration is the worst-case combination on this dimension) ``` ### CHAIN 2 — SAFETY ANALYSIS (bootstrapped from Chain 1) **Bootstrap note:** Chain 1 found WIDE blast radius hitting auth, billing, and data export simultaneously. Against that backdrop, 45% coverage with no DB-layer integration tests isn't a moderate gap — it's a gap sitting directly under the riskiest part of the platform. A silent regression here wouldn't surface in a unit test; it would surface as broken logins, broken billing lookups, or a corrupted CSV export, in production. ``` CHAIN 2 — SAFETY (calibrated by Chain 1) ────────────────────────────────────────────────────────────────── Test coverage: 45% → PARTIAL Bootstrap note: WIDE blast radius means this PARTIAL coverage is effectively the only thing standing between this change and four separate downstream failure modes (auth, billing, profile, export). Safety mechanisms: Feature flag: UNKNOWN — not stated whether tenant-aware auth can be toggled independently of legacy auth Canary deploy: NOT_AVAILABLE — deployment pattern is scheduled weekly manual deploy, not canary/gradual rollout DB transaction: UNKNOWN — not stated whether the re-indexing migration can be wrapped/rolled back atomically API versioning: UNKNOWN — not stated whether old and new method signatures can run side-by-side Shadow traffic: UNKNOWN — not stated Rollback: COMPLEX — weekly manual deploy cadence plus a schema re-index (data migration) means rollback isn't a quick flag flip; reverting likely requires a second migration and redeploy ────────────────────────────────────────────────────────────────── Safety score: 17/40 (PARTIAL coverage + no confirmed mechanisms + COMPLEX rollback) ``` ### CHAIN 3 — EXECUTION SCENARIOS + VERDICT Given a WIDE blast radius with DIRECT critical-path exposure (Scenario B's stated fit) *and* COMPLEX rollback risk on a critical path (Scenario C's stated fit), this refactor sits at the intersection. Between the two, Parallel Run is the better match here specifically because `validateSession` and `createToken` are session-issuing methods — a strangler-style gradual traffic migration on auth primitives risks having some sessions validated under the old schema and some under the new mid-migration, which is harder to reason about than a clean flag-flip fallback. **Recommended: Scenario C — Parallel Run.** Build the tenant-aware path alongside the existing single-tenant path, route a controlled subset of traffic to it, keep the legacy path as live fallback, and cut over via a flag once the new path has proven out against billing, profile, and export consumers. ``` Execution approach score: 11/30 (Even the best-fit scenario carries real complexity here: three consuming systems beyond auth itself, weekly deploy cadence limiting iteration speed, and an irreversible-feeling schema change at the center of it) ``` --- ### PHASE 5 — FINAL DELIVERY ``` ═══════════════════════════════════════════════════════════════════ REFACTOR RISK ESTIMATOR™ — W1-12 Component: Single-tenant → multi-tenant auth schema migration (AuthService.ts / UserRepository.ts) ═══════════════════════════════════════════════════════════════════ RISK VERDICT ────────────────────────────────────────────────────────────────── Overall score: 34/100 — MEDIUM Recommendation: GO WITH CONDITIONS Conditions: 1. Write integration tests for the DB layer specifically covering getUserById, validateSession, and createToken under tenant scoping before merging — this is the single highest-leverage gap given WIDE blast radius + PARTIAL coverage. 2. Confirm in writing whether a feature flag or API-versioning path exists to run old/new auth side-by-side. If neither is available, build one before starting — Parallel Run depends on it. 3. Test the rollback migration (reverse re-index) in a staging environment before the production deploy window, since the weekly manual cadence means a failed rollback attempt costs a full week, not minutes. 4. Get explicit sign-off from BillingService and the CSV export job owners before cutover — both are named dependents on a critical path (billing, data export) and neither is the team doing the refactor. BLAST RADIUS SUMMARY ────────────────────────────────────────────────────────────────── Direct dependents: 4+ named, WIDE (estimate — not a static-analysis count) Critical paths: AUTH_ACCESS (direct), API_CONTRACT (direct), PAYMENT_BILLING (partial), DATA_EXPORT (partial) Migration: HIGH — breaking signature change + schema re-index SAFETY CHECKLIST (complete before deploying) ────────────────────────────────────────────────────────────────── ☐ Integration tests written for DB-layer behavior of the 3 changed methods under tenant scoping ☐ Feature flag or versioning mechanism confirmed and configured ☐ Reverse-migration rollback procedure documented and tested in staging ☐ Monitoring/alerts set on login failure rate, billing lookup failure rate, and CSV export job success/failure ☐ BillingService and CSV export job owners briefed on cutover timing and rollback trigger conditions RECOMMENDED APPROACH ────────────────────────────────────────────────────────────────── Scenario: C — Parallel Run Rationale: Auth/session-issuing code is the riskiest place to do a gradual traffic migration (strangler-style), since it can leave some sessions validated against the old schema and some against the new mid-rollout. A parallel implementation with a flag-flip cutover keeps the legacy path as an immediate fallback for the highest-blast-radius, hardest-to-test part of this change. Step-by-step: 1. Build the tenant-aware versions of getUserById, validateSession, and createToken alongside the existing methods (not replacing them yet). 2. Run the re-indexing migration in a backward-compatible way — add tenant_id without removing the old single-tenant lookup path. 3. Write the missing DB-layer integration tests against the new path before routing any real traffic to it. 4. Route a small, low-risk internal slice of traffic to the new path; validate against billing and export consumers specifically. 5. Expand traffic gradually behind the flag; keep the legacy path live as fallback through at least one full weekly deploy cycle. 6. Remove the legacy path only after a full cycle with zero flagged regressions in auth, billing, profile, and export. CHAIN HISTORY ────────────────────────────────────────────────────────────────── Chain Focus Key finding Score 1 Blast radius WIDE dependents, DIRECT critical 6/30 paths (auth + billing + export), HIGH migration complexity 2 Safety PARTIAL coverage, no confirmed 17/40 safety mechanisms, COMPLEX rollback 3 Execution Parallel Run recommended given 11/30 session-issuing methods + weekly deploy cadence ═══════════════════════════════════════════════════════════════════ ``` One thing worth flagging directly, outside the template: the weakest link here isn't the schema migration itself, it's that nobody has confirmed a feature flag or versioning mechanism exists yet. If that turns out to be unavailable, this should be re-scored — Parallel Run isn't viable without it, and Strangler Fig becomes the fallback option despite the session-consistency concerns noted above.