# Phase 10 Execution Plan: Migration, Release, and Production Readiness

## 1. Purpose

Phase 10 turns the modular architecture work into a controlled production rollout.

Earlier phases define and enforce the architecture:

```text
Phase 1: SchoolContext
Phase 2: Core contracts
Phase 3: Finance
Phase 4: Attendance
Phase 5: Student lifecycle
Phase 6: Communication
Phase 7: Reporting
Phase 8: Controller/API cleanup
Phase 9: Boundary enforcement
```

Phase 10 answers the uncomfortable operational questions:

```text
How do we migrate without breaking the current app?
How do we cut over safely?
How do we validate old vs new behavior?
How do we rollback?
How do we monitor correctness?
How do we prove Islamic Sunday School still works?
How do we prevent this from becoming a never-ending refactor swamp?
```

The goal is not to “finish architecture.” Architecture is never finished. It just becomes less embarrassing when guarded properly.

---

## 2. Release Principle

Do not big-bang rewrite the platform.

Use controlled vertical releases:

```text
1. build modular slice
2. run in shadow/parallel where possible
3. compare outputs
4. enable behind feature flag
5. roll out to internal/test school
6. roll out to Islamic Sunday School production tenant
7. monitor
8. remove legacy path after confidence window
```

A big-bang release is just a theatrical way to discover all integration bugs at once. Very efficient, in the same way driving into a lake is efficient transportation to the bottom.

---

## 3. Release Scope

Phase 10 applies to:

```text
feature flags
data migration
compatibility adapters
parallel run validation
production rollout
rollback plans
monitoring and observability
audit verification
performance checks
security checks
user acceptance testing
staff/admin training
support playbooks
legacy deprecation/removal
post-release governance
```

Covered modules:

```text
SchoolContext
Core Contracts
Finance
Attendance
Students
Communication
Reporting
Controller/API layer
Boundary enforcement
IslamicSundaySchool extension
```

---

## 4. Target Release Model

Recommended release model:

```text
Release Track A: internal/dev validation
Release Track B: staging with production-like data copy
Release Track C: pilot school/tenant
Release Track D: Islamic Sunday School production rollout
Release Track E: broader multi-school rollout
Release Track F: legacy removal
```

Each track has explicit entry and exit criteria.

No track advances because “it seems fine.” That phrase belongs in horror movies and production postmortems.

---

## 5. Feature Flag Strategy

Use feature flags to control rollout by school/domain/module.

Required flags:

```text
school_context.enabled
core_contracts.enabled
finance.modular_payments.enabled
finance.modular_file_access.enabled
attendance.modular_scanner.enabled
attendance.modular_manual_override.enabled
students.modular_creation.enabled
students.modular_enrollment.enabled
communication.preview_required.enabled
communication.modular_send.enabled
reporting.modular_reports.enabled
api.v2.enabled
islamic_sunday_school.extension.enabled
boundary_enforcement.fail_ci.enabled
```

Flag dimensions:

```text
global
environment
school_id
domain_profile
user role
route group
module
```

Rules:

```text
- every risky module cutover must be flag-controlled
- flags must default safe
- flags must be auditable
- flags must have owners
- flags must have removal dates
```

Feature flags without removal dates become permanent haunted switches.

---

## 6. Migration Environments

### 6.1 Development

Purpose:

```text
verify compile, tests, architecture checks, developer flow
```

Exit criteria:

```text
unit tests pass
architecture tests pass
static analysis passes
module contracts compile
feature flags work
```

### 6.2 Staging

Purpose:

```text
validate migrations and behavior using production-like data
```

Exit criteria:

```text
database migrations pass
rollbacks tested
shadow comparisons completed
performance acceptable
security checks passed
UAT completed
```

### 6.3 Pilot Tenant

Purpose:

```text
validate with limited real users and real workflows
```

Exit criteria:

```text
no P0/P1 defects
support playbook validated
finance and attendance reconciled
communication sends verified
reports match expected data
```

### 6.4 Production

Purpose:

```text
controlled rollout and monitoring
```

Exit criteria:

```text
module rollout stable
legacy adapters retired according to schedule
post-release audit complete
```

---

## 7. Data Migration Strategy

### 7.1 General migration rules

```text
- migrations must be backward-compatible during rollout
- additive schema changes before destructive changes
- destructive changes only after legacy removal
- every migration has rollback plan
- every migration has validation query
- every sensitive table migration has backup checkpoint
```

Use expand-and-contract:

