Add code-reviews/prompt.md orchestration prompt

Reusable prompt for working the code-reviews/ backlog: batches one
subagent per module, TDD per finding, per-module commits, regenerates
the index. Adapted to mxaccessgw toolchains and module layout.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

code-reviews/prompt.md

@@ -0,0 +1,76 @@
+# Prompt — resolve open code-review findings
+
+Reusable orchestration prompt for clearing the `code-reviews/` backlog. Paste it
+to a fresh agent when you want the remaining findings worked through.
+
+---
+
+Resolve all open code-review findings (every severity), following the same
+workflow already used to resolve the Critical dashboard finding and the
+Client.Rust module (see git commits `a8aafdf`, `0d8a28d`, `9082e50`).
+
+## Setup
+
+- Read `code-reviews/README.md` for the open findings and `REVIEW-PROCESS.md`
+  for the workflow. Group the open findings by module.
+- A module is one folder under `code-reviews/` — a `src/MxGateway.*` project or
+  a `clients/` language client. The module→source mapping and the per-module
+  build/test commands are in `CLAUDE.md` (the "Source Update Workflow" table and
+  the per-client commands).
+
+## Dispatch — one general-purpose subagent per module, in batches of ~5 modules
+
+Each subagent, for every open finding in its assigned module, must:
+
+- Verify the finding's root cause against the actual source. Do NOT trust the
+  finding text — if it is wrong or misclassified, re-triage it (correct the
+  severity/description in that module's `findings.md`) instead of forcing a fix.
+- Use real TDD: write the regression test FIRST and run it to confirm it fails,
+  THEN implement the root-cause fix, THEN confirm it passes. (Do not use
+  `git stash` — parallel agents would race on the shared stash stack.)
+- Run that module's full build and test suite with the module-appropriate
+  toolchain and confirm it is green:
+  - `src/MxGateway.*` .NET projects — `dotnet build` + `dotnet test` for the
+    project; the Worker must build x86 (`-p:Platform=x86`).
+  - `clients/dotnet` — `dotnet build clients/dotnet/MxGateway.Client.sln` and its tests.
+  - `clients/go` — `gofmt`, `go build ./...`, `go test ./...`.
+  - `clients/rust` — `cargo fmt`, `cargo test --workspace`,
+    `cargo clippy --workspace --all-targets -- -D warnings`.
+  - `clients/python` — `python -m pytest`.
+  - `clients/java` — `gradle test`.
+- A regression test for a gateway-server finding belongs in `src/MxGateway.Tests`;
+  for a worker finding, in `src/MxGateway.Worker.Tests`. Adding a test there is
+  permitted even though it is a different module's source tree.
+- Update only that module's `code-reviews/<Module>/findings.md`: set each
+  resolved finding's Status to `Resolved` with a Resolution note describing the
+  fix (the orchestrator appends the fixing commit SHA), and update the header
+  "Open findings" count.
+- CONSTRAINTS: edit only the source and test files needed for the assigned
+  module's findings, plus that module's own `findings.md`. Do NOT edit
+  `code-reviews/README.md`. Do NOT commit. Do NOT touch another module's
+  `findings.md`.
+- Report a summary: each finding — root-cause confirmation, the fix, test names,
+  and any re-triage.
+
+Batch so that no two subagents in the same batch write to the same test project
+— e.g. do not run the `Server` and `Contracts` agents together, since both add
+regression tests under `src/MxGateway.Tests`.
+
+## After each batch returns (orchestrator does this — keep your own context lean)
+
+- Build and test every component the batch touched, using the `CLAUDE.md`
+  commands; confirm clean. For any .NET change, `dotnet build src/MxGateway.sln`.
+- Commit per module — one commit per module, message referencing the finding
+  IDs. Record the fixing commit SHA in each finding's Resolution.
+- Regenerate the index: `python code-reviews/regen-readme.py`, then
+  `python code-reviews/regen-readme.py --check` to confirm it is consistent;
+  stage `code-reviews/README.md`. (Use `python` — the bare `python3` alias on
+  this box resolves to the Windows Store stub and fails.) You may stage
+  `README.md` with each module's commit, or commit it once per batch after the
+  script runs.
+- Push.
+
+## Continue
+
+Continue batch by batch until all findings are Resolved or re-triaged. If a
+finding needs a design decision, skip it and surface it rather than guessing.