P. Final Recommendation

Confidence Level: HIGH

This recommendation is grounded in direct inspection of all four codebases — package.json files, source code, configuration, CI definitions, environment files, and inter-repo communication patterns. It is based on evidence, not assumption. Where assumptions were made, they are listed explicitly below.

Recommended Direction: Phased Monorepo Consolidation

Not a big-bang migration. Not a full rewrite. A deliberate, phased consolidation that: - Resolves security and compliance risks immediately (Phase 0) - Establishes the monorepo structure without requiring all apps to migrate simultaneously (Phase 2) - Allows product work to continue in parallel — this is infrastructure, not a feature freeze - Modernizes reverb-react to Next.js 16 + React 19 (controlled rewrite in apps/legacy-portal/)

Why Monorepo

The four repositories are separate codebases with independent deployment pipelines, but they are tightly coupled in practice: - soreto-zoe cannot function without reverb-backend running - soreto-melissa cannot function without reverb-backend running - Both portals (reverb-react and melissa) link to each other via environment variables - Both backends share the same PostgreSQL server and Redis instance

Managing them as separate repositories means accepting all the costs of a monolith (coordination overhead, coupling, shared infrastructure) with none of the benefits (atomic changes, shared tooling, unified CI). The coupling is real — the question is whether it is visible and typed or hidden and fragile.

Yes, it should.

Immediate Next Steps (Strict Priority Order)

Step 1 — TODAY: Revoke the GitHub PAT

soreto-zoe/package.json contains a live GitHub PAT
GitHub → Settings → Developer Settings → Personal Access Tokens → Revoke

This is a production security incident. Everything else waits for this.

Step 2 — THIS WEEK: Verify Production Secrets

Confirm SESSION_SECRET, TOKEN_SECRET, and COOKIE_SECRET are explicitly set in all Heroku environments (staging + production). Do not rely on the defaults in config/config.js.

heroku config -a <reverb-backend-app-name> | grep -E "SECRET|TOKEN"

Step 3 — THIS WEEK: Add CI to soreto-melissa and soreto-zoe

Neither repo has a CI pipeline. Create minimal GitHub Actions workflows:

soreto-melissa:

on: [push, pull_request]
jobs:
  validate:
    steps:
      - npm ci
      - npm run typecheck  # tsc --noEmit
      - npm run lint       # next lint
      - npm test           # jest
      - npm run build      # next build

soreto-zoe:

on: [push, pull_request]
jobs:
  validate:
    steps:
      - npm ci
      - npm run build  # tsc

Step 4 — NEXT TWO WEEKS: Upgrade Knex in soreto-zoe

Knex 0.16.3 → 0.21.x is the highest-impact dependency upgrade and a prerequisite for the Node version upgrade. Start with this increment, validate, then continue.

Step 5 — NEXT MONTH: Create the Monorepo Scaffold

Create soreto-platform/ with: - npm workspaces (built into npm 7+, no tooling change required) - Turborepo 2.x - Empty apps/, packages/, tooling/, docs/ structure - Root CLAUDE.md

Then migrate soreto-melissa in as the first app (apps/platform-ui/).

Step 6 — NEXT QUARTER: Upgrade reverb-backend to Node 20 → 24

Prerequisites: node-sass → sass, connect-redis upgraded, seneca tested on Node 18, Express 4 → 5. Incremental: 14 → 18 → 20 → 22 → 24 (Node 24 is Active LTS).

Step 7 — ONGOING: Modernize reverb-react to Next.js 16

Stand up the Next.js 16 scaffold inside apps/legacy-portal/. Port admin + client route groups, migrate Redux 3 + Flux → Zustand, rewrite components to PrimeReact 10.9.8, replace @@PLACEHOLDER@@ tokens with process.env.NEXT_PUBLIC_*. Target: Node 24, TypeScript 6, React 19. See F — Version Standardization for the full stack target.

What NOT to Do

Action	Why Not
In-place upgrade reverb-react	Stack gaps (Babel 6, React 17/dom 16.5 mismatch, react-router@3+dom@4) are too large — rewrite to Next.js 16 instead
Big-bang monorepo migration	Too much risk in parallel; phased is safer
Rewrite reverb-backend in TypeScript immediately	Phased adoption (new files only) is lower risk
Replace seneca before testing compatibility	May not be needed; test first
Introduce Redux to melissa	React Context is appropriate; don't regress
Add a second UI framework (Tailwind) to melissa	PrimeReact is established; don't split the UI approach

