# Operations Legacy Parity Contract — Phase 10.11

## Scope closed by this phase

The exact selected-branch legacy function `popr_s` / `get_patients_operations_s` is recovered in two modes:

1. Full year versus comparison year.
2. Custom date range versus the same month/day window shifted to the comparison year.

The exact legacy count contract is:

- Source: `RCP_SERVICE_RESERVATION`.
- Joined to: `OPER_OPERATION_SCHEDULE` by `SER`.
- Inclusion rule: `RCP_SERVICE_RESERVATION.SERVSTATUS <> 'C'`.
- Time axis: `EXPECTEDDONEDATE`.
- Monthly grouping by calendar month.
- Selected branch is provided by the active database connection / hospital context.

## Independent comparison paths

- Legacy path: `LegacyOperationsRepository::monthlyPatientOperations`.
- Current path: `OperationsRepository::monthlyLegacyOperations`.

The legacy path executes its own SQL and does not call `OperationsRepository`.

## Exact live parity gate

Two runtime comparisons must pass with zero difference:

- `YEAR / popr_s`
- `DATE RANGE / popr_s`

For each mode:

- current-period total difference = 0
- comparison-period total difference = 0
- maximum monthly difference = 0

## Additional executive recovery

The Operations workspace also exposes:

- scheduled / non-cancelled operations using the exact legacy `popr_s` rule
- performed operations (`SERVSTATUS = 'D'`)
- cancelled operations (`SERVSTATUS = 'C'`)
- completion rate
- monthly trends
- top specialties
- top doctors
- operating-room activity when the Oracle schema exposes a recognized room column

These additional views enrich the executive workspace but do not redefine the legacy `popr_s` parity contract.

## Explicitly not closed

The legacy `popr` function aggregates three database branches in one response. Phase 10.11 does not claim full multi-branch `popr` parity; that item remains `PARTIAL` until a dedicated three-branch comparison gate is executed.

## Write safety

Phase 10.11 parity and browser QA are read-only. No Oracle write operation is required.
