[w5jwp]

Summary

Fixes #6382

Adds one step to static-checks.yml that fails a PR introducing Q_OS_MAC into C/C++/Objective-C source. Qt 6.12 deprecates the macro, but only a macOS build warns, so the Linux and Windows lanes cannot see it come back. This is the optional gate the #6355 review suggested and asked to keep out of that PR.

Draft until #6355 merges. main still has 109 source-file hits, so this step is red on main and on any branch cut from it. It passes on #6355's head. Once #6355 is in, this PR should be rebased and marked ready.

git grep -nw Q_OS_MAC -- '*.cpp' '*.h' '*.hpp' '*.mm' '*.m' ':!third_party'

• -w does not match Q_OS_MACOS (_ is a word character), so the new spelling is fine.
• A hit emits a ::error file=,line= annotation per line and fails the job. Exit 1 from git grep (no hits) passes; any other non-zero exit fails the job rather than passing silently.
• Source files only: docs, changelog and review prose that name the old macro do not trip it. third_party/ is excluded as vendored. The workflow's own comment is a .yml, so it cannot match itself.
• It sits beside the other --strict gates with if: ${{ !cancelled() }}, so a failure above still lets it report. Static checks is a required context, so this blocks a merge, which is the intent.

Not included: the other deprecated Apple macros (Q_OS_MACX, Q_OS_OSX, Q_OS_MAC64, Q_OS_MAC32, Q_OS_DARWIN64, Q_OS_DARWIN32). None appear in the tree today; adding them is a change to the pattern.

Constitution principle honored

Principle VIII, Evidence Over Assertion. The gate is shown failing on a tree that has the macro and passing on one that does not, below.

Test plan

Run locally. The step's script was extracted from the workflow file and run with bash -e in a detached worktree of each tree:

• origin/main (Q_OS_MAC present): exit 1, 109 ::error file=...,line=... lines, first src/aetherd/main.cpp:18
• chore(build): Q_OS_MAC becomes Q_OS_MACOS, silencing the Qt 6.12 clang deprecation. Principle VIII. #6355 head ca96f047 (no Q_OS_MAC): exit 0, no output
• The 109 are the source-file subset of the 117 lines chore(build): Q_OS_MAC becomes Q_OS_MACOS, silencing the Qt 6.12 clang deprecation. Principle VIII. #6355 renames; the other 8 are in .py, .md and .yml, which the gate deliberately ignores
• Local build: not applicable, no source, CMake or build changes
• Behavior on a real radio: not applicable
• Existing tests pass (CI): expected red on Static checks until chore(build): Q_OS_MAC becomes Q_OS_MACOS, silencing the Qt 6.12 clang deprecation. Principle VIII. #6355 merges, for the reason above

Checklist

• Commits are signed (docs/COMMIT-SIGNING.md), SSH signing with the w5jwp signing key
• No new flat-key AppSettings calls (Principle V): none
• Code is clean-room (Principle IV): a git grep over this repo's own source
• All meter UI uses MeterSmoother: no UI touched
• Documentation updated if user-visible behavior changed: nothing user-visible. CHANGELOG.md is not touched
• Security-sensitive changes reference a GHSA if applicable: not applicable

🤖 Generated with Claude Code

[aethersdr-agent]

Static checks is red on ef7fdbb, and it is the step this PR adds — nothing else. The other 22 --strict gates in the job are green, and the only failure is:

No deprecated Q_OS_MAC — failure

(run 38150078635.)

So this is the red you predicted in the body, not a defect in the step. No change is needed on this branch.

Why, concretely

static-checks.yml triggers on pull_request and uses actions/checkout with no ref:, so what it checks out is refs/pull/6383/merge — this branch already merged into main. The gate therefore greps a tree that contains main's Q_OS_MAC uses, and I reproduced that locally against origin/main (not from the CI log, which only exposes step conclusions):

$ git grep -nw Q_OS_MAC origin/main -- '*.cpp' '*.h' '*.hpp' '*.mm' '*.m' ':!third_party' | wc -l
109
$ git grep -nw Q_OS_MAC origin/main -- ':!third_party' | wc -l
117

109 source hits, 117 across all file types — the two numbers in your test plan, exactly. First hit src/aetherd/main.cpp:18, also as you report. The step is doing precisely what it says on the tin.

One thing the merge ref buys you

