- Configure:
cmake --preset release - Build:
cmake --build --preset release - Test:
ctest --preset release - Single test binary:
./build/release/test/qdmi_test - For debug builds, replace
releasewithdebug. - For coverage, use the
coverageconfigure, build, and test presets. - For all available options and presets, see
CMakeLists.txtandCMakePresets.json.
The first configure may need network access because dependencies are managed
with CMake FetchContent.
- Sources:
docs/ - Configure:
cmake -S . -B build/docs -G Ninja -DBUILD_QDMI_DOCS=ON - Build:
cmake --build build/docs --target qdmi-docs - Generated HTML:
build/docs/docs/html/index.html
- Public interface: C11 headers in
include/qdmi/ - Tests and example implementations: C++20
- Build system: CMake 3.24+ with presets and
FetchContent - Unit tests: GoogleTest in
test/ - Example device, driver, tool, and FoMaC implementations:
examples/ - Device project source template:
templates/device/ - Documentation: Doxygen with Markdown sources in
docs/ - Formatting and checks:
prek,clang-format,cmake-format,rumdl,typos, and license checks - Static analysis:
clang-tidy
- MUST read and follow
docs/contributing.mdbefore making a contribution. - MUST run
uvx prek run -aafter every batch of changes. All hooks from.pre-commit-config.yamlmust pass before submitting. - MUST add or update tests for every code change, including bug fixes.
- MUST follow existing patterns in neighboring files and keep changes focused on one feature or bug; avoid unrelated refactors or formatting changes.
- MUST document new user-facing behavior, update
CHANGELOG.mdfor noteworthy changes, and updateUPGRADING.mdfor breaking changes. - MUST follow
docs/ai_usage.md: a human must review and understand all AI-assisted work. AI assistance must not be used forgood first issuecontributions. - MUST include a commit footer attribution in the form
Assisted-by: [Model Name] via [Tool Name]when AI tools helped prepare a commit. - MUST preserve the Apache-2.0-with-LLVM-exception license headers used by the surrounding source files.
- NEVER expose, print, store, or commit credentials, tokens, or other secrets.
- PREFER targeted builds and tests during development, then run the full relevant preset before handoff.
- NEVER edit generated build output or dependency source trees under
build/.
- MAY create, submit, and edit pull requests; create and manage issues; and comment on issues or pull requests when the task explicitly authorizes that external action. The human remains responsible for reviewing all submitted work.
- MUST use the repository's pull request template when one is present.
- Every agent-authored or agent-edited public text MUST begin with
馃 *AI text below* 馃on its first line. This applies to issue and pull request descriptions, review bodies, inline review comments, issue comments, replies, and other submitted text bodies; titles are exempt. - When editing human-authored public text, preserve its original content and add the disclosure at the beginning of the edited field.
- MUST keep external communication accurate, specific, and non-repetitive; do not post low-quality or unsolicited comments.
- MUST keep the public QDMI interface C11-compatible.
- MUST use C++20 for tests and example implementations.
- MUST follow the LLVM coding style and the repository's
.clang-formatand.clang-tidyconfigurations. - MUST use Doxygen-style API comments. Provide
@brief, document every parameter with@param, and document non-void return values with@return. - MUST add new public headers below
include/qdmi/and cover API changes intest/. - PREFER existing QDMI status codes, types, naming, and ownership patterns over introducing parallel abstractions.
- Treat
templates/device/as the source for generated device projects; update the source template when changing generated-project behavior. - Keep template placeholder forms (
MY,my_, andmy-) consistent withcmake/GenerateTemplate.cmake. - When changing the template, build and test its instantiated targets as well as the main QDMI test suite.
- Keep example implementations representative of the public interface and update them when interface changes require it.
- Did the relevant configure and build preset succeed?
- Did targeted tests and
ctest --preset <preset>pass? - Did
uvx prek run -apass without errors? - Are all behavior changes covered by automated tests?
- Does the public interface remain C11-compatible?
- Were Doxygen comments and documentation updated for API changes?
- Were
CHANGELOG.mdandUPGRADING.mdupdated when appropriate? - Were template and example consumers updated and tested when the interface or generation behavior changed?
- Were any agent-authored issue or pull request texts explicitly authorized and marked with the required visible disclosure?