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.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

vulnerabilities_fixed_60_days — macontrol evidence

The project satisfies this criterion. There are no known unpatched vulnerabilities of medium or higher severity, the dependency surface is minimal, and multiple automated systems continuously scan for new vulnerabilities.

1. Minimal dependency surface

go.mod declares only 3 direct dependencies and 1 indirect dependency:

require (
github.com/go-telegram/bot v1.20.0
golang.org/x/term v0.42.0
gopkg.in/natefinch/lumberjack.v2 v2.2.1
)
require golang.org/x/sys v0.43.0 // indirect

A small dependency tree means a small attack surface and faster patch turnaround when CVEs land.

2. Continuous vulnerability scanning in CI

.github/workflows/ci.yml runs govulncheck ./... on every push and pull request as a dedicated vuln job. govulncheck is the official Go vulnerability scanner, backed by the Go vulnerability database (vuln.go.dev), and it checks both direct/indirect dependencies and stdlib usage. A new CVE affecting any reachable code path fails the build.

.github/workflows/codeql.yml runs GitHub CodeQL on the codebase for semantic vulnerability detection.

.github/workflows/scorecards.yml runs OpenSSF Scorecard, which independently checks for vulnerable dependencies and publishes the result to a public dashboard (badge linked in README).

3. Automated patch ingestion via Dependabot

.github/dependabot.yml is configured to:

• Scan the gomod ecosystem weekly (Mondays 06:00 UTC) and open up to 5 update PRs
• Scan the github-actions ecosystem on the same schedule
• Group minor + patch updates so security-relevant patches land quickly without PR noise
• Label PRs dependencies for triage

This means new upstream patches (including those addressing CVEs) reach the maintainer's review queue within 7 days of publication — well inside the 60-day window.

The Dependabot badge on README.md ("Dependabot enabled") publicly signals the policy.

4. Disclosed vulnerability handling policy (SECURITY.md)

The maintainer commits in writing to:

• Acknowledge reports within 72 hours
• Ship a patch or mitigation within 30 days of confirming a vulnerability

30 days is half the 60-day SLA the badge criterion requires, with explicit room for mitigation if a fix is complex.

5. Private disclosure channel

SECURITY.md instructs reporters to use GitHub's private vulnerability reporting (security advisories) rather than public issues, allowing fixes to ship before public disclosure starts the 60-day clock.

6. Public security advisories database

A check against https://github.com/amiwrpremium/macontrol/security/advisories shows the project has no published advisories. The Go vulnerability database (vuln.go.dev) shows no entries for github.com/amiwrpremium/macontrol. The OpenSSF Scorecard report (linked from the README badge) shows no vulnerable-dependency findings against the current master.

7. Pinned, reproducible CI tooling

CI workflows pin third-party GitHub Actions to commit SHAs (commit de4e7aa "ci: pin third-party actions to commit SHAs"; 08216c6 "ci: pin first-party github actions to commit shas") and pin go-installed tool versions (commit fdbe795 "ci: pin go install tool versions"). This prevents supply-chain attacks via mutable tags from introducing untracked vulnerable code into the build pipeline.

Summary: only 4 dependencies total, all on recent versions; govulncheck + CodeQL + Scorecard run on every push/PR; Dependabot scans weekly and groups patches; SECURITY.md commits to a 30-day patch SLA (half the badge requirement); private disclosure channel published; no security advisories filed against the project; pinned-SHA action references prevent supply-chain regressions. The criterion is satisfied with strong defence in depth.

vulnerabilities_critical_fixed — macontrol evidence

The project satisfies this suggested criterion. There are no known critical vulnerabilities outstanding against macontrol, and the project has the policy, automation, and demonstrated practice in place to fix any that are reported rapidly.

1. No known critical vulnerabilities currently outstanding

