fix(validator): DEV_MODE=false enables the maintainer-filter bypass it should disable

[RealDiligent]

Summary

DEV_MODE gates the maintainer filters via not os.environ.get('DEV_MODE'), which tests for presence rather than value. Every non-empty string is truthy in Python, so:

.env line	operator intent	actual behaviour
DEV_MODE=1 / DEV_MODE=true	bypass on	bypass on (correct)
DEV_MODE=false	bypass off	bypass ON
DEV_MODE=0 / off / no	bypass off	bypass ON
(unset)	bypass off	bypass off (correct)

An operator who writes DEV_MODE=false to turn the flag off gets the exact opposite: _maybe_add_pr stops dropping OWNER/MEMBER/COLLABORATOR PRs, _should_skip_merged_mirror_pr's defensive recheck stops firing, and _should_include_issue stops dropping maintainer-discovered issues. That validator then scores maintainer contributions the rest of the network rejects, and diverges from consensus on every miner it evaluates.

.env.example makes this a realistic keystroke rather than a hypothetical: it already ships STORE_DB_RESULTS=false, so KEY=false is the idiom this project teaches its own operators. Today DEV_MODE has no working "off" value — the only way to disable it is to remove the line entirely.

Root cause

os.environ.get('DEV_MODE') returns the string 'false', and bool('false') is True. The check never looks at the value.

Fix

Parse by value in dev_mode_enabled(), placed next to STORE_DB_RESULTS in the validator config module and following the convention already established there:

STORE_DB_RESULTS = os.getenv('STORE_DB_RESULTS', 'false').lower() == 'true'   # existing

It is read at call time rather than at import so per-process toggling (and the existing monkeypatch.setenv tests) keep working. 1/true/yes/on remain truthy, so existing DEV_MODE=1 setups are unaffected; only the falsy spellings change, and they change to what they say.

Why this is not the #1067/#1069 pattern

Those were closed — correctly — as hardening parsers against input the team itself controls (master_repositories.json is maintainer-curated; the mirror API is gittensor-owned and emits real JSON booleans). This is a different source: DEV_MODE is operator-supplied, set by independent validator operators in their own .env, and the value that misfires is the one .env.example trains them to write. It is an operator-facing footgun in a flag that disables an anti-gaming filter, not defence against schema drift the team owns.

Related Issues

None. Self-contained, self-evident fix; no linked issue filed.

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation
• Other (describe below)

Testing

• Tests added/updated
• Manually tested

Added test_dev_mode_disabled_values_keep_maintainer_skip, parametrized over 0, false, off, no, '' and ' ', asserting the OWNER PR is still dropped and only the CONTRIBUTOR PR loads. It fails on test and passes here.

The existing test_dev_mode_bypasses_maintainer_skip (DEV_MODE=1) still passes on both the PR and issue-discovery surfaces, pinning backward compatibility.

Full suite: 970 passed, 0 failed, 0 skipped; ruff check, ruff format --check, pyright and vulture all clean.

Checklist

• Code follows project style guidelines
• Self-review completed
• Changes are documented (if applicable)

No CLI surface is touched, so the before/after evidence rule does not apply.