The problem

ENABLE_DFNR defaults to ON. When libdeepfilter is absent, CMake printed one STATUS line, set ENABLE_DFNR back to OFF, and continued — so every build afterwards succeeded cleanly with no further signal, while ENABLE_DFNR:BOOL=ON stayed in CMakeCache.txt the whole time. The cache flag looks correct precisely when the feature is missing.

The result: local builds silently diverge from what CI ships. All three release workflows (macos-dmg, appimage, windows-installer) run the setup step, so shipped binaries have always included DFNR — this only ever bit hand builds. Which is the bad half, since it means testing a change against a binary users don't run.

The only reliable way to notice was checking available under DFNR in get_state model=dsp at runtime.

Why documentation wasn't the fix

AGENTS.md already said to run setup-deepfilter.sh before cmake. It was framed as Optional, sat below the recipe block rather than in it, and the miss survived a full end-to-end read of that file — four consecutive DFNR-less builds followed. A documented instruction is not an enforcement point (Principle XII); the check has to live somewhere you cannot read past.

The change

• CMakeLists.txt — missing library is a FATAL_ERROR naming the fix, the opt-out, and the fact that a plain cmake --build cannot recover (detection is configure-time). Building without DFNR stays supported via -DENABLE_DFNR=OFF; it just has to be explicit rather than accidental.
• ci.yml — check-system-libs-linux never ran the setup step, so it was building DFNR-less by accident. It now passes -DENABLE_DFNR=OFF explicitly, next to the -DENABLE_RADE=OFF already in that invocation. (It's continue-on-error: true, a Debian sid canary, so it was never a gate either way.)
• AGENTS.md — setup script moves into the recipe as step 1; prose rewritten for the hard-fail; -j$(nproc) annotated with the macOS equivalent, which doesn't exist there and this file is read by agents on all four platforms.

The error a contributor now sees:

CMake Error at CMakeLists.txt:490 (message):
  DFNR (DeepFilterNet3) was requested but its library is missing:

      .../third_party/deepfilter/lib/darwin-arm64/libdeepfilter.a
    Fix:     run ./scripts/setup/setup-deepfilter.sh (Windows: scripts\setup\setup-deepfilter.ps1), then re-run cmake
    Opt out: configure with -DENABLE_DFNR=OFF

  A plain 'cmake --build' will NOT pick up a newly fetched library — this
  check runs at configure time.

Test plan

• Local build passes
  • Library present → configures, exit=0, DFNR (DeepFilterNet3) enabled — .../libdeepfilter.a
  • -DENABLE_DFNR=OFF → configures, exit=0, DFNR absent
  • Library stashed away, DFNR requested → exit=1 with the message above
  • Full build with DFNR on: 665 targets, 0 errors, 0 warnings; runtime get_state model=dsp reports DFNR available: true
• Behavior verified on a real radio if applicable — n/a, build-system change; DFNR availability confirmed on a FLEX-8600 via the automation bridge
• Existing tests pass (CI)

⚠️ Breaking change

Any checkout without third_party/deepfilter/lib/<platform>/ previously configured quietly and will now stop. That is the intent, but it will surprise people mid-work — worth a release-note line, and expect a couple of "my build broke" reports. The fix is one command and the error says so.

Reviewer note

This touches AGENTS.md, which is Tier 1 (@aethersdr/maintainers = @ten9876 only) — and @ten9876 authored it, so GitHub will block self-approval and no other CODEOWNER can satisfy that path. It needs an admin override, or the AGENTS.md hunk split out and committed separately. The CMakeLists.txt + ci.yml half is Tier 2 and reviewable normally.

Checklist

• Commits are signed
• No new flat-key AppSettings calls (Principle V) — n/a
• Code is clean-room (Principle IV)
• All meter UI uses MeterSmoother — n/a
• Documentation updated if user-visible behavior changed — AGENTS.md updated in this PR
• Security-sensitive changes reference a GHSA if applicable — n/a

🤖 Generated with Claude Code