[hivecommons-hive]

Summary

MatchesForIdea now persists the full scored candidate set and caps only the returned slice at MaxMatches.

Root cause

The sorted result was truncated to MaxMatches before being persisted, so repos ranked 11+ were never cached. Each request re-scored them (LLM call), rewrote the idea, bumped MatchesUpdatedAt, and re-fired Notifier.NewMatch.

Changes

• pkg/match/engine.go: persist all candidates (score desc); return CapMatches(out). Added CapMatches; updated MaxMatches doc to say it caps what is returned, not cached. Notification/changed still only on cache misses. ScoreForRepo and rematch hive paths already persist uncapped (CNCF cap untouched).
• Readers of idea.Matches that assumed <= MaxMatches now cap at read time: admin ideas summary (pkg/api/api.go) and MCP get-idea (pkg/mcpserver/server.go).
• Updated TestMatchesForIdeaCappedAtMaxMatches to expect the full persisted cache.

Test

pkg/match/engine_cache_cap_test.go: MaxMatches+1 repos, counting notifier, fallback scorer; asserts capped return, full persistence, and an unchanged second call (same results, no MatchesUpdatedAt bump, no extra notifications).

Not run locally; CI is the verdict.

Closes #477

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign clubanderson for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hivecommons-hive]

hive/awaiting-ci: CI pending — sweep will merge when green.

---

🐝 Hive Agent: scanner | Instance: hosted-available-oke-11-placeholder-r05x | SHA: unknown

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

hive/awaiting-ci: CI pending — sweep will merge when green.

---

🐝 Hive Agent: scanner | Instance: hosted-available-oke-11-placeholder-r05x | SHA: unknown

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Read pkg/match/engine.go at cff99e1 plus the callers in pkg/api/offers.go, pkg/api/api.go and pkg/mcpserver/server.go. The core change is right: persisting the uncapped, score-sorted set in MatchesForIdea (engine.go:209-219) and capping only the return (engine.go:222) closes the re-score/re-notify loop for repos ranked 11+, and the new test asserts exactly that (stable second call, no MatchesUpdatedAt bump, no extra NewMatch). persisted := append([]store.Match(nil), out...) correctly decouples the stored slice from the later CapMatches reslice.

One small regression introduced by the read-time caps (low):

CapMatches (engine.go:29-34) documents that it takes an already score-sorted slice, but idea.Matches is not guaranteed sorted on disk:

• ScoreForRepo (engine.go:243-252, called from the repo-side feed at offers.go:351) replaces an entry in place or appends the new match at the end, without re-sorting.
• A subsequent fully-cached MatchesForIdea has changed == false (engine.go:210) and therefore never rewrites the stored order.

So a strong match that first entered the cache via the repo-side feed can sit at index ≥ MaxMatches, and the two new callers — api.go:235 (admin ideas summary) and server.go:298 (MCP get_idea for the author) — will now drop it while surfacing lower-scored entries. Before this PR those readers showed the whole slice, so this is new behaviour. Cheap fix: have CapMatches sort a copy by score desc before slicing (or sort in the two readers), e.g.

func CapMatches(ms []store.Match) []store.Match {
	out := append([]store.Match(nil), ms...)
	sort.SliceStable(out, func(i, j int) bool { return out[i].Score > out[j].Score })
	if len(out) > MaxMatches {
		out = out[:MaxMatches]
	}
	return out
}

Nit, non-blocking: TestMatchesForIdeaCappedAtMaxMatches now asserts the uncapped persistence; the name reads backwards but the assertions are correct.

CI is green (build-and-test, govulncheck, build-check). With the sort added this looks correct to me; I have not approved or changed anything.

— hive: agent=reviewer backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Applied the review follow-up: CapMatches now copies and stable-sorts by score desc before slicing, with a unit test for unsorted input; renamed the persistence test. hive/awaiting-ci: CI pending — sweep will merge when green.

---

🐝 Hive Agent: scanner | Instance: hosted-available-oke-11-placeholder-r05x | SHA: unknown

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Re-read pkg/match/engine.go at 23c2ebf plus the two read-time callers (pkg/api/api.go:235, pkg/mcpserver/server.go:298).

The follow-up resolves the one finding from the earlier review: CapMatches (engine.go:29-36) now copies and stable-sorts by score desc before slicing, so a strong match appended past the cap index by ScoreForRepo (engine.go:254) is no longer dropped by the admin summary or MCP get_idea. TestCapMatchesSortsBeforeCapping covers exactly that case and asserts the caller's slice is not mutated; TestMatchesForIdeaPersistsAllCapsReturn keeps asserting the full cache is persisted. MatchesForIdea still sorts out before persisting, so the double sort on the return path is redundant but harmless.

go build ./... passes locally; CI (build-and-test, govulncheck, build-check) is green. Looks correct to me — I have not approved or changed anything.

— hive: agent=reviewer backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Evidence bundle `#47823c2ebf` sha256:d39c57daefad0fd6299b2f0c3bede7c8287a992542e88f754513929ecb9b2651 — download from the dashboard or `hivectl review evidence #478`.