# EDU-015 — Operational independence and legacy exit

- **Status:** implemented-contracts
- **Type:** integration and deployment program
- **Phase:** 6
- **Blockers:** production deployment evidence and implementation of each future EDU-011 worker/scanner workload

## Outcome

The target backend runs its selected education capabilities without depending on the old NestJS API, worker, Supabase auth/storage, or asset-scanner deployment, except for explicitly time-bounded adapters with owners and exit dates.

## Scope

- Replace selected Worker jobs with Infra Job/MQ and owning-domain handlers.
- Complete retries, dead letters, audit, notifications, and observability.
- Complete file/scanner deployment or approved alternative.
- Remove or disable temporary Scalar/legacy adapters according to provider strategy.
- Reconcile migrated data and operational runbooks.
- Prove deployment, startup, Flyway, and core user flows.

## Delivered contracts

- `/admin-api/education/operations/health` exposes the runtime dependency registry plus durable Worker/Scanner and open dead-letter summaries.
- `JAVA_READ` performs a target-only PostgreSQL schema readiness proof; Scalar is explicitly `NOT_SELECTED` in that mode.
- `SCALAR_READ` is marked legacy, required only when selected, uses `FAIL_CLOSED`, and records success/failure telemetry without exposing URL or credentials.
- V4170 owns durable `education_operational_component` and tenant-scoped `education_dead_letter` contracts without retaining business payloads.
- `EducationTenantContextPropagation` re-establishes and restores tenant context for executor tasks.
- `tools/education-target-smoke/java-read-readiness.sh` asserts target-only provider selection against a running target deployment.

Production migration and deployment evidence remain release activities and are not claimed by this change.

## Acceptance criteria

- [ ] Every temporary legacy dependency has an owner, telemetry, failure policy, and exit date.
- [ ] At-least-once consumers are duplicate-safe.
- [ ] Job retries/dead letters and scanner health are observable.
- [ ] PostgreSQL migrations are actually executed and validated in an authorized environment.
- [ ] Student and selected admin E2E flows pass against the target only.
- [ ] Runbooks contain no active MySQL/manual-SQL or obsolete NestJS startup requirement.
- [ ] Rollback and incident procedures are documented.

## Verification

- Application startup and health.
- Flyway history and migration execution.
- Worker/job deployment smoke tests.
- Playwright student harness and selected admin flows.
- Logs, metrics, traces, retry/dead-letter, and scanner health checks.

## Risk and rollback

- **Risk:** High deployment and production reliability risk.
- **Rollback:** Per capability using application/configuration rollback while preserving forward database history.