Because the checked-out tree is the merge ref and not the branch head, once #6355 lands you should not need a rebase to turn this green — a re-run (or GitHub's "Update branch") recomputes refs/pull/6383/merge against the new main, which will have zero source hits. A rebase is still good hygiene and makes the history read cleanly; it just isn't the thing standing between this PR and a green check. I can't trigger a re-run to prove that, so treat it as "should be enough" rather than verified.

The flip side is that merge order is forced: Static checks is a required context (per the header in .github/workflows/static-checks.yml), so #6355 has to merge first, then this. You have that right in the body.

On the step itself

The script reads correctly to me:

• git grep -nw — _ is a word character, so Q_OS_MACOS is not matched. Confirmed against the chore(build): Q_OS_MAC becomes Q_OS_MACOS, silencing the Qt 6.12 clang deprecation. Principle VIII. #6355 spelling.
• The rc handling is the part people usually get wrong, and you got it right: grep exit 1 means no matches and passes, exit 0 means hits and fails with annotations, and anything else fails loudly rather than being swallowed. The || rc=$? also keeps the assignment from tripping the runner's bash -e.
• Source globs plus :!third_party keeps the docs, CHANGELOG.md and review prose that legitimately name the old macro from tripping it — and as you note, the step's own comment is in a .yml, so it can't match itself.

No Copilot or reviewer findings on the PR as of now, so there's nothing cross-referenced to the failure.

Suggested next step

If it isn't already marked a draft on GitHub, converting it would keep it from reading as "contributor PR with red CI" to anyone scanning the queue. Otherwise just park it behind #6355.

Thanks for splitting the gate out of #6355 rather than bundling it — a ratchet that lands separately from the cleanup it protects is much easier to review, and the fail-on-main / pass-on-#6355-head evidence is the right way to show a new gate actually bites. 73

---

_{🤖 aethersdr-agent · cost: $4.6119 · model: claude-opus-5}

[ten9876]

Issue fit

Yes, with the documented dependency on #6355. #6382 requests a required-context ratchet preventing the deprecated macro from returning after cleanup. The single step implements the issue’s exact glob, excludes vendored/prose files, annotates hits, and distinguishes no hits from Git failure. The expected current-main red is a dependency, not a defect in the step.

Scope

File/group	Change	Claimed?	Verdict
.github/workflows/static-checks.yml:364–377	Q_OS_MAC source ratchet, annotations, and explicit git error handling	Yes, exactly #6382’s requested gate	In scope

Everything in the diff is explained by the issue and body. One commit, authored 2026-10-11, one workflow, no changes to application behavior, no dependency or public interface additions. The body’s scope checklist holds.

Blockers

None in the implementation. Merge #6355 first and obtain a fresh green required check before landing this gate.

Nits (non-blocking)

• Non-blocking — .github/workflows/static-checks.yml:370: the “C/C++/Objective-C source” description overstates the selected extensions. The globs omit *.c, despite tracked C sources such as tests/vita_packet_admission_test.c. In an isolated tracked fixture, src/plain.c containing Q_OS_MAC passes this gate. This matches the issue’s proposed command, and no present C hit is lost by the migration, so it is a completeness nit rather than a blocker. Add '*.c' if the intended policy really includes C, or narrow the prose to the listed extensions.

Verification and attacks

• Also ran the unchanged extracted script directly in the existing #6355-head scratch worktree: exit 0 with no output.
• Extracted the exact run: script and executed with bash -e: grep against #6383 head returned 109 annotations and exit 1; against #6355 head returned zero output and exit 0. Revision selection was supplied through a shell wrapper solely to inspect committed trees without full checkouts; the wrapper adds revision prefixes, so those annotation paths are not treated as runner output.
• Ran the unchanged script in an isolated Git fixture with tracked source/docs/vendor files. Q_OS_MACOS, PREFIX_Q_OS_MAC, and Q_OS_MAC_EXTRA passed; replacing the C++ guard with Q_OS_MAC failed with ::error file=src/probe.cpp,line=1::Q_OS_MAC is deprecated in Qt 6.12; use Q_OS_MACOS. Deprecated tokens in docs and third_party were excluded. This mutation establishes that the new gate bites.
• Injected git statuses 0, 1, 2 and 128 into the exact shell script: gate statuses were 1, 0, 2 and 128 respectively. Error paths fail closed under bash -e instead of treating grep failure as no matches.
• Read workflow trigger, checkout and step condition: pull_request merge checkout, no explicit ref override, and !cancelled() allow this step to report despite earlier failures. No changed test sources or socket tests; no build or demo app session because this is only a workflow text gate. Automated code-review skill was unavailable; performed the equivalent manual pass.

