|
| 1 | +# Agent-Review Checklist (T4 enforcement) |
| 2 | + |
| 3 | +The tier-4 gate from [architectural-requirements.md](../architectural-requirements.md) §*Quality |
| 4 | +attributes and enforcement*. It enforces the **semantic** architectural requirements — the ones no |
| 5 | +compiler or linter can express — by having an LLM reviewer judge a diff against each item. Run it as |
| 6 | +a CI step on every change (and locally before pushing). |
| 7 | + |
| 8 | +## How to run |
| 9 | + |
| 10 | +Input: the change under review (a diff / PR / working tree). For **each** checklist item, output one |
| 11 | +of: |
| 12 | + |
| 13 | +- `PASS` — the change plainly complies (or the item doesn't apply). |
| 14 | +- `FLAG — <file>:<line> — <one-line reason>` — a clear violation. |
| 15 | +- `QUESTION — <file>:<line> — <what to check>` — plausibly a violation but genuinely a judgment call; |
| 16 | + escalate to human review (T5), don't block on it. |
| 17 | + |
| 18 | +Ground rules: |
| 19 | + |
| 20 | +1. **Precision over recall.** Only `FLAG` on a clear violation; when unsure, `QUESTION`. A noisy gate |
| 21 | + gets ignored. |
| 22 | +2. **Judge only what static checks miss.** The compiler, `clang-tidy`, and `check-architecture.sh` |
| 23 | + already cover the mechanical rules; you cover *semantics* (intent, logic, duplication). |
| 24 | +3. **Respect the ledgers.** Couplings already recorded in |
| 25 | + [architecture-exceptions.md](../architecture-exceptions.md) or names in |
| 26 | + [naming-exceptions.md](../naming-exceptions.md) are known — don't re-flag them; flag only *new* |
| 27 | + deviations, and propose them as new ledger rows. |
| 28 | +4. **Scope to the diff.** Review what the change adds or moves, not the whole pre-existing tree. |
| 29 | + |
| 30 | +## Checklist |
| 31 | + |
| 32 | +**[AR-ORG-VIS-SPLIT] Does protocol/model code contain visualization or instrumentation logic?** |
| 33 | +FLAG if a protocol/mobility/physical module draws on a canvas, builds a figure, or references a |
| 34 | +visualizer beyond emitting a signal. *Not a violation:* emitting a `@signal` that a visualizer |
| 35 | +consumes from outside. |
| 36 | + |
| 37 | +**[AR-ORG-KERNEL] Does the change reimplement or patch an OMNeT++ kernel facility inside INET?** |
| 38 | +FLAG a private reimplementation of event scheduling, RNG, suspend/resume, breakpoints, or a hand-patch |
| 39 | +of kernel internals. *Not a violation:* consuming a kernel API, or a documented shim with a linked |
| 40 | +upstream issue. |
| 41 | + |
| 42 | +**[AR-MOD-COMPOSITION] Is new behavior added by composition, or by inheritance / a growing god-module?** |
| 43 | +FLAG a new deep inheritance chain, or a simple module/class that accretes several unrelated |
| 44 | +responsibilities. *Not a violation:* extending a `*Base` for genuine shared machinery. |
| 45 | + |
| 46 | +**[AR-COM-SOCKETS] Does a new application talk to a transport protocol via raw messages?** |
| 47 | +FLAG an app that hand-rolls command/indication messages instead of using `UdpSocket`/`TcpSocket`/peer. |
| 48 | +*Not a violation:* a new protocol implementing the socket-facing side. |
| 49 | + |
| 50 | +**[AR-COM-DIRECT] Is a zero-time message standing in for a direct call?** |
| 51 | +FLAG `scheduleAt(simTime(), …)` or a zero-delay `send()` used for same-instant, same-node coordination |
| 52 | +between sibling submodules. *Not a violation:* a message that advances simulation time or crosses the |
| 53 | +medium. |
| 54 | + |
| 55 | +**[AR-OBS-NED-TRUTH] Does prose/code duplicate what a NED declaration owns?** |
| 56 | +FLAG doc text that restates parameters/gates/signals/statistics already in NED, or C++ that hardcodes a |
| 57 | +value that should be a NED parameter. *Not a violation:* referencing the NED declaration. |
| 58 | + |
| 59 | +**[AR-OBS-INTROSPECTION] Does a new protocol ship its introspection support?** |
| 60 | +FLAG a new protocol header/chunk added without a registered serializer, dissector, and printer. |
| 61 | +(Partly covered by a completeness test; you catch the "registered but empty/incorrect" case.) |
| 62 | + |
| 63 | +**[AR-CFG-INFER / DRY] Is a derivable fact restated instead of inferred?** |
| 64 | +FLAG a manually configured value that the model could infer (e.g. interface counts), or the same |
| 65 | +constant/parameter duplicated across sites instead of set once and propagated. |
| 66 | + |
| 67 | +**[AR-CFG-PARAMS] Are new parameters/fields well-formed?** |
| 68 | +FLAG a physical-quantity parameter without `@unit`, a parameter without a `default()`, or one field |
| 69 | +that means both "user override" and "computed value." *Not a violation:* a dimensionless count. |
| 70 | + |
| 71 | +**[AR-EXT-NOCORE] Does adding a protocol require editing core code?** |
| 72 | +FLAG a change that adds a protocol by modifying `common/` or a dispatcher/registry switch, rather than |
| 73 | +registering through existing contract/registration points. |
| 74 | + |
| 75 | +**[AR-BUILD-DECLARATIVE] Are build values hardcoded?** |
| 76 | +FLAG absolute machine paths, `-march=native`, or per-machine flags baked into build scripts instead of |
| 77 | +declared in the build descriptors. |
| 78 | + |
| 79 | +**[AR-QUAL-NAMING] Do new NED/`.msg`/semantic names follow the conventions?** |
| 80 | +FLAG names that break [naming-conventions.md](../naming-conventions.md) on the NED/message side that |
| 81 | +`clang-tidy` can't see (wrong role suffix, `Msg`/`Message` packet, abbreviated field). Propose new |
| 82 | +findings as `naming-exceptions.md` rows. |
| 83 | + |
| 84 | +**[AR-QUAL-LOGGING] Is a programming error logged instead of thrown?** |
| 85 | +FLAG a violated invariant / impossible state that is written to the log and execution continues, where |
| 86 | +it should `throw`/`ASSERT`/`check_and_cast`. *Not a violation:* informational logging. |
| 87 | + |
| 88 | +**[AR-QUAL-TESTS] Does the change ship with tests matching its nature?** |
| 89 | +FLAG new behavior with no accompanying unit/module/statistical/validation test (fingerprints alone |
| 90 | +detect *that* behavior changed, not *whether it is correct*). |
| 91 | + |
| 92 | +**[AR-QUAL-DISPLAY] Does a new module have a distinguishing icon?** |
| 93 | +FLAG a new module type with no `@display("i=…")`, or one reusing a generic catch-all icon for a |
| 94 | +semantically distinct role. |
| 95 | + |
| 96 | +## Output footer |
| 97 | + |
| 98 | +End with a one-line verdict: `REVIEW: n PASS, n FLAG, n QUESTION` and, for any `FLAG`, a suggested |
| 99 | +ledger row (`AV-*` or `NV-*`) so the finding lands in the backlog rather than being lost. |
0 commit comments