Evidence-based project review: what was built, what works, what's broken, and a realistic path to production. Compiled from live GitLab data, staging inspection, and full project history — not self-reported status.
Engineering substance is genuinely strong — every architectural finding from the original audit is closed with live, verifiable code. The failures are in the connective tissue: an app went silently undeployed for six months, the project's own tracker has claimed "done" since April, and yesterday's celebrated fixes are sitting on an untracked branch one deletion away from regressing.
A THG InAPI-compatible multiplayer crash betting game. Players bet on a climbing multiplier and cash out before it crashes, with shared real-time rounds and provably-fair verification.
| Layer | Technology |
|---|---|
| Backend | Fastify 5.x (TypeScript), Node 22 |
| ORM / DB | Drizzle ORM 0.45 → PostgreSQL |
| Cache / PubSub | Redis 5.x |
| Frontend | React + Vite + Zustand |
| Admin | Separate React/Vite SPA, served at /admin/ |
| Money math | decimal.js — no float errors |
| Auth | @fastify/jwt + httpOnly cookies |
| Observability | Prometheus + Grafana + node-exporter (Tailscale-only) |
This project did not start at v3.0.0. Versions v1.0–v2.0 shipped Feb–Apr 2026, before this engagement began. The v3.x line (32 tags, current work) is the second phase of a pre-existing product — presenting v3.0.0 as "day one" would overstate what was built from scratch here.
Verified live from GitLab contributor and member records.
| Person | Role | Evidence |
|---|---|---|
| Tico | Builder / orchestrator agent | 36 + 6 commits (two identities) |
| Ondrej Lapides | Owner | 17 commits, Access 50 |
Ondrej Gregor (gregor2, "ondrog") | Operational stakeholder — merges, direction | Merged MR !33, !34; Access 40 (Maintainer) |
| Vera (agent) | Repo Maintainer access | No commits, no memory evidence of involvement |
| Vicky / Vika | — | Zero evidence of any crash-game involvement found |
GSD-style planning — structured .planning/ docs per phase (predates this engagement).
Claude Code as the dev harness, with subagent delegation for focused tasks.
GitLab REST API as the default commit path — the local sandbox git remote broke repeatedly (3+ times), so direct API commits are now standard practice, not a fallback.
Deploy-verify loop — commit → poll pipeline → trigger manual deploy job → poll + read the deploy script's own health-check trace. Used successfully 7 times across Sept 17–18.
Evidence-backed wins only — independently re-verified, not self-reported.
A performance bug (bet-placement latency 1.3s idle → 13.3s at 500 concurrent users) was root-caused to synchronous per-bet broadcasting, not guessed at. Fixed via per-tick batching: 13.3s → 1.6s, an 8.1× improvement, re-confirmed on the next release.
Database partitioning had silently disabled a unique constraint, reopening a duplicate-bet race condition. Fixed with advisory locks and proven via real concurrent-request tests — not mocked assertions.
End-to-end tests only ran on tagged builds — exactly how a breaking bug once reached the main branch undetected. Now: full build + tests on every push, with branch protection requiring a green pipeline before merge.
Health check pulled today: 90,252 entries, verified: true. This is a certification-relevant control functioning in production-like conditions, not a design doc.
Multiple recorded instances of surfacing bad news (a process not running, a caveat volunteered unprompted, infra failures reported rather than silently retried) instead of reporting plausible-sounding success.
Named plainly — the point of this report is to be useful, not flattering.
The deploy script had no step at all for the admin application. It was separated out in March; the gap wasn't caught until September — and only because a new UI element failed to appear. Nothing ever compared what was deployed to what was actually built.
5 Critical / 11 High / 7 Medium findings were delivered once, in chat. No document anywhere records a formal re-audit. Most items were genuinely fixed — but nobody ever re-ran the audit and declared it closed, and 7 of the 11 High findings are now unrecoverable from any available source.
Multiple "deployed, try it now" claims were made while the old UI was still live — the root cause was checking server files instead of what the browser actually rendered. This drove a lasting "verify before reporting" discipline, but it cost trust early.
The local git sandbox has broken 3+ times. The workaround (GitLab's API directly) is now standard practice — pragmatic, but an unexplained defect has effectively been normalized rather than fixed.
Four separate rounds of UI polish, each requiring a manual one-off deploy because automatic preview deploys for untagged work were never built, despite being requested.
It's currently failing in the pipeline — but marked non-blocking, so the overall pipeline still reports green. The one automated control meant to catch security regressions cannot block a merge.
Seven commits — including all three fixes celebrated yesterday — are sitting on an untracked feature branch with no merge request. This includes the fix for the six-month admin-deploy gap. They are live on staging, but not in the main development branch. If that branch is deleted, or staging is ever redeployed cleanly, the admin deploy gap silently returns.
| Claim | Verification | Result |
|---|---|---|
| Admin app now actually deploys | Live bundle inspected directly | ✓ Confirmed |
| "Test Players" feature visible | String search in live bundle | ✓ Confirmed |
| Version label added to admin UI | Confirmed in live bundle | ✓ Confirmed |
| Start-button error fixed (code) | Live fetch code inspected directly | ✓ Confirmed |
| Start-button fix confirmed by stakeholder | Awaiting browser re-check | ⏳ Outstanding |
| Backend health | Live health endpoint | ✓ Healthy |
Four more commits and three successful deploys occurred this morning (07:09–07:31 UTC) — none of it recorded in any status file before this report. Root cause: the new test-bot pool was tripping the game's own rate limiter, now fixed with proper backoff.
Original 2026-05-06 audit findings, checked against live code today — not assumed.
| Finding | Status |
|---|---|
| Vulnerable dependencies | Resolved |
| Wallet timing / cashout race condition | Resolved |
| Input validation gaps | Unknown — never verified |
| Missing DB constraints | Resolved (twice — regressed once, re-fixed) |
| Cookie / JWT security | Resolved |
| Rate limiting | Resolved — proven today when test bots tripped it |
| Multi-tenant / operator model | Resolved |
| Single-process engine (leader election) | Resolved |
| Third-party RNG/fairness certification | Not started |
| Production environment | Does not exist — staging only, by design |
| Alerting on monitoring metrics | Metrics collected, nothing pages anyone |
Every architectural finding rated highest-effort in the original review — multi-tenancy, single-point-of-failure engine design — is closed, with live code evidence, not just claimed. Real-money readiness was assessed at ~15% in June on the architecture axis; that has substantially inverted.
A structured project tracker does exist, in-repo, and it's genuinely well-designed. But its own status file has said "v2.0 complete, ready for next milestone" since April — five months ago. Since then: 32 tags, 33 merged changes, and an entire security-hardening program shipped, recorded nowhere in the project's own documentation.
A newcomer opening this project's own tracker today would be confidently told it finished five months ago. That's a worse failure mode than having no documentation at all — an empty page invites questions; a wrong one invites false confidence.
Ranges reflect elapsed calendar time under the observed intermittent working pattern — not continuous-effort hours. All estimates are inferences, stated with explicit confidence.
Under 1 session (hours) · Confidence: high
Pure hygiene, pipeline already green. Highest-value, lowest-effort action available — protects work already paid for.
2–4 weeks elapsed · Confidence: medium
Individually small, well-understood items. Schedule risk is stakeholder availability and a couple of human decisions, not engineering effort.
1–2 weeks after B · Confidence: medium
This has to be a fresh audit — the original findings list is lost, so there's nothing left to "re-check" against.
6–10 weeks from today · Confidence: low–medium
Dominated by a decision that hasn't been made yet: provisioning an actual production environment. The engineering is largely done; this is an infrastructure and business decision gap.
4–9 months from today · Confidence: low
Not gated on engineering at all. Third-party certification is a procurement and calendar process — engaging a lab, queueing, evidence rounds. Industry norm is 3–6 months after code freeze. No amount of engineering speed compresses this. Treat any shorter estimate with suspicion.
Do A and documentation resync first — hours of work that protects everything already built. Then B → C as one push to close the security story. D and E need business decisions before they need more engineering — specifically: will a production environment actually be provisioned, and is real-money launch actually the goal?
Flagged explicitly because several widely-held assumptions turned out to be stale once checked against live evidence.
Live check found it merged two days prior, along with a follow-up MR the same day. Current open-MR count: zero.
Seven commits, including all three celebrated fixes, sit on an untracked branch with no merge request — the real risk was masked by everyone assuming a since-merged MR was still the active tracker for that work.
The live running version differs from what's recorded in the most recent status notes — a deploy happened after the last update was written.
Two earlier major versions shipped before this engagement began. Treating the current phase as "day one" overstates what was built from scratch here.
One has repo access but zero commits; the other has zero evidence of any involvement at all across every available source.