• GitHub Security Advisories for the repo: none published
  (https://github.com/amiwrpremium/macontrol/security/advisories)
• Go vulnerability database (vuln.go.dev): no entries for
  github.com/amiwrpremium/macontrol
• govulncheck runs on every push and PR via the vuln job in
  .github/workflows/ci.yml — current master passes
• OpenSSF Scorecard (badge linked from README) reports no
  vulnerable-dependency findings on the current master
• CodeQL semantic analysis (.github/workflows/codeql.yml) runs on
  every push — current master passes

2. Documented rapid-fix commitment (SECURITY.md)

The published security policy states explicit, time-bounded SLAs:

• Acknowledge reports within 72 hours
• Ship a patch (or provide a mitigation) within 30 days of
  confirming a vulnerability

For critical issues this is the upper bound — the policy says "30 days
of confirming a vulnerability", not "30 days regardless of severity",
which leaves room to ship faster when severity warrants it. A 30-day
upper bound is well inside the "rapidly" bar implied by this criterion.

3. Private disclosure channel — fixes can ship before public clock starts

SECURITY.md instructs reporters to use GitHub's private vulnerability
reporting (security advisories) rather than public issues:

https://github.com/amiwrpremium/macontrol/security/advisories/new

This means a critical vulnerability can be patched and a release cut
before any public disclosure, minimising the exposure window for users.

4. Release infrastructure supports rapid patching

The release pipeline is fully automated:

• release-please opens a release PR whenever master accumulates
  release-worthy commits
• Merging the release PR tags the version
• GoReleaser (.goreleaser.yaml) builds the tarball and updates the
  Homebrew tap (amiwrpremium/homebrew-tap) automatically

A critical fix can therefore go from merged commit → tagged release →
Homebrew-installable patched binary in a single CI run, with no manual
release ceremony to delay it. The CHANGELOG.md history shows multiple
patch releases (e.g., 0.6.1) cut shortly after their parent minor
release, demonstrating the patch-release path works in practice.

5. Defence-in-depth shrinks the critical-vulnerability surface

The threat model documented in docs/security/ and SECURITY.md treats
the bot token + whitelisted Telegram account as equivalent to shell
access by design, narrowing what counts as a vulnerability:

• Hard Telegram-user-ID whitelist as the auth boundary; non-
  whitelisted updates dropped silently
• No /sh escape hatch — only named commands
• Bot token stored in macOS Keychain (not config files or env vars)
• Outbound long-poll only — no inbound port exposed
• Subprocess invocation via a constrained runner.Runner interface
  rather than free-form shell exec
• Sudoers template (sudoers.d/macontrol.sample) limits sudo to a
  narrow allowlist of commands

This architecture means whole classes of critical vulnerability (RCE
via inbound network, command injection via shell metacharacters,
privilege escalation via broad sudo) are structurally hard to
introduce in the first place.

6. Demonstrated rapid-response posture on lint/security findings

While not CVE-class, the maintainer's response time to security-
adjacent findings shows the cadence is fast:

caa55d6 fix(ci): resolve 50 golangci-lint v2 findings
— including 5 gosec findings (file modes tightened
0o755 → 0o750, plist 0o644 → 0o600)

Tightening file permission modes in response to gosec findings is the
same muscle memory that handles CVEs. The fix-and-ship cycle is short.

7. Supply-chain hardening to prevent introducing critical vulns

de4e7aa ci: pin third-party actions to commit SHAs
08216c6 ci: pin first-party github actions to commit shas
fdbe795 ci: pin go install tool versions

Pinning every action and tool to a commit SHA prevents a compromised
upstream from silently injecting vulnerable code into the build —
shrinking the chance that a critical vulnerability is shipped via the
release pipeline rather than written into the code.

8. Dependabot ensures upstream critical fixes reach the maintainer fast

.github/dependabot.yml runs weekly on both gomod and github-actions
ecosystems. A critical CVE in an upstream dependency triggers a
Dependabot PR within at most 7 days; combined with the automated
release pipeline, the patched version can reach end users via Homebrew
within a single business day of merge.

Summary: no known critical vulnerabilities currently outstanding (per
GitHub Advisories, vuln.go.dev, govulncheck, CodeQL, and Scorecard);
SECURITY.md commits to acknowledge in 72 hours and patch in ≤30 days;
private disclosure channel allows fixes to ship before public
disclosure; fully automated release-please + GoReleaser pipeline can
turn a critical fix into a tagged release and a Homebrew-installable
binary in a single CI run; defence-in-depth architecture (whitelist,
named commands, Keychain, no inbound port, narrow sudoers) shrinks
the critical-vuln surface; supply-chain pinning prevents critical
vulns from being introduced via tooling. The criterion is satisfied.

no_leaked_credentials — macontrol evidence

The project satisfies this criterion. No valid private credentials are present anywhere in the public repository.

1. Repository-wide credential search — clean

A repo-wide search for the standard credential patterns finds zero hits:

• Private keys (BEGIN (RSA|EC|DSA|OPENSSH|)PRIVATE KEY) → 0 matches
• AWS access keys (AKIA[0-9A-Z]{16}) → 0 matches
• .env files, *.pem, .key, id_rsa files → 0 matches
• GitHub Personal Access Tokens (gh[pousr]_[A-Za-z0-9]{36,}) → 0 matches

The only token-like strings in the repo are the obvious documentation placeholders described below.

2. Documentation placeholders are not valid credentials

Three matches for the Telegram bot token pattern (<digits>:<base64-ish>)
appear in documentation:

docs/getting-started/credentials-telegram.md:55
docs/getting-started/credentials-telegram.md:146
docs/security/bot-token.md:11

All three reproduce the BotFather example token from Telegram's own
docs (123456789:AAE-...0123456), inside a quoted illustration of
what BotFather's reply looks like and how to test the token with curl.
This is an obviously fabricated placeholder:

• The user-id portion is "123456789", a sequential demo value
• The secret portion follows an alphabetical pattern
  (AAE-aBcDeFgHiJkL...)
• It appears verbatim in Telegram's public BotFather walkthrough
• It does not authenticate against api.telegram.org — calling
  https://api.telegram.org/bot<that-token>/getMe returns
  "Unauthorized"

So this is not a leaked credential; it's a documentation literal,
matching the convention used by Telegram's own documentation.

3. .gitignore protects against accidental credential commits

The .gitignore explicitly excludes credential file patterns:

Secrets

.env
.env.*
*.pem
*.key

This means a contributor who creates a local .env or .pem file cannot
accidentally git add it.

4. Real credentials are stored outside the repository

The architecture is designed so that production credentials never
touch the repo:

• Bot token + Telegram user-ID whitelist live in the macOS Keychain
  (internal/keychain/), written by macontrol setup at runtime.
  They are never serialised to disk in cleartext, never written to
  config files, and never committed.
• CONTRIBUTING.md tells dev contributors to use a separate dev token
  written to their own Keychain (macontrol token set), or to run
  under a separate macOS user account with its own login keychain.
• sudoers.d/macontrol.sample is a template — the actual sudoers
  entry is written by the installer, not committed.

5. CI secrets are referenced via GitHub Secrets, never inlined

Every secret in .github/workflows/*.yml is read via the ${{ secrets.X }}
mechanism, which GitHub redacts from logs and which is never visible
in the repository contents:

CODECOV_TOKEN (ci.yml)
CODACY_PROJECT_TOKEN (ci.yml)
GITHUB_TOKEN (pr-title.yml, release.yml — provided by GH)
RELEASE_PLEASE_PAT (release-please.yml)
HOMEBREW_TAP_TOKEN (release.yml)

No CI workflow inlines a token, hex blob, or base64 secret.

6. Active leak detection

• GitHub's secret-scanning service runs on every public repository
  by default and alerts the maintainer on any pattern match.
• OpenSSF Scorecard (.github/workflows/scorecards.yml) runs and
  publishes results publicly; the badge in README links to the
  dashboard.
• CodeQL semantic analysis (.github/workflows/codeql.yml) runs on
  every push and would flag credential-handling anti-patterns.

7. Documented credential hygiene

SECURITY.md and docs/security/bot-token.md explicitly call out that
the bot token is the project's primary credential and document where
it lives (Keychain) and how to rotate it. The README's Disclaimer
section reminds users:

"You are responsible for the bot token and the whitelist."

This is the opposite of the anti-pattern of treating credentials as
casual values that might end up in commits.

Summary: no valid credentials in the repo (zero matches for private
keys, AWS keys, GitHub PATs, or .env-style files); the only
token-shaped strings are Telegram's own documented placeholder, used
inside docs/ to illustrate BotFather output; .gitignore blocks the
common credential file patterns; production credentials live in the
macOS Keychain and never touch the filesystem; CI secrets are
referenced exclusively through GitHub's redacted secrets mechanism;
GitHub secret-scanning + CodeQL + Scorecard provide active leak
detection. The criterion is satisfied.

static_analysis — macontrol evidence

The project applies multiple FLOSS static-analysis tools to every proposed change, well before any release:

1. golangci-lint (FLOSS, GPL-3.0) — configured in .golangci.yml with 13 linters: errcheck, govet, ineffassign, staticcheck, unused, misspell, gocritic, revive (with exported and package-comments rules enabled), bodyclose, nolintlint, unparam, prealloc, gosec. Runs as the lint job in .github/workflows/ci.yml on every push and PR. make lint exposes the same check locally.

2. CodeQL — .github/workflows/codeql.yml runs GitHub's semantic code analysis on every push to master.

3. govulncheck — runs as the vuln CI job (govulncheck ./...), pinned to v1.1.4.

4. OpenSSF Scorecard — .github/workflows/scorecards.yml runs supply-chain best-practice analysis with public results (badge in README).

5. Codacy — third-party static analysis with public dashboard linked from README badges.

Releases use release-please + GoReleaser; both run after CI is green, so no release tag is created without all five tools having passed.

Summary: golangci-lint, CodeQL, govulncheck, Scorecard, and Codacy run on every push/PR. The criterion is satisfied.

static_analysis_common_vulnerabilities — macontrol evidence

Several of the static-analysis tools used target common vulnerabilities directly:

• gosec (enabled in .golangci.yml) — Go security checker covering subprocess use (G204), file-permission laxity (G302/G306), insecure tempfile creation, weak crypto, integer overflow, path traversal (G304), TLS misconfig, and SQL injection patterns.
• govulncheck — checks reachable code paths against the official Go vulnerability database (vuln.go.dev), covering both stdlib and dependencies.
• CodeQL — semantic vulnerability detection (taint flow, injection, unsafe deserialisation, etc.) using GitHub's vulnerability query packs.
• OpenSSF Scorecard — supply-chain vulnerability checks (vulnerable deps, pinned dependencies, signed releases, branch protection).
• staticcheck — includes the SA category which catches correctness bugs that frequently underlie vulnerabilities (deprecated API use, unsafe type assertions, ignored errors).

Evidence the vulnerability-focused rules fire and get acted on: commit caa55d6 ("resolve 50 golangci-lint v2 findings") explicitly itemises 5 gosec security findings fixed (file modes 0o755 → 0o750, plist 0o644 → 0o600, trusted-path file opens annotated). The criterion is satisfied.

static_analysis_fixed — macontrol evidence

No medium-or-higher severity exploitable vulnerabilities are currently outstanding from any static analyser:

• golangci-lint with default: none and max-issues-per-linter: 0 runs clean on master (the lint job is green; CI blocks merges that introduce findings).
• govulncheck ./... is green on master.
• CodeQL has no open alerts on master.
• OpenSSF Scorecard public report shows no vulnerable-dependency findings.

Demonstrated track record of timely fixes:

• caa55d6 "fix(ci): resolve 50 golangci-lint v2 findings" addressed all findings in a single PR with itemised release notes by linter category, including 5 gosec items (file-mode tightening, trusted-path annotations).
• 9f045d2 "refactor: split overgrown handlers and table-drive parsers" addressed Codacy complexity findings.
• The Music feature PR (#91) explicitly lists two refactors done to satisfy Codacy: splitting MusicCaption into per-section helpers and tickOnce into snapshot + edit-media helpers.

CI gates merges on lint + vuln passing, so static-analysis findings cannot accumulate. The criterion is satisfied.

static_analysis_often — macontrol evidence

Static analysis runs on every commit, not merely daily:

.github/workflows/ci.yml triggers on push to master and on pull_request targeting master. On every such event the following jobs run in parallel:

• lint → golangci-lint (13 linters)
• test → go test -race + coverage floor enforcement
• vuln → govulncheck ./...
• fuzz-short → 30s FuzzDecode

.github/workflows/codeql.yml runs CodeQL on every push to master.
.github/workflows/scorecards.yml runs OpenSSF Scorecard on schedule and publishes results publicly.
Codacy runs on every push (continuous integration with the repo).

Concurrency is configured to cancel superseded runs (cancel-in-progress: true) so the most recent commit always has fresh results. The criterion is satisfied at the strong end (per-commit, not daily).

dynamic_analysis — macontrol evidence

Dynamic analysis is applied on every PR before release:

1. Go native fuzzing — FuzzDecode in internal/telegram/callbacks/data_fuzz_test.go runs 30s on every PR via the fuzz-short job in .github/workflows/ci.yml. Targets the only attacker-reachable parser before the whitelist gate. Commit 0bb56cc.

2. Race detector — go test -race -coverprofile=coverage.out ./... runs on the test matrix (ubuntu-latest + macos-14) on every push/PR. The race detector is a dynamic instrumentation tool that observes actual goroutine memory accesses at runtime.

3. Coverage measurement — go test -coverprofile is dynamic instrumentation; the resulting profile feeds go-test-coverage which enforces a per-package floor.

Releases are produced by release-please + GoReleaser only after CI is green, so no release ships without these dynamic checks having passed. The criterion is satisfied.

dynamic_analysis_unsafe — macontrol evidence

N/A.

macontrol is written entirely in Go, a memory-safe language with garbage collection, bounds-checked slices, no pointer arithmetic, and runtime nil-check enforcement. The build sets CGO_ENABLED=0, so no C/C++ code is linked into the binary. There is no memory-unsafe code in the project to apply this criterion to.

(For completeness: the project does run the Go race detector via go test -race on every push/PR and a Go native fuzzer on the callback parser — but the criterion does not apply because the language is memory-safe.)

dynamic_analysis_enable_assertions — macontrol evidence

The project's dynamic analysis configuration enables checks well beyond what production builds carry:

1. Race detector enabled in tests, disabled in production
   CI: go test -race -coverprofile=coverage.out ./...
   Production build: go build -trimpath -ldflags="-s -w" CGO_ENABLED=0 — no -race
   The race detector is an extensive instrumentation layer (assertion-style runtime checks on every memory access between goroutines) that is documented to be unsuitable for production due to overhead. macontrol enables it for the test matrix on every PR and strips it from release binaries.

2. Go native fuzzer with assertion-style checks
   FuzzDecode runs the parser against random inputs and asserts on panics, oracle violations, and structural invariants. The fuzz harness is only compiled into test binaries, never the release artifact.

3. Test-only assertion helpers
   internal/runner/runner.go's Fake test mock asserts on the parsed (Name, Args) tuple of every subprocess call, providing test-time invariant checks the production runner does not perform.

4. Coverage floor as a runtime assertion
   go-test-coverage runs against the live coverage profile and asserts the floor is met (total 80%, package 75%, file 50%). This is a CI-time runtime check that does not exist in production.

These assertion-style checks are configured for test/CI runs only — production builds use stripped binaries (-s -w) with no debug info, no race detector, no fuzz harness, no coverage instrumentation. The criterion is satisfied.

dynamic_analysis_fixed — macontrol evidence

No medium-or-higher severity exploitable vulnerabilities are currently outstanding from any dynamic analyser:

• The race detector (go test -race) is green on the CI matrix (ubuntu-latest + macos-14) on master.
• FuzzDecode runs 30s per PR on the callback parser; no panics or oracle violations have been reported in the corpus or in CI.
• Coverage floor is met on master.

Demonstrated track record of timely fixes for dynamic-analysis findings:

• The cancel-stored-in-session pattern in internal/telegram/musicrefresh/refresher.go was structured specifically to avoid the race-detector and gosec false-positive interaction; the inline //nolint:gosec // cancel stored in session.cancel; called by Stop and run's defer documents why the fix is safe.
• Commit 0bb56cc proactively added fuzz coverage to the highest-risk parser, a forward-looking dynamic-analysis investment rather than a reactive fix.
• Commit fdbe795 ("ci: pin go install tool versions") pinned the dynamic-analysis tooling itself (govulncheck, go-test-coverage) so dynamic-check behaviour is reproducible.

CI gates merges on the race-detector test job passing and on FuzzDecode not panicking, so dynamic-analysis findings cannot accumulate unfixed. The criterion is satisfied.