feat(review): make orb check publication configurable

[JSONbored]

Summary

Adds a configurable reviewCheckMode (gate.checkMode in .gittensory.yml) so a self-hosted repo can choose how the Gittensory Orb Review Agent check-run is published, independent of the autonomous merge/close decision:

• required — publish/update the check-run exactly as before; use when GitHub branch protection requires it as a status check. This is the legacy behavior.
• visible — publish/update the same check-run for advisory UI visibility only; not intended to be a required branch-protection context.
• disabled — never create or update the check-run. Reviews, comments, labels, audit trail, and autonomous merge/close all continue to work.

gate.enabled: true / gateCheckMode: "enabled" continue to map to required, and false/"off" to disabled, so existing configs behave identically. An explicit reviewCheckMode / gate.checkMode always takes precedence over the legacy boolean, both in .gittensory.yml and at the settings-write API routes (fixed a latent bug where the internal/dashboard write routes never actually exercised the legacy-boolean-derives-new-field fallback in upsertRepositorySettings).

Critically, the autonomous decision engine (merge/close) no longer depends on the check-run's existence at all — gate evaluation now runs whenever the check is published or an automation agent is configured (shouldEvaluateGate), so reviewCheckMode: disabled repos still get correct auto-merge/auto-close via internal gate state + real CI + freshness + mergeability, with zero check-run API calls.

Also fixes a related staleness bug found while validating this: a required branch-protection status context that never reports (vs. genuinely pending CI) was held under the same blunt 30-minute stale-CI cap, so PRs could look stuck for up to half an hour. It now defers under its own short 2-minute cap, so review proceeds promptly once real CI is clear — no new polling or extra GitHub API calls either way.

Migration notes for self-host operators

