docs: add repo review and next production-safe implementation phase

[cvsz]

Motivation

• Capture a production-safe next-phase plan after a full repository review to align documented wallet APIs with the repo and propose a minimal, low-risk backend increment (wallet module hardening) without touching infra or running recursive builds.

Description

• Add docs/NEXT_PHASE_PRODUCTION_PLAN.md which records findings, the recommended small backend scope (POST /api/wallet/create, GET /api/wallet/:userId, GET /api/wallet/:userId/balance), DTO/typing guidance, validation commands, blockers, and rollback notes.

Testing

• No automated tests were run because this is a documentation-only change; repository inspection commands and the commit succeeded.

---

Codex Task

[gemini-code-assist]

Code Review

This pull request introduces a production-safe plan for the next phase of development, focusing on hardening the backend wallet module and addressing discrepancies between the repository and existing documentation. Review feedback highlights potential risks in exposing new API endpoints while key architectural blockers—such as the authoritative source for wallet balances and the multi-wallet persistence model—remain unresolved. A suggestion was also provided to refine the validation plan by testing the compiled build artifact rather than the source files to better simulate a production environment.

[gemini-code-assist]

Implementing a balance endpoint with a placeholder while the authoritative source is still listed as a blocker (Line 54) introduces a risk of shipping misleading data. For a production-safe plan, the source of truth (on-chain vs. internal ledger) should be defined before exposing this API to avoid technical debt and potential consistency issues.

[gemini-code-assist]

The POST /api/wallet/create endpoint is proposed while the multi-wallet persistence model is still a blocker (Line 53). Since the current Prisma schema enforces a unique walletAddress per User, the purpose of a 'create' endpoint is unclear. Defining the wallet cardinality should precede the API definition to prevent immediate architectural misalignment.

[gemini-code-assist]

For a production-safe validation plan, it is preferable to smoke-test the compiled build artifact rather than using tsx on source files. This ensures that the build process itself is successful and that the resulting bundle behaves as expected in an environment closer to production.

Suggested change

	- `pnpm --filter ./apps/backend exec tsx src/main.ts` (smoke run)
	- pnpm --filter ./apps/backend exec node dist/main.js (smoke run)