fix(#6006): pr_impact stops reporting zero merge conflicts when communities were never computed

[cajasmota]

grafel_pr_impact answered "do these branches conflict?" with "no", always — a false negative on a safety question, which is the worst direction to be wrong in. An agent reads absence of data as absence of risk.

Mechanism

Merge risk intersects the community sets each ref touches. Both producer (pr_impact.go:375) and consumer (:323) filter the ungrouped sentinel c < 0. With no community overlay every entity carries CommunityID = -1, so both filters dropped everything, the intersection was empty, and AnalyzeMergeRisk returned an empty risky-pair list — indistinguishable from a genuine no-conflict result.

And this was the permanent state, not an edge case. Verified two ways: cmd/grafel/index.go:1975-1991 states the per-repo Pass-4 pass no longer runs and algo fields stay at schema sentinels; runPass4Algorithms is retained but has no callers; carryForwardAlgoAttrs only copies from a prior doc that also has none. Empirically, no entity in any readable graph.fb carries a CommunityID. Reproduced through MCP before fixing: two refs with a genuine shared community returned "risky_pair_count":0.

Note the issue was already one correction deep — the original report claimed the opposite behaviour ("reports every ref pair as conflicting"), disproved by reading the filters.

Data source: the group overlay

groupCommunityStamper reads <group>-algo.json and stamps CommunityID onto each ref graph before analysis, mirroring applyGroupAlgoOverlay exactly so the two surfaces can never disagree on availability.

Restamping graph.fb was rejected deliberately: it would revive a per-repo Louvain whose partition is not the group partition every other grafel surface reports, so merge risk would be computed against a second, disagreeing community numbering.

Review confirmed no shared-state hazard — loadRefGraph materialises a fresh *Document per call, so in-place stamping cannot leak into other readers.

Availability is measured over the changed set, not the entity set

The first version of this fix reintroduced the bug in a worse costume, and review caught it.

CommunityDataAvailable was computed over the whole entity set, so any covered entity anywhere in the repo flipped it true — including when zero changed entities were covered. The test fixture concealed this: it stamped svc:NewA/svc:NewB into the overlay, entities that exist only on the feature refs and that the group-algo pass, computed from the indexed group union, cannot produce. Swapping in a production-shaped overlay and changing nothing else gave:

risky_pair_count=0   community_data_available=true

The exact scenario the control arm existed to detect returned a confident all-clear — #6006 again, now wearing an availability stamp that made it look more trustworthy than before the fix.

Now: availability follows the changed set, and changed_entities_without_community is reported at result, per-ref and single-mode level so partial coverage is legible rather than silent. An empty change set stays vacuously available — that is the live default-base path (conflicts mode diffs refs[0] against itself) and hard-erroring it would break every default call. Fixture rewritten to production shape: the overlay covers only pre-existing entities, conflict refs modify a covered entity, and separate add-only refs exercise the failing shape.

One fixture detail worth recording: perturbing EndLine to trigger modified-classification yielded changed_count: 0, because EndLine does not round-trip through graph.fb. Signature does (load.go:601).

Stale overlays are answered, not refused

The first version used ReadOverlay, which rejects stale overlays. Review demonstrated with a real git repo that this made a git checkout alone turn conflicts mode into a hard error: the staleness key is the graph.fb of whichever ref is currently checked out, so standing on a feature branch — the only posture from which anyone asks about conflicts — refused to answer, with the overlay fully covering both refs and the conflict entirely computable.

The window is not marginal. Measured constants: link debounce 10 s, link pass ~9 min, group-algo debounce 180 s, sweep 10 m. After any reindex of any repo in the group, conflicts mode would have errored for roughly 50 minutes.

A partition 50 minutes old is overwhelmingly the same partition. ReadOverlayAnyAge now applies a stale overlay and reports it (community_data_stale, overlay_computed_at); absent, corrupt and version-mismatched remain hard misses. Error causes are split — the previous message said "missing or stale" for both, so a user hitting the staleness path was told to "run/await a group index" when they had just done exactly that.

Also

• Third filter aligned: impacted_communities now drops c < 0, so the ungrouped bucket is no longer surfaced as community_id: -1.
• A non-nil pointer to a negative community id no longer counts as coverage. This was a ninth mutation review found surviving: no fixture produced that value (stripCommunities sets nil, and load.go:609 maps the fb -2 sentinel to nil), but it is reachable — stamp() writes the overlay value verbatim, and any legacy graph.json carries it. It would have set CommunityDataAvailable: true while all three filters dropped everything.
• Overlay read memoized on (path, mtime, size), parsed overlay treated as immutable so concurrent agents share it; staleness deliberately outside the key and recomputed per call; misses not cached. Previously re-read and unmarshalled per call — measured at 326 ms / 76 MB on the 31.9 MB corpus overlay, which matters on a 16 GB box running concurrent MCP agents.

Verification

16 mutations across both rounds, all killed. Independently re-verified: weakening availability back to always-true fails three tests including TestAnalyzePRImpact_AvailabilityFollowsChangedSetNotEntitySet.

go build ./... && go vet ./... && gofmt -l . clean. internal/graph/... (all 8 sub-packages) and internal/mcp green with raw exit codes via rtk proxy.

Review confirmed grafel_impact_radius scope=changeset — the canonical advertised name, with grafel_pr_impact a hidden alias — routes to the same handler, so this covers the surface agents actually use.

Known and disclosed

• Add-only PRs now hard-error in conflicts mode. Intended: their entities were never in the indexed group union, so we genuinely cannot place them. It is a common PR shape and the error will be seen; the message routes to single mode and blast radius. Flagged as a product call rather than settled.
• Partial coverage still under-reports. A PR modifying one covered entity and adding three uncovered ones reports available: true with changed_entities_without_community: 3. The verdict stands on what was placed; the count makes the gap legible. No weighting or threshold attempted.
• The tool-description budget (budget_test.go) caps descriptions at 80 chars, leaving room for exactly one fact. It was spent on the safety point: "PR impact + merge-risk. Conflicts mode errors (not 0 pairs) when uncomputed."

Independently adversarially reviewed.

Closes #6006

[cloudflare-workers-and-pages]

Deploying grafel with    Cloudflare Pages

Latest commit:	5eebb56
Status:	⚡️  Build in progress...

View logs