Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

https://github.com/amiwrpremium/macontrol/blob/master/CHANGELOG.md

Repository on GitHub, which uses git. git is distributed.

https://github.com/amiwrpremium/macontrol/blob/master/release-please-config.json

https://github.com/amiwrpremium/macontrol/tags
https://github.com/amiwrpremium/macontrol/releases

Non-trivial release notes file in repository: https://github.com/amiwrpremium/macontrol/blob/master/CHANGELOG.md.

https://github.com/amiwrpremium/macontrol/tags
https://github.com/amiwrpremium/macontrol/releases

Non-trivial SECURITY[.md] file found file in repository: https://github.com/amiwrpremium/macontrol/blob/master/SECURITY.md. [osps_do_02_01]

https://github.com/amiwrpremium/macontrol/issues

https://github.com/amiwrpremium/macontrol/

https://github.com/amiwrpremium/macontrol/blob/master/SECURITY.md

https://github.com/amiwrpremium/macontrol/blob/master/SECURITY.md

Non-trivial build file in repository: https://github.com/amiwrpremium/macontrol/blob/master/Makefile.

Non-trivial build file in repository: https://github.com/amiwrpremium/macontrol/blob/master/Makefile.

It cleanly satisfies this criterion:

Written in Go — the official Go toolchain is BSD-licensed FLOSS.
Build system is Make (Makefile) — GPL FLOSS.
Lives in Git on GitHub — Git itself is GPL FLOSS.
Linting via golangci-lint — GPL/MIT FLOSS.
Released via GoReleaser + release-please — both MIT FLOSS.
Targets macOS, but the build doesn't require Xcode's proprietary bits; go build cross-compiles for darwin/arm64 from any platform.

1. Automated test suite under FLOSS license ✅
   The repo contains 48 Go test files (*_test.go) covering essentially every package — runner, config, keychain, capability, every domain module (battery, bluetooth, display, media, music, notify, power, sound, status, system, tools, wifi), and the Telegram handlers/callbacks. They use Go's standard testing package, which ships with the Go toolchain under a BSD-3-Clause license — unambiguously FLOSS. The tests themselves inherit the project's MIT license.
   There's also a fuzz test (FuzzDecode in internal/telegram/callbacks/), which is a nice extra — Go's built-in fuzzer is also FLOSS.

2. Documentation of how to run them ✅
   Multiple, redundant places — any reviewer will find one:
   Makefile has both make test (go test ./...) and make lint test mentioned in the README's Development section.
   README.md explicitly shows make lint test under the Development heading on line 135.
   .github/workflows/ci.yml runs go test -race -coverprofile=coverage.out ./... on every push/PR, with a coverage matrix uploading to Codecov and Codacy (the badges on the README link to both dashboards).
   docs/development/testing.md exists as a dedicated testing doc, plus docs/development/ci.md documents the CI pipeline.
   CONTRIBUTING.md at the repo root is also present.

test_invocation — macontrol evidence

The project satisfies this criterion. Tests are invoked using the standard Go convention:

go test ./...

This is the canonical Go test command and works directly from a fresh clone with no flags, environment setup, or custom scripts.

