PQA008 — Custom function overrides system function

A custom_functions: entry has the same name as a framework function; the custom definition wins.

The generator resolves a function name against the adapter's custom_functions: first, then the framework catalogue. A name present in both means the adapter's definition is used and the framework one is not.

Why this is reported

The shadowing is invisible at the call site. A device type declaring Door reads identically whether it gets the framework door or a private one, while the states, events and commands behind it differ.

Shared meaning is the point of the catalogue. A door that reports its own state vocabulary breaks every consumer that was written against the framework's — rules, UI, reporting, and other adapters' behaviour on the same screen.

It is usually an accident of naming. A vendor term collides with a framework term and the collision is only visible here.

How to fix it

Rename the custom function to something the catalogue does not use, ideally carrying the vendor's own term.

Or drop it and use the framework function, when the capability is genuinely the same thing under a different name.

If the framework definition is inadequate for a capability that recurs across vendors, the fix belongs in the catalogue, not in a private override — raise it.

If you disagree with a report

Do not suppress it. A wrong report is a bug in the check — report it with the YAML that triggered it.