ci(jobnik-e2e): make the e2e suite a gate on unreleased code

[CptSchnitz]

Replace the e2e composition's sibling-repo build with the pruned
build: both the manager and migrator services now build
docker/backend.Dockerfile from the repository root with
APP_NAME=jobnik-manager, instead of a ./jobnik-manager context that
only ever existed for the cross-repository checkout. The migrator's
npx prisma ... also picks up the prisma@6 pin ticket 05 flagged —
without it, a fresh image build resolves Prisma 7 and the migration
fails outright, for the same reason the image build itself does.

The suite is wired into the single entry point for real: turbo's
existing e2e task already dispatched to a package script, but
vitest run alone never brought the composition up. It now does, via
a globalSetup/teardown pair mirroring the manager's own
integration-test convention (tests/configurations/integration/
globalSetup.ts) — docker compose up --build --wait before the suite,
down after it in CI only, so a local run leaves the stack up for
faster iteration. --build is unconditional rather than skip-if-
running, because the whole point of this ticket is that the suite
tests the current checkout, never a stale container.

jobnik-e2e gained a type-check script and a jobnik-manager
workspace:* devDependency it doesn't import from — the former wires
tsc --noEmit into the existing type-check task for free (all it
needed was the script to exist), the latter gives turbo's package
graph an edge from the suite to the service it tests, which is what
--affected actually walks. Without it, a manager-only change with no
SDK or spec involvement would never mark the suite affected. Verified
by touching apps/jobnik-manager/src/index.ts and confirming
turbo run e2e --affected --dry=json includes jobnik-e2e. A new e2e
job in pull_request.yaml runs turbo run e2e --affected, following
the existing matrix jobs' pattern of always running but doing nothing
when unaffected — there is no scheduled trigger.

Wiring in type-check surfaced the staleness ticket 02 called out: the
workspace SDK's generated types no longer accept the status values
pause.spec.ts and wait.spec.ts were setting. Checked both against the
current OpenAPI contract (stageOperationStatus: PENDING only;
taskOperationStatus: COMPLETED/FAILED only) and against the manager's
actual transition logic, not just the type error: tasks are created
PENDING by TaskManager.addTasks regardless of the stage's status, and
a stage created via startAsWaiting is already WAITING, so both specs'
redundant status-setting calls were dead weight even before they
became type errors — removed rather than retargeted at a different
value. The one remaining explicit PENDING call in pause.spec.ts (on a
stage that's already PENDING at creation, being the job's first
stage) stays: it's a no-op the manager already treats as idempotent,
still valid against the contract, and not what tsc flagged.

Verified end-to-end: turbo run e2e builds both images from this
checkout, runs migrations through the pinned prisma@6, brings up the
full composition, and all 24 tests across 9 files pass, including the
two fixed specs. turbo run type-check lint test stays green
repo-wide, confirming the manager's own integration tests — which
resolve their compose file by the same upward search, from a sibling
directory that still has none — are unaffected by anything here.

Refs: .scratch/monorepo-migration/issues/06-e2e-suite-branch-gate.md

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

[github-actions]

Coverage Report for apps/jobnik-manager

Status	Category	Percentage	Covered / Total
🟢	Lines	100% (🎯 80%)	767 / 767
🟢	Statements	100% (🎯 80%)	784 / 784
🟢	Functions	100% (🎯 80%)	112 / 112
🟢	Branches	100% (🎯 80%)	219 / 219

File Coverage

No changed files found.

Generated in workflow #5 for commit 0e2699c by the Vitest Coverage Report Action