You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(review): fleet-wide gaming-pattern detector for the self-host orb fleet (#2350) (#5083)
Extends computeFleetAnalytics (src/orb/analytics.ts) with a more targeted
detection signal than the existing single-metric outlier check: an instance
whose decided-PR volume is unusually high, whose merge-precision is
unusually high, AND whose reversal-rate is unusually low -- all three
simultaneously -- fits the exact "mass-submitting only trivially-safe PRs to
inflate merge-precision" signature the issue describes. A high-precision
instance alone isn't suspicious (could be a genuinely careful team); combined
with abnormal volume and suspiciously few reversals, it is.
Detection only: gamingPatternFlags is a new read-only field surfaced on the
existing operator dashboard tile set and the operator-only MCP
gittensory_get_fleet_analytics tool summary -- nothing acts on it
automatically, nothing here touches the live gate, and instanceId is the
same opaque HMAC-derived handle already used throughout this pipeline
(orb-collector.ts), never a login or anything more identifying.
Scope note (see the module's own doc comment): this flags a self-hosted
INSTANCE, never an individual miner -- the fleet pipeline carries no
per-actor identity by deliberate, repeatedly-documented design
(review_audit has no login column; predicted_gate_calibration_ledger is
explicitly never-exported, citing this issue as the reason why). A genuine
per-miner detector would require adding a new anonymized per-actor signal to
the export pipeline, a separate privacy-sensitive design decision deserving
its own focused issue.
Also out of scope: "duplicate-claim-election win-rate skew"
(isDuplicateClusterWinnerByClaim) is not implemented. Its outcome is never
persisted anywhere in this pipeline -- only the losing side of a duplicate
cluster produces a finding, with no cluster id and no actor linkage, so
there is no winner data to measure a win-rate from. No proxy is implemented;
a misleading one would be worse than none.
Advances #2350 (does not close it -- the win-rate-skew and per-miner
sub-deliverables remain genuinely unbuildable from data that exists today)
0 commit comments