Archery Apprentice Documentation

week-20-god-class-discovery

12 min read

Week 20: God Class Discovery & Analysis

Discovery Date: November 9, 2025 Analyst: Agent 3 (AAA - Auditor, Analysis, Architecture) Scope: Full codebase scan Status: 🔴 CRITICAL FINDING

Executive Summary

Major Discovery: Full codebase scan revealed 10 god classes totaling 16,211 lines (not 3 as previously documented).

Impact: God class refactoring scope is 3.3x larger than previously estimated:

  • Previously known: 3 classes, 5,089 lines
  • Actual scope: 10 classes, 16,211 lines
  • Additional work: 7 classes, 11,122 lines

Priority: HIGH - Repository layer god classes (3,726 lines) are critical blockers for iOS Firebase abstraction.

The Discovery

Previously Known God Classes (3 classes, 5,089 lines)

From baseline documentation and CLAUDE.md:

  1. LiveScoringViewModel - 1,497 lines

    • Originally 2,808 lines (Week 2)
    • Reduced 46% through service extraction
    • Remaining: UI orchestration logic

  2. RoundViewModel - 1,581 lines

    • Originally 2,177 lines
    • 82 methods, complex state management
    • Primary god class target

  3. ActiveScoringScreen - 2,011 lines

    • UI composition god class
    • Grew 6% since baseline (1,896 → 2,011)
    • Needs splitting into components

Known Total: 5,089 lines

Newly Discovered God Classes (7 classes, 11,122 lines)

Agent 3’s Week 20 scan discovered 7 additional god classes:

Repository Layer (3 classes, 3,726 lines) 🔴 CRITICAL

4. FirebaseTournamentRepository - 1,912 lines

  • Methods: 42 Firebase-dependent operations
  • Complexity: Transactions, batches, real-time listeners
  • Blocker: iOS Firebase abstraction (Week 15-16 investigation)
  • Priority: CRITICAL PATH for KMP migration

5. HybridTournamentRepository - 1,814 lines

  • Delegates to: FirebaseTournamentRepository + OfflineTournamentRepository
  • Complexity: Sync logic, conflict resolution, offline queue
  • Dependencies: Firebase repository (must refactor together)

6. RoundRepository - 1,518 lines (interface + implementations)

  • Methods: 30+ round management operations
  • Complexity: Multi-source data (local + Firebase)
  • Issue: Interface too large, needs splitting

Repository Layer Total: 3,726 lines (23% of total god class scope)

UI Layer (3 classes, 3,951 lines)

7. TournamentDetailsScreen - 1,725 lines

  • Type: Compose UI screen
  • Complexity: Multi-tab layout, participant management, scoring
  • Similar to: ActiveScoringScreen pattern
  • Needs: Component extraction

8. RoundDetailsScreen - 1,215 lines

  • Type: Compose UI screen
  • Complexity: Round configuration, scoring display
  • Opportunity: Shared components with TournamentDetailsScreen

9. RoundScoringEntryScreen - 1,011 lines

  • Type: Compose UI screen
  • Complexity: Score input, validation, submission
  • Minimum god class size (1,000 line threshold)

UI Layer Total: 3,951 lines (24% of total god class scope)

ViewModel Layer (1 class, 1,418 lines)

10. TournamentDetailsViewModel - 1,418 lines

  • Methods: 45+ tournament management operations
  • Complexity: Participant state, scoring state, sync state
  • Dependencies: HybridTournamentRepository
  • Similar to: RoundViewModel pattern

ViewModel Layer Total: 1,418 lines (9% of total god class scope)

Newly Discovered Total: 11,122 lines (7 classes)

All God Classes Combined: 16,211 lines (10 classes)

Breakdown by Layer

LayerClassesTotal Lines% of TotalPriority
UI (Screens)33,95124%Medium
Repository33,72623%🔴 Critical
ViewModel47,49646%High
UI (Known)1 (ActiveScoringScreen)2,01112%Medium
TOTAL1016,211100%-

Key Insight: ViewModel + Repository layers account for 69% of god class scope (11,222 lines).

Repository Health Assessment

Overall Score: 72/100 ⭐⭐⭐⭐ (Fair to Good)

Agent 3’s comprehensive health analysis:

Strengths ✅

  1. Excellent Test Coverage

    • 257 test files
    • 87,000+ lines of test code
    • 4,034+ tests passing (100% pass rate)
    • Good test organization (clear patterns)

  2. Good Architecture

    • Clear layer separation (UI, ViewModel, Repository, Data)
    • Established patterns (MVVM, Repository)
    • KMP migration progress (Weeks 1-19)

  3. Stable CI/CD

    • Hybrid runner system functional
    • Automated test execution
    • Branch protection enforced

Critical Issues 🔴

  1. God Classes (10 classes, 16,211 lines)

    • Impact: Maintainability, testability, iOS readiness
    • Scope: 3.3x larger than previously known
    • Priority: Repository layer blocks iOS Firebase abstraction

  2. Repository Layer Bloat

    • FirebaseTournamentRepository: 1,912 lines (42 methods)
    • HybridTournamentRepository: 1,814 lines (sync complexity)
    • RoundRepository: 1,518 lines (too many responsibilities)
    • Blocker: Cannot move to KMP shared layer until refactored

  3. Code Duplication

    • 452 log statements (opportunity for LoggingService)
    • 147 StateFlow instances (opportunity for StateViewModel base class)
    • Repeated validation patterns
    • Repeated error handling

  4. Technical Debt

    • 127 TODO/FIXME comments
    • 23 deprecated API usages
    • 15 suppressed warnings
    • Inconsistent naming conventions

Medium Concerns ⚠️

  1. UI Complexity

    • 3 UI god classes (3,951 lines total)
    • Component reuse opportunities missed
    • Compose best practices not always followed

  2. ViewModel Complexity

    • 4 ViewModel god classes (7,496 lines total)
    • Business logic in ViewModels (should be in Presenters/Services)
    • Weeks 17-19 proved migration pattern works

  3. Documentation Gaps

    • God class discovery not documented until Week 20
    • Repository interfaces not documented
    • Firebase abstraction design documented but not implemented

Week 21+ Roadmap

Agent 3 created 3 execution options for god class refactoring:

Option 1: Conservative (18% reduction, 20-25 hrs/week)

Scope: UI extractions only

  • Focus: ActiveScoringScreen, TournamentDetailsScreen, RoundDetailsScreen
  • Target: ~3,000 lines reduced (18% of total)
  • Risk: LOW - UI extractions are low-risk
  • Velocity: Steady, sustainable

Timeline: 8-10 weeks Pros: Low risk, predictable Cons: Slow progress, doesn’t address repository blockers

Option 2: Balanced (28% reduction, 30-35 hrs/week) ⭐ RECOMMENDED

Scope: UI extractions + service extractions + ViewModel migrations

  • Track 1: UI component extractions (~3,000 lines)
  • Track 2: Service extractions from ViewModels (~1,500 lines)
  • Track 3: ViewModel → Presenter migrations (proven pattern)
  • Target: ~4,500 lines reduced (28% of total)
  • Risk: MEDIUM - Proven patterns, managed velocity

Timeline: 6-8 weeks Pros: Good velocity, manageable risk, proven patterns Cons: Requires coordination across tracks

Agent Allocation:

  • Agent 2: ViewModel migrations (Track 3) - proven velocity
  • Agent 3: UI extractions (Track 1) - started in Week 20
  • Agent 1: Service extractions (Track 2) - when iOS work paused

Option 3: Aggressive (40% reduction, 40-50 hrs/week)

Scope: All tracks + repository refactoring

  • Track 1: UI extractions
  • Track 2: Service extractions
  • Track 3: ViewModel migrations
  • Track 4: Repository layer refactoring (HIGH RISK)
  • Target: ~6,500 lines reduced (40% of total)
  • Risk: HIGH - Repository refactoring is complex

Timeline: 4-6 weeks Pros: Maximum velocity, fastest path to iOS readiness Cons: High risk, requires perfect execution, repository changes are dangerous

Not Recommended: Repository refactoring is high-risk, requires careful planning

Week 20 Quick Wins (Executed)

From Agent 3’s roadmap, Week 20 pivot executed immediately:

