feat(bounties): add lifecycle watcher signals

[Crystora]

Summary

Close: #23

• Add bounty lifecycle checks to advisories, preflight, issue quality, opportunity ranking, MCP tools, and agent flows.
• Distinguish active, completed, cancelled, historical, stale, and ambiguous bounty states so stale or inactive bounty work is not treated as an active opportunity.
• Include linked PR context in bounty advisory results and add focused lifecycle coverage in tests.

Validation

• npm run test:ci
• npm run changelog:check

Safety

• Backend-only change
• No secrets, wallet details, user PATs, raw trust scores, or private rankings exposed
• Public text avoids compensation-seeking or optimization-tactic language
• OpenAPI/MCP behavior updated where needed
• Public docs/changelogs updated where needed

[JSONbored]

PR #29 - feat: Add bounty lifecycle checks across core signals and MCP flows
Signal: REQUEST CHANGES

Required changes:

• Fix changelog freshness: CI fails at changelog:check.
• Rename PR title to conventional style, e.g. feat(bounties): add lifecycle watcher signals.
• Remove or regenerate the incorrect packages/gittensory-mcp/CHANGELOG.md edits unless this PR actually changes the npm package.
• Re-check broad listAllIssues/listAllPullRequests use in decision-pack building; acceptable only if queue/job-only, not request-path.
• Add explicit tests proving completed/cancelled/stale bounties do not become strong “good” opportunities.
• Add performance/bounded-work coverage for large bounty + issue sets.

[Crystora]

@JSONbored I've updated all.

[JSONbored]

@JSONbored I've updated all.

Please fix merge conflicts

[Crystora]

@JSONbored Fixed conflicts.

[JSONbored]

@bittoby this is much closer. The old changelog feedback should be treated as artifact cleanup, not a product blocker, but the PR still needs cleanup before merge.

Required:

• Remove the accidental CHANGELOG.md and packages/gittensory-mcp/CHANGELOG.md edits. (test suite should no longer generate changes when run).
• Tighten bounty lifecycle status parsing so broad terms like reward/award do not accidentally mark active bounty-like states as completed.
• Keep the decision-pack/shared-input optimization; that addresses the earlier repeated full-scan concern for batch jobs.
• Re-run npm run test:ci after the changelog cleanup.

[Crystora]

@JSONbored I've fixed all.

[Crystora]

Hi @JSONbored, I’ve resolved several conflicts after updating this pr based on your feedback but I haven’t got any updates from you yet.
Is there anything else I need to update more? Why you hold this PR?
It’s very headache for me to keep resolving conflicts every time other PRs are merged.
pls let me know.

[JSONbored]

Hi @JSONbored, I’ve resolved several conflicts after updating this pr based on your feedback but I haven’t got any updates from you yet. Is there anything else I need to update more? Why you hold this PR? It’s very headache for me to keep resolving conflicts every time other PRs are merged. pls let me know.

There were underlying improvements, a massive new frontend overhaul, and other backend changes that needed improvement - i'll get to reviewing this shortly, please be patient.

[Crystora]

All CI passed.

[JSONbored]

@bittoby this is a strong feature pass overall, but I still would like one correctness refinement before landing.

A few notes:

• Expanding bounty lifecycle beyond active / historical / unknown is the right direction.
• Filtering completed, cancelled, and historical bounty work out of contributor opportunities is important and should stay.
• Wiring bounty state into issue quality and preflight warnings is also the right product behavior.
• The remaining concern is linked PR interpretation. We do want to factor in open, merged, and closed PRs, but they should not all mean the same thing:
  • Open linked PRs are active overlap/collision risk.
  • Merged linked PRs are possible resolution/completion risk.
  • Closed-unmerged linked PRs are historical caution or ambiguity, not necessarily active competing work.
• Right now consensusRisk is still based mostly on raw linked PR count, which can make historical/closed PRs look like the same risk as multiple active open PRs.

Required changes:

• Compute bounty/issue risk from linked PR state, not just raw linked PR count.
• Treat open linked PRs as active overlap risk.
• Treat merged linked PRs as possible solved/completed work.
• Treat closed-unmerged linked PRs as caution/ambiguity, especially when there are several.
• Keep the public wording specific to the actual risk class so contributors know whether they are avoiding duplicate active work, verifying a possibly solved bounty, or reviewing historical attempts.

Validation expected:

• Add regression coverage for multiple open linked PRs producing elevated overlap risk.
• Add regression coverage for a merged linked PR producing a solved/resolution warning.
• Add regression coverage for only closed-unmerged PRs producing caution/ambiguous history, not the same active-overlap wording.
• Keep npm run test:coverage and npm run ui:openapi:check green.

[Crystora]

@JSONbored I've updated all.

• Risk now uses PR state, not count — consensusRisk is computed from open/merged/closed linked PRs instead of raw linked-PR count.
• Open PRs → high overlap risk — multiple open linked PRs now score high (active duplicate-work risk).
• Merged PRs → solved warning — a merged linked PR adds a warning that the bounty may already be resolved.
• Closed-unmerged PRs → history caution — closed attempts are flagged as historical caution, not active competing work.
• Distinct wording per class — three separate findings (bounty_has_active_pr, bounty_linked_pr_merged, bounty_linked_pr_closed_history), each naming the actual PR numbers.
• New regression tests — coverage for multiple-open (overlap), merged (resolution), and closed-only (ambiguous history) cases.
• Gates green — test:coverage and ui:openapi:check both pass.

@bittoby this looks ready from my side now.

A few notes:

• The bounty lifecycle expansion is the right shape: active, completed, cancelled, historical, stale, ambiguous, and unknown each carry different contributor guidance.
• Filtering completed/cancelled/historical bounty work out of contributor opportunities is important and should stay.
• The latest update addresses the linked-PR risk concern: open PRs now mean active overlap, merged PRs mean possible resolution, closed-unmerged PRs mean historical caution, and unknown PRs stay ambiguous.
• The tests now cover the cases I cared about: multiple open linked PRs, merged linked PRs, only closed-unmerged linked PRs, issue-quality warnings, preflight warnings, and opportunity ranking behavior.

No code changes requested from me.