# Legacy Source Coverage and Evidence Boundary

## What is proven

Phase 10.8 inventories **31 legacy dispatcher functions** evidenced by the user-provided legacy `files/funcations.php` excerpt. The dispatcher exposes the function keys, called legacy function names, shared filter parameters, branch behavior, and several full SQL bodies.

The legacy revenue page excerpt also proves five revenue panels and their filter modes: year, compare year, and custom date range with the same-year date-range guard.

## What is not present in the supplied ddb-new archive

The complete original legacy site archive is not contained in `ddb-new.zip`. Therefore Phase 10.8 does not invent missing SQL or silently declare parity. Rows whose exact business rule is not fully available are marked with an explicit source-detail status and remain `PARTIAL` or `MISSING`.

## Acceptance rule

A legacy capability may become `PARITY_PASS` only after all of the following are proven:

1. Old function identified.
2. Old business rule and Oracle source documented.
3. Old filters documented.
4. New implementation mapped.
5. Same hospital and same input period executed.
6. Old and new results compared.
7. Difference is zero, or a documented replacement is formally approved.
8. Permission parity verified.
9. Evidence ZIP produced.

## Priority consequence

No new workflow expansion should displace legacy migration work until the master matrix is closed. The immediate next functional phase is Revenue Legacy Functional Parity.

## Phase 10.12 source recovery update

The exact legacy bodies for `get_lab_tests`, `get_rad_tests`, `get_lab_tests_s`, and `get_rad_tests_s` are now available. Phase 10.12 implements the selected-branch contracts `plts_s` and `prts_s` with independent legacy execution paths and exact year/date-range parity gates. The three-branch aggregate functions `plts` and `prts` remain `PARTIAL` until exact multi-branch parity is proven.
