// API class validation rules for Scopy plugins. Auto-loads when reviewing or editing `*_api.h` / `*_api.cpp` files or running API quality checks.
| name | api-quality-checks |
| description | API class validation rules for Scopy plugins. Auto-loads when reviewing or editing `*_api.h` / `*_api.cpp` files or running API quality checks. |
Apply these 7 validation categories when reviewing or generating API classes for Scopy plugins.
ApiObjectQ_OBJECT macro is present in the class bodySCOPY_<PLUGIN>_EXPORT) is on the class declaration<Plugin>Plugin * as its sole argumentfriend class <Plugin>_API is declared in the plugin headerm_api is declared as <Plugin>_API *m_api = nullptr; in the plugin headerinitApi() is declared in the plugin headerinitApi() is the last call in onConnect() before return truedelete m_api; m_api = nullptr; is the first statement in onDisconnect()ScopyJS::GetInstance()->registerApi(m_api) is called inside initApi()m_api->setObjectName("<name>") uses a lowercase, short name consistent with similar plugins.cpp file ends with #include "moc_<plugin>_api.cpp"Q_INVOKABLE method null-checks plugin/instrument members before accessing themreadFromWidget() / writeToWidget() null-check m_widgetGroup before useCross-reference the tool's IIOWidget lambdas to verify:
" dB"): getter strips the suffix before returning20*log10(1/linear) rounded to int; setter applies pow(10, -val/20)QStringList before calling writeToWidgetgetTools() method is presentreadWidget() / writeWidget() helpers are presentreadFromWidget(const QString &key) and writeToWidget(const QString &key, const QString &value) are declared as private helpersm_plugin->m_widgetGroup before accessing itQString; setter parameters use const QString &friend class insteadget<Attribute>() / set<Attribute>()Guidelines for using Context7, web search, and other research tools to find solutions outside the Scopy codebase. Loaded when the task involves unfamiliar technology or external libraries.
Core Scopy architecture knowledge including plugin lifecycle, library dependencies, build system, and key design patterns. Loaded by clarify-task and design-task commands.
How Scopy libraries depend on each other, plugin commonalities, MessageBroker topics, shared widgets, style system flow, and build system relationships. Loaded when determining component interactions or change impact.
Decision trees for common Scopy architectural choices - plugin vs core, tool vs section, widget type selection, sync vs async, GNU Radio vs direct, package organization, and API exposure. Loaded when making design decisions.
Catalog of all Scopy development tools including package generator, testing tools, CI scripts, format/license scripts, and dev plugin commands. Loaded when analyzing what tools exist for a task.
Code patterns and examples for Scopy IIOWidget unit tests. Covers standard helpers, data-driven testing, and complex multi-step scenarios. Auto-loads when creating or reviewing `*_Unit_test.js` files.