Refactor: SRP audit across core modules and route handlers

[necdetsanli]

Scope (files / modules)

Project-wide SRP review with priority focus on:

• src/lib/** (shared utilities: rate limiting, IP extraction, logging, enums, env helpers)
• src/app/**/_lib/** (page-scoped business logic)
• API route handlers under src/app/api/** (especially reports + admin/*)
• UI modules that mix data-fetching/business logic with rendering

Exclusions (unless violations are obvious / risky):

• Pure presentational components that already have a single responsibility
• Test files, unless refactors require updating them

What is the current problem?

As the codebase grows, some modules can gradually accumulate multiple responsibilities:

• Route handlers may mix validation, parsing, rate limiting, DB writes, logging, and response formatting in one file.
• “Utility” modules can become grab-bags (formatting + business rules + DB queries).
• Components may start to contain business logic that belongs in a dedicated lib layer.

This makes the code harder to test, harder to evolve safely, and increases the chance of regressions in production.

Given that SRP is a non-negotiable project principle, we should periodically review and refactor before complexity becomes entrenched.

Proposed refactor

Perform an SRP audit and refactor where needed, aiming for small, safe, incremental changes:

• Identify modules/functions that clearly do more than one job (validation + persistence + logging, etc.)
• Split responsibilities into focused units with clear boundaries, for example:
  • parse/validate functions (Zod parsing + friendly error shaping)
  • domain functions (business rules, normalization, dedupe decisions)
  • persistence functions (Prisma queries/transactions)
  • response functions (HTTP status/body shaping)
  • logging functions (structured logs, sensitive-data-safe)
• Prefer composition over giant helpers: small modules that are easy to test in isolation.
• Ensure exported functions in lib layers have JSDoc and strict typing.
• Preserve existing security and semantics:
  • Honeypot behavior must remain stable (honeypot-only issues => 200 OK, no DB writes)
  • Rate limiting behavior must not change unless explicitly planned
  • Env validation remains centralized; avoid ad-hoc process.env reads

Deliverable approach:

• Start with the highest-risk/highest-complexity areas (e.g. /api/reports, admin moderation routes, rateLimit modules).
• Land refactors in small commits with tests updated/added as needed.

Behaviour changes

• No behaviour change intended (internal refactor only).
• Behaviour may change slightly (describe below).

Behaviour change details (if any)

N/A. If small differences occur (e.g. log message text), they should be explicitly called out in the PR description while keeping severity/structure consistent.

Planned checks

• npm run lint
• npm run check
• npm run test
• npm run test:coverage
• npm run test:e2e
• npm run verify