• To stop publishing the check-run fleet-wide, set gate.checkMode: disabled (or visible to keep it advisory-only) in the global private config.
• Before switching a repo to disabled, remove Gittensory Orb Review Agent from that repo's required branch-protection status checks first — Gittensory cannot manage branch-protection settings itself, and a required check that's never published will leave PRs stuck at "Expected — Waiting for status to be reported."
• Gittensory remains the autonomous controller of merge/close in all three modes; reviewCheckMode only controls whether/how the check-run itself is published.

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.
• This is small enough / self-evident enough that the summary explains why an issue is not needed (a repo-owner authored self-host config feature, not a contributor bugfix).

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally; 100% patch coverage (lines and branches) verified on every changed line in src/**.
• npm run test:workers
• npm run build:mcp
• npm run test:mcp-pack
• npm run ui:openapi:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

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 here, but the settings-write routes gained regression tests for the legacy-derivation fix.)
• API/OpenAPI/MCP behavior is updated and tested where needed — openapi.json regenerated, ui:openapi:settings-parity passes.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks. (No apps/gittensory-ui UI changes in this PR — backend/config-only.)
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs. (.gittensory.yml.example and config/examples/*.yml updated; CHANGELOG.md untouched.)

Notes

• Migration 0107_repository_review_check_mode.sql adds review_check_mode (default disabled) and backfills existing gate_check_mode = 'enabled' rows to required.
• No apps/gittensory-ui dashboard changes — this is intentionally backend/config-driven only for now; the dashboard toggle continues to write gateCheckMode, which the API layer now correctly derives reviewCheckMode from.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	gittensory-ui	6238380	Commit Preview URL Branch Preview URL	Jul 04 2026, 04:28 AM

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.03%. Comparing base (a1ad1ac) to head (6238380).
⚠️ Report is 6 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2863   +/-   ##
=======================================
  Coverage   96.03%   96.03%           
=======================================
  Files         259      259           
  Lines       28393    28411   +18     
  Branches    10326    10339   +13     
=======================================
+ Hits        27266    27284   +18     
  Misses        491      491           
  Partials      636      636           

Files with missing lines	Coverage Δ
src/api/routes.ts	94.49% <100.00%> (+<0.01%)	⬆️
src/db/repositories.ts	96.39% <100.00%> (+<0.01%)	⬆️
src/db/schema.ts	69.46% <ø> (ø)
src/github/backfill.ts	96.66% <100.00%> (+0.01%)	⬆️
src/openapi/schemas.ts	100.00% <ø> (ø)
src/queue/processors.ts	92.70% <100.00%> (+<0.01%)	⬆️
src/review/check-names.ts	100.00% <100.00%> (ø)
src/services/maintainer-activation.ts	100.00% <100.00%> (ø)
src/signals/engine.ts	97.35% <100.00%> (ø)
src/signals/focus-manifest.ts	99.40% <100.00%> (+<0.01%)	⬆️
... and 2 more

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Warning

Gittensory review approved this PR

Review summary
The diff adds reviewCheckMode across persistence, config parsing, OpenAPI, settings previews, and the queue publication path, with the schema and migration kept in parity. The migration backfills existing enabled rows to required and uses D1-safe statements, while runtime check-run writes now consistently go through shouldPublishReviewCheck. The autonomous path is also covered so disabled check publication no longer suppresses merge/close decisions when autonomy is configured.

Nits (4)

• nit: src/signals/focus-manifest.ts:31 says gate evaluation always runs regardless of checkMode/enabled, but src/queue/processors.ts:6488 and src/queue/processors.ts:7610 evaluate only when the check publishes or autonomy is configured, so the comment should match the actual shouldEvaluateGate rule.
• nit: src/signals/engine.ts:4279 and src/signals/engine.ts:4524 keep the local name gateEnabled even though it now means published-check-or-autonomy presentation, so a name like shouldShowGateResult would reduce future confusion.
• src/signals/focus-manifest.ts:1591 should get a focused test for gate.enabled combined with gate.checkMode to pin the documented precedence when both are present.
• src/queue/processors.ts:6488 would be easier to audit if shouldEvaluateGate were extracted near shouldPublishReviewCheck or named consistently across processors and signals presentation code.

Public GitHub metadata was checked for review readiness. Gittensor-specific context appears only when confirmed.

Readiness score: 93/100

Signal	Result	Evidence	Action
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.	Explain no-issue PR.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.	No action.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).	No action.
Validation posture	✅ 25/25	PR body includes validation/test evidence.	No action.
Contributor workload	✅ 10/10	Author activity: 60 registered-repo PR(s), 51 merged, 436 issue(s).	No action.
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 60 PR(s), 436 issue(s).	No action.
Gate result	⚠️ Advisory only	Advisory only.	No action.

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.

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: 60 PR(s), 436 issue(s).
• PR-specific overlap: none found.

Maintainer notes

• Repo lane unavailable for contributor scoring: Repository registration is not available in the local Gittensory cache. Maintainer-authored work is treated as repo stewardship, not contributor-lane eligibility.
• No linked issue detected: The planned PR does not reference a closing issue or explicit linked issue number.

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.

• Re-run Gittensory review

---

💰 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.

[JSONbored]

Addressed both review findings:

1. Gate presentation bug (confirmed) — buildPublicPrIntelligenceComment/buildPublicPrPanelSignalRows in src/signals/engine.ts keyed their local gateEnabled display flag on shouldPublishReviewCheck alone, so a reviewCheckMode: disabled repo with autonomy configured would show "Advisory only" / "No action" in the public comment even when a real, evaluated gate failure existed. Fixed by also treating a configured autonomy policy as enabling gate presentation (mirrors the shouldEvaluateGate policy signal already used in processors.ts), with a regression test covering both the panel row and the comment's alert/title.

2. "Possible leaked secret" — false positive. The flagged strings are pre-existing test-mock fixtures (token: "installation-token", token: "public-token") used to stub GitHub API responses in vi.stubGlobal("fetch", ...). This exact pattern already appears 553 times across the test suite (207 of them in test/unit/queue.test.ts on main before this PR touched it) — no real credential is present anywhere in the diff.

Also rebased onto latest main to resolve the reported branch conflict (a trivial two-new-tests-at-the-same-anchor conflict in test/unit/queue.test.ts, not a logical conflict) and re-ran the full local gate (typecheck, unsharded coverage, workers tests) green.

[JSONbored]

Addressed the migration-coverage finding:

Migration backfill lacked a real pre-migration regression test (confirmed). `createTestEnv()` applies every migration (including 0107) up front against an empty table, so the added `repository-settings-review-check-mode.test.ts` suite only exercised the application-layer derivation, never the migration's own `UPDATE ... WHERE gate_check_mode = 'enabled'` backfill running against a real pre-existing row.

Added `test/unit/migration-0107-review-check-mode.test.ts`, mirroring the existing `migration-0102-linked-issue-gate-mode.test.ts` pattern: replays every migration before 0107 into a fresh in-memory DB, inserts a raw `gate_check_mode='enabled'` row exactly as a pre-existing installed repo would have it, applies migration 0107 for real, and asserts the backfill. Also covers the `'off'` case and an unrecognized legacy value both failing closed to the new column's `'disabled'` default, plus a multi-row backfill in one run.

The "possible leaked secret" flag is the same recurring false positive noted on the previous round (pre-existing test-mock tokens, unchanged) — no real credential anywhere in the diff.

Rebased onto latest `main` (moved 10 more commits) and re-ran the full local gate (typecheck, unsharded coverage — 8085 tests passing, migrations check) green.