Complete audit of admin tRPC routers across WOPR and Paperclip platforms for extraction into platform-core.
| Metric | Value |
|---|---|
| Total WOPR admin procedures | 67 |
| Extractable to platform-core | 45 (67%) |
| WOPR-specific (keep local) | 22 (33%) |
| Paperclip admin procedures | 6 (completely disjoint) |
| Overlap between products | None |
- 🟢 CORE (25/67): Pure generic, zero WOPR dependencies. Ready to extract immediately.
- Audit, credits, users, tenant status, notifications, billing, compliance
- 🟡 SEMI-CORE (20/67): Generic concepts, WOPR-specific storage. Extractable after store abstraction.
- Notes, analytics, bulk operations
- 🔵 WOPR-SPECIFIC (22/67): Product-specific features. Stay in wopr-platform.
- Rates, GPU management, affiliate fraud, snapshot restore, usage by capability
Complete audit with:
- Executive summary
- Categorization of all 67 procedures (CORE/SEMI-CORE/WOPR-SPECIFIC)
- Dependency analysis (16 platform-core imports + 7 local imports)
- Product filtering analysis (no X-Product header, tenant-scoped)
- Extraction roadmap (3 phases)
- Risk assessment
- Comparison with Paperclip admin router
Read this first for strategy and context.
Line-by-line breakdown of all 67 procedures:
- Name, type (query/mutation), input/output, dependencies
- Grouped by category (audit, credits, users, etc.)
- Auth & validation rules
- Implementation notes (pagination, date ranges, audit logging, error handling)
Use this for implementation — copy procedures from here.
Step-by-step execution plan across 4 phases:
- Phase 1 (4-6h): Move 25 CORE procedures to platform-core
- Phase 2 (8-12h): Abstract stores + move 20 SEMI-CORE procedures
- Phase 3 (2-4h): Keep 22 WOPR-specific in wopr-platform
- Phase 4 (4-6h): Validate Paperclip integration, cross-product tests
Use this to execute — follow the checklist and steps.
- All procedures assume caller is authenticated
platform_admin - All tenant operations accept
tenantIdas input parameter - Multi-tenant ready (no implicit tenant from ctx)
- AdminAuditLog, RoleStore, ILedger, Credit, IAutoTopupSettingsRepository
- NotificationService, INotificationQueueRepository
- MetricsCollector, AlertChecker, SystemResourceMonitor
- RestoreService, IRestoreLogStore
- ITenantStatusRepository, IAccountExportStore, IAccountDeletionStore
These are currently local to wopr-platform but generic enough for platform-core:
- AdminUserStore — used by 2 procedures (usersList, usersGet)
- AnalyticsStore — used by 10 procedures (revenue, margins, tenant health, time series)
- IBulkOperationsStore — used by 7 procedures (bulk grant, suspend, etc.)
- IAdminNotesRepository — used by 4 procedures (notes CRUD)
Action: Move interfaces to platform-core, keep implementations in wopr-platform (DI pattern).
gpuAllocations,updateGpuAllocation,gpuConfigurations,updateGpuConfiguration
These depend on IGpuAllocationRepository and IGpuConfigurationRepository which encode WOPR's GPU fleet model. Cannot be generalized.
- 6 procedures, zero overlap with WOPR
- Operates on different concepts (gateway models, instances, orgs)
- Can safely import generic core admin router without conflicts
- Create
platform-core/src/trpc/routers/admin.ts - Copy 25 CORE procedures from wopr-platform
- Move AdminRouterDeps interface to platform-core
- Update wopr-platform to re-export and extend core router
- Run tests ✅
- Create abstract store interfaces in platform-core
- Move 20 SEMI-CORE procedures to platform-core
- Update wopr-platform DI to provide concrete implementations
- Run tests ✅
- Integrate Paperclip admin router with core router
- Cross-product validation tests
- Deploy with feature flag (optional)
Total: ~1 week of focused work
AdminAuditLog, RoleStore, ILedger, Credit
NotificationService, INotificationQueueRepository
ITenantStatusRepository
MetricsCollector, AlertChecker, SystemResourceMonitor
IAccountExportStore, IAccountDeletionStore
IAdminNotesRepository
AnalyticsStore
IBulkOperationsStore
AdminUserStore (or pull from wherever it's defined)
RateStore (WOPR rates model)
IGpuAllocationRepository (GPU fleet)
IGpuConfigurationRepository (GPU hardware)
IAffiliateFraudAdminRepository (WOPR affiliate model)
- All 25 CORE procedures copied to platform-core without modification
- AdminRouterDeps interface compiles in platform-core
- wopr-platform admin router re-exports core router
- All 67 procedures remain accessible via wopr-platform admin router (no breaking change)
- WOPR admin router tests pass
- Platform-core admin router tests pass
- Paperclip admin router imports core router successfully
- No import cycles between platform-core and products
- Type safety verified with
tsc --noEmit - Lint passes:
pnpm lint - Full test suite passes:
pnpm test
Rates (9 procedures) encode WOPR's specific marketplace model (sell rates to customers, provider rates to suppliers). Paperclip doesn't have this. Similarly, GPU procedures are WOPR-specific because no other product (yet) manages GPU resources.
AdminUserStore, AnalyticsStore, etc. are implemented locally in wopr-platform but their interfaces are generic enough to work across products. By abstracting them to platform-core interfaces, we allow:
- Paperclip (and future products) to reuse the procedures
- Different implementations per product (wopr analytics ≠ paperclip analytics)
- DI (dependency injection) to wire concrete impls at boot time
Procedures operate at the platform admin level, not tenant level. Tenant filtering happens at the input parameter level (tenantId in input), not HTTP header level. This keeps admin routers simple and multi-tenant safe.
- Main audit:
docs/audit-admin-router.md - Procedure reference:
docs/procedure-details.md - Extraction plan:
docs/EXTRACTION_STRATEGY.md - Source:
/home/tsavo/platform/platforms/wopr-platform/src/trpc/routers/admin.ts(1,919 lines, 67 procedures)
See docs/audit-admin-router.md for detailed risk assessment, or docs/EXTRACTION_STRATEGY.md for step-by-step execution.
Audit completed: 2026-03-30 Status: Ready for Phase 1 implementation