```text
1. expand schema
2. write to old and new paths if needed
3. backfill
4. validate
5. read from new path
6. stop writing old path
7. remove old path later
```

### 7.2 Finance migration rules

Finance migrations require stronger controls:

```text
- backup before migration
- balance reconciliation before and after
- audit log verification
- payment file access validation
- no destructive payment/invoice migration during business hours
```

Required validation:

```text
total invoice count
total payment count
sum invoice totals
sum payment amounts
outstanding balances by school
refund/reversal counts
payment file count
finance audit count
```

### 7.3 Attendance migration rules

Required validation:

```text
attendance session count
attendance record count
scan log count
duplicate scan handling
student/staff attendance count by date
wrong-school scan isolation
manual override audit count
```

### 7.4 Student lifecycle migration rules

Required validation:

```text
student count by school
guardian count by school
student_guardian links
enrollment count
assignment count
student identifier uniqueness
Islamic profile extension row count
sensitive field authorization
```

### 7.5 Communication migration rules

Required validation:

```text
message count
recipient log count
delivery attempt count
preference count
template count/version
preview snapshot count
provider callback mapping
```

### 7.6 Reporting migration rules

Required validation:

```text
report registry entries
core report availability
Islamic report availability
report snapshot access
export audit logs
scheduled report recipient validation
```

---

## 8. Parallel Run and Shadow Validation

For high-risk modules, run old and new logic in parallel before cutover where practical.

### 8.1 Finance shadow mode

Compare:

```text
legacy invoice balance
modular BalanceCalculator result
legacy payment edit behavior
modular PaymentService result simulation
legacy finance report
modular finance report
```

Do not double-write real payments in shadow mode unless explicitly designed. Simulate and compare. Duplicating payments because of “testing” would be a bold new genre of self-harm.

### 8.2 Attendance shadow mode

Compare:

```text
legacy scanner result
modular ScannerService result
legacy late/present status
modular AttendanceStatusPolicy result
legacy attendance summary
modular Attendance read model summary
```

### 8.3 Student lifecycle shadow mode

Compare:

```text
legacy student creation payload
modular DTO mapping
legacy generated identifier
modular identifier format
legacy enrollment assignment
modular enrollment/assignment result
```

Do not create duplicate students in production shadow mode.

### 8.4 Communication shadow mode

Compare:

```text
legacy recipient query
modular recipient preview
legacy recipient count
modular deduped count
legacy excluded recipients
modular preference exclusions
```

Do not send duplicate messages. Shadow recipient resolution only.

### 8.5 Reporting shadow mode

Compare:

```text
legacy student roster
modular student roster
legacy attendance summary
modular attendance summary
legacy finance balance report
modular outstanding balance report
```

---

## 9. Cutover Strategy

### 9.1 Cutover order

Recommended order:

```text
1. SchoolContext read-only enforcement
2. Payment file access hardening
3. Communication preview-before-send
4. Student identifier generation
5. Finance payment recording/editing
6. Attendance scanner and manual override
7. Student enrollment/assignment/promotion
8. Reporting registry and exports
9. API/controller v2 routes
10. Islamic Sunday School extension routes/reports
11. Legacy route deprecation/removal
```

Why this order:

```text
- security fixes first
- low-side-effect safety improvements early
- money and attendance after validation
- reports after domain truth is stable
- extension routes after core contracts are stable
```

### 9.2 Cutover checklist

Before enabling a module flag:

```text
- tests pass
- architecture checks pass
- migration validation passes
- shadow comparison reviewed
- rollback procedure tested
- monitoring dashboard ready
- support team briefed
- owner approval recorded
```

### 9.3 Cutover window

For high-risk modules:

```text
finance: low-activity window
attendance/scanner: outside active program/class session
communication: never immediately before critical announcement
student lifecycle: outside registration rush if possible
reporting: normal hours acceptable if read-only
```

Apparently releasing attendance scanner changes five minutes before morning check-in is considered “bad.” Humanity retains some instincts.

---

## 10. Rollback Strategy

Every module must have rollback steps.

Rollback types:

```text
feature flag rollback
route rollback
service binding rollback
database rollback
data repair
provider integration rollback
```

### 10.1 Feature flag rollback

Preferred rollback:

```text
disable modular feature flag
route traffic back to adapter/legacy path
preserve new logs for analysis
```

### 10.2 Database rollback

Avoid destructive rollback when production writes have occurred.

Use:

```text
forward-fix migration
compatibility read adapters
data repair scripts
manual reconciliation for finance
```

