fix(settings): read the two remaining LOOPOVER_* flags via the codebase truthy convention

[shin-core]

What & why

This codebase has one documented truthy convention for a LOOPOVER_* boolean env flag — trimmed, case-insensitive /^(1|true|yes|on)$/i — used by ~12 flag readers and documented in src/env.d.ts for a sibling flag. Two flags did not follow it, yet each asserted in its own JSDoc that its === "true" form was the convention:

// src/settings/duplicate-winner-mode.ts
export function isDuplicateWinnerEnabledGlobally(env) {
  return env.LOOPOVER_DUPLICATE_WINNER === "true";
}

So LOOPOVER_DUPLICATE_WINNER=1 — the value the convention regex accepts first, and the form env.d.ts publishes as valid for a sibling flag — read as OFF. A TRUE spelling, or a .env value with trailing whitespace (routine in Docker/compose), also read as OFF, with no warning: the flag simply behaved as unset. The observable effect is a silent policy difference (every duplicate sibling closed instead of the earliest claimant spared) that an operator who set =1 has no signal for.

The fix

Route both through the exact convention, byte-identical in shape to selfTuneFlagOn (src/settings/repository-settings.ts:12):

return /^(1|true|yes|on)$/i.test((env.LOOPOVER_DUPLICATE_WINNER ?? "").trim());

• Both JSDoc blocks now name /^(1|true|yes|on)$/i as the convention (as automation-bot-skip.ts does) instead of claiming exact-"true" is it.
• src/rules/advisory.ts's third restatement now names isDuplicateWinnerEnabledGlobally as the resolver rather than re-teaching the raw comparison.
• Unchanged: this only widens the accepted truthy set. "true" still enables; unset/empty still disables; resolveDuplicateWinnerEnabled / resolveOpenPrFileCollisionEnabled's inherit/off/enabled resolution and the already-"true" wrangler.jsonc values keep their exact current behaviour. No new shared helper is introduced and the ~12 convention-following call sites are untouched (out of scope, per the issue).

Tests

• isDuplicateWinnerEnabledGlobally and isOpenPrFileCollisionEnabledGlobally each return true for "1", "true", "TRUE", "yes", "on", " true " and false for undefined, "", "0", "false", "off", "no", "maybe" — the old "ON only for exact true" / "OFF for truthy-looking values" tests are replaced (they fail on main with the new convention).
• Regression (settings(flags): LOOPOVER_DUPLICATE_WINNER and LOOPOVER_OPEN_PR_FILE_COLLISION reject the repo's own truthy convention #10054): resolveDuplicateWinnerEnabled(isDuplicateWinnerEnabledGlobally({ LOOPOVER_DUPLICATE_WINNER: "1" }), "inherit") is true — the =1 form enables the feature end-to-end through the resolver, not just the global reader.

Validation

• Both changed predicate files are at 100% diff coverage line and branch (the new ?? "" nullish arm is exercised on both the absent and present sides); advisory.ts is a JSDoc-only edit.
• npm run typecheck clean for these files (the only local errors are a pre-existing missing-release-please-dep phantom in unrelated release tooling, present on bare main).
• git diff --check clean; no schema/route/env-reference/wrangler change, so no generated artifact is affected.

Closes #10054

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-31 07:01:06 UTC}

5 files · 1 AI reviewer · no blockers · readiness 86/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR fixes a genuine correctness bug: two LOOPOVER_* flag readers used exact `=== "true"` comparison instead of the codebase's documented `/^(1|true|yes|on)$/i` truthy convention used elsewhere (e.g. selfTuneFlagOn), so setting `LOOPOVER_DUPLICATE_WINNER=1` or `TRUE` silently read as OFF. The fix is a straightforward, byte-identical port of the existing convention regex, JSDoc is corrected to stop misdescribing the old behavior as the convention, and tests are updated to cover the newly-accepted truthy values plus an end-to-end resolver check. Scope is appropriately narrow — only the two non-conforming flags are touched, the ~12 already-conforming call sites are left alone, and behavior for existing 'true' values is unchanged.

Nits — 4 non-blocking

• The regex `/^(1|true|yes|on)$/i` is now duplicated in three places (duplicate-winner-mode.ts, open-pr-file-collision-mode.ts, and presumably selfTuneFlagOn) — consider extracting a shared `isTruthyFlag(value)` helper to prevent future drift, though this is out of scope per the PR's stated exclusion of the ~12 convention-following sites.
• src/rules/advisory.ts:379 JSDoc update is a pure comment change with no behavioral effect — fine, but worth double-checking no other comment in the file still references the old `=== "true"` wording for these two flags.
• Consider a follow-up issue to extract the shared truthy-flag regex/helper referenced in three files now, to guard against a fourth flag reintroducing the same bug.
• The PR description says it closes/addresses settings(flags): LOOPOVER_DUPLICATE_WINNER and LOOPOVER_OPEN_PR_FILE_COLLISION reject the repo's own truthy convention #10054 per the external brief — confirm that reference is present in the actual PR body for issue-linking compliance.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#10054
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 65 registered-repo PR(s), 50 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	shin-core; Gittensor profile; 65 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
Both flag readers now use the exact `/^(1|true|yes|on)$/i.test((env.X ?? "").trim())` pattern matching selfTuneFlagOn, both JSDoc blocks name the correct convention, the stale advisory.ts comment is corrected to reference the resolver, and resolve*Enabled functions/wrangler.jsonc values are left untouched as required, with tests updated to verify the widened truthy set.

Review context

• Author: shin-core
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 65 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• Then work through the remaining 1 step in the Signals table above.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.69%. Comparing base (d301523) to head (a13d030).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main   #10097       +/-   ##
===========================================
- Coverage   91.88%   79.69%   -12.20%     
===========================================
  Files         930      285      -645     
  Lines      113852    59040    -54812     
  Branches    27473     8808    -18665     
===========================================
- Hits       104615    47051    -57564     
- Misses       7940    11694     +3754     
+ Partials     1297      295     -1002     

Flag	Coverage Δ
backend	98.13% <100.00%> (+2.46%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/rules/advisory.ts	98.09% <ø> (ø)
src/settings/duplicate-winner-mode.ts	100.00% <100.00%> (ø)
src/settings/open-pr-file-collision-mode.ts	100.00% <100.00%> (ø)

... and 778 files with indirect coverage changes

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.