# EDU-015 — Operational independence and legacy exit

- **Status:** blocked
- **Type:** integration and deployment program
- **Phase:** 6
- **Blockers:** EDU-011, EDU-013, EDU-014 child decisions, all temporary-adapter owners and exit plans

## 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.

## 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.