[Naveen Chatlapalli (1aifanatic)]

Summary

Fixes #572.

The API now mints these IDs with UUIDv7 (RFC 9562) instead of UUIDv4:

• submissionId (single, multi-run, profile-variation and bulk-resubmit submissions, plus the fallback minted when an uploaded run archive has none)
• request _id and each attempt's run._id, including retries
• report _id (POST /reports, bulk create, bulk trigger)

UUIDv7 puts a millisecond timestamp in the most significant bits, so string and binary sort order is creation order. Grouping the runs list by submissionId now sorts chronologically by default, and index inserts become append-mostly.

What doesn't change

• Existing v4 IDs stay valid. Same format and length, no migration. They simply carry no ordering, and they age out of active views.
• Content-addressed UUIDv5 IDs (task prompts, skill revisions) are untouched.
• Profile, insight and token-manager IDs still use v4. They aren't grouped or ordered by ID, so I kept this PR to the IDs the issue targets. Happy to extend it if you'd like everything on v7.

uuid@^11.1.1 is already a dependency of apps/api and ships v7, so there's no new dependency.

Tests

apps/api/src/endpoints.test.ts:

• a single submission's submissionId, request _id and run._id match a strict v7 pattern
• three sequential submissions return IDs whose lexical sort equals creation order
• every run of a count: 2 submission gets v7 request and run IDs and shares the submission ID
• POST /reports returns a v7 report ID

npx vitest run apps/api/src: 37 files, 791 tests pass. tsc --noEmit for apps/api is clean.

Docs

docs/architecture/app-design.md (Run submission flow) documents which IDs are v7, why, and how legacy v4 IDs behave.

🤖 Generated with Claude Code