Conversation
Add VersionRange, RemediationCategory, and RemediationInfo schemas to represent Trustify v3's structured remediation data. The existing fixedIn field is preserved for backward compatibility. Bump API model version from 5.2.0 to 5.3.0. Ref: TC-4521 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Reviewer's GuideExtends the v5 OpenAPI remediation schema to carry structured remediation metadata and Trustify v3-style version range information, and bumps the API model version from 5.2.0 to 5.3.0. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #113 +/- ##
=========================================
Coverage 95.00% 95.00%
Complexity 35 35
=========================================
Files 4 4
Lines 100 100
Branches 9 9
=========================================
Hits 95 95
Misses 4 4
Partials 1 1
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- Consider marking required properties explicitly on the new schemas (e.g.,
RemediationInfoandVersionRange) so consumers can rely on which fields are always present rather than inferring this from descriptions. - The
VersionRangedescription references different variants (Full/Left/Right/Unbounded) but the schema itself doesn’t encode which variant is in use; consider adding atypediscriminator or clarifying how clients should distinguish these cases programmatically. - For
RemediationCategory, if future categories are expected, you may want to document that clients should handle unknown enum values gracefully or use a more extensible pattern to avoid breaking changes.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider marking required properties explicitly on the new schemas (e.g., `RemediationInfo` and `VersionRange`) so consumers can rely on which fields are always present rather than inferring this from descriptions.
- The `VersionRange` description references different variants (Full/Left/Right/Unbounded) but the schema itself doesn’t encode which variant is in use; consider adding a `type` discriminator or clarifying how clients should distinguish these cases programmatically.
- For `RemediationCategory`, if future categories are expected, you may want to document that clients should handle unknown enum values gracefully or use a more extensible pattern to avoid breaking changes.
## Individual Comments
### Comment 1
<location path="api/v5/openapi.yaml" line_range="580-582" />
<code_context>
+ details:
+ type: string
+ description: Human-readable remediation details
+ url:
+ type: string
+ description: URL with more information about the remediation
+ VersionRange:
+ type: object
</code_context>
<issue_to_address>
**suggestion:** Consider adding a `format: uri` constraint for remediation URLs.
Using `format: uri` for `RemediationInfo.url` will improve client type-safety and OpenAPI-based validation while remaining backward compatible.
```suggestion
url:
type: string
format: uri
description: URL with more information about the remediation
```
</issue_to_address>
### Comment 2
<location path="api/v5/openapi.yaml" line_range="587-589" />
<code_context>
+ type: object
+ description: Affected version range from a vulnerability advisory. Fields present depend on the range type - Full (all fields), Left (scheme and low bound), Right (scheme and high bound), or Unbounded (empty).
+ properties:
+ versionSchemeId:
+ type: string
+ description: Version scheme identifier (e.g. semver, rpm, generic)
+ lowVersion:
+ type: string
</code_context>
<issue_to_address>
**suggestion:** Version scheme identifiers might benefit from a more constrained type.
`versionSchemeId` is currently an unconstrained string with only descriptive examples. If the set of schemes is relatively stable, consider using an enum (or at least an `enum`/`pattern` constraint in the schema) so clients can validate and branch on this value reliably.
Suggested implementation:
```
properties:
versionSchemeId:
type: string
description: Version scheme identifier. Supported values: `semver`, `rpm`, `generic`.
enum:
- semver
- rpm
- generic
remediations:
type: array
description: Detailed remediation information from vulnerability advisories
items:
$ref: '#/components/schemas/RemediationInfo'
```
```
versionRanges:
type: array
description: Affected version ranges from vulnerability advisories
items:
$ref: '#/components/schemas/VersionRange'
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Collaborator
Author
|
[sdlc-workflow/verify-pr] Re: @sourcery-ai review Classified 3 suggestions:
None upgraded to code change requests (no matching CONVENTIONS.md rules or codebase patterns). |
Collaborator
Author
Verification Report — TC-4521Task: TC-4521 — Extend Remediation model for Trustify v3 version ranges Verdicts
Review Feedback5 items classified from sourcery-ai — all as suggestion, none upgraded:
Acceptance Criteria Detail
Sub-Tasks CreatedNone — all checks passed. This report was AI-generated by sdlc-workflow/verify-pr v0.11.0. |
4 tasks
Strum355
approved these changes
Jun 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
VersionRangeschema to represent Trustify v3's structured version range data (Full, Left, Right, Unbounded variants)RemediationCategoryenum (VENDOR_FIX, WORKAROUND, MITIGATION, NO_FIX_PLANNED, NONE_AVAILABLE, WILL_NOT_FIX)RemediationInfoschema with category, details, and URL fieldsRemediationwith optionalremediationsandversionRangesarraysfixedInfield for backward compatibilityJira
TC-4521
Test plan
mvn clean verify)fixedInfield preserved in generated Remediation classRemediationCategory,RemediationInfo,VersionRangeclasses generated🤖 Generated with Claude Code
Summary by Sourcery
Extend the remediation schema and versioning to support structured remediation and version range data from vulnerability advisories.
New Features:
Build: