Added Plugin and Interface rules for Thunder QA#286
Added Plugin and Interface rules for Thunder QA#286workkavint-ship-it wants to merge 15 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces an OpenSpec change bundle for a proposed “Thunder PluginQA” system, adding specification and planning documents for plugin/interface rule validation and CSV report generation.
Changes:
- Added OpenSpec configuration plus a new change package (
openspec/changes/thunder-plugin-qa/) containing proposal, design, tasks, and specs. - Added detailed rule reference documents for Thunder plugin rules (v3.3.0) and Thunder interface validation rules.
- Added a report-generation spec describing CSV output formats for plugin and interface validation runs.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 16 comments.
Show a summary per file
| File | Description |
|---|---|
| openspec/config.yaml | Adds baseline OpenSpec configuration stub (schema + optional context/rules sections). |
| openspec/changes/thunder-plugin-qa/tasks.md | Adds a comprehensive implementation task breakdown for the PluginQA system. |
| openspec/changes/thunder-plugin-qa/specs/reports/spec.md | Defines CSV report requirements/formatting for plugin & interface review outputs. |
| openspec/changes/thunder-plugin-qa/specs/plugin/Thunder-plugin-rules.md | Adds the plugin rules reference document (v3.3.0) with 79 rules and examples. |
| openspec/changes/thunder-plugin-qa/specs/plugin/spec.md | Adds the plugin validation delta/spec (folder structure, setup script behavior, rule loading). |
| openspec/changes/thunder-plugin-qa/specs/interface/Thunder-interface-rules.md | Adds the interface validation rules reference document (core + advisory rules). |
| openspec/changes/thunder-plugin-qa/specs/interface/spec.md | Adds the interface validation + plugin generation delta/spec (commands, setup, rule updates). |
| openspec/changes/thunder-plugin-qa/proposal.md | Adds the PluginQA proposal and delivery structure overview. |
| openspec/changes/thunder-plugin-qa/design.md | Adds the architecture/design document describing prompts, rule loading, reporting, and setup. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
…rdkcentral/ThunderTools into spec/plugin-qa-tool-integration
MFransen69
left a comment
There was a problem hiding this comment.
Not conclusive yet, this is how far we got up to now
|
|
||
| **Description:** | ||
| Thunder interface headers must follow the standard file and namespace structure: | ||
| - File must be in `ThunderInterfaces/interfaces/` (or `qa_interfaces/` for QA) |
There was a problem hiding this comment.
will not work for entservices
| 4. Check for any non-declaration code (function implementations, static variables, etc.) | ||
|
|
||
| **Verification Logic:** | ||
| 1. Verify the file is inside the `WPEFramework::Exchange` namespace |
| **Verification Logic:** | ||
| 1. Verify the file is inside the `WPEFramework::Exchange` namespace | ||
| 2. Verify the primary interface struct name matches the file name (e.g. `IDictionary` in `IDictionary.h`) | ||
| 3. Verify there is no implementation code — only forward declarations, typedefs, struct/enum declarations |
|
|
||
| ### rule_37 | ||
|
|
||
| **No Hardcoded Numeric Tuning Parameters** | `violation` |
| | [rule_38](#rule_38) | CXX_STANDARD Uses Thunder Variable | violation | CMake | | ||
| | [rule_39](#rule_39) | COM Methods Return Core::hresult | violation | COM Interface | | ||
| | [rule_40](#rule_40) | #pragma once (all headers) | suggestion | Conventions | | ||
| | [rule_41](#rule_41) | Apache 2.0 Copyright Header | suggestion | Conventions | |
| | [rule_39](#rule_39) | COM Methods Return Core::hresult | violation | COM Interface | | ||
| | [rule_40](#rule_40) | #pragma once (all headers) | suggestion | Conventions | | ||
| | [rule_41](#rule_41) | Apache 2.0 Copyright Header | suggestion | Conventions | | ||
| | [rule_42](#rule_42) | STL Types | warning | Code Quality | |
There was a problem hiding this comment.
Let's not have this rule
| | [rule_40](#rule_40) | #pragma once (all headers) | suggestion | Conventions | | ||
| | [rule_41](#rule_41) | Apache 2.0 Copyright Header | suggestion | Conventions | | ||
| | [rule_42](#rule_42) | STL Types | warning | Code Quality | | ||
| | [rule_43](#rule_43) | ASSERT vs Error Handling | warning | Code Quality | |
There was a problem hiding this comment.
Let's not have this rule
| | [rule_41](#rule_41) | Apache 2.0 Copyright Header | suggestion | Conventions | | ||
| | [rule_42](#rule_42) | STL Types | warning | Code Quality | | ||
| | [rule_43](#rule_43) | ASSERT vs Error Handling | warning | Code Quality | | ||
| | [rule_44](#rule_44) | OOP Registration Order | violation | Lifecycle Integrity | |
There was a problem hiding this comment.
This needs more investigation, remove for now
sebaszm
left a comment
There was a problem hiding this comment.
Many good rules, some perhaps overly strict or non-thunder related.
| **Description:** | ||
| Thunder interface headers must follow the standard file and namespace structure: | ||
| - File must be in `ThunderInterfaces/interfaces/` (or `qa_interfaces/` for QA) | ||
| - Interface must be declared inside the `WPEFramework::Exchange` namespace |
There was a problem hiding this comment.
Or Thunder::Exchange in Thunder 5.x
| **Description:** | ||
| Thunder COM interfaces must follow the correct declaration shape: | ||
| - Must be a struct (not class) with the `EXTERNAL` macro | ||
| - Must inherit virtually from `Core::IUnknown` (or from another Thunder interface) |
There was a problem hiding this comment.
Must not inherit from any other interface than Core::IUnknown!
| **Severity:** violation | ||
|
|
||
| **Description:** | ||
| In Thunder 5.0+, all COM interface methods annotated with `@json` (i.e. methods that generate JSON-RPC code) MUST return `Core::hresult`. Void return types and other return types are not allowed for JSON-RPC-generating methods. Methods in pure COM interfaces (no `@json`) should also use `Core::hresult` for error reporting where applicable. |
There was a problem hiding this comment.
Except for notification methods which are required to have void return type.
|
|
||
| **JSONRPC Inheritance When Used** | `violation` | *Conditional: skip if plugin registers no JSON-RPC handlers* | ||
|
|
||
| **What to check:** If the plugin registers JSON-RPC handlers (`Register()` calls in `Initialize()`), the plugin class must inherit `PluginHost::JSONRPC`. |
There was a problem hiding this comment.
Or PluginHost::JSONRPCSupprotsStatusListener or others...
|
|
||
| --- | ||
|
|
||
| ### rule_74 |
There was a problem hiding this comment.
same comment as for rule 61
|
|
||
| --- | ||
|
|
||
| ### rule_76 |
There was a problem hiding this comment.
Not sure what this rule is about. Why would you need a wrapper for OOP calls? Even though changing the result could be part of the logic.
|
|
||
| --- | ||
|
|
||
| ### rule_78 |
There was a problem hiding this comment.
This rule should not be needed, the registration is normally done via JSON-RPC glue code.
sebaszm
left a comment
There was a problem hiding this comment.
Looks like good to go for a first spin!
fee8994
PR Summary
This PR adds the rule reference documents that will be used as the basis for the automated Thunder QA checks:
If you think a rule should be added, removed, reworded, or have its severity changed, please edit the relevant .md file and push to this branch.