qttune

QtTune is pre-release (v0.1.0–v0.3.0) with no production or widely-used older versions; the current development line supersedes prior tags, as stated in the version support table (https://github.com/erickramer42/qttune/blob/main/SECURITY.md). Upgrade compatibility is managed by design: the public C ABI is append-only so newer cores remain source-compatible with existing consumers, and deliberate breaks are flagged with feat!: commits, the ECUIO_SIGNAL_SET_LAYOUT version guard (https://github.com/erickramer42/qttune/blob/main/docs/adr/0016-signal-definition-layout.md), and documented in ADRs under docs/adr/.

GitHub's issue tracker is used for tracking individual issues: https://github.com/erickramer42/qttune/issues

QtTune is in pre-release development (v0.1.0–v0.3.0) with no production-deployed versions in the wild. No vulnerability reports have been received and resolved in the last 12 months per the security policy (https://github.com/erickramer42/qttune/blob/main/SECURITY.md). The project has a public reporting channel via GitHub Security Advisories, but as of this assessment date, no CVEs or security advisories have been issued.

SECURITY.md documents the full response process: intake via GitHub Security Advisories (https://github.com/erickramer42/qttune/security/advisories/new), acknowledgment within 7 days and status updates within 30 days, coordinated public disclosure after mitigation, and category-specific response paths distinguishing code-security findings (CVE assignment if severe) from supply-chain, privacy and intentional protocol-analysis behavior. See https://github.com/erickramer42/qttune/blob/main/SECURITY.md.

Coding standards are identified per primary language and required of contributions: LLVM-based .clang-format for C/C++ (with documented deviations), SEI CERT C as the reference for the strict-C ABI headers, Qt's QML Coding Conventions for the front end, and the tree's CMake conventions, with zero-warning builds enforced for every first-party target. See https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md and https://github.com/erickramer42/qttune/blob/main/.clang-format

The project builds with CMake, which honors the standard environment variables by design: CC/CXX select the compiler and CFLAGS/CXXFLAGS/LDFLAGS are absorbed into the initial CMAKE_<LANG>_FLAGS cache at configure time and applied to every compiler and linker invocation, rather than replaced. The project's own flags (-Wall -Wextra, hardening) are appended per-target via target_compile_options and never overwrite the incoming values. Sanitizer builds (ASan/UBSan) are enabled in CI through CMake options, so distribution hardening and instrumentation features can be turned on without editing the build files. See https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt

The build system is CMake with no stripping anywhere in the build: there is no install -s, no --strip linker flag, and no post-build strip step in any target or CI job. Debugging information follows the standard CMake mechanism — -g arrives via CXXFLAGS/CFLAGS or CMAKE_BUILD_TYPE=Debug/RelWithDebInfo and is passed through to every compiler invocation, with no toolchain file or target property overriding it. Sanitizer and fuzz builds in CI compile with full symbol information. See https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt

The build uses CMake, which is not a recursive build system: add_subdirectory scopes variables and targets but does not invoke an independent build per directory. CMake generates one unified dependency graph for the whole project, so cross-directory dependencies are expressed accurately — the app target links ecuio-core, tests link both, and the root-level Qt-link check reads ecuio-core's link properties after every subdirectory has been processed, which only works because the graph is global. No recursive make invocation exists anywhere in the tree. See https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt

QtTune is pre-release software with no distributed artifacts: there are no releases, downloads, or packages intended for installation, and per SECURITY.md no supported production versions exist yet. The project distributes only source, built locally by users from the repository, so no commonly-used installation convention applies. Formal installation and packaging (including signed release artifacts) are planned for v1.0 as documented in SECURITY.md. See https://github.com/erickramer42/qttune/blob/main/SECURITY.md

QtTune has no installation system: it is pre-release source-only software with no make install, packaging, or distributed artifacts, so no installation-location convention applies. Users build and run from their own build trees. Packaging with standard conventions is planned for v1.0 (see SECURITY.md's release plans). See https://github.com/erickramer42/qttune/blob/main/SECURITY.md

Potential developers get a documented, quick setup path: CONTRIBUTING.md's "Building" section gives the complete three-command flow (cmake configure with CMAKE_PREFIX_PATH, build, ctest), with exact compiler and CMake minimums stated up front. docs/development.md extends this with platform-specific instructions, including installing Qt via aqtinstall (with the documented workaround), the two-tree Windows layout for the surrogate and fake DLLs, and troubleshooting. Every test tier that can run without real hardware (Unit, Bridge, QML, HARNESS, Fuzzing) executes through the same ctest invocation, so the test environment comes with the standard build. The CI workflows demonstrate the setup is fully automatable: GitHub Actions installs Qt, configures, builds and runs the whole suite on all three desktop platforms from the repository alone. See https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md and https://github.com/erickramer42/qttune/blob/main/docs/development.md

The project's external dependencies are declared in the build system's computer-processable form: root and per-directory CMakeLists.txt files use find_package(Qt6 6.12 REQUIRED COMPONENTS Core Gui Quick ...) with the required components and minimum version stated, and each first-party target links against the imported targets by name. The compiler/CMake minimums are likewise machine-checked via cmake_minimum_required(VERSION 3.21) and the C++17 standard setting, so a configure step fails loudly and early when a dependency is missing or too old. CI workflows additionally encode the dependency acquisition (Qt via aqtinstall with a pinned version) in executable YAML. See https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt and https://github.com/erickramer42/qttune/blob/main/app/CMakeLists.txt

The repository monitors external dependencies with Dependabot (.github/dependabot.yml), which performs version and vulnerability monitoring on the dependency surface declared in the repository — GitHub Actions workflows — and opens pull requests when updates or vulnerable versions are detected. GitHub additionally surfaces Dependabot alerts for any dependency in a recognized manifest. The project's runtime dependency surface is deliberately minimal: Qt is a system-provided library rather than a vendored or manifest-pinned component, and the C ABI design keeps convenience copies of third-party code out of the tree. See https://github.com/erickramer42/qttune/blob/main/.github/dependabot.yml

QtTune uses system/provided components rather than bundling them: Qt is resolved via find_package(Qt6) against the user's or distro's Qt installation and linked dynamically (LGPL), with no vendored or forked convenience copies anywhere in the tree. The only externally-maintained components consumed at build/runtime are Qt and the Windows VC redistributable, both obtained from their upstream providers through their standard distribution mechanisms (system Qt packages, aqtinstall in CI, VS redist installer). CI pins Qt's version at acquisition, so updating to a patched Qt release is a one-line change in the workflow file. See https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt

The project's technology stack is current throughout: C++17 with CMake 3.21+ targeting Qt 6.12 (the current Qt release line), MSVC 2022+/GCC 10+/Xcode 16+ as minimums — all matching Qt 6's own requirements. No deprecated API usage is apparent, and several documented decisions explicitly chose modern alternatives: UTF-8/UTF-16 conversion via the established pattern in win_utf8 instead of Annex K functions, Win32 registry enumeration via RegOpenKeyExW/RegEnumKeyExW with explicit wide-char forms rather than the legacy ANSI variants, and GetProcAddress-based dynamic resolution instead of deprecated import mechanisms. The build enforces currency mechanically: every first-party target compiles with /W4 or -Wall -Wextra at zero warnings, so deprecation warnings (a standard category in both compilers) cannot accumulate silently. See https://github.com/erickramer42/qttune/blob/main/CMakeLists.txt

The project runs its full test suite in CI on every push and pull request via .github/workflows/ci.yml: GitHub Actions builds and runs the ctest suite on Windows, Linux and macOS for each commit to main and each PR, producing pass/fail reports on the Actions run page. Reports detail every test case and outcome per platform. Additional jobs run the Qt-free core-only configuration, sanitizer builds (ASan/UBSan), libFuzzer harnesses, and the iOS Simulator smoke on PRs. The commit history shows CI has been consistently applied since its introduction. See https://github.com/erickramer42/qttune/blob/main/.github/workflows/ci.yml and https://github.com/erickramer42/qttune/actions

Every bug fixed in the last six months receives a regression test as a matter of documented policy: CONTRIBUTING.md's pull-request checklist requires tests for bug fixes, and the project's testing tiers exist to pin bug behavior at the level where it occurred. The closed Known Issues (#21, #25, #26, #31, #32, #33, #34, and others in STATUS.md's history) correspond to test coverage in the suite — e.g., the write-latch behavior (#33's async teardown) is pinned by bridge tests, and the backoff-growth test (BackoffGrowsUnderSustainedHardFailure) exists specifically to prevent the sustained-failure regression from returning. See https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md

The project has a documented, enforced policy that new functionality requires tests: CONTRIBUTING.md's Testing section states "a change is only done when tested at the right tier" and mandates the appropriate tier per change type — with the strengthened rule that "changes to timing, threading, callbacks or streaming state need at least a Bridge- or HARNESS-tier test even if a unit test passes." Pull requests must describe how the change is tested (the // File/layer: and // Testing: headers every changed file carries), and CI gates merging on a green suite ("A pull request that isn't green on CI won't be merged"). Evidence: https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md

The testing policy for changes is documented in CONTRIBUTING.md, the project's instructions for contributions (https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md): it requires tests at the appropriate tier for each change, defines the tiers, and states that pull requests failing CI are not merged.

The project enables warnings for all first-party targets (via qttune_enable_warnings()) and keeps builds clean at zero warnings on MSVC, as documented in STATUS.md and the README. The sole exception is a documented MSVC pragma suppressing C4702 (unreachable code) inside Qt's own inline headers — a vendor-supplied third party that the project cannot modify, noted as such in the build configuration. This is maximal strictness given the external dependency.

QtTune implements secure design principles through: (1) read-only vehicle interaction by default, eliminating write-side attack surfaces; (2) strict URI scheme validation rejecting unknown transports; (3) append-only C ABI preventing accidental interface mutation; (4) tiered test coverage including libFuzzer harnesses and ASan/UBSan in CI; (5) thread-isolation rules ensuring callbacks cannot block or destroy sessions. See https://github.com/erickramer42/qttune/blob/main/CONTRIBUTING.md and https://github.com/erickramer42/qttune/blob/main/SECURITY.md.