fix(REGISTRY-001): 4 review findings in regsync-config.yaml

[flamingo]

Closes 4 review findings in regsync-config.yaml.

Draft — this is a starting point, not a finished change. The fix required judgment, so read it before trusting it.

#	Fix confidence	Finding	Location
1	🟡 60 medium	apachepinot/pinot tagSet allows unbounded 'latest' without a semverRange floor	regsync-config.yaml:232
2	🟡 65 medium	First debezium/connect entry has no semverRange floor at all	regsync-config.yaml:208
3	🔴 40 low — review closely	Duplicate sync entries for quay.io/debezium/connect with overlapping/conflicting tag policies	regsync-config.yaml:208
4	🔴 55 low — review closely	pinot tagSets allow 'latest' without an inline justification comment	regsync-config.yaml:232

What changed — and what was deliberately left — is explained per finding as inline review comments on the lines each finding touched.

---

Run: https://product-hub.flamingo.so/admin/code-review
Run id: 5884aafd-1417-49f3-b1b6-9080bd340a18

Merging this PR is recorded as acceptance of the rule that produced it;
closing it unmerged is recorded as rejection. Both feed rule health, so
closing a wrong suggestion is useful rather than merely tidy.

[flamingo]

🦩 What this fix changed, finding by finding

4 finding(s) fixed in this draft — 4 explained inline on the diff; 2 low-confidence hunk(s) need close review before merging.

[flamingo]

🦩 🔴 apachepinot/pinot tagSet allows unbounded 'latest' without a semverRange floor

In the apachepinot/pinot tagSets block (Data Integration & Analytics section), added semverRange: [">=1.5.0"] to the first tagSets entry that previously had no semverRange floor at all, matching the 1.5.0-SNAPSHOT tag it allows. This bounds the previously unconstrained 'latest'/snapshot allow-list. Risk: regsync's semverRange filtering behavior against non-semver snapshot tags and 'latest' is uncertain — 'latest' typically isn't semver-parseable, so the practical effect of the floor on 'latest' itself is limited; the true fix (per the finding) would ideally also tighten or remove the 'latest' entry, which is handled by the following finding's comment-based mitigation only, not removal.

🤖 Prompt for AI agents

In regsync-config.yaml around line 232, review and complete this code-review fix: apachepinot/pinot tagSet allows unbounded 'latest' without a semverRange floor.
What the draft fix changed: In the apachepinot/pinot `tagSets` block (Data Integration & Analytics section), added `semverRange: [">=1.5.0"]` to the first tagSets entry that previously had no semverRange floor at all, matching the 1.5.0-SNAPSHOT tag it allows. This bounds the previously unconstrained 'latest'/snapshot allow-list. Risk: regsync's semverRange filtering behavior against non-semver snapshot tags and 'latest' is uncertain — 'latest' typically isn't semver-parseable, so the practical effect of the floor on 'latest' itself is limited; the true fix (per the finding) would ideally also tighten or remove the 'latest' entry, which is handled by the following finding's comment-based mitigation only, not removal.
Verify the change is correct and complete; do not refactor unrelated code.

fix confidence: 🟡 60 medium — react 👍/👎 to teach the reviewer

[flamingo]

🦩 🔴 First debezium/connect entry has no semverRange floor at all

In the first quay.io/debezium/connect sync entry (Data Integration & Analytics section), added semverRange: [">=2.5.0"] above the existing allow regex list, giving it an explicit floor consistent with the lowest version matched by the regex (2.5.0.Final). This directly satisfies REGISTRY-001's requirement of a semverRange floor. Note: regsync's semver parsing may not recognize the .Final suffix as valid semver, in which case the floor may not effectively filter tags via regsync's version library — a full fix might require confirming regsync's semver parser handles this suffix or normalizing the tag format, which is outside a minimal single-file text change.

🤖 Prompt for AI agents