Agent 3: UI Extraction (✅ COMPLETE)

  • File: ActiveScoringScreen.kt
  • Extracted: ~235 lines (statistics panel component)
  • Impact: 1.5% of total goal (235/16,211)
  • Status: Merged to main

Agent 1: Stub Cleanup (🔄 IN PROGRESS)

  • File: RoundViewModel.kt
  • Target: ~250 lines (iOS-specific stubs)
  • Impact: 1.5% of total goal (250/16,211)
  • Status: Worktree created, work started

Agent 2: ViewModel Migrations (🔄 IN PROGRESS)

  • Target: 3-4 medium ViewModels (~1,200 lines)
  • Impact: 7.4% of total goal (1,200/16,211)
  • Status: Week 20 kickoff prompt ready

Week 20 Combined Target: ~1,685 lines (10.4% of total god class goal)

Actual Week 20 Execution:

  • Agent 3 complete: 235 lines ✅
  • Agent 1 ongoing: ~250 lines 🔄
  • Agent 2 ongoing: ~1,200 lines 🔄
  • Total: ~1,685 lines (if all complete)

Key Insights

1. Repository Layer = New Critical Blocker

Discovery: Repository god classes (3,726 lines) are critical blockers for iOS Firebase abstraction.

Why Critical:

  • FirebaseTournamentRepository (1,912 lines) has 42 Firebase-dependent methods
  • Week 15-16 investigation identified Firebase coupling as CRITICAL PATH blocker
  • Cannot move services to shared:domain until Firebase abstracted
  • iOS app cannot use Firebase until repository layer is KMP-compatible

Priority: 🔴 HIGHEST - Must address after current ViewModel migrations

Approach:

  1. Complete Agent 1 Firebase abstraction design (already done)
  2. Implement RemoteDataSource interfaces (Week 21-22)
  3. Refactor FirebaseTournamentRepository → interface implementation
  4. Refactor HybridTournamentRepository to use interfaces
  5. Move repository interfaces to shared:data

2. Week 2 Success Proves Refactoring Pattern Works

Evidence: LiveScoringViewModel reduced 46% successfully

  • Before: 2,808 lines (Week 2 baseline)
  • After: 1,497 lines (current)
  • Reduction: 1,311 lines (46%)
  • Method: Service extraction (19 services created)

Pattern Proven:

  • Extract business logic → domain services
  • Keep UI orchestration in ViewModel
  • Maintain 100% test coverage
  • Zero regressions

Implication: Same pattern can apply to all god class ViewModels

3. Weeks 17-19 Proved ViewModel → Presenter Migration Pattern

Evidence: 10 ViewModels migrated with 70.2% code reduction

  • Total reduction: 1,370 lines (70.2% average)
  • Test coverage: 100% maintained
  • Regressions: 0
  • iOS readiness: All Presenters KMP-compatible

Pattern Proven:

  • ViewModel → thin wrapper (delegation only)
  • Business logic → KMP Presenter (shared:presentation)
  • Repository abstraction → interface in shared:data
  • Memory leak prevention (stateIn pattern)

Implication: Apply to remaining 4 ViewModel god classes

4. Code Duplication = Quick Win Opportunities

452 Log Statements:

  • Opportunity: Create LoggingService utility
  • Impact: Reduce 452 duplications
  • Effort: 1-2 days
  • Benefit: Cleaner code, centralized logging

147 StateFlow Instances:

  • Opportunity: Create StateViewModel base class
  • Impact: Reduce 147 duplications
  • Effort: 2-3 days
  • Benefit: Consistent state management pattern

Validation Patterns:

  • Opportunity: Extract validation logic to domain services
  • Impact: Reduce duplication across ViewModels
  • Effort: 3-5 days per validation type

5. UI God Classes Need Component Extraction

Pattern: 3 UI god classes (ActiveScoringScreen, TournamentDetailsScreen, RoundDetailsScreen)

Approach (proven in Week 20):

  • Extract reusable Compose components
  • Create shared UI building blocks
  • Reduce duplication across screens
  • Improve testability (component-level tests)

Week 20 Example:

  • Extracted statistics panel from ActiveScoringScreen (235 lines)
  • Created reusable component
  • Improved testability

Next Targets:

  • Participant list component (shared across 2 screens)
  • Scoring display component (shared across 3 screens)
  • Navigation components

