You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-`contrib/mutterkey.service`: example user service
40
43
-`contrib/org.mutterkey.mutterkey.desktop`: hidden desktop entry used for desktop identity/integration
41
44
-`scripts/check-release-hygiene.sh`: repo hygiene checks for publication-facing content
45
+
-`next_feature/`: tracked upcoming feature plans as Markdown; keep only plan `.md` files and the folder-local `.gitignore`
42
46
-`docs/Doxyfile.in`: Doxygen config template for repo-owned API docs
43
47
-`docs/mainpage.md`: Doxygen landing page used instead of the full README
44
48
-`scripts/run-valgrind.sh`: deterministic Valgrind Memcheck runner for release-readiness checks
@@ -64,6 +68,10 @@ cmake -S . -B "$BUILD_DIR"
64
68
cmake --build "$BUILD_DIR" -j"$(nproc)"
65
69
```
66
70
71
+
If a sandboxed build fails with `ccache: error: Read-only file system`, treat
72
+
that as an environment limitation rather than a repo regression and rerun the
73
+
build with `CCACHE_DISABLE=1`.
74
+
67
75
If the task affects install layout, licensing, or packaging, also validate a temporary install prefix:
68
76
69
77
```bash
@@ -94,6 +102,7 @@ Notes:
94
102
- A small `Qt Test` + `CTest` suite exists for config loading and audio normalization, including malformed JSON, wrong-type config inputs, and recording-normalizer edge cases
95
103
- Config loading is intentionally forgiving: invalid runtime values fall back to defaults and log warnings
96
104
- Use `ctest --test-dir "$BUILD_DIR" --output-on-failure` for changes that affect covered code
105
+
- Keep Qt GUI or Widgets tests headless under `CTest`: set `QT_QPA_PLATFORM=offscreen` in the test registration or test properties rather than relying on the caller environment
97
106
- Use `bash scripts/run-valgrind.sh "$BUILD_DIR"` or `cmake --build "$BUILD_DIR" --target valgrind` when validating memory behavior for release readiness or after fixing memory-lifetime issues
98
107
- On Debian-family systems, install `libc6-dbg` if Valgrind fails at startup with a `ld-linux` / mandatory redirection error
99
108
- Use `cmake --build "$BUILD_DIR" --target clang-tidy` after C++ changes when static-analysis noise is likely to matter
@@ -114,10 +123,12 @@ Notes:
114
123
- Keep the Doxygen main page in `docs/mainpage.md` small and API-focused. The release-facing `README.md` may link to files outside the Doxygen input set and should not be used as the Doxygen main page unless the input set is expanded deliberately
115
124
- Keep analyzer fixes targeted to `src/` and `tests/`; do not churn `third_party/` or generated Qt autogen output to satisfy tooling
116
125
- Reconfigure the build directory after installing new tools so cached `find_program()` results are refreshed
126
+
- When validating inside a restricted sandbox, be ready to disable `ccache` with `CCACHE_DISABLE=1` if the cache location is read-only; that is an execution-environment issue, not a Mutterkey build failure
117
127
- Prefer fixing the code over weakening `.clang-tidy` or the Clazy check set; only relax tool config when the warning is clearly low-value for this repo
118
128
- Do not add broad Valgrind suppressions by default; only add narrow suppressions after reproducing stable third-party noise and keep them clearly scoped
119
129
- When adding tests, prefer small `Qt Test` cases that run headlessly under `CTest` and avoid microphone, clipboard, or KDE session dependencies unless the task is specifically integration-focused
120
130
- For tool-driven cleanups, preserve the existing design and behavior; do not perform broad rewrites just to satisfy style-oriented recommendations
131
+
- Keep forward-looking feature plans under `next_feature/` as tracked Markdown files; do not leave scratch notes, binaries, or generated artifacts there
121
132
122
133
## Coding Guidelines
123
134
@@ -128,6 +139,8 @@ Notes:
128
139
- Avoid introducing optional backends, plugin systems, or cross-platform abstractions unless the task requires them
129
140
- Keep the audio path explicit: recorder output may not already match Whisper input requirements, so preserve normalization behavior
130
141
- Prefer narrow shared value types across subsystems; for example, consumers that only need captured audio should include `src/audio/recording.h`, not the full recorder class
142
+
- Keep JSON and other transport details at subsystem boundaries; prefer typed C++ snapshots/results once data crosses into app-owned control, tray, or service code
143
+
- Prefer dependency injection for tray-shell and control-surface code from the first implementation so headless Qt tests stay simple
131
144
- Preserve the current product direction: embedded `whisper.cpp`, KDE-first, CLI/service-first
132
145
133
146
## C++ Core Guidelines Priorities
@@ -193,12 +206,16 @@ Typical model location:
193
206
194
207
- Read `README.md` first, especially `Overview`, `Quick Start`, `Run As Service`, and `Development`, then read the touched source files before editing
195
208
- Prefer targeted changes over speculative cleanup
209
+
- If a change grows daemon, tray, or control-plane behavior, prefer extracting or extending repo-owned libraries under `src/app/`, `src/control/`, or other focused modules instead of piling more orchestration into `src/main.cpp`
196
210
- Update `README.md` and `config.example.json` when behavior or setup changes
197
211
- Update `contrib/mutterkey.service` and `contrib/org.mutterkey.mutterkey.desktop` when service/desktop behavior changes
198
212
- Update `LICENSE`, `THIRD_PARTY_NOTICES.md`, CMake install rules, and `third_party/whisper.cpp.UPSTREAM.md` when packaging, licensing, or vendored dependency behavior changes
199
213
- Keep `README.md`, `AGENTS.md`, and any relevant local skills aligned with the current `scripts/update-whisper.sh` workflow when the vendor-update process changes
214
+
- Store upcoming feature plans in `next_feature/` as Markdown files, and update the existing plan there when refining the same upcoming feature instead of scattering notes across the repo
215
+
- Treat `mutterkey-tray` as a shipped artifact once it is installed or validated in CI; keep install rules, README/setup notes, release checklist items, and workflow checks aligned with that status
200
216
- Verify with a fresh CMake build when the change affects compilation or linkage
201
217
- Run `ctest` when touching covered code in `src/config.*` or `src/audio/recordingnormalizer.*`, and extend the deterministic headless tests when practical
218
+
- When adding or fixing Qt GUI tests, make the `CTest` registration itself headless with `QT_QPA_PLATFORM=offscreen` so CI does not try to load `xcb`
202
219
- Prefer expanding tests around pure parsing, value normalization, and other environment-independent logic before adding KDE-session or device-heavy coverage
203
220
- Use `-DMUTTERKEY_ENABLE_ASAN=ON` and `-DMUTTERKEY_ENABLE_UBSAN=ON` for fast iteration on memory and UB bugs, and use the repo-owned Valgrind lane as the slower release-focused confirmation step
204
221
- Run `clang-tidy` and `clazy` targets for non-trivial C++/Qt changes when the tools are installed in the environment
0 commit comments