Call Analyst — Refactor & Build-Segregation Plan

How to organize this codebase into something two people can maintain, fix the build segregation properly, and keep every existing feature working. No rewrite. Incremental, reversible, ground-truthed against the actual repo.

Repo: cus-commits/call-analyst · App: call-analyst-pwa/index.html (~20,500 lines) · Companion: the build docs explain how it works today.

The premise (let's be honest)

The codebase is a 20k-line single-file PWA with no build step, two products served from one file, and a second segregation mechanism (a forked git branch) that drifts. A senior dev looks at that and says "nightmare," and on team-scale standards that's fair. But two things are also true:

So this is not "you built it wrong, rewrite it." It's "it's graduating from a solo prototype that prints money into something a team maintains." Different phase, different rules. The plan below buys ~80% of the maintainability for ~5% of the effort, and never stops shipping.

Guiding principles

• Retain every build. Zero feature loss. Consumer and internal both keep working at every step.
• No big-bang rewrite. No React migration, no framework. Mechanical, reversible moves only.
• Single source of truth. Every consumer-vs-internal difference lives in one declarative place. Never a hostname check, never a branch edit.
• Never break a build. One change per PR, verified on a deploy-preview, behavior identical before merge.
• Highest-leverage, lowest-risk first. Kill the scariest risk (prod blast radius) and the structural issue (segregation) before cosmetic cleanup.

The plan at a glance

WS1 · Fix build segregation priority

What's broken (verified in the repo)

Consumer (callanalyst.app) vs internal (analyst.daxos.us) is enforced two ways at once:

• Runtime (good): index.html:5206 sets IS_CONSUMER by hostname and builds a BUILD_FLAVOR capability object (~13 flags: tours, accountChrome, aiRouting, analysisPrompts, etc.). Its header comment literally states: "the ONLY place host-divergent features are decided... a feature missing a flag is a bug."
• Git branch (the problem): a long-lived internal branch that differs from main in exactly 11 files (strips Stripe checkout + the secret coupon, removes the Pro bot-image endpoint, hardcodes "Ask Claude", swaps the live-transcript engine to Fireflies). Internal hosts deploy from internal; consumer hosts auto-deploy from main.

Target: one source of truth, no divergent branch

Kill the internal branch. All code on main. Promote BUILD_FLAVOR into a dedicated flavors.js exporting two config objects:

// call-analyst-pwa/flavors.js  — the ONLY place builds differ
export const CONSUMER = {
  brand:'Call Analyst', askLabel:'Ask AI', aiRouting:'proxy',
  liveEngine:'recall', billing:true, secretCoupons:true,
  proBotImage:true, tours:true, accountChrome:true, /* ...all flags... */
};
export const INTERNAL = {
  brand:'Daxos Analyst', askLabel:'Ask Claude', aiRouting:'direct',
  liveEngine:'fireflies', billing:false, secretCoupons:false,
  proBotImage:false, tours:false, passwordGate:true, /* ...all flags... */
};

Each of the 11 branch-diffs becomes a flag, a brand string, or a conditionally-loaded module — never a branch edit:

The serverless side

Functions differ by flavor too (Stripe = consumer only). Replace branch edits with one env var per site: FLAVOR=consumer|internal. Functions read process.env.FLAVOR (edge: Deno.env.get) and branch. Most "internal" differences are just the absence of a caller (internal has no billing UI), so the code can live on main unconditionally and stay inert.

Deploy topology after the fix

One fix on main reaches both flavors on next deploy. No merge, no remembering.

Migration (never breaks either build, reversible)

1. Extract flavors.js capturing today's consumer behavior verbatim. Pure refactor; deploy to consumer-testing, confirm byte-identical.
2. Fold each of the 11 internal diffs into a flag/module on main behind the internal flavor. Verify on an internal preview (call-analyst-testing) that it matches analyst.daxos.us exactly. One small revertible commit each.
3. Set FLAVOR=internal on the three internal sites and repoint them to deploy main. Verify each against current live behavior.
4. Collapse the duplicate lib/ files to one shared source.
5. Delete the internal branch last, only after parity is proven for a full deploy cycle. Until then it's the rollback.

Guardrails against future drift

• CI grep gate: fail the build if index.html/tour.js contain a raw location.hostname check or a bare IS_CONSUMER ? … outside flavors.js.
• Completeness test: assert CONSUMER and INTERNAL have the identical key set (no flag defined for one and silently missing on the other).
• Lib-parity check: CI asserts shared lib/ files are identical across the two runtimes (or that only one copy exists).
• One-screen flavor matrix doc beside flavors.js, kept honest by the completeness test.
• Rule: one long-lived branch (main) only. Variants are config, never git history.

WS2 · Stop main = prod do first · an afternoon

Target: one integration branch, one promote step

• main = integration → auto-deploys ONLY to consumer-testing.
• release = protected → consumer-analyst (callanalyst.app) builds ONLY from this.
• Promote = a single fast-forward main → release (or Netlify's "Publish deploy" button).

Concrete Netlify settings

1. consumer-analyst → Build & deploy → Production branch = release. Branch deploys off. This alone severs main from prod.
2. consumer-analyst → enable manual publishing (a release push stages but doesn't go live until you click Publish). Belt-and-suspenders for live Stripe.
3. consumer-testing → Production branch = main (auto-deploy stays on for fast feedback).
4. GitHub → branch protection on release: require PR + green CI, no force-push.

Rollback: Netlify keeps every prior deploy immutable. consumer-analyst → Deploys → pick last-good → Publish. Instant, no rebuild. Record the last-good deploy ID in each release PR.

WS3 · Minimal CI smoke tests

Not coverage. The three gates that actually predict "did I break prod," on every PR:

Total < 3 min. Make it a required check on release.

WS4 · Split the 20k-line file

Reading the file, it already partitions cleanly: one ~4,900-line CSS block, one ~5,800-line bare-global core (index.html:7284–13094 — holds store, getSessions, getKeys, MODEL_INFO, renderContent), and ~12 already-IIFE-wrapped consumer blocks (Projects Hub, calls list, recall live, settings-v2…) that talk to the core through a handful of named globals. tour.js already proves external files work.

Phase 1 — ordered <script src> files, no build step low risk

Move each block verbatim into call-analyst-pwa/js/, loaded in order (leaf → core → consumers). Classic (non-module) scripts share one global scope, so behavior is byte-identical to today. Keep globals global for now — converting to a namespace is a later refactor, not part of the move.

call-analyst-pwa/
  index.html            # HTML + <link styles.css> + ordered <script src> tags
  styles.css            # the 4,900-line <style> block  (extract FIRST)
  js/ 01-flavor.js  02-paywall-ui.js  03-bot-image.js  04-calendar.js
      05-org-byok.js  10-core.js      20-auth.js        30-projects-hub.js
      40-calls-list.js 41-recall-live.js 50-app-shell.js 51-home-wiring.js
      60-settings-v2.js 61-plan-picker.js 62-credits-nudge.js 63-autocreate.js
  flavors.js  tour.js  sw.js

The one invariant is load order: 01-flavor first, 10-core before any consumer, and the files that decorate window.renderContent (home-wiring, calls-list, settings-v2) after core. Extract leaves first, 10-core.js last and all at once — everything reads it by bare name, so it's the riskiest move.

Phase 2 — esbuild + ES modules + incremental TypeScript only when a 2nd dev is steady

Add a one-command esbuild bundle (bundles 20k lines in tens of ms, so deploys stay effectively instant — the velocity advantage is kept). Convert globals to real import/export one leaf at a time. Add types progressively: // @ts-check + JSDoc on leaf files first, then rename clean leaves to .ts. Never touch 10-core.js until its dependencies are typed.

WS5 · Cleanup & env-as-code

Dead code — what's actually dead (we checked, not assumed)

Safe-removal process for any deletion: grep for all references → delete on a branch → deploy-preview + smoke → bake on consumer-testing 24–48h → watch /analytics.html js_error events before promoting.

Env / secrets as code

The CLI env:set --site silently fails; the working pattern is DELETE-then-POST via the Netlify API. Encode it: a checked-in infra/env-manifest.json (var names per site, no values) + a small infra/sync-env.mjs that reads the manifest and a local untracked .env.<site> and syncs via the API. A second dev runs node infra/sync-env.mjs consumer-testing and a site stands up with no tribal knowledge. Hygiene (CI-enforced): grep-deny hardcoded secret fallbacks (process.env.X || 'sk-…'); keep GitHub push-protection on.

Sequenced roadmap

How two people split the work

The file-split (WS4) is what makes this division possible: once Projects Hub, billing, and the live-call engine are separate files, the two of you stop colliding in one 20k-line file.

What NOT to do

• Don't rewrite in React/TypeScript now. It optimizes for the dev's comfort over the runway. The plan above gets ~80% of the maintainability for ~5% of the effort and keeps shipping. Revisit a framework only after the file is split and segregation is fixed.
• Don't add a build step just to fix segregation. Runtime config solves it with zero build. A bundler is a Phase-2 maintainability choice, not a segregation prerequisite.
• Don't delete the half-wired file-drop. It's the R2 upload seam. Flag it.
• Don't keep a product-variant branch. The whole point is that variants are config. No new long-lived branches.
• Don't move and refactor in the same PR. Move verbatim, refactor later. It keeps every step reversible.

Appendix · the 11-file internal branch diff

From git diff --stat origin/main origin/internal — this is the exact punch-list to fold into flavors.js:

Every one of these is a brand string, a feature flag, or a conditional module on main — none of them need to be a branch edit.

Appendix · the file-split map