mxaccessgw/code-reviews/prompt.md

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.