### 10.3 Finance rollback

Finance rollback must include:

```text
payment/invoice reconciliation
audit log review
idempotency key review
manual correction plan
finance owner approval
```

### 10.4 Communication rollback

Communication rollback must avoid duplicate sends.

Required:

```text
check idempotency records
check message logs
disable scheduled sends if needed
verify no retry storm
```

### 10.5 Attendance rollback

Required:

```text
preserve scan logs
compare attendance records
repair duplicate/missing records
notify operations if scanner behavior affected
```

---

## 11. Observability and Monitoring

Create dashboards and alerts before production rollout.

### 11.1 Platform-level metrics

```text
request count by route
error rate by route
latency by route
auth failures
authorization failures
school context resolution failures
wrong-school access attempts
feature flag state by school
```

### 11.2 Finance metrics

```text
payment create count
payment edit count
payment reversal/refund count
invoice recalculation count
finance audit log count
payment file download count
payment file authorization denial count
balance mismatch count
idempotency conflict count
```

Critical alerts:

```text
balance mismatch detected
payment mutation without audit log
payment file wrong-school access attempt
finance exception spike
```

### 11.3 Attendance metrics

```text
scan count
duplicate scan count
scan failure count
badge not found count
late status count
manual override count
attendance audit log count
scanner latency
```

Critical alerts:

```text
scanner error spike
duplicate scan spike
attendance mutation without audit
wrong-school badge attempt
```

### 11.4 Student lifecycle metrics

```text
student create count
identifier collision count
guardian link count
enrollment count
assignment count
promotion count
status transition count
student audit count
```

Critical alerts:

```text
identifier collision spike
student creation failure spike
wrong-school guardian link attempt
```

### 11.5 Communication metrics

```text
recipient preview count
bulk send count
recipient dedupe count
preference exclusion count
delivery failure count
retry count
provider error count
scheduled send count
```

Critical alerts:

```text
bulk send without preview attempt
provider failure spike
retry storm
wrong-school recipient attempt
```

### 11.6 Reporting metrics

```text
report run count
export count
snapshot count
scheduled report count
sensitive export count
report authorization denial count
cache hit/miss
```

Critical alerts:

```text
sensitive export by unauthorized actor
report export without audit
cross-school report attempt
scheduled report failure spike
```

---

## 12. Audit Verification

Audit logs are part of production readiness.

Verify audits for:

```text
finance mutations
payment file downloads
attendance mutations
manual overrides
student lifecycle changes
guardian links
bulk communication sends
report exports
sensitive Islamic Sunday School profile access
role/permission changes
```

Audit verification checklist:

```text
- audit row created
- actor_user_id present
- school_id present
- action present
- entity type/id present
- before/after present where required
- reason present where required
- request_id present
```

If an operation mutates important data and does not create audit logs, it is not production-ready. It is just leaving footprints in wet cement and hoping nobody checks.

---

## 13. Security Readiness

Security checks before production:

```text
cross-school access tests
wrong-role access tests
file download authorization
bulk communication authorization
report export authorization
extension route domain-profile checks
sensitive field access checks
rate limits on risky endpoints
provider callback signature verification
```

High-risk Islamic Sunday School extension data:

```text
imam/admin sensitive notes
Qur'an/Arabic/Islamic studies placement details
scholarship/sadaqah support indicators
family/community profile notes
guardian contact information
```

These require explicit permissions and audit on access/export.

---

## 14. Performance Readiness

Baseline performance before rollout.

Targets should be defined per project, but recommended checks:

```text
student list response time
scanner process latency
payment record latency
recipient preview generation time
bulk send queueing time
report run time
export generation time
SchoolContext resolution overhead
```

Performance risks:

```text
unscoped queries
N+1 relationships in resources
large recipient previews
large exports
report joins across extension tables
scanner latency during check-in rush
```

Mitigation:

```text
indexes
read models
chunking
queues
pagination
export jobs
caching only when safe
```

Fast wrong answers remain wrong. Optimize after correctness unless the system is timing out, in which case enjoy doing both at once, nature’s punishment for optimism.

---

## 15. User Acceptance Testing

UAT must be scenario-based, not vague clicking.

### 15.1 Admin scenarios

```text
create student
link guardian
enroll student
assign class/group
record payment
edit payment
download payment file
run attendance report
send bulk communication with preview
export student roster
```

### 15.2 Teacher/staff scenarios

