Files
lmxopcua/code-reviews/prompt.md
Joseph Doherty 76d35d1b9f chore: add per-module code review process and tracking infra
Adapts the code-review procedure, folder layout, template, and tooling
from the sibling mxaccessgw repo to lmxopcua.

- REVIEW-PROCESS.md: per-module review workflow — a module is one src/
  or tests/ project (ZB.MOM.WW.OtOpcUa. prefix stripped); 10-category
  checklist; finding IDs/severities/statuses; re-review rules.
- code-reviews/_template/findings.md: per-module findings template.
- code-reviews/regen-readme.py: generates the cross-module README.md
  index from the per-module findings.md files; --check gates staleness
  and consistency.
- code-reviews/test_regen_readme.py: dependency-free generator tests.
- code-reviews/prompt.md: orchestration prompt for clearing the backlog.
- code-reviews/README.md: generated index (no modules reviewed yet).
- scripts/check-code-reviews-readme.ps1: CI / pre-commit check wrapper.

Adapted to this repo: ZB.MOM.WW.OtOpcUa module naming, OtOpcUa
conventions checklist (in-process GalaxyDriver + mxaccessgw,
contained-name vs tag-name, ACL at DriverNodeManager), single .NET
solution build/test commands, and the lmxopcua design docs.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-22 04:08:47 -04:00

4.1 KiB

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 workflow in REVIEW-PROCESS.md.

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/ — one src/ project or one tests/ project, named with the ZB.MOM.WW.OtOpcUa. prefix stripped. The module→project mapping is in REVIEW-PROCESS.md section 1; the build/test commands are in CLAUDE.md ("Build 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.)
  • The regression test belongs in the reviewed project's own test project — a finding in src/.../ZB.MOM.WW.OtOpcUa.Driver.Galaxy gets its test in tests/.../ZB.MOM.WW.OtOpcUa.Driver.Galaxy.Tests.
  • Run that module's build and test suite and confirm it is green:
    • Build + unit-test the affected project, e.g. dotnet build src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Galaxy/... and dotnet test tests/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Galaxy.Tests/....
    • A single test: dotnet test --filter "FullyQualifiedName~MyClass.MyMethod".
    • *.IntegrationTests need their Docker fixture up — bring it up with lmxopcua-fix up <driver> <profile> (see CLAUDE.md "Docker Workflow"). DB-backed *.Configuration.Tests, *.Admin.Tests, and *.Server.Tests need the central SQL Server. If a fixture/service is unavailable, document why the suite was skipped rather than reporting it green.
    • For a change that crosses project boundaries, build each affected project; a whole-solution check is dotnet build ZB.MOM.WW.OtOpcUa.slnx.
  • 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 project. In particular do not review a src/ project and its matching *.Tests project in the same batch — a finding in the source project adds its regression test to that test project.

After each batch returns (orchestrator does this — keep your own context lean)

  • Build and test every project the batch touched, using the CLAUDE.md commands; confirm clean. For a wide change, dotnet build ZB.MOM.WW.OtOpcUa.slnx.
  • 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.