Severity: HIGH
Location: src/db/repositories.ts:3942
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
markPullRequestLinkedIssueHardRuleViolated (src/db/repositories.ts:3942-3952) writes linkedIssueHardRuleViolatedAt via COALESCE only -- there is no code path anywhere in src/ that ever resets this column back to null (verified by grep across the repo). mergeLinkedIssueHardRuleWithPersistedViolation (src/review/linked-issue-hard-rules.ts:152-159) forces violated: true whenever persisted.violatedAt is non-null, REGARDLESS of what the live evaluation says -- including when live is undefined because resolveLinkedIssueHardRule's anyRuleOn check (src/review/linked-issue-hard-rules.ts:183-188) is false (every rule now set to 'off'). Concretely: a maintainer enables ownerAssignedClose: block; PR #77 links an issue that (perhaps incorrectly, e.g. due to a stale assignee) trips the rule, and markPullRequestLinkedIssueHardRuleViolated persists the violation. The maintainer realizes the rule is too aggressive and flips ownerAssignedClose (and all other linkedIssueHardRules) to 'off' in .gittensory.yml. On the next pass, resolveLinkedIssueHardRule returns undefined (no rule is on), but mergeLinkedIssueHardRuleWithPersistedViolation still returns {violated: true, reason: persisted.reason}, and src/settings/agent-actions.ts:958-979's willCloseForLinkedIssue (driven purely by .violated === true) still closes PR #77 once the verify-delay elapses.
Impact
A maintainer's own current, deliberate configuration change (disabling a hard rule) cannot undo its effect on PRs already caught by the old configuration -- those PRs stay condemned to a one-shot auto-close even though the rule that flagged them no longer exists. This is a real operational trap for exactly the iterative gate-tuning workflow this repo's maintainer uses (turn a rule on, discover a false positive, turn it off) -- the affected PR is never rescued by the fix.
Severity: HIGH
Location:
src/db/repositories.ts:3942Found 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
markPullRequestLinkedIssueHardRuleViolated (src/db/repositories.ts:3942-3952) writes
linkedIssueHardRuleViolatedAtvia COALESCE only -- there is no code path anywhere in src/ that ever resets this column back to null (verified by grep across the repo). mergeLinkedIssueHardRuleWithPersistedViolation (src/review/linked-issue-hard-rules.ts:152-159) forcesviolated: truewheneverpersisted.violatedAtis non-null, REGARDLESS of what the live evaluation says -- including when live isundefinedbecause resolveLinkedIssueHardRule'sanyRuleOncheck (src/review/linked-issue-hard-rules.ts:183-188) is false (every rule now set to 'off'). Concretely: a maintainer enablesownerAssignedClose: block; PR #77 links an issue that (perhaps incorrectly, e.g. due to a stale assignee) trips the rule, and markPullRequestLinkedIssueHardRuleViolated persists the violation. The maintainer realizes the rule is too aggressive and flipsownerAssignedClose(and all other linkedIssueHardRules) to 'off' in.gittensory.yml. On the next pass, resolveLinkedIssueHardRule returnsundefined(no rule is on), but mergeLinkedIssueHardRuleWithPersistedViolation still returns{violated: true, reason: persisted.reason}, and src/settings/agent-actions.ts:958-979'swillCloseForLinkedIssue(driven purely by.violated === true) still closes PR #77 once the verify-delay elapses.Impact
A maintainer's own current, deliberate configuration change (disabling a hard rule) cannot undo its effect on PRs already caught by the old configuration -- those PRs stay condemned to a one-shot auto-close even though the rule that flagged them no longer exists. This is a real operational trap for exactly the iterative gate-tuning workflow this repo's maintainer uses (turn a rule on, discover a false positive, turn it off) -- the affected PR is never rescued by the fix.