```text
view assigned students
record attendance
scanner check-in/check-out
manual override if permitted
view attendance summary
send class communication if permitted
```

### 15.3 Finance user scenarios

```text
record payment
edit payment with reason
reverse/refund payment
view invoice balance
download payment file
export outstanding balance report
```

### 15.4 Islamic Sunday School scenarios

```text
create Islamic Sunday School student profile
assign Qur'an level
assign Arabic level
assign Islamic studies track
assign halaqa/group
record Sunday program attendance
view Qur'an progress report
view halaqa attendance report
message Qur'an class guardians with preview
export masjid family/community summary with permissions
```

### 15.5 Guardian/parent scenarios, if applicable

```text
view own student profile
view allowed attendance
view allowed finance info
receive communication
not see unrelated students
not see sensitive notes
```

---

## 16. Training and Support

Prepare support materials before rollout.

Required materials:

```text
admin quick guide
finance quick guide
attendance/scanner guide
student lifecycle guide
communication preview/send guide
reporting/export guide
Islamic Sunday School extension guide
support escalation guide
known changes/changelog
```

Support playbooks:

```text
payment balance discrepancy
scanner not recognizing badge
duplicate scan complaint
guardian cannot see student
bulk message sent to unexpected recipients
report export missing data
Islamic profile field missing/unauthorized
```

---

## 17. Data Reconciliation

Run reconciliation before and after module cutovers.

### 17.1 Finance reconciliation

```text
invoice totals match
payment totals match
balances match
refund/reversal totals match
audit counts match mutation counts
payment files accessible only through authorized routes
```

### 17.2 Attendance reconciliation

```text
attendance counts by date/session match
duplicate scans not counted
manual overrides preserved
staff/student attendance separated correctly
audit counts match mutation counts
```

### 17.3 Student reconciliation

```text
student count stable
guardian links stable
enrollments stable
assignments stable
identifiers unique
Islamic extension profiles linked correctly
```

### 17.4 Communication reconciliation

```text
recipient previews match expected audiences
dedupe counts reviewed
preference exclusions correct
message logs complete
delivery attempts tracked
```

### 17.5 Reporting reconciliation

```text
core reports match source domain read models
Islamic reports match extension read models
exports match report view
sensitive columns filtered
```

---

## 18. Production Readiness Review

Hold a readiness review before each major module rollout.

Required attendees:

```text
platform owner
module owner
security reviewer
QA/test owner
support owner
Islamic Sunday School domain owner, if extension affected
finance owner, if finance affected
```

Review checklist:

```text
tests passing
known issues reviewed
migration plan approved
rollback plan approved
monitoring ready
support docs ready
UAT signoff complete
owner approval recorded
```

---

## 19. Legacy Removal Strategy

Legacy removal must be deliberate.

Removal order:

```text
1. disable legacy route behind flag
2. monitor for usage
3. add deprecation warning/header
4. notify clients/admins if needed
5. remove route
6. remove adapter controller
7. remove legacy service method
8. remove old tests
9. remove old schema only after data retention review
```

Never remove old paths while unknown clients still use them unless the route is unsafe. In that case, security wins and the support team gets coffee.

---

## 20. API Client Migration

If external/admin clients consume the API, provide migration guidance.

Required docs:

```text
v1 to v2 route mapping
request payload changes
response envelope changes
error envelope changes
deprecation dates
new auth/permission requirements
new Islamic extension endpoints
```

For each breaking change:

```text
old endpoint
new endpoint
old payload
new payload
old response
new response
migration notes
sunset date
```

---

## 21. Incident Response Plan

Define incident categories.

### P0 incidents

```text
cross-school data leak
unauthorized payment file access
incorrect payment balances at scale
bulk communication sent to wrong audience
sensitive report export leak
scanner outage during active session
student data corruption
```

### P1 incidents

```text
module unavailable
report incorrect for subset
payment edit failure
attendance duplicate spike
communication provider failure
Islamic extension profile unavailable
```

### Response steps

```text
1. disable feature flag if applicable
2. stop affected queues/jobs
3. preserve logs and audit evidence
4. notify owner/security/support
5. run reconciliation
6. apply rollback or forward fix
7. document root cause
8. add regression test
```

---

## 22. Post-Release Review

After each module rollout, run a post-release review.

Review:

```text
incidents
support tickets
performance metrics
audit completeness
reconciliation results
missed tests
missed docs
flag cleanup
legacy usage
```

Output:

```text
post-release report
follow-up tickets
test additions
docs corrections
legacy removal decisions
```