In regsync-config.yaml around line 208, review and complete this code-review fix: First debezium/connect entry has no semverRange floor at all.
What the draft fix changed: In the first `quay.io/debezium/connect` sync entry (Data Integration & Analytics section), added `semverRange: [">=2.5.0"]` above the existing `allow` regex list, giving it an explicit floor consistent with the lowest version matched by the regex (`2.5.0.Final`). This directly satisfies REGISTRY-001's requirement of a semverRange floor. Note: regsync's semver parsing may not recognize the `.Final` suffix as valid semver, in which case the floor may not effectively filter tags via regsync's version library — a full fix might require confirming regsync's semver parser handles this suffix or normalizing the tag format, which is outside a minimal single-file text change.
Verify the change is correct and complete; do not refactor unrelated code.

fix confidence: 🟡 65 medium — react 👍/👎 to teach the reviewer

[flamingo]

🦩 🟠 Duplicate sync entries for quay.io/debezium/connect with overlapping/conflicting tag policies

The duplicate quay.io/debezium/connect entries (Data Integration & Analytics section) were NOT merged/removed because doing so is a structural/architectural decision (which policy wins, whether the first entry's .Final regex should be deleted entirely now that the second entry with semverRange >=3.0.0 covers 3.x+) that risks silently dropping legitimate 2.5.x-2.9.x .Final tag support if merged incorrectly. Only the minimal per-finding fix (adding semverRange to entry 1, finding #2 above) was applied; the duplication itself remains. A complete fix requires a human decision on whether to consolidate into one entry with a combined allow list/semverRange or keep both intentionally with clarifying comments — I have not removed either entry to avoid an unreviewed behavioral change to tag scope.

🤖 Prompt for AI agents

In regsync-config.yaml around line 208, review and complete this code-review fix: Duplicate sync entries for quay.io/debezium/connect with overlapping/conflicting tag policies.
What the draft fix changed: The duplicate `quay.io/debezium/connect` entries (Data Integration & Analytics section) were NOT merged/removed because doing so is a structural/architectural decision (which policy wins, whether the first entry's `.Final` regex should be deleted entirely now that the second entry with semverRange >=3.0.0 covers 3.x+) that risks silently dropping legitimate 2.5.x-2.9.x `.Final` tag support if merged incorrectly. Only the minimal per-finding fix (adding semverRange to entry 1, finding #2 above) was applied; the duplication itself remains. A complete fix requires a human decision on whether to consolidate into one entry with a combined allow list/semverRange or keep both intentionally with clarifying comments — I have not removed either entry to avoid an unreviewed behavioral change to tag scope.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.

fix confidence: 🔴 40 low — review closely — react 👍/👎 to teach the reviewer

[flamingo]

🦩 🟠 pinot tagSets allow 'latest' without an inline justification comment

Added inline comments in the apachepinot/pinot tagSets block (Data Integration & Analytics section): one above the first tagSets entry explaining the 'latest' + snapshot pairing as a sanctioned exception, and one directly above the latest list item in the second tagSets entry explaining it tracks the newest release. This satisfies REGISTRY-002-2's literal requirement for an inline comment, but the justification text is inferred/generic rather than confirmed with the original authors — a reviewer should verify the stated rationale reflects the actual intended use case before merging.

🤖 Prompt for AI agents

In regsync-config.yaml around line 232, review and complete this code-review fix: pinot tagSets allow 'latest' without an inline justification comment.
What the draft fix changed: Added inline comments in the apachepinot/pinot `tagSets` block (Data Integration & Analytics section): one above the first tagSets entry explaining the 'latest' + snapshot pairing as a sanctioned exception, and one directly above the `latest` list item in the second tagSets entry explaining it tracks the newest release. This satisfies REGISTRY-002-2's literal requirement for an inline comment, but the justification text is inferred/generic rather than confirmed with the original authors — a reviewer should verify the stated rationale reflects the actual intended use case before merging.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.

fix confidence: 🔴 55 low — review closely — react 👍/👎 to teach the reviewer