# Technical Debt Audit — Checkout Module (Rails Monolith) ## DEBT CONTEXT TABLE | Dimension | Classification | Rationale | |-----------|---------------|-----------| | Debt origin | Mixed (Bit rot + Deliberate) | Deprecated gems point to bit rot (entropy from not upgrading); untested checkout code more likely reflects a deliberate "ship first, test later" tradeoff common under weekly release pressure. **INFERRED** | | System age signal | Legacy (5+ yrs) | Directly given. **STATED** | | Change frequency | High (weekly deploys) | Directly given. **STATED** | | Failure cost | Critical (core revenue) | Directly given — checkout downtime = immediate revenue loss. **STATED** | | Team debt awareness | Partially known | The team can name two debt items (tests, gems) unprompted, which suggests some awareness, but a 4-person team shipping weekly with heavy context-switching is unlikely to have a full inventory. **INFERRED** | ## FAILURE MODE PRIORITY MAP | Failure Mode | Priority | Evidence Type | Conf | |-------------|----------|---------------|------| | Debt invisible to new team members — onboarding collapse | MED | INFERRED | 55 | | Debt compounding — one fix requires 3 others first | HIGH | INFERRED | 70 | | Debt causing production incidents directly | HIGH | INFERRED | 75 | | Velocity drag accumulating without awareness | HIGH | STATED (context-switching) + INFERRED (drag) | 65 | | Security debt converting to vulnerability | HIGH | INFERRED | 68 | **Rationale:** A revenue-critical module with zero test coverage, shipped weekly by a small team, is the textbook setup for silent production incidents — every deploy is effectively untested in the one place downtime is most expensive. Compounding risk is rated high because legacy Rails apps with deprecated gems typically can't be upgraded without first having tests to verify behavior didn't change, which is a classic "can't fix A without B" trap. Onboarding risk is rated MED rather than HIGH only because team size (4) means tribal knowledge is currently concentrated, not yet proven to be a failure point. ## DEBT REGISTER | # | Debt Item | Category | Severity | Interest Rate | Effort to Fix | Evidence Type | Conf | |---|-----------|----------|----------|---------------|---------------|---------------|------| | 1 | Zero automated test coverage on checkout module | Test | 🔴 | High (compounding weekly) | L | STATED (existence) / INFERRED (impact) | 90 | | 2 | Deprecated gem versions with likely unpatched CVEs | Security | 🔴 | High | M | STATED (existence) / INFERRED (severity) | 70 | | 3 | Rails framework version likely several majors behind | Infra | 🟡 | Med | XL | INFERRED | 55 | | 4 | No CI gating / required checks before checkout deploys | Process | 🔴 | High | S | INFERRED | 60 | | 5 | Fat models / "God object" pattern typical of 5-yr-old Rails apps | Architecture | 🟡 | Med | L | INFERRED | 65 | | 6 | Tight coupling between checkout logic and payment gateway integration | Architecture | 🔴 | High | L | INFERRED | 60 | | 7 | No feature flag or fast-rollback mechanism for checkout deploys | Infra/Process | 🔴 | High | M | INFERRED | 55 | | 8 | Manual QA reliance as the only safety net pre-deploy | Process | 🟡 | Med | S | INFERRED | 60 | | 9 | Half-finished refactors left behind from context-switching between features and bugs | Process | 🟡 | Med | M | STATED (context-switching) / INFERRED (effect) | 50 | | 10 | No automated dependency scanning or update cadence | Process/Security | 🟡 | Med | S | INFERRED | 60 | | 11 | Database schema debt — likely missing indices, unresolved migration backlog | Infra | 🟢 | Low | M | INFERRED | 40 | | 12 | Undocumented checkout business logic ("tribal knowledge" risk in a 4-person team) | Architecture/Process | 🔴 | High | M | INFERRED | 55 | ## ASSUMPTION LEDGER | Assumption | Where It Enters | If False — Effect on Debt Assessment | |------------|----------------|--------------------------------------| | "No test coverage" means zero automated tests on checkout, not just low coverage | Items 1, 4, 8 | If partial coverage exists, severity of 1 drops from 🔴 to 🟡 and Phase 1 shrinks significantly | | Deprecated gems include at least one with a known CVE, not just version lag | Item 2 | If purely cosmetic version lag, this becomes 🟡 Med and moves out of Phase 1 | | Weekly deploys imply *some* CI/CD pipeline already exists (just without checkout-specific gates) | Items 4, 7 | If no CI/CD exists at all, effort for item 4 jumps from S to M/L | | All 4 engineers rotate across the whole codebase rather than owning discrete areas | Register-wide effort estimates | If ownership is siloed, bus-factor risk (item 12) drops but cross-training need rises | | "High context-switching" reflects fragmented ownership, not just a busy sprint calendar | Items 9, 12 | If it's a temporary staffing crunch, items 9/12 are transient rather than structural debt | **⚠ Silent corruption flags:** - **Item 2 (deprecated gems)** — reads as routine maintenance, easy to keep deprioritizing until one gem's CVE becomes an active exploit path. - **Item 6 (checkout ↔ payment gateway coupling)** — invisible day-to-day; surfaces suddenly when the payment vendor ships an API change and the blast radius turns out to be far larger than expected. - **Item 12 (undocumented business logic)** — feels fine while the one engineer who understands it is still on the team; becomes a crisis the day they're unavailable or leave. ## DEPENDENCY & COMPOUNDING MAP | Debt Item | Blocks | Blocked By | Compounding Risk | |-----------|--------|------------|-------------------| | 1. No test coverage | 3, 5, 6, 7, 9, 12 | — | High | | 2. Deprecated gems | 3 | — | High | | 3. Rails version behind | 5, 6 | 1, 2 | Med | | 4. No CI gating | — | 1 | High | | 5. Fat models | 9 | 1, 3, 12 | Med | | 6. Checkout↔gateway coupling | — | 1, 3, 12 | High | | 7. No rollback mechanism | — | — | High | | 8. Manual QA reliance | — | 1 | Low | | 9. Half-finished refactors | — | 1, 5, 12 | Med | | 10. No dependency scanning | 2 (future recurrence) | — | Low | | 11. DB schema debt | — | — | Low | | 12. Undocumented business logic | 5, 6, 9 | — | High | **Critical path:** Item 1 (checkout test coverage) and Item 12 (document business logic) unblock the most downstream work and should move together — you can't safely refactor or upgrade what you can't verify or understand. Once those land, Item 4 (CI gating) and Item 7 (rollback capability) become cheap and high-leverage, because they turn the new tests into an enforced safety net rather than a one-time exercise. Only after that foundation is in place does it make sense to tackle Item 2 → Item 3 (gem updates, then Rails upgrade), followed by Items 6 and 5 (decoupling and model refactors), which is when Item 9's stalled refactors can finally be closed out. ## BUSINESS IMPACT TABLE | Debt Item | Velocity Cost (hrs/sprint lost) | Incident Risk | Revenue Risk | Evidence Type | |-----------|--------------------------------|---------------|--------------|---------------| | 1. No test coverage | 8–12 (manual verification tax) | High | Direct | INFERRED | | 2. Deprecated gems | 2–4 | Med | Indirect | INFERRED | | 4. No CI gating | 4–6 (post-deploy firefighting) | High | Direct | INFERRED | | 6. Checkout↔gateway coupling | 3–5 | High | Direct | INFERRED | | 7. No rollback mechanism | 2–4 (extended incident duration) | High | Direct | INFERRED | | 8. Manual QA reliance | 5–8 | Med | Indirect | INFERRED | | 9. Half-finished refactors | 3–5 | Med | Indirect | STATED (cause) / INFERRED (cost) | | 12. Undocumented business logic | 4–6 | Med | Indirect | INFERRED | **Total estimated velocity drag: ~31–50 hrs/sprint across a 4-person team** — (confidence: MED, since only two inputs were STATED and every hour figure above is INFERRED from typical patterns in similarly-shaped Rails monoliths, not measured from this team's actual sprint data.) ## REMEDIATION ROADMAP | Phase | Timeframe | Debt Items Addressed | Rationale | Prerequisite | |-------|-----------|---------------------|-----------|--------------| | Phase 1 — Stop the bleeding | Weeks 1–4 | 1, 4, 7, 12 | These are the blockers and the direct-incident-risk items; nothing else can be safely touched until checkout has tests, a documented rulebook, deploy gates, and a rollback lever | None | | Phase 2 — Foundation repair | Months 2–3 | 2, 3, 6 | With tests as a safety net, gems and framework version can be brought current, and the payment gateway coupling can be decoupled without flying blind | Phase 1 complete | | Phase 3 — Velocity recovery | Months 4–6 | 5, 9, 8, 10, 11 | Model refactors and stalled work can finally close out once the platform underneath them is stable; manual QA and DB debt come last since they're lower interest rate | Phase 2 complete | | Ongoing — Debt prevention | Continuous | Process/tooling | Dependency bot for automatic gem PRs, a lightweight "definition of done" that includes tests for checkout-adjacent PRs, and a rotating pairing schedule to reduce single-person knowledge silos | — | **Phase 1 implementation briefs:** **Item 1 — Checkout test coverage.** Start with characterization tests, not unit tests: capture current checkout behavior (happy path, common failure paths, edge cases around discounts/taxes/payment failures) as integration/request specs before changing any code, so the tests document reality rather than intent. Prioritize the payment-processing and order-finalization code paths first, since those carry the highest revenue risk. Verify done when checkout has request-spec coverage on all primary flows and a coverage report shows no untested payment-critical branches. **Item 4 — CI gating on checkout deploys.** Add a required CI check that runs the new checkout test suite (from Item 1) and blocks merge/deploy on failure; if a pipeline already exists (likely, given weekly deploys), this is a config change, not new infrastructure. Order this immediately after enough of Item 1's tests exist to make the gate meaningful rather than a no-op. Verify done when a deliberately broken checkout PR is blocked automatically without manual intervention. **Item 7 — Rollback mechanism.** Implement either a feature flag around new checkout code paths or a one-command deploy-revert script, whichever is faster given current infra (a flag is usually cheaper if using a gem like Flipper; a revert script is faster if deploys are already scripted). Do this in parallel with Items 1 and 4 since it doesn't depend on either. Verify done by running a live-fire drill: intentionally deploy a broken change to staging and confirm rollback completes in under 5 minutes. **Item 12 — Document checkout business logic.** Have the engineer(s) most familiar with checkout write a short living doc covering pricing/discount rules, tax handling, payment retry logic, and edge cases — pair this with whoever is writing the Item 1 tests so documentation and tests reinforce each other. Do this concurrently with Item 1, since writing tests naturally surfaces undocumented behavior. Verify done when a team member who didn't write the original code can explain the checkout flow using only the doc. ## INPUT ROBUSTNESS SCENARIOS | Condition | First Break Point | Predicted Team Behavior Without Intervention | Conf | |-----------|------------------|---------------------------------------------|------| | Sparse (team insists the codebase is "fine") | First checkout incident during a high-traffic period exposes the untested code path | Team treats it as a one-off bug, patches symptom, doesn't add tests, debt reasserts itself within a sprint or two | 60 | | Contradictory (team says "fast" but deploys monthly) | Doesn't apply here — deploys are weekly and stated consistently — but generally, contradiction surfaces when "fast" delivery claims don't match cycle time data | Team would likely attribute slowness to headcount rather than debt, and ask for more engineers instead of remediation time | 45 | | Missing (no tests, no docs, no ownership map) | A single engineer leaving or going on leave stalls checkout work entirely | Remaining engineers reverse-engineer behavior under time pressure, introducing new undocumented debt while "fixing" the gap | 65 | | High-pressure (debt told to fix itself via feature work) | Phase 1 items get partially started then abandoned when a feature deadline hits | Test coverage stays permanently partial ("we'll finish it next sprint"), and the safety net never becomes reliable enough to actually trust | 70 | ## AUDIT INTEGRITY CHECK | Check | Status | Note | |-------|--------|------| | Debt register has ≥ 8 specific named items | ✅ | 12 items registered | | Every 🔴 item has an interest rate and effort estimate | ✅ | Items 1, 2, 4, 6, 7, 12 all populated | | Dependency map covers all items that have a known blocker | ✅ | All 12 items mapped, including items with no blockers | | Roadmap phases are sequenced by dependency, not by category | ✅ | Phase 1 mixes Test/Process/Infra/Architecture based on what unblocks the most, not by discipline | | Silent corruption flags identify the items teams most underestimate | ✅ | 3 flags raised (gems, coupling, tribal knowledge) | | All INFERRED findings are labeled | ✅ | Labeled per-row throughout | **AUDIT CONFIDENCE: 58/100** — Only two facts were directly stated (missing checkout tests, deprecated gems); everything else — architecture patterns, dependency structure, and hour estimates — is inferred from what's typical in a 5-year-old, weekly-deploy Rails monolith, so real codebase access would likely shift several severity and effort ratings. **Biggest unknown:** Whether the "no test coverage" claim means literally zero automated tests anywhere near checkout, or just that the checkout *module itself* is untested while surrounding code has partial coverage — this single fact would reshape Item 1's severity, Phase 1's scope, and the entire critical path. **Findings from description alone (STATED):** - 5-year-old Rails monolith - No test coverage on the checkout module - Several deprecated gem versions - 4 engineers, shipping weekly, high context-switching between features and bug fixes - Checkout directly processes revenue; downtime is immediate revenue loss **Findings requiring codebase access to verify (VERIFY):** - Actual Rails/Ruby version and how many majors behind - Whether any of the deprecated gems have published CVEs - Whether CI/CD infrastructure exists at all vs. just needs checkout-specific gates - Degree of coupling between checkout and the payment gateway - Existence and severity of fat models / God objects - State of database schema, indices, and migration backlog - Whether prior refactor attempts were actually left half-finished, and where