A. Executive Summary

Date: 2026-05-19 · Repos: soreto-melissa · soreto-zoe · reverb-react · reverb-backend

In One Paragraph

The Soreto/Reverb ecosystem consists of four independent repositories (reverb-backend, reverb-react, soreto-melissa, soreto-zoe) that are tightly coupled in practice through a shared PostgreSQL database, a hand-crafted HTTP API client vendored as a local module, and cross-application URL links. Although each repo is a separate codebase with its own deploy pipeline, they cannot function independently — which creates coordination overhead, fragmented CI/CD, and hidden API contracts. The ecosystem is also carrying a reverb-react modernization (Babel 6/Webpack 4/Node 10 → Next.js 16/Node 24) while the backend and job engine remain on divergent, aging stacks.

What Was Found

The Four Repos Are Tightly Coupled Despite Being Separate

Although these are four separate repositories with independent deployment pipelines, they cannot function independently in practice:

soreto-zoe calls reverb-backend via a hand-crafted HTTP API client stored as local_modules/reverb
soreto-melissa calls reverb-backend at NEXT_PUBLIC_APP_API_URL
reverb-react links to Melissa as "New Portal" via @@MELISSA_PORTAL_URL@@
soreto-melissa links back to reverb-react as "Legacy Dashboard" via NEXT_PUBLIC_LEGACY_PORTAL_URL
Both reverb-backend and soreto-zoe run Knex migrations against the same PostgreSQL instance

This is the definition of a distributed monolith: the repos are deployed separately but cannot function independently.

A Portal Transition Is Underway — reverb-react Is Being Modernized

reverb-react and soreto-melissa are two separate, independent admin/client portals that currently cross-link to each other. The plan is to modernize reverb-react to Next.js 16 + React 19 + Node 24 (a controlled rewrite, not an in-place upgrade) — the existing Babel 6 / Webpack 4 / React 17/dom 16.5 / react-router v3+v4 stack cannot be incrementally upgraded; the gaps are too large. See F — Version Standardization for the full modernization target stack.

The Stack Is Severely Fragmented

	reverb-backend	reverb-react	soreto-melissa	soreto-zoe
Node	14 (EOL)	10 (EOL ⛔)	22 ✓	16 (EOL)
Language	JS	JS	TypeScript	TS + JS
CI/CD	Travis CI	Travis CI (no tests)	None	None

Three of four repos run on End-of-Life Node versions. Two of four have no CI/CD at all.

Immediate Risks (Act Now)

These must be addressed before any architecture decision:

1. Leaked GitHub Personal Access Token — CRITICAL

A live PAT is embedded directly in soreto-zoe/package.json:

"soreto-arena": "https://github_pat_11ALCU2CQ0...@github.com/soreto/soreto-arena.git"

This PAT appears in every npm install log, CI build output, and git history entry where this line existed. Revoke this PAT today. See B4 — soreto-zoe and D — Technical Debt.

2. Node 10 in Production — CRITICAL

reverb-react declares engines.node: "~10.15.3". Node 10 reached End-of-Life in December 2020 — over 5 years ago. It receives zero security patches. See F — Version Standardization.

3. Two Version Mismatches in reverb-react — HIGH

reverb-react has react@17.0.1 but react-dom@16.5.0 (must be identical), and react-router@3.2.1 with react-router-dom@4.2.2 (v3 and v4 are incompatible packages). Two separate library pairs are running on mismatched versions simultaneously. See G — Frontend Architecture and B2 — reverb-react.

4. Hardcoded Default Secrets — HIGH

reverb-backend/config/config.js ships with inline default values for SESSION_SECRET, TOKEN_SECRET, and COOKIE_SECRET. If the corresponding environment variables are absent in any environment, real secrets are silently replaced with these defaults. See B1 — reverb-backend.

Architecture Direction

Recommended: Phased Monorepo Consolidation

The repos are already coupled. A monorepo makes that coupling visible, typed, and manageable — rather than hidden and fragile. The migration should be phased (not a big-bang rewrite) and run in parallel with product work.

Full evaluation at E — Monorepo Evaluation. Full migration plan at L — Migration Plan. Target structure at K — Target Architecture.

Expected Outcomes

Outcome	Expected Improvement
Maintenance overhead	-30 to -50% (unified tooling, no version drift)
New engineer onboarding	-40 to -60% (one repo, one set of conventions)
Cross-repo change cycle time	-50 to -70% (atomic commits vs 3 PRs across 3 repos)
AI-assisted development quality	+40 to +60% (shared types, consistent conventions)
Security posture	Significantly improved once PAT and secrets issues are resolved
CI coverage	From 50% (2/4 repos) to 100%