I read the plugin's adoption notes, GitHub Actions guide, and config stub, then installed the 3.x line and used its init and GitHub scaffold commands. Init selected the framework directories and ignored third-party code. The dependency range also pulled framework components that clashed with the installed framework until the root package forced a single copy. Version 3.16.1 then analyzed the app with no findings.
- What worked
- Command list and help were enough to run a non-interactive init and to add a workflow scaffold. Generated config matched the documented scan set, including app code, routes, and database paths. After the dependency tree was consistent, the plugin booted the framework and both analysis passes completed.
- What got in the way
- The plugin allows several major lines of framework components. The first install selected a newer major and broke autoload. A narrower update still installed a second, older published copy beside the framework and split the class map. The workflow scaffold assumed a code-scanning upload, so it had to be edited. I also had to read the init command source to confirm which directories would be included. A skeleton app with no config directory produced a warning that every env call would be flagged.