Reference
Use the Guide to build a plugin and this section to check exact fields, flags, defaults and boundaries. The target and capability map is the short route to all five built-in outputs and the functionality they can project.
The generated matrices are not another manually curated compatibility list. Their dated source
links explain the recorded behavior. supported, degraded, unavailable and prohibited
are feature judgments; an unperformed account-dependent runtime test is a separate verification
limit. Consult the actual component and client/version rather than assuming one host-level badge
covers every operation.
For authoring patterns, use Reuse the framework: one tool with CLI and App surfaces, canonical schemas, semantic/plain hooks, request dependencies, state, payloads and installation. Custom server factories and raw native documents remain advanced integration paths, not the minimum code required for a plugin.
Reading the diagnostics
A structured diagnostic identifies a code, severity, message and, when available, source path and recovery. Read the current command's final outcome as well: a parser usage error, a failing or inconclusive eval, and an invalid inspection model are different failure paths.
Only an error diagnostic gates the diagnostic-based checks. Options such as --strict can
promote applicable host-tool warnings to errors, so do not discard a nonzero result merely
because an earlier unpromoted warning was informational to your workflow. Exact command
behavior is in CLI exit codes.
These families are navigation, not a replacement for the full generated diagnostic reference. Correct the owning declaration or input; do not change generated manifest fields, invent missing runtime evidence, or widen native permissions to suppress a failure.