cms doctor: the vtex CLI content plugin resolves `vtex` from the wrong root and dies with MODULE_NOT_FOUND

[JonasJesus42]

Symptom

Every vtex content … command fails before doing anything:

$ vtex content generate-schema cms/faststore/components cms/faststore/pages -o cms/faststore/schema.json
Error: Cannot find module 'vtex'
Require stack:
- ~/.local/share/vtex/node_modules/@vtex/cli-plugin-content/build/commands/content/generate-schema.js
- <nvm>/lib/node_modules/vtex/node_modules/@oclif/config/lib/plugin.js
...
Code: MODULE_NOT_FOUND

Cause

The oclif user-plugin install tree and the CLI itself live in different roots:

• plugin: ~/.local/share/vtex/node_modules/@vtex/cli-plugin-content
• CLI: <nvm>/lib/node_modules/vtex

@vtex/cli-plugin-content does require('vtex') at runtime, and Node resolves upward from the plugin's own directory — where vtex is not a sibling. It only works when the CLI happens to be installed somewhere the plugin can reach, which nvm-managed globals break.

Workaround

ln -sfn "$(npm root -g)/vtex" ~/.local/share/vtex/node_modules/vtex

Why this belongs here

Two reasons:

1. Every FastStore migration hits it the first time it touches the CMS, and the error names @oclif/config five times and the real cause zero times — it reads like a corrupt CLI install, so the instinct is to reinstall, which does not fix it.
2. It is exactly the class of environment breakage parity cms doctor is for. Doctor already verifies the vtex login session (✓ jonas.jesus@electrolux.com on electroluxecfaststore · expires in 24h); adding a check that the content plugin actually loads, with the symlink as the suggested fix, costs one vtex content --help and saves the whole detour.

Related: #343 (parity should own schema upload, which would make the plugin optional), #324.