Makefile (wraps the standard command, doesn't replace it):
test: go test ./...
test-race: go test -race -coverprofile=coverage.out ./...

make test and make test-race are convenience aliases — the underlying command is exactly what a Go developer would type by reflex. A reviewer ignoring the Makefile entirely would still succeed by running go test ./....

CI (.github/workflows/ci.yml) uses the same standard command:
go test -race -coverprofile=coverage.out ./...

Fuzz tests also use the canonical Go invocation:
go test -run='^$' -fuzz=FuzzDecode -fuzztime=30s ./internal/telegram/callbacks/

Summary: the project uses go test ./... (the standard Go invocation), exposes it through a conventional Makefile test target, and runs the same command in CI. No custom test runner, no proprietary harness, no project-specific learning curve required.

test_most — macontrol evidence

The project satisfies this suggested criterion with strong, enforced coverage of code branches, input fields, and functionality.

Test surface area:

• 48 *_test.go files against 96 non-test .go files — roughly a 1:2 test-to-source ratio, with every internal package having a corresponding test file.
• Tests cover every domain module: battery, bluetooth, display, media, music, notify, power, sound, status, system, tools, wifi — plus runner, config, keychain, capability, version, and the telegram handlers/callbacks.
• 30+ table-driven test blocks exercise multiple input cases per function — the standard Go pattern for branch and input-field coverage.
• A fuzz test (FuzzDecode in internal/telegram/callbacks/data_fuzz_test.go) exercises the callback decoder against randomized input to catch edge-case branches; it runs in CI via go test -run='^$' -fuzz=FuzzDecode -fuzztime=30s.

Coverage is measured and enforced, not just claimed:

• CI runs go test -race -coverprofile=coverage.out ./... on every push/PR.
• Coverage is uploaded to both Codecov and Codacy — both badges are visible at the top of README.md and link to public dashboards.
• A coverage floor is enforced in CI via the cover-floor Make target, which runs go-test-coverage --config=./.testcoverage.yml.

Coverage thresholds (from .testcoverage.yml):

• Total project: 80%
• Per package: 75%
• Per file: 50%
• internal/domain/status: 80% (package-specific override)
• internal/telegram/telegramtest: 70% (test helper)
• cmd/macontrol: 5% (entry point — covered by integration tests on a real Mac, not unit tests; documented in the config file)
• cmd/macontrol/shim.go: 0% (tiny shim, documented)

Notably the thresholds are intentionally set below current measured coverage (per the comment in .testcoverage.yml) so that regressions are caught without blocking every small change — meaning actual coverage exceeds these floors.

Summary: the project doesn't just have tests — it measures branch/file/package coverage, publishes it on two public dashboards, enforces a per-package floor of 75% and a project floor of 80% in CI, and uses fuzz testing on the highest-risk parser (the callback data decoder). Documented exceptions (entry-point and shim files) are explicit and justified.

test_continuous_integration — macontrol evidence

The project satisfies this suggested criterion. CI is implemented via GitHub Actions, runs on every push and pull request, and integrates code into the central repository with a full battery of automated checks.

CI configuration: .github/workflows/ci.yml

Triggers:

• push to master
• pull_request targeting master
• concurrency group cancels superseded runs to keep feedback fast

Jobs that run on every change:

1. Lint (ubuntu-latest)

   • golangci-lint at latest version

2. Test (matrix: ubuntu-latest + macos-14)

   • go test -race -coverprofile=coverage.out ./...
   • Coverage uploaded as workflow artifact
   • Coverage floor enforced via go-test-coverage against .testcoverage.yml
   • Coverage published to Codecov and Codacy on every run

3. Build (ubuntu-latest)

   • Cross-compiles the actual release target: GOOS=darwin GOARCH=arm64 CGO_ENABLED=0
   • Catches build regressions before merge

4. Vulnerability scan (ubuntu-latest)

   • govulncheck ./... against the Go vulnerability database

5. Fuzz (short, ubuntu-latest)

   • 30-second smoke fuzz on FuzzDecode (the callback parser — the only attacker-reachable parser before the whitelist gate)
   • Guards against newly-introduced panics on every PR

Additional CI workflows in .github/workflows/:

• codeql.yml — GitHub CodeQL static analysis
• scorecards.yml — OpenSSF Scorecard checks
• pr-title.yml — Conventional Commits enforcement on PR titles
• release-please.yml — automated release PR generation
• release.yml — GoReleaser pipeline on tag push

Visible signals on the repository:

• CI badge at the top of README.md links to the live workflow runs
• codecov and Codacy coverage badges link to their public dashboards
• OpenSSF Scorecard badge links to the public scorecard report

Summary: every push and PR triggers parallel jobs covering lint, test (on Linux and macOS), cross-compile build, vulnerability scan, and fuzz testing. Coverage is measured, enforced against a per-package floor, and published to two public dashboards. Additional scheduled/triggered workflows handle CodeQL, OpenSSF Scorecard, and the release pipeline. This goes well beyond the suggested criterion.

test_policy — macontrol evidence

The project has an explicit, documented policy that new functionality must come with tests. The policy is enforced both in writing and through CI gating.

1. Documented policy

CONTRIBUTING.md instructs every contributor to run make lint test before opening a PR, and the PR template/process treats failing tests as a blocker.

docs/development/adding-a-capability.md is a step-by-step guide for adding a new feature (a "capability"). It is structured as a 6-step checklist, and step 2 of every new capability is explicitly "Domain test" — the guide includes a worked example showing both happy-path and error-path tests using runner.Fake, with the note that the result "Should pass with 100% coverage on the two test functions." Step 5 of the same checklist is "Test the handler." The file table at the top of the guide lists the test files alongside the source files as required deliverables for any new capability, not as optional extras.

docs/development/testing.md documents the test infrastructure (runner.Fake for subprocess mocking, telegramtest.NewBot for the Telegram API) so contributors have no excuse not to write tests — the helpers needed to test any new domain or handler already exist and are documented.

2. Policy enforcement in CI

The policy isn't aspirational — it's enforced:

• Every push and PR runs go test -race -coverprofile=coverage.out ./... on both Linux and macOS.
• A coverage floor is enforced via go-test-coverage against .testcoverage.yml: 80% total, 75% per package, 50% per file. New code that drops coverage below those floors fails CI.
• Coverage is published to Codecov and Codacy on every run, so any drop is visible in the PR review.
• A 30-second fuzz test of the callback decoder runs on every PR.

3. Cultural signal

Conventional Commits (enforced by a CI job on PR titles) include test as a first-class commit type, and feat commits in the changelog routinely land alongside their corresponding tests. The CHANGELOG.md history shows tests added in the same release as the features they cover.

Summary: the project has an explicit written policy in CONTRIBUTING.md and the capability-adding guide that requires tests for new functionality, backed by ready-made test helpers (runner.Fake, telegramtest.NewBot), and enforced by a CI-gated coverage floor that blocks PRs which regress coverage. This satisfies the criterion well beyond the "general policy, formal or not" bar.

tests_are_added — macontrol evidence

The most recent major changes to macontrol show the test_policy being followed consistently. Every recent feature PR ships with tests for the new code, and dedicated test-only PRs have been used to raise coverage proactively.

Most recent feature: feat(bot): add 🎵 Music category (#91, latest 0.7.0 release)

This is a large feature touching 24 files, +2,869 lines. Of those 24 files, 6 are *_test.go files added or expanded alongside the new code:

internal/capability/detect_test.go | 37 lines changed
internal/domain/music/music_test.go | 264 lines added (new file)
internal/telegram/flows/seek_test.go | 95 lines added (new file)
internal/telegram/handlers/mus_test.go | 235 lines added (new file)
internal/telegram/keyboards/mus_test.go | 236 lines added (new file)
internal/telegram/musicrefresh/refresher_test.go | 312 lines added (new file)

Every new production file in this PR landed with a corresponding _test.go in the same commit:
music.go ↔ music_test.go
seek.go ↔ seek_test.go
mus.go (handlers) ↔ mus_test.go
mus.go (keyboards) ↔ mus_test.go
refresher.go ↔ refresher_test.go

This exactly matches the policy in docs/development/adding-a-capability.md, which mandates a domain test file and a handler test alongside any new capability.

Pattern across the last several feat commits:

feat(bot): Timezone picker (01b2ae5) → +tools_test.go, +remaining_test.go, +keyboards_test.go
feat(bot): Shortcuts list (a1a2be1) → +remaining_test.go, +keyboards_test.go
feat(bot): DNS presets submenu (98646fb) → +remaining_test.go, +keyboards_test.go
feat(bot): Disks redesign (ef77b3c) → +tools_test.go, +remaining_test.go, +keyboards_test.go

Every single one of the most recent feat(bot) PRs in git log includes test additions in the same commit. None landed bare.

Dedicated test-improvement work:

test: expand unit coverage from 73.9% to 85.0% across the repo (#76, commit 51e7d31)
test(callbacks): add Go native fuzz tests for Decode (#89, commit 0bb56cc)

These two PRs show the policy is treated as an active concern, not a checkbox — the maintainer has merged standalone PRs whose only purpose is to raise coverage and add fuzz testing.

Enforcement signal:

CI's coverage floor (.testcoverage.yml: 80% total, 75% per package) blocks merges that drop coverage below the threshold. The fact that recent feature PRs all merged green is itself evidence that the feature code was covered by the tests added in the same PR — otherwise the floor check would have failed.

Summary: the most recent major change (the Music category) added 6 test files alongside the 18 new/edited production files, matching the policy in docs/development/adding-a-capability.md exactly. The same pattern holds for every prior feat(bot) PR in the history. The project also merges dedicated test-improvement PRs (#76, #89). The criterion is satisfied with a clear, traceable record.

tests_documented_added — macontrol evidence

The project documents the test-adding policy in multiple change-proposal-facing locations, satisfying this suggested criterion.

1. Pull Request template (.github/PULL_REQUEST_TEMPLATE.md)

GitHub auto-loads this template into every new PR's description box. It contains a "Test plan" section with the policy as an explicit checkbox the contributor must tick:

Test plan

• make lint test passes locally
• New/changed code has unit tests
• Verified on macOS (version / chip: … )
• If permissions changed: updated docs/permissions.md
• If new capability: added to README feature table

The "New/changed code has unit tests" line is the policy stated directly in the change-proposal interface — every contributor sees it the moment they open a PR.

2. CONTRIBUTING.md

The contributor workflow makes running tests a required pre-PR step:

3. Run checks locally before pushing:

     make lint test

The "Adding a new capability" section lists the required files for a new capability and step 6 explicitly mandates tests:

6. Write a domain test using the runner.Fake helper and a
   keyboard-layout test.

7. docs/development/adding-a-capability.md

A dedicated, full-length guide for change proposals that add new functionality. It treats tests as a structural requirement, not a suggestion:

• The file table at the top lists _test.go files alongside source files as required deliverables.
• Step 2 of every new capability is "Domain test", with a worked example covering both happy-path and error-path tests.
• Step 5 is "Test the handler".
• The guide notes that the worked example "Should pass with 100% coverage on the two test functions."

4. docs/development/testing.md

Documents the test infrastructure (runner.Fake, telegramtest.NewBot) so contributors know exactly how to satisfy the policy. The helpers needed to test any new domain or handler are pre-built and documented.

5. Conventional Commits

CONTRIBUTING.md lists test as a first-class commit type, signaling that test-only changes are an expected, encouraged contribution.

Summary: the test-adding policy is documented in the PR template (the most direct change-proposal surface), in CONTRIBUTING.md (the canonical contributor doc), and in two dedicated development guides (adding-a-capability.md and testing.md). A contributor cannot open a PR without seeing the "New/changed code has unit tests" checkbox in their PR body. This goes beyond the suggested bar.

warnings — macontrol evidence

The project satisfies this criterion with a comprehensive linter configuration enforced in CI.

Primary linter: golangci-lint (FLOSS, GPL-3.0)

The repository ships an explicit configuration at .golangci.yml that enables 13 linters covering correctness, security, and style — all are themselves FLOSS:

• errcheck — unchecked errors
• govet — go vet, the official correctness checker
• ineffassign — ineffective assignments
• staticcheck — comprehensive static analysis (correctness + simplification)
• unused — unused code
• misspell — common misspellings
• gocritic — opinionated bug-pattern checks
• revive — replacement for golint, with the exported and package-comments rules explicitly enabled (enforces godoc on exported symbols)
• bodyclose — HTTP response bodies that must be closed
• nolintlint — catches stale or malformed //nolint directives
• unparam — unused function parameters
• prealloc — slices that could be preallocated
• gosec — security-focused checks (with G204 excluded since subprocess invocation is the project's purpose, documented inline)

Formatters (gofumpt + goimports) are also enforced, with project-local import grouping configured.

Test files have a narrowly scoped exclusion (gosec, unparam, gocritic) which is the standard pattern for Go projects — these linters produce noise on test scaffolding.

Enforcement:

• Makefile target: make lint → golangci-lint run. make lint-fix for auto-fixable issues. make all runs lint + test + build.
• CI: .github/workflows/ci.yml has a dedicated lint job that runs golangci-lint on every push and pull request. It runs in parallel with the test job, so regressions are caught before merge.
• CONTRIBUTING.md instructs every contributor: make lint test before opening a PR.

Additional static analysis layers:

• govulncheck (golang.org/x/vuln) — runs as the vuln CI job on every push/PR via govulncheck ./...
• CodeQL (.github/workflows/codeql.yml) — GitHub's semantic code analysis on the repo
• OpenSSF Scorecard (.github/workflows/scorecards.yml) — supply-chain best-practice scoring
• The Go compiler itself emits warnings/errors for unused imports and variables, and go vet is included via the govet linter above

All four of these tools are FLOSS.

Summary: the project enables 13 FLOSS linters via golangci-lint with an explicit checked-in configuration, runs them in CI on every push and PR, and layers govulncheck + CodeQL + Scorecard on top. The make lint target makes the same checks runnable locally, and the contributor workflow requires it before opening a PR. The criterion is satisfied well beyond the minimum.

warnings_fixed — macontrol evidence

The project actively addresses warnings rather than ignoring them. Multiple lines of evidence:

1. CI fails on warnings, blocking merges

The lint job in .github/workflows/ci.yml runs golangci-lint on every push and PR. golangci-lint defaults to a non-zero exit on any finding, so any unaddressed warning fails CI and blocks merge. Recent feature PRs (#91 Music, #82 handler split, #67 Timezone, #60 Shortcuts) all merged green, meaning each was warning-clean by the time it landed.

2. Documented history of fixing warnings, not suppressing them

Direct evidence in the commit log:

caa55d6 fix(ci): resolve 50 golangci-lint v2 findings
34182c8 fix(ci): upgrade lint action and Go toolchain to pass checks
d0b3eaf docs: comprehensive godoc for all production code + enable strict lint (#77)
c4474e8 docs: thorough godoc rewrite with structured sections (#78)
ed45c0e chore: quiet markdownlint rules pre-PR1 wasn't enforcing (#84)

The "resolve 50 golangci-lint v2 findings" commit is particularly strong evidence. Its body itemises every fix:

• errcheck (14) → explicit _ = on intentionally discarded errors;
  deferred handlers wrapped to discard returns explicitly
• gofumpt (11) + goimports (1) → formatter auto-fix pass
• staticcheck (10) → QF1012 fmt.Fprintf simplifications, SA1019 deprecated
  API replacements (EnvVarIsNotSetError → VarIsNotSetError)
• gosec (5) → directory modes tightened 0o755 → 0o750, plist 0o644 → 0o600
• gocritic (2) → singleCaseSwitch collapsed; exitAfterDefer fixed with
  explicit cancel()
• prealloc (3) → slice capacities sized upfront

These are real code changes, not ignore-list additions.

3. Disciplined use of suppressions

A repo-wide grep finds only 3 //nolint directives across the entire codebase:

internal/domain/tools/tz_country.go:58
os.ReadFile(path) //nolint:gosec // G304: path is from a constant allowlist

internal/telegram/musicrefresh/refresher.go:199
context.WithCancel(ctx) //nolint:gosec // cancel stored in session.cancel;
called by Stop and run's defer

cmd/macontrol/daemon.go:100
//nolint:gocritic // explicit cancel() above flushes the context before exit

Each is narrow (single line, specific linter named) and carries an inline justification. The nolintlint linter is also enabled in .golangci.yml, which catches stale, unused, or unjustified nolint directives — meaning suppressions themselves are policed.

The .golangci.yml has exactly one global exclusion (gosec G204 — subprocess invocation), and it's documented in a comment ("Subprocess call is the whole point of this project"). Test files have a narrowly scoped exclusion of gosec/unparam/gocritic, the standard Go pattern.

4. Refactors driven by warnings

9f045d2 refactor: split overgrown handlers and table-drive parsers (#82)

The release notes for the Music feature (#91) explicitly call out two refactor steps done to satisfy Codacy findings:

• refactor(keyboards): split MusicCaption into per-section helpers (Codacy)
• refactor(music): split tickOnce into snapshot + edit-media helpers (Codacy)

So warnings from the secondary scanner (Codacy) are also being acted on, not just dismissed.

5. Strict-lint regime expanded over time

Commit d0b3eaf ("comprehensive godoc for all production code + enable strict lint") shows the bar being raised: revive's exported and package-comments rules were enabled, then the codebase was brought into compliance by writing godoc for every exported symbol. This is the opposite of the anti-pattern of relaxing rules to make warnings disappear.

Summary: warnings are surfaced by golangci-lint (13 linters) + govulncheck + CodeQL + Codacy, blocked at the CI gate, addressed in dedicated fix commits with itemised release notes, and only suppressed in 3 narrow places — each with a written justification, all policed by nolintlint. The criterion is satisfied with a strong, traceable record.

warnings_strict — macontrol evidence

The project takes a maximally strict posture on warnings, well within the "where practical" qualifier of this suggested criterion.

1. Strict golangci-lint configuration (.golangci.yml)

issues:
max-issues-per-linter: 0
max-same-issues: 0

These two settings disable golangci-lint's default deduplication caps. By default golangci-lint shows only the first 50 findings per linter and the first 3 of each kind; setting both to 0 means every finding is surfaced. This is the strict-mode setting — the project wants to see all warnings, not a sampled summary.

2. Strict linter selection with default: none

linters:
default: none
enable: [errcheck, govet, ineffassign, staticcheck, unused, misspell,
gocritic, revive, bodyclose, nolintlint, unparam, prealloc, gosec]

default: none means no linters run unless explicitly enabled — so the active set is deliberate, not accidental. The 13 enabled linters include the strictest commonly-used ones:

• staticcheck (covers SA, ST, S, QF check categories — the gold-standard Go static analyser)
• gosec (security)
• gocritic (opinionated bug-pattern checks beyond go vet)
• revive with exported and package-comments rules explicitly enabled — these enforce godoc on every exported symbol and every package, a notably strict bar
• nolintlint (polices the suppressions themselves — stale or unjustified //nolint directives are themselves warnings)

3. Minimal, justified exclusions

The configuration suppresses almost nothing:

• One global exclusion: gosec G204 (subprocess invocation), with an inline comment explaining why ("Subprocess call is the whole point of this project"). Without this the entire project would be one giant warning, since shelling out to pmset/networksetup/osascript is its purpose.
• Test files exclude only gosec, unparam, gocritic — the standard Go pattern, since these produce noise on test scaffolding and assertion helpers.
• generated: lax — generated files are excluded from lint, the standard convention.

There are no broad path exclusions, no per-linter rule disables, no severity downgrades. The configuration is roughly 50 lines and contains nothing that softens the rules.

4. Strict bars layered on top of golangci-lint

• govulncheck runs in CI as a separate vuln job — any known-vulnerable dependency or stdlib usage fails the build.
• CodeQL (.github/workflows/codeql.yml) — semantic analysis on every push.
• OpenSSF Scorecard (.github/workflows/scorecards.yml) — supply-chain best-practice scoring published publicly.
• Codacy + Codecov dashboards — third-party static analysis with public badges.
• gofumpt (stricter than gofmt) and goimports (with local-prefix grouping enforced) run as formatters — formatting drift is a CI failure.
• A 30-second fuzz test (FuzzDecode) runs on every PR.
• Race detector enabled in CI tests: go test -race.

5. Strict bar raised over time, not lowered

The history shows the project tightening, not loosening, its strictness:

d0b3eaf docs: comprehensive godoc for all production code + enable strict lint (#77)
c4474e8 docs: thorough godoc rewrite with structured sections (#78)
caa55d6 fix(ci): resolve 50 golangci-lint v2 findings

The "enable strict lint" commit turned on revive's exported and package-comments rules and then brought the entire codebase into compliance — the opposite of the anti-pattern of relaxing rules to make warnings disappear.

6. Evidence the strict bar is held in practice

A repo-wide grep finds only 3 //nolint directives across the codebase. Each is single-line, names the specific linter being suppressed, and carries an inline justification. nolintlint enforces this format. Three narrow, justified suppressions across ~96 production .go files is a notably tight ratio.

The macOS-target build is also configured strictly:

GOFLAGS ?= -trimpath
LDFLAGS ?= -s -w …
CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" …

-trimpath removes filesystem path leakage, and -s -w strips debug info from release binaries.

7. Practical limits, honestly handled

The "where practical" qualifier matters here. macontrol is a subprocess-orchestration daemon; gosec G204 (subprocess with non-constant input) cannot be globally satisfied because the project's purpose is to run macOS CLIs. The maintainer suppresses G204 globally with a documented justification rather than littering the code with per-call suppressions or pretending it's not an issue. That's the right kind of pragmatic strictness — strict everywhere it's practical, explicitly bounded where it isn't.

Summary: the project enables 13 linters with default: none, sets max-issues caps to 0 to surface every finding, enforces godoc on every exported symbol via revive, layers govulncheck + CodeQL + Scorecard + Codacy on top, uses gofumpt (stricter than gofmt), runs tests with -race, fuzzes the highest-risk parser, and has a documented history of raising the bar (enable strict lint → fix the resulting 50 findings) rather than lowering it. Only 3 narrowly justified //nolint suppressions exist in the entire codebase. The criterion is satisfied at the strong end of the spectrum.

know_secure_design — macontrol evidence

The primary developer (@amiwrpremium) demonstrates secure-design knowledge across every dimension the criterion lists.

1. Written threat model

docs/security/ contains a dedicated threat model. SECURITY.md documents scope (daemon, CLI, LaunchAgent plist, sudoers template, Homebrew formula, install.sh), out-of-scope (attacks already holding the bot token, upstream Apple bugs), private disclosure via GitHub Security Advisories, and SLAs (72h ack, ≤30d patch). A written threat model with named boundaries is itself a secure-design artifact.

2. Secure defaults

• No inbound port — outbound long-poll only. Eliminates the entire class of inbound-network attacks.
• Hard Telegram-user-ID whitelist; non-whitelisted updates dropped silently (no enumeration via differentiated errors).
• No /sh escape hatch — only named commands. A leaked token cannot be turned into arbitrary code execution.
• Bot token stored in macOS Keychain, never in config files or env vars.
• Commit caa55d6 proactively tightened file modes in response to gosec findings: directories 0o755 → 0o750, LaunchAgent plist 0o644 → 0o600.

3. Defense in depth

Six independent layers, each assuming the previous bypassed:

L1: Telegram user-ID whitelist (auth)
L2: Named-command surface (no shell escape)
L3: runner.Runner interface (constrained subprocess invocation)
L4: Narrow sudoers entry (sudoers.d/macontrol.sample)
L5: macOS TCC gates on camera/screen/microphone
L6: Keychain ACL bound to binary path

4. Least privilege

• Sudoers is a narrow allowlist, not NOPASSWD: ALL.
• runner.Runner carries an explicit Sudo bool per call — sudo is opt-in per command, not ambient.
• Daemon runs as the user's LaunchAgent, not root.
• Keychain ACL binding to binary path means another binary running as the same user must trigger a fresh user consent prompt.

5. Input validation on the attacker-reachable surface

The Telegram callback_data string is the only attacker-reachable parser before the whitelist gate. The developer:

• Wrote a Go native fuzz test (FuzzDecode in internal/telegram/callbacks/data_fuzz_test.go), commit 0bb56cc.
• Runs it 30s on every PR via the fuzz-short CI job.
• Documented in the CI workflow comment that it is "the only attacker-reachable parser before the whitelist gate" — showing pinpointed threat awareness, not blanket fuzzing.

6. Avoiding common attack classes

• Command injection: subprocess invocation through runner.Runner with separate Name + Args fields, never string concatenation. The Args-not-shell pattern is what makes the global gosec G204 suppression safe.
• Path traversal: the one os.ReadFile from a non-constant path (tools/tz_country.go) checks against an allowlist; the inline //nolint:gosec // G304: path is from a constant allowlist shows the finding was read, classified, and mitigated.
• Race conditions: go test -race in CI; musicrefresh uses an explicit cancel-stored-in-session lifecycle pattern.
• Supply-chain: every third-party Action and go-installed tool is pinned to a commit SHA (commits de4e7aa, 08216c6, fdbe795). govulncheck on every PR.

7. Secret handling

• Token only ever held in the macOS Keychain via internal/keychain/, with a dedicated test file.
• Keychain ACL is binary-path-bound — a foreign binary triggers a macOS UI prompt rather than silent re-read.
• CI secrets use GitHub's redacted ${{ secrets.X }} mechanism; no inlined credentials anywhere.

8. Secure SDLC

CodeQL on every push, OpenSSF Scorecard publicly scored, govulncheck on every PR, 13 linters via golangci-lint including gosec, race detector in CI, Dependabot weekly on gomod + github-actions, Conventional Commits + squash-merge for clean audit trail, private vulnerability disclosure channel.

9. Evidence of considered (not templated) thinking

The author maintains a sibling project, shellboto, for Linux VPS — with a different security model (pty-backed shell, SHA-256 hash-chained audit logs, per-user RBAC). Choosing different controls for different threat surfaces shows threat-model thinking, not a single template applied everywhere.

10. Trust boundaries surfaced to users

The README disclaimer enumerates the trust anchors users accept: the daemon's capabilities, the bot token + whitelist as the auth boundary, and transitive trust in Telegram/Apple/Homebrew. Articulating the trust model in user-facing docs is itself a secure-design practice.

Summary: written threat model with scope boundaries; secure defaults (no inbound port, named commands only, tightened file modes); six-layer defense in depth; least privilege (narrow sudoers, per-call Sudo bool, non-root); fuzz-tested input validation pinpointed at the attacker-reachable parser; injection-resistant subprocess invocation; Keychain-based secret storage with binary-path ACL; full secure SDLC (CodeQL, Scorecard, govulncheck, gosec, race detector, Dependabot, pinned actions). The criterion is satisfied.

know_common_errors — macontrol evidence

Common vulnerability classes for a network-connected, subprocess-orchestrating macOS daemon, with the mitigation applied in macontrol:

1. Command / subprocess injection
   Subprocess goes through runner.Runner with separate Name (string) and Args ([]string) fields, passed directly to exec.Cmd. No sh -c, no string interpolation. The runner.Fake test mock asserts on the parsed (Name, Args) tuple, proving the production form.

2. Privilege escalation via overbroad sudo
   sudoers.d/macontrol.sample is a narrow allowlist, not NOPASSWD: ALL. runner.Runner carries an explicit Sudo bool per call — sudo is opt-in per invocation, not ambient.

3. Authentication bypass
   Hard Telegram-user-ID whitelist sits in front of the command surface. Non-whitelisted updates dropped silently (no user enumeration). A leaked token alone cannot drive the bot — the attacker also needs a whitelisted user-ID.

4. RCE via inbound network exposure
   No inbound port. Telegram long-poll over outbound HTTPS only. Eliminates the entire inbound-RCE class.

5. Untrusted-input parsing (fuzz-class bugs)
   FuzzDecode (internal/telegram/callbacks/data_fuzz_test.go) runs 30s on every PR. The CI comment identifies callbacks.Decode as "the only attacker-reachable parser before the whitelist gate" — fuzz coverage was deliberately aimed at the single highest-risk parser. Commit 0bb56cc.

6. Path traversal
   The one os.ReadFile with a non-constant path (tools/tz_country.go) reads from a constant allowlist. The inline //nolint:gosec // G304: path is from a constant allowlist shows the gosec finding was read by number and mitigated.

7. Credential leakage at rest
   Bot token + whitelist live in the macOS Keychain (internal/keychain), not config files or env vars. Keychain ACL bound to binary path — foreign binaries trigger a fresh user consent prompt.

8. Credential leakage in repo / CI logs
   .gitignore excludes .env*, *.pem, *.key. CI secrets read via ${{ secrets.X }}, never inlined. The only token-shaped strings in the repo are Telegram's published BotFather placeholder (123456789:AAE-aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456). GitHub secret-scanning runs by default.

9. Race conditions / TOCTOU
   go test -race on Linux + macOS in CI. musicrefresh uses an explicit cancel-stored-in-session lifecycle.

10. Goroutine leaks
    musicrefresh.Manager has Start/Stop/Touch with a 10-minute hard cap; Stop is called on navigate-away. refresher_test.go (312 lines) covers lifecycle paths.

11. Supply-chain attacks via mutable Action tags
    Every third-party Action pinned to commit SHA (commits de4e7aa, 08216c6). go-installed tools pinned to versions (commit fdbe795).

12. Vulnerable dependencies
    govulncheck on every push/PR. Dependabot scans gomod weekly. Total deps: 3 direct + 1 indirect.

13. Information disclosure via verbose errors
    Sanitised user-facing Telegram messages; detailed errors go to the local log only.

14. Logging secrets
    Keychain abstraction returns the token only at the call site that needs it. lumberjack rotates logs to bound retention.

15. Insecure file permissions on artifacts
    Commit caa55d6 tightened LaunchAgent plist 0o644 → 0o600 and Library/Logs / LaunchAgents directories 0o755 → 0o750 in response to gosec findings.

16. Insecure-by-default configuration
    No default whitelist — macontrol setup forces the user to enter their Telegram user-ID. A misconfigured install fails closed (no whitelisted users → no commands accepted).

17. Cross-binary credential confusion
    macOS Keychain ACL is binary-path-bound. CONTRIBUTING.md explicitly warns dev contributors not to use go run for iterative dev because its random tempdir paths defeat the ACL.

18. Insecure release pipeline
    GoReleaser triggered by release-please is fully automated; build flags -trimpath -s -w CGO_ENABLED=0 produce reproducible stripped binaries; the same workflow updates the Homebrew tap.

19. Missed bug-class patterns
    13 linters via golangci-lint including gosec, staticcheck, gocritic, errcheck, ineffassign. CodeQL semantic analysis on every push. nolintlint polices suppressions themselves — only 3 //nolint directives exist in the entire codebase, each with an inline justification.

20. No vulnerability disclosure channel
    SECURITY.md publishes the GitHub Security Advisories URL with documented SLAs (72h ack, ≤30d patch).

Direct evidence of awareness (not incidental coverage):

• Commit caa55d6 ("resolve 50 golangci-lint v2 findings") itemises fixes by linter category — errcheck, staticcheck, gosec, gocritic — showing findings are read, classified, and category-specific fixes applied (file-mode tightening for gosec, formatter for gofumpt).
• Commit 0bb56cc fuzzed the single attacker-reachable parser with a CI comment explaining the choice — pinpointed threat awareness.
• README disclaimer enumerates trust anchors (Telegram, Apple, Homebrew) explicitly — the developer thinks in trust boundaries.
• Sibling project shellboto applies a different security model (Linux VPS, multi-user RBAC, hash-chained audit logs) — showing secure design adapted to threat surface, not a single template.

Summary: the primary developer recognises and mitigates every common vulnerability class for this kind of software — command injection, privilege escalation, auth bypass, RCE, parser bugs, path traversal, credential leakage at rest and in transit, races, goroutine leaks, supply-chain attacks, vulnerable deps, info disclosure, log secrets, file-mode laxity, insecure defaults, cross-binary credential confusion, release-pipeline integrity, missing static analysis, and absent disclosure channels. Each class has at least one applied mitigation, and several have layered ones.