**Post-edit self-scan (required):**
Before reporting, mechanically scan whether your own edits introduced new problems. This scan is separate from closing review findings or plan obligations; its target is the diff your edits just created.
1. Scan for orphaned code. Search for parameters, variables, functions, exports, imports, and types that lost their callers or references through this edit, and delete them. When you added or changed branches, also check that no branch, parameter, or fallback became unreachable because every case is now absorbed. A parameter or option that every caller now fills with the same constant has outlived its purpose — fold the value into the definition and delete the parameter
2. Check dependency direction. For every import you added or changed, confirm it does not run against the layering rules the project declares (declaration comments, configuration, documentation). When you moved, renamed, or re-layered a module, check every import inside that module — the direction can change even though the import statements did not. When an import against that direction seems necessary, do not add it — reconsider which layer the implementation belongs to
3. For every module whose import, export, callee, or call site you added or changed, search the repository for matching module mocks and test doubles: `vi.mock`, `jest.mock`, `mock.module`, provider-specific module mocks, spies, stubs, fakes, mock factories, fixtures, and shared test helpers. Inspect every test file that defines a matching mock or double, and confirm that each preserves the changed signature, return shape, error behavior, and side effects. Do not turn this into a sweep of every consumer that merely imports the module.
4. Through the project's test script (for example `npm test -- <test-file>`), run the test files that define the matching mocks or doubles and the classified test files that directly own the changed behavior, including the canonical/shared fix path where applicable. Do not substitute a direct Vitest invocation or require every importing consumer test. If an integration or heavy test was changed, also run the required classification/wiring test (`npm test -- src/__tests__/releaseVerificationWiring.test.ts`) and the targeted test; record command, exit status, and result. When a fix invalidates verification results you already collected (build, tests, recorded evidence), rerun the affected verification before reporting.
Fix the problems this scan finds that fall within what this step is allowed to edit, within the current edit. Do not fix problems outside that boundary (such as production code seen from a test-only step) — record them in your report instead. Record the scanned modules, matching mock/double test files, directly owning classified test files, commands, and outcomes in one line of your report.