fix(ci): check every service lock and build core-worker's image (M-01)

[eldad-caura-ai]

Fixes part 1 of M-01 from the 2026-10-01 OSS audit.

Every service lock is checked

Each service image installs its own uv.lock as it stands (uv export --frozen), while CI tests the pyproject ranges, resolved afresh, and nothing checked that a lock still matched its pyproject. A pyproject edit made without a re-lock passed CI and was missing from the image.

• The check: the CI job now runs uv lock --check --directory <service> for all four services, before it installs anything, and names every stale lock in one error. uv lock --check fails when re-locking would change the lock; it exists since uv 0.5.8, and CI runs 0.9.26.
• Main passes it today, as far as reading the files can tell: in all four locks, the requirements, extras, dependency groups, Python range and version they recorded match their pyprojects, before and after release chore: release main #1980.
• Bots keep the locks in step: release-please bumps each service's version in its uv.lock with its pyproject.toml (fix(release): keep the core-operations version in sync #1717 does the same for core-operations), Dependabot's uv updates re-lock, and its pip updates touch only the root requirements.txt.

core-worker's image is built

No workflow built core-worker's image, the write path in deferred mode. The image job ("core-api image bakes a real version") now builds it and runs python -c "import uvicorn, core_worker.app" inside it: the app its CMD serves, from what the image installed. In CI's shared venv another service's dependency can stand in for one core-worker never declared; in the image it cannot.

The import needs no environment: every setting has a default, ddtrace is imported under try/except ImportError, and the event bus and storage client start only in the app's lifespan. Every other third-party module the app loads at import is a declared core-worker dependency.

Tests

tests/test_m01_every_lock_is_checked_and_every_image_built.py fails when a service's uv.lock is not named in a ci.yml step that runs uv lock --check, or a service's Dockerfile is not built by a ci.yml docker build. A guard checks that the scans find all four services, and the core-api image build.

Push	Run	Result
Tests alone (46383fe)	37622734288	Failed exactly the 2 new cases: no ci.yml step checked any of the four locks, and no docker build built core-worker's Dockerfile. The guard and 9,654 other tests passed. The first push (46383fe) had stopped at the root-tests ruff check (SIM300) before the tests ran; the amend flipped two comparisons.
Fix added (1e9036f)	37624349643	This PR's checks

Not in this PR

• Part 2 of M-01, CI installing from the service locks, waits on aligning SQLAlchemy: core-api's lock pins 2.0.50 and core-storage-api's 2.1.0.
• L-01, making the image job a required check, is a branch-protection setting.

🤖 Generated with Claude Code

[github-actions]

Claude Code Review — skipped: draft PR

[github-actions]

Claude Code Review — skipped: no source files to review (only tests/docs/config)

[eldad-caura-ai]

@claude

[github-actions]

🤖 Review by Claude Code

Claude Code Review ✅ No issues found.

---

Reviewed by claude-sonnet-5-5 · cost $0.16321575000000002

[eldad-caura-ai]

@erni-a plasr arprpvoe