Add a rspec lint check to check title: and description:line lengths.

[jasnow]

Add a rspec lint check to check title: and description:line lengths.

• Initial the maximum title: line length will be 154.
• Initial the maximum description: line length will be 80.
• Initial start date is May 9, 2026 and it is the earliest start date with no failed checks.
• Also excluded OSVDB advisory since they are very old.

These max numbers are at or close to the minimum to get a clean "rake" run.

[flavorjones]

@jasnow Did you explore whether it's easier to add these checks to spec/schemas/gem.json now that we have the json schemea validator? I suspect this is something it can do quite easily (and quickly).

[simi]

@jasnow good to keep in json scheme as much as possible IMHO. It is easier to maintain and easier for people to contribute.

[jasnow]

@jasnow Did you explore whether it's easier to add these checks to spec/schemas/gem.json

I am more comfortable working with YAML. I hope you reconsider approving this PR.

[StantonMatt]

I ran this locally with Ruby 3.3.11:

bundle exec rake lint
61543 examples, 0 failures

bundle exec rspec spec/schema_validation_spec.rb
1279 examples, 0 failures

git diff --check also passes.

On the schema question: I think the title/description checks can mostly live in JSON Schema if the project wants them there. title can use maxLength, and the description line limit can be expressed with a not pattern against lines of 81+ characters. Since these shared examples apply to all advisories, that would probably need to be added to both spec/schemas/gem.json and spec/schemas/ruby.json, not only the gem schema.

The caveat is the grandfathering. I tried adding title.maxLength = 154 and a description long-line not pattern to the gem schema locally, and schema validation reports 467 existing gem advisory failures. So the date/OSVDB gate in this PR is doing real work unless maintainers want to clean up existing records or enforce the rule globally.

The filename-root URL check is a different case: the current JSON Schema validation only sees the advisory data, not the file path, so that rule does not map cleanly to the existing schema validator. But that check already exists on current master, so I would keep this PR focused on the two length rules.

Given that, I think either direction is reasonable:

• keep this as RSpec logic if the goal is incremental enforcement for newer advisories only;
• move the two length limits into JSON Schema if the project wants the simpler long-term rule and is willing to handle the existing-data failures.

Small cleanup if this stays in RSpec: the description example string currently uses ${MAX_DESC_LEN} instead of Ruby interpolation, and that block has a few indentation inconsistencies.