CI is intentionally red on Static checks until #6355 lands; the other four reported checks succeeded. Earliest head run creation was 2026-10-11 15:09:07Z, before current main’s commit time, 15:12:10Z. The pull_request merge snapshot is therefore stale, and strict branch protection does not force it current. Do not assume rerunning the old workflow refreshes its SHA: create a fresh run against the updated merge ref after #6355 lands (for example through the planned rebase/update).

Recommendation

Approve with nits, once #6355 is merged and the updated integration passes required checks. Match, no-match, word-boundary, exclusions, mutation and error-status cases survived the empirical checks. Clarify or extend the C coverage; this is not an approval event.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-12T03:20:25.591874Z	ef7fdbb	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[aethersdr-agent]

Issue fit

Yes. #6382 asks for one static-checks.yml step that fails a PR re-introducing Q_OS_MAC into C/C++/Objective-C source, scoped to source globs, excluding third_party/, using -w so Q_OS_MACOS is not matched, annotating per file and line, and failing loudly on a git grep exit other than 0 or 1. The diff is that step and nothing else. Every acceptance point in the issue maps to .github/workflows/static-checks.yml:367-379, and I reproduced each one (below). The issue's own out-of-scope list — the sibling Apple macros, and the unified_title_bar_test tracker — is respected.

Scope

File / group	What it changes	Claimed by title/body	Verdict
.github/workflows/static-checks.yml:364-379	One run: step in the existing static-checks job, beside the other --strict gates, with if: ${{ !cancelled() }} and a 3-line rationale comment	Yes — this is the whole PR	In scope

Everything in the diff is explained by the issue. No source, CMake, test, docs or CHANGELOG.md change; the body's "CHANGELOG.md is not touched" self-certification is accurate, and git diff --stat is one file, +14/−0. No new public surface, no deleted guard, no - lines at all.

One scope consequence worth stating plainly rather than burying: Static checks is a required context, so this step becomes merge-gating for every PR — a whole-tree ratchet, not a diff check. The body says so explicitly, and it is the stated intent, so I read it as disclosed rather than smuggled. Expect it to go red on any in-flight branch cut before #6355 that adds a new Q_OS_MAC line, because CI judges the merge tree; that is the gate working.

Blockers

None.

Nits

All non-blocking.

• .github/workflows/static-checks.yml:374 — .inc is not in the glob list. Four tracked .inc files are #included into translation units (src/core/Nr2GammaTables.inc, src/core/backends/anan/AnanDroopDefaultTables.inc, src/gui/SpeLcdFontRom.inc, tests/SeamSignalProbeTable.inc), so a platform guard added in one would compile and warn on macOS while the gate stayed green. In practice all four are generated data tables with no preprocessor guards, so this is theoretical. (*.c is moot in the other direction — the 14 tests/*.c files are plain C and cannot reach qsystemdetection.h.) If you want it, the one-word fix:

          hits=$(git grep -nw Q_OS_MAC -- '*.cpp' '*.h' '*.hpp' '*.mm' '*.m' '*.inc' ':!third_party') || rc=$?