Blockers (Must Resolve Before Migration Starts)

Blocker	Status	Owner
GitHub PAT revoked	⛔ Pending	Immediate — any engineer
soreto-melissa CI established	⚠️ Pending	Platform engineer
soreto-arena replacement strategy	⚠️ Pending	Backend engineer
`SESSION_SECRET` etc. verified in all envs	⚠️ Pending	DevOps
Seneca strategy decided (keep/replace)	⚠️ Pending	Architecture review

Assumptions

All assumptions made during this audit:

#	Assumption	Confidence
A1	`.env` files in repos are development defaults only; production secrets managed separately	HIGH — common Heroku pattern
A2	soreto-melissa and soreto-zoe deploy to Heroku (inferred from `heroku-private-modules` in zoe)	MEDIUM — not confirmed
A3	`soreto-arena` is a monitoring dashboard, not a critical user-facing feature	MEDIUM — inference from bull-arena lineage
A4	reverb-backend and soreto-zoe connect to the same PostgreSQL instance with different schemas	HIGH — connection string patterns are consistent
A5	reverb-react is intentionally being replaced by soreto-melissa	HIGH — both codebases cross-link; melissa has "Legacy Dashboard" link
A6	The `zoe` and `reverb` PostgreSQL schemas do not cross-reference each other directly	MEDIUM — not verified; needs Q5 from discovery questions
A7	Test coverage in reverb-backend is sufficient to validate Node version upgrades	LOW — coverage % not measured; worst-case timeline accounts for this
A8	The `soreto-arena` GitHub URL (`soreto/soreto-arena`) is a Soreto-owned private fork	HIGH — GitHub org matches
A9	The leaked GitHub PAT has access to the `soreto-arena` repository at minimum	HIGH — it's used in the install URL

Evidence Summary

This recommendation is based on the following direct observations (not assumptions):

Observation	Source
GitHub PAT in package.json	`soreto-zoe/package.json` line 49
React 17 + react-dom 16.5 mismatch	`reverb-react/package.json` lines 28, 62
Node 10 declared	`reverb-react/package.json` engines field
No CI in melissa or zoe	File system scan — no `.travis.yml`, no `.github/` directory
`local_modules/reverb` HTTP client	`soreto-zoe/local_modules/reverb/index.js`
melissa calls reverb-backend API	`soreto-melissa/service/BaseService.tsx`, `.env`
melissa links to legacy portal	`soreto-melissa/shared/constants.ts` line 3 (via NEXT_PUBLIC_LEGACY_PORTAL_URL)
reverb-react links to melissa	`reverb-react/src/config/config.js` line 47
Hardcoded default secrets	`reverb-backend/config/config.js` lines 2–4
Knex 0.16.3	`soreto-zoe/package.json` dependencies
AMD TypeScript namespaces	`soreto-zoe/src/app.ts`, `src/services/baseService.ts`
Four different ESLint versions	ESLint field in each package.json
Google UA dead API	`reverb-backend` `universal-analytics@0.4.13`

Final Statement

The Soreto/Reverb ecosystem is at a fork. The current state — four repos, four Node versions, two EOL runtimes, one critical security vulnerability, and zero CI on two of the four repos — is not sustainable as the platform grows. The good news is that the transition has already begun (melissa replacing reverb-react), the modern codebase (melissa) is well-structured, and the migration has a clear, phased path.

The monorepo is not a destination — it is a container for doing the real work: typing the API contracts, standardizing the tooling, retiring the legacy portal, and making the system legible to engineers and AI tools alike.

Start today with Phase 0. Everything else follows from there.

Audit completed 2026-05-19 · Evidence-based · Read-only inspection · No code modified Version references updated 2026-05-19 against live docs: Next.js 16.2.6 · React 19.2.6 · Node 24 LTS · TypeScript 6.0 · Puppeteer 25.x · Express 5.2.1 · Turborepo 2.9.14 · npm workspaces