fix(rees): gate the expected-commit check on SENTRY_REQUIRE_COMMITS

[JSONbored]

Summary

• Found via Sentry (issue GITTENSORY-X, 9 occurrences, regressed): Error: Sentry release validation failed (1): ...["release commits do not include expected commit ..."], culprit runReleaseValidation(upload-sourcemaps).
• review-enrichment/scripts/validate-sentry-release.mjs's validateSentryRelease has two commit-related checks gated on config.requireCommits (mirroring SENTRY_REQUIRE_COMMITS/the strict deploy flag): "release has no associated commits" correctly checks config.requireCommits, but the sibling "release commits do not include expected commit" check only tested config.expectedCommitSha — never config.requireCommits. Since upload-sourcemaps.ts always passes SENTRY_COMMIT_SHA (the deploy's actual git SHA — not itself a strictness signal) regardless of the strict flag, expectedCommitSha is essentially always set, so this specific check fired unconditionally even on a deploy that explicitly requested non-strict validation (SENTRY_REQUIRE_COMMITS=false), causing spurious release-validation failures.
• Fix: add the same config.requireCommits && guard already used by the sibling check, so both commit-related checks consistently respect strict mode.
• No issue filed — small, self-evident bug found via direct Sentry investigation.

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked an issue, or this is small enough that the summary explains why an issue is not needed.

Validation

• git diff --check
• npm run typecheck (repo root, clean)
• node --test --experimental-strip-types test/sentry-release-validation.test.ts (run from review-enrichment/) — 5/5 passing, including the new regression test
• npm run test:workers / npm run build:mcp / npm run test:mcp-pack / npm run ui:openapi:check / npm run ui:build — not run individually this PR; this change is entirely within review-enrichment/, a separately-deployed sub-package with its own test runner, and doesn't touch the Worker/MCP/UI/OpenAPI surface.
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries — added a regression test exercising the exact previously-broken case (mismatched commit SHA + SENTRY_REQUIRE_COMMITS=false), which now resolves successfully instead of throwing; the existing strict-mode test (mismatched commit SHA with default requireCommits: true) is untouched and still correctly rejects.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. — N/A.
• API/OpenAPI/MCP behavior is updated and tested where needed. — N/A, no API/OpenAPI/MCP surface changed.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks. — N/A, no UI change.
• Visible UI changes include a UI Evidence section below. — N/A, no visible UI change.
• Public docs/changelogs are updated where needed. — N/A, internal deploy-tooling fix, no documented/user-facing behavior change.

Notes

• Part of a stack-health pass triggered by a live Sentry audit on the self-hosted deployment; see the parallel fixes for the RAG chunk-cap, PR-publish silent-drop, REES safeCodeSpan TypeError, and codex hang-detection issues found in the same pass.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[gittensory-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-05 07:27:52 UTC}

2 files · 1 AI reviewer · no blockers · readiness 93/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
The change correctly makes commit validation fully conditional on SENTRY_REQUIRE_COMMITS: non-strict runs no longer fetch /commits/ and therefore cannot fail on either a mismatched expected SHA or a transient commits-endpoint error. The added regression coverage drives the production validator path with SENTRY_COMMIT_SHA still present, which matches the caller behavior described in the PR. I do not see a reachable correctness defect in the visible diff.

Nits — 4 non-blocking

• nit: review-enrichment/scripts/validate-sentry-release.mjs:194 has a long explanatory comment that mostly repeats the PR description; keeping only the invariant that expectedCommitSha is not a strictness signal would make this easier to maintain.
• nit: review-enrichment/test/sentry-release-validation.test.ts:121 duplicates a lot of fixture setup with the strict-mode expected-commit test, so future changes to the base release shape or deploy requirement will need to be updated in multiple places.
• review-enrichment/test/sentry-release-validation.test.ts:121 could share the common release/deploy fixture helpers with the existing validation tests while keeping the non-strict assertions explicit.
• review-enrichment/scripts/validate-sentry-release.mjs:194 could shorten the comment to the behavioral contract: fetch commits only when requireCommits is true because SENTRY_COMMIT_SHA is always populated by the deploy path.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 56 registered-repo PR(s), 46 merged, 416 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 56 PR(s), 416 issue(s).
Gate result	✅ Passing	No configured blocker found.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 56 PR(s), 416 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• No action.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[gittensory-orb]

Gittensory approves — the gate is satisfied and CI is green.