What happened
On PR #2457, the review bot's cross-repo-contracts sub-agent flagged actions/upload-artifact@v7 (in site-build.yml) paired with actions/download-artifact@v8 (in site-deploy.yml) as a low [api-contract] finding, warning about potential cross-version compatibility issues. This finding appeared in review runs #27822632228 and #27950815426, consuming sub-agent tokens each time.
upload-artifact and download-artifact are independently versioned GitHub Actions maintained in the same actions/toolkit monorepo. Their artifact format compatibility is handled at the protocol level — v7 upload produces artifacts that v8 download can consume. Different major versions across these two actions is normal and expected.
What could go better
The cross-repo-contracts sub-agent applies a general heuristic: when two related actions have different major versions, flag potential incompatibility. This heuristic is reasonable for tightly coupled action pairs (e.g., actions/cache/save and actions/cache/restore), but produces false positives for independently versioned actions like upload-artifact and download-artifact.
Confidence: High that this is a false positive. GitHub's own documentation and release notes confirm cross-version compatibility. The artifact protocol version is what matters, not the action's major version number.
Uncertainty: I haven't verified whether this heuristic is hardcoded in the sub-agent prompt or emergent from the LLM's general reasoning. The fix approach differs depending on which it is.
Proposed change
In the pr-review skill (internal/scaffold/fullsend-repo/skills/pr-review/SKILL.md), add guidance to the cross-repo-contracts sub-agent prompt (or the orchestrator's finding evaluation logic) to distinguish between:
- Tightly coupled action pairs (same action, different sub-paths like
actions/cache/save and actions/cache/restore) — version skew is a valid concern
- Independently versioned action pairs (like
upload-artifact and download-artifact) — different major versions are expected and should not be flagged
Specifically, add a note like: "GitHub Actions upload-artifact and download-artifact are independently versioned. Different major versions across these actions are normal and do not indicate a compatibility issue. Do not flag version differences between independently versioned actions as api-contract findings."
If the heuristic is emergent rather than prompted, adding a negative example to the sub-agent's prompt should suppress it.
Validation criteria
On the next 3 PRs that bump upload-artifact and download-artifact to different major versions, the review agent should not emit an api-contract finding about version skew between them. The finding should still fire for genuinely coupled actions (e.g., actions/cache/save@v4 paired with actions/cache/restore@v3).
Generated by retro agent from #2457
What happened
On PR #2457, the review bot's cross-repo-contracts sub-agent flagged
actions/upload-artifact@v7(insite-build.yml) paired withactions/download-artifact@v8(insite-deploy.yml) as a low [api-contract] finding, warning about potential cross-version compatibility issues. This finding appeared in review runs #27822632228 and #27950815426, consuming sub-agent tokens each time.upload-artifactanddownload-artifactare independently versioned GitHub Actions maintained in the sameactions/toolkitmonorepo. Their artifact format compatibility is handled at the protocol level — v7 upload produces artifacts that v8 download can consume. Different major versions across these two actions is normal and expected.What could go better
The cross-repo-contracts sub-agent applies a general heuristic: when two related actions have different major versions, flag potential incompatibility. This heuristic is reasonable for tightly coupled action pairs (e.g.,
actions/cache/saveandactions/cache/restore), but produces false positives for independently versioned actions likeupload-artifactanddownload-artifact.Confidence: High that this is a false positive. GitHub's own documentation and release notes confirm cross-version compatibility. The artifact protocol version is what matters, not the action's major version number.
Uncertainty: I haven't verified whether this heuristic is hardcoded in the sub-agent prompt or emergent from the LLM's general reasoning. The fix approach differs depending on which it is.
Proposed change
In the
pr-reviewskill (internal/scaffold/fullsend-repo/skills/pr-review/SKILL.md), add guidance to the cross-repo-contracts sub-agent prompt (or the orchestrator's finding evaluation logic) to distinguish between:actions/cache/saveandactions/cache/restore) — version skew is a valid concernupload-artifactanddownload-artifact) — different major versions are expected and should not be flaggedSpecifically, add a note like: "GitHub Actions
upload-artifactanddownload-artifactare independently versioned. Different major versions across these actions are normal and do not indicate a compatibility issue. Do not flag version differences between independently versioned actions as api-contract findings."If the heuristic is emergent rather than prompted, adding a negative example to the sub-agent's prompt should suppress it.
Validation criteria
On the next 3 PRs that bump
upload-artifactanddownload-artifactto different major versions, the review agent should not emit anapi-contractfinding about version skew between them. The finding should still fire for genuinely coupled actions (e.g.,actions/cache/save@v4paired withactions/cache/restore@v3).Generated by retro agent from #2457