Comparison: Known vs Actual Scope

Previously Documented (CLAUDE.md + Baseline)

ClassLinesStatus
LiveScoringViewModel1,497Known (reduced 46% in Week 2)
RoundViewModel1,581Known (primary target)
ActiveScoringScreen2,011Known (grew 6%)
Total5,0893 classes

Estimated Effort: 4-6 weeks (based on 3 god classes)

Actual Scope (Week 20 Discovery)

ClassLinesLayerPriority
LiveScoringViewModel1,497ViewModelHigh
RoundViewModel1,581ViewModelHigh
ActiveScoringScreen2,011UIMedium
FirebaseTournamentRepository1,912Repository🔴 Critical
HybridTournamentRepository1,814Repository🔴 Critical
TournamentDetailsScreen1,725UIMedium
RoundRepository1,518RepositoryHigh
TournamentDetailsViewModel1,418ViewModelHigh
RoundDetailsScreen1,215UIMedium
RoundScoringEntryScreen1,011UIMedium
Total16,21110 classesMixed

Revised Effort: 8-12 weeks (based on 10 god classes, Option 2)

Scope Increase: 3.2x larger (16,211 vs 5,089 lines)

Impact on KMP Migration Timeline

Original Plan (Pre-Discovery)

Week 19: ViewModel migrations complete (10 ViewModels) Week 20-22: Continue ViewModel migrations (3 god classes) Week 23-24: iOS app development Week 25: Production deployment

Estimated Timeline: 6 weeks to iOS readiness

Revised Plan (Post-Discovery)

Week 20: Quick wins (UI + stubs + ViewModels) ~1,685 lines Week 21-22: Firebase abstraction implementation (CRITICAL PATH) Week 23-28: God class refactoring (Option 2: Balanced approach)

  • Tracks: UI extractions + Service extractions + ViewModel migrations
  • Target: ~4,500 lines reduced (28% of total) Week 29-30: Repository layer refactoring (high-risk, careful planning) Week 31-32: iOS app development Week 33: Production deployment

Revised Timeline: 14 weeks to iOS readiness (8 weeks added)

Critical Path: Firebase abstraction MUST complete before repository refactoring can begin

Recommendations

Immediate (Week 20)

  1. Continue Quick Wins

    • ✅ Agent 3: UI extraction (complete)
    • 🔄 Agent 1: Stub cleanup (in progress)
    • 🔄 Agent 2: ViewModel migrations (in progress)
    • Target: ~1,685 lines (10.4% of goal)

  2. Document Discovery

    • ✅ Create vault entry (this document)
    • Update CLAUDE.md with god class count (10 not 3)
    • Update roadmap with revised timeline

  3. User Decision Required

    • Choose execution option (recommend Option 2: Balanced)
    • Approve extended timeline (14 weeks vs 6 weeks)
    • Prioritize Firebase abstraction (CRITICAL PATH)

Week 21-22 (CRITICAL PATH)

Priority 1: Firebase Abstraction Implementation

  • Agent: Agent 1 (AAP) or Agent 2 (AAM)
  • Effort: 3-4 weeks (from Week 15-16 investigation)
  • Deliverable: RemoteDataSource interfaces implemented
  • Blocker: MUST complete before repository refactoring

Rationale:

  • FirebaseTournamentRepository (1,912 lines) cannot refactor without abstraction
  • iOS Firebase support requires abstraction layer
  • Blocks entire repository layer refactoring (3,726 lines)

Week 23-28 (Balanced Execution)

Option 2: Balanced Approach (RECOMMENDED)

  • Track 1: UI extractions (Agent 3)
  • Track 2: Service extractions (Agent 1, when iOS paused)
  • Track 3: ViewModel migrations (Agent 2, proven velocity)
  • Target: ~4,500 lines (28% reduction)
  • Timeline: 6-8 weeks

Why Balanced:

  • Proven patterns (Weeks 2, 17-19)
  • Manageable risk
  • Good velocity without overextension
  • Addresses multiple layers simultaneously

Week 29-30 (High-Risk Work)

