Severity: HIGH
Location: src/queue/processors.ts:8458
Found via a full-system adversarial audit of the ORB review/scoring engine (2026-07-15) — 2 independent skeptic passes, both had to vote "confirmed" for this to survive.
Failure scenario
The live webhook-driven gate evaluation calls buildSlopAssessment with only { changedFiles, description, inDuplicateCluster } (processors.ts:8458-8471) -- no commitMessages, tests, testFiles, hasLinkedIssue, or issueDiscoveryLane. grep confirms processors.ts never fetches commit messages at all (no 'commitMessages', 'pr.commits', or 'listCommits' anywhere in the file). buildLowQualityCommitMessageFinding (packages/loopover-engine/src/signals/slop.ts:221-235) guards on if (input.commitMessages === undefined || input.commitMessages.length === 0) return null; -- since commitMessages is always undefined on this path, this detector unconditionally returns null in production, no matter how generic or empty the PR's actual commit subject is (e.g. a PR whose sole commit message is literally "wip" or "." scores 0 from this signal on the live gate).
Impact
SLOP_WEIGHTS.lowQualityCommitMessage=15 (slop.ts:74) and SLOP_RUBRIC_MARKDOWN (slop.ts:79-95, item 'generic or empty commit message') both advertise this as one of the seven active deterministic signals feeding the score that is 'the ONLY thing allowed to gate (block)' per this file's own top-of-function comment (slop.ts:63-68) -- but it is structurally dead weight on the real gate. Meanwhile the MCP self-review tool (src/mcp/server.ts:1022-1024, 3616) and the API preflight endpoint (src/api/routes.ts:462/482-484, 3083) DO wire commitMessages/hasLinkedIssue/issueDiscoveryLane through to the same buildSlopAssessment function -- so a contributor running the loopover-miner/loopover-mcp pre-submit predictor sees a slopRisk that includes this penalty, while the actual live gate that decides merge/auto-close silently never applies it. This is a real predicted-vs-actual score mismatch: a contributor can 'pass' their local self-review at a score the live gate will never reproduce, and conversely the anti-slop protection is 15-30 points weaker than the rubric documents for any PR relying on this signal (e.g. a borderline PR at slopRisk=45 that should reach 60 with a generic commit message stays under the block threshold).
Severity: HIGH
Location:
src/queue/processors.ts:8458Found via a full-system adversarial audit of the ORB review/scoring engine (2026-07-15) — 2 independent skeptic passes, both had to vote "confirmed" for this to survive.
Failure scenario
The live webhook-driven gate evaluation calls buildSlopAssessment with only { changedFiles, description, inDuplicateCluster } (processors.ts:8458-8471) -- no commitMessages, tests, testFiles, hasLinkedIssue, or issueDiscoveryLane. grep confirms processors.ts never fetches commit messages at all (no 'commitMessages', 'pr.commits', or 'listCommits' anywhere in the file). buildLowQualityCommitMessageFinding (packages/loopover-engine/src/signals/slop.ts:221-235) guards on
if (input.commitMessages === undefined || input.commitMessages.length === 0) return null;-- since commitMessages is always undefined on this path, this detector unconditionally returns null in production, no matter how generic or empty the PR's actual commit subject is (e.g. a PR whose sole commit message is literally "wip" or "." scores 0 from this signal on the live gate).Impact
SLOP_WEIGHTS.lowQualityCommitMessage=15 (slop.ts:74) and SLOP_RUBRIC_MARKDOWN (slop.ts:79-95, item 'generic or empty commit message') both advertise this as one of the seven active deterministic signals feeding the score that is 'the ONLY thing allowed to gate (block)' per this file's own top-of-function comment (slop.ts:63-68) -- but it is structurally dead weight on the real gate. Meanwhile the MCP self-review tool (src/mcp/server.ts:1022-1024, 3616) and the API preflight endpoint (src/api/routes.ts:462/482-484, 3083) DO wire commitMessages/hasLinkedIssue/issueDiscoveryLane through to the same buildSlopAssessment function -- so a contributor running the loopover-miner/loopover-mcp pre-submit predictor sees a slopRisk that includes this penalty, while the actual live gate that decides merge/auto-close silently never applies it. This is a real predicted-vs-actual score mismatch: a contributor can 'pass' their local self-review at a score the live gate will never reproduce, and conversely the anti-slop protection is 15-30 points weaker than the rubric documents for any PR relying on this signal (e.g. a borderline PR at slopRisk=45 that should reach 60 with a generic commit message stays under the block threshold).