No “we survived, ship the next one” ritual. Survival is not evidence of quality. Cockroaches survive too.

---

## 23. Final Modular Platform Acceptance Criteria

The modular platform is production-ready when:

```text
SchoolContext is enforced.
SchoolCore contracts exist and are used by controllers.
IslamicSundaySchool is isolated as extension layer.
Finance file access is payment-scoped and authorized.
Finance payment mutation is transactional and audited.
Attendance scanner is idempotent and service-owned.
Student identifier generation is race-safe.
Student lifecycle behavior is service-owned.
Communication bulk sends require preview and dedupe.
Reporting consumes read models/domain truth.
Controllers are adapters.
Architecture tests and CI gates are active.
Route inventory and OpenAPI docs are current.
Cross-school access tests pass.
Sensitive data access is audited.
Legacy unsafe routes are removed or disabled.
Production monitoring is active.
Rollback plans are tested.
```

---

## 24. Implementation Tickets

## REL-001: Create feature flag rollout map

### Description

Define module flags, owners, default states, rollout scope, and removal dates.

### Acceptance Criteria

```text
- All high-risk modules have flags.
- Flags support school/domain rollout.
- Each flag has owner and removal target.
- Flag state is auditable.
```

---

## REL-002: Create migration validation scripts

### Description

Create validation scripts for finance, attendance, students, communication, and reporting.

### Acceptance Criteria

```text
- Scripts run in staging.
- Scripts compare pre/post counts.
- Scripts detect cross-school anomalies.
- Finance validation includes balance totals.
```

---

## REL-003: Add shadow comparison jobs

### Description

Add jobs or commands to compare legacy and modular outputs.

### Acceptance Criteria

```text
- Finance balance comparison exists.
- Attendance scanner comparison exists.
- Communication recipient comparison exists.
- Reporting comparison exists.
- Output includes mismatch details.
```

---

## REL-004: Build production monitoring dashboards

### Description

Create dashboards and alerts for modular rollout.

### Acceptance Criteria

```text
- Platform metrics visible.
- Finance alerts configured.
- Attendance alerts configured.
- Communication alerts configured.
- Reporting/export alerts configured.
- SchoolContext failures visible.
```

---

## REL-005: Create rollback playbooks

### Description

Create module-specific rollback procedures.

### Acceptance Criteria

```text
- Finance rollback playbook exists.
- Attendance rollback playbook exists.
- Student rollback playbook exists.
- Communication rollback playbook exists.
- Reporting rollback playbook exists.
- Rollback tested in staging.
```

---

## REL-006: Run security readiness review

### Description

Validate authorization, file access, report exports, extension routes, and sensitive fields.

### Acceptance Criteria

```text
- Cross-school tests pass.
- Sensitive Islamic Sunday School fields protected.
- Payment file access protected.
- Bulk send protected.
- Report export protected.
```

---

## REL-007: Run performance readiness review

### Description

Baseline key endpoint and job performance.

### Acceptance Criteria

```text
- Scanner latency acceptable.
- Payment mutation latency acceptable.
- Recipient preview performance acceptable.
- Report/export performance acceptable.
- Slow query risks documented.
```

---

## REL-008: Complete UAT scenarios

### Description

Run scenario-based UAT for admin, finance, attendance, students, communication, reporting, and Islamic Sunday School extension.

### Acceptance Criteria

```text
- UAT scenarios completed.
- P0/P1 defects fixed or rollout blocked.
- Islamic Sunday School owner signs off extension workflows.
```

---

## REL-009: Prepare support and training material

### Description

Create guides and support playbooks.

### Acceptance Criteria

```text
- Admin guide exists.
- Finance guide exists.
- Attendance/scanner guide exists.
- Communication guide exists.
- Reporting/export guide exists.
- Islamic Sunday School guide exists.
- Support escalation playbook exists.
```

---

## REL-010: Execute pilot rollout

### Description

Enable modular features for a controlled pilot scope.

### Acceptance Criteria

```text
- Pilot school/tenant selected.
- Flags enabled progressively.
- Monitoring reviewed daily during pilot.
- Reconciliation passes.
- No unresolved P0/P1 defects.
```

---

## REL-011: Execute Islamic Sunday School production rollout

### Description

Roll out Islamic Sunday School extension with core modular services.

### Acceptance Criteria

```text
- islamic_sunday_school domain profile enabled.
- Extension routes active.
- Qur'an/Arabic/Islamic studies/halaqa workflows validated.
- Masjid family/community reports validated.
- Sensitive permissions verified.
```