• .github/workflows/static-checks.yml:374 — no escape hatch for a prose mention in source. A .cpp/.h comment that names the macro (// migrated from Q_OS_MAC, or a comment explaining this very gate) fails the job with no way to annotate it, unlike check_qsettings.py's ALLOWED table. The step's own 3-line comment is only safe because .yml is not scanned — which the body notes, and which is a real piece of care, but it means the gate cannot be explained in the code it polices. Not worth an allowlist for a 7-line check; worth knowing before someone hits it.
• The PR body is now stale. It still reads "Draft until #6355 merges. main still has 109 source-file hits, so this step is red on main" and "Existing tests pass (CI): expected red on Static checks". #6355 landed (7ac07b039 on main), the branch has main merged in at 5a1f14a, and all five checks are green there. Worth a one-line edit so the body does not contradict the check list a maintainer is looking at.

Other tools' findings

security-audit (CodeGuard) ran over the file. All 14 CodeGuard findings are false positives, and I am dropping every one:

• The 12 CS-VLN-CMDI-BACKTICK hits (lines 14, 36, 81, 172, 309, 332, 340, 355, 399, 414, 469, 531) are backticks inside YAML # comments used as Markdown code spans, plus escaped \` inside the heredoc at 528-543 — none reach a shell. This is the rule's known lexical-match behaviour.
• CS-VLN-CMDI-SUBSHELL at 496 is FILES=$(cat /tmp/changed_gui_files.txt | tr '\n' ' ') — a fixed path, no untrusted text in the command.
• CS-VLN-CMDI-ENVVAR at 534 expands ${SUMMARY} inside a heredoc; bash does not re-parse expansion results.

All 14 are also on pre-existing lines, not on the added step. The audit confirmed the new step is clean: no ${{ }} interpolation, no secrets, "$hits" quoted on the pipe, a literal awk program, and no reachable ::add-mask/::stop-commands smuggling through the annotation (the ::error file= prefix is fixed and git quotes paths containing newlines). The decisive structural fact is that this workflow triggers on pull_request, not pull_request_target, so the job already executes PR-authored tools/check_*.py at its own privilege level — there is no boundary for an interpolation to cross.

The audit did raise one pre-existing hardening item outside this PR's diff, for a maintainer rather than this author: static-checks.yml:473 and :486 interpolate ${{ github.base_ref }} straight into run: text (git merge-base HEAD "origin/${{ github.base_ref }}"). The double quotes do not neutralize it, because ${{ }} is textual substitution before bash parses the line. github.base_ref is a base-repository branch name and is not on GitHub's untrusted-context list, so it is not exploitable here — the fix if those lines are ever touched is env: BASE_REF: ${{ github.base_ref }} and "origin/$BASE_REF". CodeGuard did not flag these. Worth its own issue, not a change to this PR.

What I tried to break

• The obvious way to make this gate useless: a false positive on the new spelling. Q_OS_MACOS appears across 19+ files in the head checkout. I ran the step's exact script against the head tree: exit 0, "GATE PASSED", zero annotations. -w holds because _ is a word character, so the gate does not fire on the very migration it protects.
• Does it actually bite? I appended #ifdef Q_OS_MAC / #endif // Q_OS_MAC to a tracked src/core/SystemInfo.cpp and re-ran: two correctly-formed ::error file=src/core/SystemInfo.cpp,line=409::… annotations and exit 1. Reverted. A gate that only passes is not a gate, and this one fails on the thing it names.
• The git grep exit-code trap, which is where these checks usually rot. grep exit 1 means no matches; the naive || true spelling passes silently on exit 128 too. I ran the step body outside a git repository: ::error::git grep failed (exit 128) and exit 128, not a pass. Under the runner's default bash -e, hits=$(…) || rc=$? also keeps the assignment from aborting the step. This is handled correctly.
• The body's load-bearing numeric claim. It says origin/main had 109 source-file hits, first at src/aetherd/main.cpp:18. git grep -nw Q_OS_MAC ef7fdbb -- '*.cpp' '*.h' '*.hpp' '*.mm' '*.m' ':!third_party' | wc -l → 109, matching exactly.
• The Qt claim, which I could only partly verify. My local Qt 6.11.2 qsystemdetection.h:157 has #define Q_OS_MAC // FIXME: Deprecate with no pragma, while its siblings in the same block (Q_OS_MAC64, Q_OS_MAC32, Q_OS_DARWIN64/32, Q_OS_MACX, Q_OS_OSX) all carry #pragma clang deprecated. That is consistent with the pragma arriving in 6.12, and issue #6354 quotes the 6.12.0 header directly. I have no 6.12 header to read, so the "Qt 6.12 deprecates it" premise rests on #6354's quote plus the 6.11-vs-siblings shape, not on my own reading of 6.12.
• Is the gate redundant with a build lane? No -Werror, /WX or WARNINGS_AS_ERRORS anywhere in CMakeLists.txt or ci.yml, and check-macos is a build-only job — so the macOS lane really does stay green on the deprecation warning. The gate is not duplicating an existing failure.
• Does the step have a working tree to grep? It sits in the static-checks job, which does actions/checkout with fetch-depth: 0 (static-checks.yml:170-173), so git grep runs against a full checkout from the repo root. (git grep sees tracked files only; in CI everything is tracked, so that is not a hole.)
• The re-introduction vectors #6354 named. AGENTS.md:202, GEMINI.md:57 and .github/copilot-instructions.md:57 now all say Q_OS_MACOS; tools/docs/gen_reference.py and the two ci.yml comments are clean. A whole-tree git grep -nw Q_OS_MAC finds only this step's own comment and one CHANGELOG.md line. The guidance that was re-adding the macro is fixed, so the gate is guarding zero rather than papering over a source of new hits.
• CI, read rather than assumed. Head 5a1f14a is green on all five checks. ef7fdbb was red with only No deprecated Q_OS_MAC failing while all 22 sibling --strict steps passed — which is both the !cancelled() design working and a live red/green demonstration of the gate better than my local simulation. The red was the pre-#6355 merge tree's 109 hits, exactly as the body predicted.
• Could not check: I cannot run the GitHub Actions runner, so the annotation rendering (::error file=,line=:: surfacing on the Files-changed tab) is reasoned from the documented workflow-command format, not observed. Every other finding above is from a command I ran against the head checkout; nothing in this review is reasoned at runtime on a radio or in a built binary, which this PR does not touch.

Recommendation

Approve with nits. The gate does what the issue asked, it fails on the violation and passes on the clean tree, and the exit-code handling — the part these checks most often get wrong — is correct. The evidence quality is unusually good: the body's 109-hit claim reproduces exactly, and this PR's own CI history contains the fail-then-pass pair that proves the gate bites. Nothing here needs a code change to merge. Concrete next step: fix the stale "Draft until #6355 merges" paragraph in the body, and decide whether *.inc is worth adding to the glob — both are one-line edits and neither blocks. The github.base_ref interpolation at :473/:486 is pre-existing and belongs in its own issue, not in this diff.

Thanks for splitting the ratchet out of the cleanup it protects, and for showing it red on a tree with the macro and green on one without — that is the right way to land a new merge-gating check.

---

_{🤖 aethersdr-agent · cost: $11.8411 · model: claude-opus-5}

[aethersdr-agent]

Cisco CodeGuard — static analysis of this PR (14 finding(s))

• [CRITICAL] CS-VLN-CMDI-SUBSHELL — Vulnerability: CS-VLN-CMDI-SUBSHELL in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:496
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:14
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:36
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:81
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:172
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:309
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:332
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:340
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:355
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:399
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:414
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:469
• [CRITICAL] CS-VLN-CMDI-BACKTICK — Vulnerability: CS-VLN-CMDI-BACKTICK in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:531
• [MEDIUM] CS-VLN-CMDI-ENVVAR — Vulnerability: CS-VLN-CMDI-ENVVAR in .github/workflows/static-checks.yml /tmp/aetherclaude/pr-6383/.github/workflows/static-checks.yml:534

_{Automated static scan by Cisco DefenseClaw CodeGuard on the changed files. Advisory — some may be false positives; the review above verifies them.}

---

_{🤖 aethersdr-agent · cost: $11.9899 · model: claude-opus-5}

[rfoust]

Issue fit

Yes. #6382 requests a required static-checks gate for reintroduced Q_OS_MAC. The added step checks the requested source extensions, excludes third_party/, emits per-line annotations, and fails on matches or unexpected git grep errors. #6355 has merged, and this PR's updated integration passes the gate.

Scope

File/group	Change	Claimed?	Verdict
.github/workflows/static-checks.yml:367-379	One whole-tree Q_OS_MAC gate	Yes, exactly #6382	In scope

Everything in the diff is explained by the issue. No application code, tests, dependencies, or public surface changed.

Blockers

None.

Nits (non-blocking)

• The issue describes C/C++/Objective-C source, but its proposed globs, used here, omit *.c. See the inline note. This does not hold this PR because the implementation follows the issue's exact command.
• The PR body still says #6355 is pending and that Static checks is expected to be red. Those statements are now stale; an editorial update would help future readers.

Verification

On head 5a1f14aa, build, check-windows, check-macos, Static checks, and Sanitizer option configures all passed. I extracted the workflow script and ran it with bash -e in a tracked Git fixture: Q_OS_MACOS plus deprecated tokens in docs and third_party/ passed; a Q_OS_MAC in src/probe.cpp failed with ::error file=src/probe.cpp,line=1::...; restoring Q_OS_MACOS passed. A tracked .c file containing the old token did not trip the gate. No runtime app test applies to this workflow-only change.

Approved. The gate fails on the violation and passes on the clean merge tree. The remaining notes are non-blocking.