Repository Layer Refactoring

  • FirebaseTournamentRepository → interface-based
  • HybridTournamentRepository → use interfaces
  • RoundRepository → split responsibilities
  • Risk: HIGH - Requires careful planning and testing
  • Approach: Incremental, one repository at a time

Week 31-32 (iOS Development)

iOS App Development

  • Agent 1 (AAP): iOS runtime validation
  • Validate all Presenters work on iOS
  • Validate Firebase abstraction layer
  • Create iOS UI with SwiftUI

Risk Assessment

Critical Risks 🔴

  1. Repository Refactoring Complexity

    • Risk: Breaking changes in data layer
    • Impact: Production outages, data loss
    • Mitigation: Incremental refactoring, comprehensive testing, feature flags

  2. Firebase Abstraction Delay

    • Risk: Blocks repository refactoring (3,726 lines)
    • Impact: Timeline slippage, iOS readiness delayed
    • Mitigation: Prioritize Firebase work, allocate experienced agent

  3. Scope Creep

    • Risk: Discovering more god classes during refactoring
    • Impact: Timeline extension, team fatigue
    • Mitigation: Option 2 (Balanced) provides buffer, regular scope reviews

Medium Risks ⚠️

  1. Parallel Track Coordination

    • Risk: Merge conflicts, integration issues
    • Impact: Rework, delayed merges
    • Mitigation: Clear file ownership, frequent integration

  2. Test Coverage Maintenance

    • Risk: Regressions during refactoring
    • Impact: Production bugs, rollbacks
    • Mitigation: Maintain 100% test coverage, Agent 3 validation

  3. Agent Availability

    • Risk: macOS delays, agent conflicts
    • Impact: Timeline slippage
    • Mitigation: Flexible agent allocation, pivot strategies

Success Metrics

Week 20 (Quick Wins)

  • UI extraction complete (~235 lines) - ✅ Agent 3
  • Stub cleanup complete (~250 lines) - 🔄 Agent 1
  • ViewModel migrations complete (~1,200 lines) - 🔄 Agent 2
  • Target: ~1,685 lines (10.4% of goal)

Week 21-22 (Firebase Abstraction)

  • RemoteDataSource interfaces designed
  • FirebaseRemoteDataSource implementation complete
  • Domain layer Firebase imports eliminated (10 imports)
  • All services ready for shared:domain migration

Week 23-28 (Balanced Execution)

  • UI extractions: ~3,000 lines reduced
  • Service extractions: ~1,500 lines reduced
  • ViewModel migrations: All remaining ViewModels migrated
  • Target: ~4,500 lines (28% of goal)

Week 29-30 (Repository Refactoring)

  • FirebaseTournamentRepository refactored
  • HybridTournamentRepository refactored
  • RoundRepository split into focused interfaces
  • All repository interfaces in shared:data

Week 31-32 (iOS Readiness)

  • iOS app builds successfully
  • All Presenters work on iOS
  • Firebase abstraction validated on iOS
  • Production deployment ready

Week 20 Analysis Documents (Agent 3 worktree):

  • GOD_CLASS_STATE_ASSESSMENT_WEEK_20.md (god class discovery)
  • CODEBASE_HEALTH_REPORT_WEEK_20.md (health score 72/100)
  • WEEK_21_PLUS_ROADMAP.md (3 execution options)

Historical Context:

Strategic Documents:

  • docs/kmp-migration/WEEK_15_20_INVESTIGATION_FINDINGS.md (Firebase abstraction)
  • docs/kmp-migration/KMP_MIGRATION_ROADMAP.md (overall plan)
  • CLAUDE.md (will be updated with god class count)

Tags

kmp-migration god-class-discovery code-quality analysis week-20 repository-layer firebase-abstraction critical-finding scope-increase roadmap

Status

🔴 CRITICAL FINDING DOCUMENTED

  • God class scope: 3.2x larger than known (16,211 vs 5,089 lines)
  • Timeline revised: +8 weeks (14 weeks vs 6 weeks to iOS)
  • Critical blocker: Repository layer requires Firebase abstraction first
  • Recommended approach: Option 2 (Balanced, 28% reduction, 6-8 weeks)
  • Week 20 quick wins: In progress (~1,685 lines target)

User Decision Required: Approve execution option and revised timeline

Graph View

Backlinks