---

## REL-012: Remove legacy unsafe routes

### Description

Disable or remove legacy routes that are unsafe or superseded.

### Acceptance Criteria

```text
- filename-based payment file route removed/disabled.
- blind bulk send route removed/disabled.
- unsafe student identifier path removed.
- legacy scanner mutation path removed/disabled.
- deprecated routes have replacements.
```

---

## REL-013: Complete post-release review

### Description

Review rollout metrics, incidents, support tickets, and cleanup items.

### Acceptance Criteria

```text
- Post-release report exists.
- Follow-up tickets created.
- Regression tests added for incidents.
- Legacy removal schedule updated.
```

---

## 25. Rollout Timeline Template

Use this as a planning template, not a divine prophecy.

```text
Week 1:
  - finalize flags
  - complete validation scripts
  - run staging migrations

Week 2:
  - run shadow comparisons
  - fix mismatches
  - complete monitoring dashboards

Week 3:
  - complete security/performance readiness
  - complete UAT
  - prepare support docs

Week 4:
  - pilot rollout
  - monitor and reconcile
  - patch defects

Week 5:
  - Islamic Sunday School production rollout
  - monitor and reconcile
  - freeze unsafe legacy paths

Week 6:
  - broader rollout
  - remove/deprecate legacy routes
  - post-release review
```

Actual timing depends on defect count, data quality, team size, and how many legacy surprises crawl out from under the floorboards.

---

## 26. Definition of Done for Phase 10

Phase 10 is done when:

```text
- Feature flag rollout map exists.
- Migration validation scripts exist.
- Shadow comparison jobs exist for high-risk modules.
- Production dashboards and alerts exist.
- Rollback playbooks exist and are tested in staging.
- Security readiness review is complete.
- Performance readiness review is complete.
- UAT scenarios are complete.
- Support/training materials exist.
- Pilot rollout completed successfully.
- Islamic Sunday School production rollout completed successfully.
- Legacy unsafe routes are removed or disabled.
- Post-release review is complete.
- Follow-up cleanup tickets are created.
```

---

## 27. Non-Goals

Do not include in Phase 10:

```text
- brand-new feature development
- major UI redesign
- full external SIS integration
- full analytics warehouse
- provider migration unrelated to modular rollout
- complete rewrite of all legacy modules
- speculative optimizations without measured bottlenecks
```

Phase 10 is about safe release, not ambition cosplay.

---

## 28. Main Risks

### Risk: data migration corrupts production data

Mitigation:

```text
- additive migrations
- backups
- validation scripts
- staging rehearsal
- rollback/forward-fix plan
```

### Risk: modular and legacy paths diverge

Mitigation:

```text
- shadow comparisons
- compatibility adapters
- feature flags
- mismatch reports
```

### Risk: finance balances differ

Mitigation:

```text
- finance reconciliation
- BalanceCalculator comparison
- manual review threshold
- rollback flag
```

### Risk: scanner disruption

Mitigation:

```text
- rollout outside active session
- scanner latency monitoring
- duplicate scan monitoring
- legacy scanner fallback flag
```

### Risk: accidental communication blast

Mitigation:

```text
- preview required
- confirmation token
- idempotency
- send limit/rate controls
- pilot audience first
```

### Risk: Islamic Sunday School extension leaks sensitive data

Mitigation:

```text
- explicit permissions
- extension route middleware
- sensitive export audit
- UAT with domain owner
```

### Risk: team leaves feature flags forever

Mitigation:

```text
- flag removal dates
- post-release cleanup tickets
- release gate warning on expired flags
```

---

## 29. Immediate Next Work Queue

Start here:

```text
1. REL-001 Create feature flag rollout map
2. REL-002 Create migration validation scripts
3. REL-003 Add shadow comparison jobs
4. REL-004 Build production monitoring dashboards
5. REL-005 Create rollback playbooks
6. REL-006 Run security readiness review
7. REL-007 Run performance readiness review
8. REL-008 Complete UAT scenarios
9. REL-009 Prepare support and training material
10. REL-010 Execute pilot rollout
11. REL-011 Execute Islamic Sunday School production rollout
12. REL-012 Remove legacy unsafe routes
13. REL-013 Complete post-release review
```

Start with flags, validation, and rollback. If you cannot turn it off, prove it, and recover from it, you are not ready to ship it. You are ready to gamble with extra steps.
