fix(submit): harden trusted submission ingestion

[ShivamB25]

Summary

• harden the submit boundary before competitive data is written
• return explicit trust-state decisions for trusted, rejected, and review-required submissions
• fix legacy token writes and dated snapshot parsing at the submit layer

Changes

• reject malformed, empty, duplicate-date, unsupported-client, negative-counter, and future-dated payloads before persistence
• add submit trust decisioning with machine-readable reason codes
• defer legacy token upgrades until accepted writes
• parse separated snapshot model dates such as gpt-4o-2024-08-06

Testing

• frontend Vitest coverage for submit validation and trust decisioning
• frontend typecheck
• frontend build
• local runtime verification against the app and Postgres

Refs #441

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
tokscale	Ready	Preview, Comment	Apr 18, 2026 9:54pm

[cubic-dev-ai]

2 issues found across 14 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/frontend/src/lib/validation/submissionTrust.ts">

<violation number="1" location="packages/frontend/src/lib/validation/submissionTrust.ts:33">
P1: Unvalidated `timestampMs` conversion can throw `RangeError` and crash trust assessment instead of returning structured trust-state output.</violation>
</file>

<file name="packages/frontend/src/lib/db/migrations/0005_concerned_justin_hammer.sql">

<violation number="1" location="packages/frontend/src/lib/db/migrations/0005_concerned_justin_hammer.sql:5">
P2: `submission_reviews` lacks DB integrity constraints for trust state/domain and numeric/date invariants, allowing invalid records despite ingestion hardening.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[ShivamB25]

@junhoyeo @IvGolovach sorry to bother you I may be missing context here, but I noticed the public all-time leaderboard still appears to show some unusually large entries (hundreds of billions of tokens / very large cost totals across a relatively small number of submits).

Since this PR is focused on hardening submit trust/persistence, could you share whether there has already been any review/backfill/removal plan for existing inflated leaderboard rows, or if there are follow-up steps planned? Thanks for taking a look.

[junhoyeo]

@ShivamB25 Hi, thank you for all your efforts! I’ll definitely review them when I have some spare time.

[ShivamB25]

For temporary measure please check the first 2-3 on leaderboard and permanent ban would be nice I believe.

…

On 2 May 2026, at 8:11 PM, Junho Yeo ***@***.***> wrote: junhoyeo left a comment (junhoyeo/tokscale#443) <#443 (comment)> @ShivamB25 <https://github.com/ShivamB25> Hi, thank you for all your efforts! I’ll definitely review them when I have some spare time. — Reply to this email directly, view it on GitHub <#443 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AY6KJAOZOWIYRQGRETBNY7T4YYCKLAVCNFSM6AAAAACX6EKEF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNRUGA2TCMJQHE>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.