Validate model short_description length in the CLI and schema

[Nicolas Palpacuer (NickPPC)]

Summary

Check model short_description length on the client side, so modules catch it in CI instead of when a release fails. app.viam.com rejects descriptions over 100 characters, but only the server checks this. Today modules find out when viam module update fails mid-deploy (e.g. beanjamin).

Changes

• New offline viam module validate: needs no credentials, so any module's PR CI can run it against meta.json
• module update / module upload fail before the RPC: same check, with an error that names every offending model
• Schema field fixed: the model field was documented as description, but the CLI reads short_description. It now has maxLength: 100, so editors that apply $schema flag long descriptions as you type
• Same byte count as the server: the CLI uses len(), like app. JSON Schema counts code points, so the two only differ for non-ASCII text

Testing

• go test ./cli -run 'TestValidateManifestLimits|TestValidateModuleAction': covers the limit boundary, several offending models, and the command end to end without auth

Claude Code prompts used

• "Hi Claude, we just got this error in CD: https://github.com/viamrobotics/beanjamin/actions/runs/36877394749/job/110422025513. We have seen this before and it is inconvenient that we discover this only after a new release is attempted. Could we add something in our CI to check for this? Given that it affects most Viam module what is the recommend way to fix this in a way that will benefit most of those modules"
• "Can you start a worktree and create a draft PR for the upstream change in rdk? You can find the repo at @~/code/rdk/"

🤖 Generated with Claude Code

[Ale Paredes (ale7714)]

is this different from our api? i guess should we keep it consistent?

[Nicolas Palpacuer (NickPPC)]

It is not different from our API, short_description is the correct key. The struct field is called Description and that's why I assume we got the key wrong in the schema (or maybe the key changed afterwards).

type ModuleComponent struct {
API          string  `json:"api"`
Model        string  `json:"model"`
Description  *string `json:"short_description,omitempty"`
MarkdownLink *string `json:"markdown_link,omitempty"`
}

[Ale Paredes (ale7714)]

i like this idea but i think this is more of a syntax check than a full validate. the only reason i think the distintiction matters is that you could pass this validate and still have errors (like uploading a duplicate model to the registry) that would fail during cloud build time. i don't a good proposal for a name or maybe the usage text could be more clear that this is a syntax check

[Nicolas Palpacuer (NickPPC)]

We could use maybe module lint-manifest?