feat(miner): pre-submission gate prediction on the local branch (self-gate)

[JSONbored]

The highest-leverage miner feature: a contributor can now see "will my PR pass repo X's gate, and what would block it?" before opening the PR — the score-moving feedback that previously only existed in the maintainer PR pipeline.

How (true parity, one engine)

New src/rules/predicted-gate.ts → buildPredictedGateVerdict builds a synthetic PR from the local branch metadata and runs the exact same engine the maintainer PR pipeline runs: buildPullRequestAdvisory + buildPublicReadinessScore + evaluateGateCheck. So the verdict a miner sees pre-submission is the verdict the gate computes post-submission — not a separate approximation.

Boundary-safe by construction (per the access invariant)

The gate policy is sourced only from the repo's public .gittensory.yml (manifest.gate) + safe defaults — never the maintainer's private dashboard/DB settings. The .gittensory.yml lives in the repo and is publicly viewable, so this leaks nothing a contributor couldn't already read. The verdict is labelled predicted / public_config and notes that private overrides and the dual-model AI-consensus blocker aren't evaluated pre-submission. Output runs through sanitizePublicComment.

• Wired into POST /v1/local/branch-analysis (already requireContributorAccess + self-scoped) as a predictedGate block, so every existing miner branch-analysis tool inherits it.
• A non-confirmed contributor's prediction is forced neutral, matching the real gate (only confirmed Gittensor contributors are ever hard-blocked).

Tests

predicted-gate.test.ts: clean→pass; duplicate→block (and duplicates:off→no block); missing-linked-issue blocks only on linkedIssue:block (advisory by default); non-confirmed→neutral.

Verification

typecheck ✅ · test:coverage ✅ (97.01% branch, 1692 tests) · test:workers ✅ · git diff --check ✅

Part of #525. (Follow-ups: AI advisory on the local diff arrives with contributor BYOK; a dedicated gittensory_self_check_gate MCP tool name.)

[ghost]

Note

Gittensory Gate skipped

PR closed before full evaluation. No late first comment was created.

Signal	Result	Evidence	Action
Gate result	⚠️ Skipped	#688 is no longer open.	No action.

---

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

[superagent-security]

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

[ghost]

gittensory · advisory review

Reviewed 3 changed file(s) — two independent AI reviewers.

Suggested action: ✅ Safe to merge — both reviewers found no blocking issues.

Reviewer A · gpt-oss-120b — recommends ✅ merge
This PR adds a new pre‑submission gate prediction feature by introducing a PredictedGate rule, integrating it into the local‑branch analysis endpoint, and providing unit tests. The implementation mirrors the existing gate logic, sanitizes public output, and appears type‑correct.

Suggestions

• Document the new predictedGate field in the API response schema or OpenAPI spec.
• Consider adding a test case where the repository manifest lacks a gate configuration to verify graceful handling.
• If the endpoint is public, verify that the added payload size remains within any response size limits.

Worth double-checking

• Performance impact of running the full gate evaluation on every local‑branch analysis request.
• Potential null repo handling in the new rule; ensure downstream functions tolerate null safely.

Reviewer B · mistral-small-3.1-24b-instruct — recommends ✅ merge
This PR adds a new feature to predict the gate outcome for a local branch before submission. The implementation is thorough, with proper sanitization and clear documentation. The tests cover various scenarios effectively.

Suggestions

• Consider adding a comment explaining why confirmedContributor is optional in PredictedGateInput but required in buildPredictedGateVerdict arguments.
• Ensure that the PREDICTED_GATE_NOTE string is consistent with other public-facing messages in terms of tone and clarity.

Worth double-checking

• Verify that the sanitizePublicComment function is robust and covers all edge cases for the new public-facing outputs.
• Check that the new feature does not introduce any performance regressions, especially in the API route handling.