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>
54 lines
1.8 KiB
Markdown
54 lines
1.8 KiB
Markdown
# Code Review — <Module>
|
|
|
|
<!-- Template for a per-module findings file. Copy to code-reviews/<Module>/findings.md.
|
|
See ../../REVIEW-PROCESS.md for the full process. The base README.md is generated
|
|
from these files by regen-readme.py — do not edit README.md by hand. -->
|
|
|
|
| Field | Value |
|
|
|---|---|
|
|
| Module | `src/<area>/ZB.MOM.WW.OtOpcUa.<Module>` |
|
|
| Reviewer | <name> |
|
|
| Review date | <YYYY-MM-DD> |
|
|
| Commit reviewed | `<short-sha>` |
|
|
| Status | Not started |
|
|
| Open findings | 0 |
|
|
|
|
## Checklist coverage
|
|
|
|
A comprehensive review completes every category, recording "No issues found" where
|
|
a category produced nothing rather than leaving it blank.
|
|
|
|
| # | Category | Result |
|
|
|---|---|---|
|
|
| 1 | Correctness & logic bugs | _pending_ |
|
|
| 2 | OtOpcUa conventions | _pending_ |
|
|
| 3 | Concurrency & thread safety | _pending_ |
|
|
| 4 | Error handling & resilience | _pending_ |
|
|
| 5 | Security | _pending_ |
|
|
| 6 | Performance & resource management | _pending_ |
|
|
| 7 | Design-document adherence | _pending_ |
|
|
| 8 | Code organization & conventions | _pending_ |
|
|
| 9 | Testing coverage | _pending_ |
|
|
| 10 | Documentation & comments | _pending_ |
|
|
|
|
## Findings
|
|
|
|
<!-- One ### entry per finding. IDs are <Module>-NNN, sequential within the module,
|
|
never reused. Findings are never deleted — close them by changing Status and
|
|
completing Resolution. -->
|
|
|
|
### <Module>-001
|
|
|
|
| Field | Value |
|
|
|---|---|
|
|
| Severity | Critical / High / Medium / Low |
|
|
| Category | one of the 10 checklist categories |
|
|
| Location | `path/to/File.cs:NN` |
|
|
| Status | Open / In Progress / Resolved / Won't Fix / Deferred |
|
|
|
|
**Description:** What is wrong and why it matters.
|
|
|
|
**Recommendation:** Concrete suggested fix.
|
|
|
|
**Resolution:** _(empty until closed; on close, record the fixing commit SHA, the date, and a one-line description of the fix)_
|