fix(linear): stop fuzzy matching workspace milestones

[JSONbored]

Motivation

• Listing Linear workspace project milestones exposed an existence oracle because milestone names (workspace-scoped) were fuzzy-matched against PR title/body controlled by any PR author.
• The change prevents public yes/no suggestions that leak whether an internal milestone exists while preserving confirmed native links from Linear's attachments lookup.

Description

• Make LinearAdapter.listOpenMilestones inert and return an empty list with a doc comment explaining the privacy risk so workspace milestone names are no longer fetched.
• Change resolveTrackerMatches(..., backend === "linear") to only fuzzy-match Linear projects (set milestone: null) while still preferring findLinearNativeLink for confirmed native links.
• Update unit tests in test/unit/linear-adapter.test.ts to assert that milestone listing is inert and that milestone-based fuzzy suggestions no longer occur.

Testing

• Ran the modified unit tests with npm exec -- vitest run test/unit/linear-adapter.test.ts --reporter=verbose, which passed (18 passed).
• Ran type checking with npm run typecheck, which succeeded.
• Attempted full coverage with npm run test:coverage; the focused unit test coverage run completed, but the full coverage run did not finish in this environment and/or fails the repo-wide coverage gate locally, so please run the full gate (npm run test:ci and npm run test:coverage) in CI or locally before pushing.

---

Codex Task

[superagent-security]

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.22%. Comparing base (12147aa) to head (3b9b74d).
⚠️ Report is 65 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4977      +/-   ##
==========================================
- Coverage   94.22%   94.22%   -0.01%     
==========================================
  Files         439      439              
  Lines       38704    38693      -11     
  Branches    14100    14098       -2     
==========================================
- Hits        36468    36457      -11     
  Misses       1576     1576              
  Partials      660      660              

Flag	Coverage Δ
shard-1	50.78% <100.00%> (?)
shard-2	29.60% <0.00%> (?)
shard-3	31.31% <50.00%> (?)
shard-4	28.47% <0.00%> (?)
shard-5	34.45% <0.00%> (?)
shard-6	41.67% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/integrations/linear-adapter.ts	100.00% <100.00%> (ø)
src/integrations/project-tracker-adapter.ts	100.00% <100.00%> (ø)

🚀 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 result - manual review recommended

_{Review updated: 2026-07-11 12:49:57 UTC}

3 files · 1 AI reviewer · 2 blockers · readiness 93/100 · CI green · unstable

⏸️ Suggested Action - Manual Review

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Review summary
The PR removes Linear workspace milestone fuzzy matching entirely: `listOpenMilestones()` is stubbed to always return `[]` and `resolveTrackerMatches` unconditionally sets `milestone: null` for the Linear backend, falling back only to `findLinearNativeLink`'s confirmed attachment lookup. This is a correct source-layer fix (it stops fetching/exposing the workspace-scoped milestone names at all, rather than redacting them after the fact), the GitHub path is untouched, and tests were updated to assert both that milestones are never listed and that fuzzy suggestions no longer surface them, with a clear regression test for the exact oracle scenario described in the motivation. The now-unused pagination types (`LinearProjectMilestoneNode`, `ListProjectMilestonesResponse`) were cleanly removed alongside the dead code.

Nits — 5 non-blocking

• The `listOpenMilestones()` signature dropped the `ctx: ProjectTrackerContext` param entirely rather than keeping it unused — confirm no other caller outside the two files shown still invokes it with an argument expecting the old contract (TS structural typing accepts this, but worth a quick grep).
• The doc comment update is thorough, but the PR description doesn't link a tracking issue for the vulnerability itself (only references the original feat(agent): Linear adapter for project/milestone matching #3186 feature) — worth confirming there's an eligible issue this closes per repo convention.
• `test/unit/linear-adapter.test.ts` deleted the pagination/error-propagation tests for the old `listOpenMilestones` implementation along with the implementation — reasonable given the stub, but double check no other code path still relies on that pagination behavior being documented via tests.
• Consider a one-line changelog/comment near `findLinearNativeLink` noting that it's now the *only* source of Linear milestone matches, so a future contributor doesn't reintroduce fuzzy milestone matching without re-reading the full history.
• If there's an internal security-issue tracker entry for this oracle, link it explicitly in the PR description rather than only referencing the original feature issue feat(agent): Linear adapter for project/milestone matching #3186.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 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: 47 registered-repo PR(s), 39 merged, 423 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 47 PR(s), 423 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 47 PR(s), 423 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.
• 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