Build progress dashboard

What it is

A live telemetry dashboard for the rebuild roadmap, served at https://ralli-roadmap.oaoisme.top. It answers one question at a glance: how much of the legacy system has actually been rebuilt, and where does the plan disagree with reality?

It is not a static report. On every request it loads the roadmap manifest and re-scans the ralli_backend repo, then reconciles the two. The source lives outside the backend repo at /root/work/ralli-roadmap/ (Node + Express, pm2-managed, bound to 127.0.0.1:3500, reverse-proxied by nginx).

How the live scan works

The scanner (lib/scanner.js) reads the repo and gathers signals:

• Nest modules — directories containing a *.module.ts.
• Prisma models — parsed from schema.prisma.
• Route coverage — controller decorator text vs the manifest's endpoint paths.
• Spec files and the FEATURES.md registry.

For each task it evaluates the task's detect hints and produces a detected status (done / in-progress / planned), then compares it to the manifest's recorded status. A mismatch renders as a ▲ DRIFT badge with a one-line reason.

The scoring is baseline-aware (why drift isn't noise)

Naïve hint-matching produces false positives: a Phase-3 "applicant profile" task lists the Applicant model as a hint, but Applicant already exists from Phase 0 — so a dumb scorer would call the task "in-progress". The scorer avoids this:

• A feature is "built" when its dedicated (new) module exists and its routes are present. Modules and Prisma models that already exist are treated as shared baseline and, on their own, never promote a later-phase task.
• Phase-0 tasks are exempt — they legitimately own the shared auth/users modules.
• Models alone never prove a build (they're shared infra); a new route is the strong signal.

With this, the board reads honestly: Phase 0 = done (9/9), everything else = planned, drift = 0 — and the moment a real Phase-1+ module lands, the next scan flips it without anyone editing the manifest.

The views

• Overview — an instrument gauge ring (overall % ) + inventory cards (phases, tasks, endpoints, the 68 data models, emails, integrations) + a phase ladder + a drift/integrity panel.
• Phases — the dependency-ordered plan; expand a phase → a task to see its legacy source, frozen-contract §, data-model delta, suggested improvement, and the live detect evidence (which hints hit/missed).
• Coverage — wafer-grid matrices for data models / emails / integrations, plus the full ~194-endpoint table, each cell colored by status and outlined on drift.
• Flows — the applicant (12 steps) and employer (10 steps) journeys as blueprint schematics (actor-tagged step cards with endpoints + emails).
• Guide — renders the in-repo docs/roadmap/** Markdown in-app with a grouped TOC.

Design

A bespoke "Drafting Table / Mission Telemetry" identity (see design.md): a dark blueprint canvas with a faint drafting grid, IBM Plex Sans + Mono with tabular numerals, hairline instrument panels, all-caps mono eyebrow labels, and a semantic status palette (azure chrome ≠ emerald "done"). Synthesized from three deliberately disagreeing anchors — Linear (restraint), SpaceX (mission-control voice), ClickHouse (scarce accent + a real state palette) — so it resembles none of them, nor the other sites on the box.

Verified

A Playwright e2e (e2e.mjs) drives the live HTTPS URL across desktop + a 390px mobile viewport + reducedMotion: reduce, exercises all five views and the expand/drawer interactions, and asserts zero console / page / request errors. Latest run: 20/20 assertions, 0 errors.