feat(notifications): miner-facing post-merge reward & outcome attribution (#702)

[JSONbored]

What

Closes the pre-hoc→post-hoc loop (#702): when a miner's PR merges, they get a self-scoped, public-safe outcome record of what it did for their standing. Reuses the #535 notification pipeline (whose Wave-3 refinement explicitly intended to "fire on merge to feed #702").

• detectNotificationEvents now also detects pull_request_merged (action closed + merged_at set; never a close-without-merge; bot / missing-author suppressed). The author is both recipient and actor — it's their own outcome.
• The notification service dispatches content by event type: buildMergedOutcomeNotification frames what merged work does for the contributor's standing/lane signals on the repo. Public-safe (sanitizePublicComment) — never raw reward $/trust/score.
• The webhook already enqueues notify-evaluate per detected event, so a merge flows through the existing pipeline → an idempotent outcome delivery the miner can read.
• New MCP tool gittensory_pr_outcome (self-scoped via requireContributorAccess) lists a contributor's own merged-PR outcomes; listNotificationDeliveriesForRecipient gains an eventType filter. The outcomes also surface in the notification feed (gittensory_list_notifications).

Distinct from #543 (which calibrates the model vs outcomes — this attributes outcomes to the contributor).

Acceptance (#702)

✅ A merged PR produces a public-safe, self-scoped outcome record the miner can retrieve (via gittensory_pr_outcome + the feed), computed through the same pipeline, no raw $/trust/score.

Access boundary

Strictly miner-scoped: the merged-PR notification recipient is the PR author, and both gittensory_pr_outcome + gittensory_list_notifications enforce requireContributorAccess (a session can only read its own login). All copy public-safe.

Tests

• Merge detection: emitted for the author; close-without-merge / bot / missing-author ignored; deeplink fallback.
• Service: public-safe merge copy; eventType-filtered persistence (merge surfaces, changes-requested doesn't).
• MCP gittensory_pr_outcome: own merged outcomes only; self-scope rejection.
• 97% coverage gate green; workers tests + git diff --check + ui:openapi:check pass.

Closes #702 (sub-issue of #529).

[ghost]

Note

Gittensory Gate skipped

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

Signal	Result	Evidence	Action
Gate result	⚠️ Skipped	#714 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 8 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 MCP tool to retrieve a contributor's own post‑merge outcome records, introduces detection and notification handling for merged pull requests, extends the notification delivery query to filter by event type, updates type definitions, and adds comprehensive tests. The implementation respects the public‑private sanitizer and appears functionally correct.

Suggestions

• Verify that the eventType column exists in the notificationDeliveries table and add a migration if it does not.
• Document the new gittensory_pr_outcome tool in the MCP CLI/reference docs.
• Consider adding a test for the limit parameter of the prOutcomes tool to ensure pagination works as expected.

Worth double-checking

• If the eventType field is missing from the DB schema, the new query will fail at runtime.
• Ensure the sanitizer covers any future changes to the merged‑outcome message to avoid accidental leakage of forbidden terms.

Reviewer B · mistral-small-3.1-24b-instruct — recommends ✅ merge
This PR adds a new feature to notify contributors about post-merge outcomes for their pull requests. It includes changes to the MCP server, notification events, and related services, along with comprehensive tests. The implementation is clean and adheres to the project's conventions.

Suggestions

• Consider adding a comment in the prOutcomeShape and prOutcomeOutputSchema definitions to explain why limit is optional and has a maximum value of 100.
• Ensure that the sanitizePublicComment function is thoroughly tested to handle edge cases, especially with the new notification content.
• Add a test case to verify that the prOutcomes method handles cases where no outcomes are found for a given login.

Worth double-checking

• Verify that the new notification event handling does not introduce any performance regressions, especially with the addition of the eventType filter in listNotificationDeliveriesForRecipient.
• Ensure that the new gittensory_pr_outcome tool is properly secured and that it cannot be abused to retrieve outcomes for unauthorized logins.
• Check that the new notification content is accessible and responsive across different devices and screen sizes.