Files
jobtrackingapp/docs/verification/core-001-sqlite-provider-parity.md
T

2.8 KiB

CORE-001 — SQLite/provider parity verification

Date: 2026-08-02

Result

VERIFIED LOCALLY. The audited SQLite DateTimeOffset failures are fixed without changing stored types or MariaDB query behavior. Production MariaDB execution and browser verification remain outstanding.

Implementation

  • SQLite materializes only owner/job-scoped CV variants, extraction runs/artifacts and AI rows before DateTimeOffset ordering or range comparison.
  • MariaDB retains server-side ordering, range filtering, aggregation and pagination.
  • The correction also covers CV retention cleanup and reprocess-artifact selection.
  • No schema, dependency or deployment configuration changed.

Automated evidence

  • Focused affected-service suite: 81/81 passed.
  • Real-provider compatibility suite: 3/3 passed in SqliteDateTimeOffsetCompatibilityTests.
    • SQLite relational database: newest-first CV/history/workspace/assets, current-month/all-time AI usage, generation entitlement query, extraction runs, latest artifact and owner isolation.
    • MariaDB/Pomelo: production ordering and range expressions generate SQL without opening a network connection.
  • Full backend regression: 509/509 passed.
  • git diff --check: passed (line-ending notices only).
  • docker compose config --quiet: passed with expected unset optional-variable warnings.

Runtime evidence

An isolated API used a disposable fresh SQLite root and synthetic example.test accounts only:

Check Result
/health 200
registration 200; local cookies only
/api/cv/variants 200 []
/api/profile-cv/runs 200 []
/api/ai/usage 200, zero usage
/api/jobapplications/1/ai/history 200 []
missing workspace 404
synthetic owner workspace 200 with correct company/job/checklist aggregate
same workspace as User B 404
User B variants 200 []

The exact isolated API process was stopped and port 5303 was confirmed closed. Logs and disposable evidence are under docs/audits/evidence/core-001-runtime/; no secret or personal data is present.

Limitations

  • Browser localhost access remains denied by the in-app browser administrator policy; no browser claim is made.
  • No MariaDB server was available. Pomelo SQL generation passed, but execution awaits a disposable or production-safe MariaDB smoke.
  • Direct dotnet ef database update against a completely blank SQLite file still fails in the pre-existing reconciler-owned schema gap at AddJobEntityAndProspectStages. The documented application startup path succeeds because the reconciler establishes those columns before migrations. This is JT-019 schema-ownership debt, not the JT-003 query defect, and historical migrations were not changed.
  • Execution policy denied deletion of the exact disposable nested data directory; it is stopped and recorded in the session handoff.