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
-`once` mode requires microphone access and a valid Whisper model path
122
+
-`once` mode requires microphone access and a valid model artifact path
116
123
- Real transcription verification needs a configured model in `~/.config/mutterkey/config.json` or a custom config path
117
124
- A small `Qt Test` + `CTest` suite exists for config loading, audio normalization, streaming-runtime helpers, and transcription-worker orchestration, including malformed JSON, wrong-type config inputs, recording-normalizer edge cases, and fake streaming backend behavior
118
125
- Repo-owned test cases are expected to carry `WHAT/HOW/WHY` comments near the start of each real test body; `scripts/check-test-commentary.sh` and `scripts/check-release-hygiene.sh` enforce that convention
@@ -130,6 +137,9 @@ Notes:
130
137
- Use `cmake --build "$BUILD_DIR" --target docs` when touching repo-owned public headers, Doxygen config, the Doxygen main page, or CI/docs wiring
131
138
- If install rules or licensing files change, confirm the temporary install contains the expected files under `share/licenses/mutterkey`
132
139
- If you add or change public methods in repo-owned headers, expect `cmake --build "$BUILD_DIR" --target docs` to fail until the new API is documented; treat that as part of the normal implementation loop, not follow-up polish
140
+
- Newly added repo-owned public structs and free functions in public headers also
141
+
need Doxygen comments immediately; the `docs` target treats undocumented new
142
+
API surface as a real failure, not optional cleanup
133
143
134
144
## Tooling Best Practices
135
145
@@ -166,11 +176,17 @@ Notes:
166
176
- Avoid introducing optional backends, plugin systems, or cross-platform abstractions unless the task requires them
167
177
- Keep the audio path explicit: recorder output may not already match Whisper input requirements, so preserve normalization behavior
168
178
- Prefer product-owned naming such as runtime audio, chunks, events, diagnostics, and compatibility wrappers over backend-shaped naming when touching app-owned code
179
+
- Prefer product-owned model terminology too: package, manifest, catalog, metadata,
180
+
compatibility marker, and model artifact path are the primary nouns now;
181
+
reserve backend-shaped wording for the whisper adapter or raw-file migration path
169
182
- 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
170
183
- 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
171
184
- Prefer dependency injection for tray-shell and control-surface code from the first implementation so headless Qt tests stay simple
172
185
- When preparing the transcription path for future runtime work, prefer app-owned engine/session seams and injected sessions over leaking concrete backend types into CLI, service, or worker orchestration. Keep immutable capability reporting on the engine side, keep runtime inspection data in `RuntimeDiagnostics`, and keep the session side focused on mutable decode state, warmup, chunk ingestion, finish, and cancellation
173
186
- Prefer product-owned runtime interfaces, model/session separation, and deterministic backend selection before adding new inference backends or widening cross-platform support
187
+
- Keep model validation, metadata extraction, and compatibility checks app-owned.
188
+
`whisper.cpp` should not be the first component that tells Mutterkey whether a
189
+
model artifact is obviously malformed, incompatible, or oversized
174
190
- Keep compatibility shims explicit in naming. If a one-shot daemon/CLI path is implemented on top of the streaming runtime seam, name it as a compatibility wrapper rather than making the old one-shot shape look like the primary contract
175
191
- Keep backend-specific validation out of `src/config.*` when practical. Product config parsing should normalize and preserve user input, while backend support checks should live in the app-owned runtime layer near `src/transcription/*`
176
192
- Preserve the current product direction: embedded `whisper.cpp`, KDE-first, CLI/service-first
@@ -199,6 +215,9 @@ Apply the C++ Core Guidelines selectively and pragmatically. For this repo, the
199
215
-`scripts/update-whisper.sh` requires a clean Git work tree before it will fetch or run subtree operations
200
216
- Treat `third_party/whisper.cpp` as subtree-managed vendor content and update it through the helper script rather than manual directory replacement
- Prefer resolving model-package, metadata, and import work entirely in app-owned
219
+
code. Raw whisper.cpp `.bin` support is now a compatibility/import concern, not
220
+
the canonical product contract
202
221
- Prefer keeping fake runtime tests and app-owned helpers free of vendored whisper linkage unless the test is specifically about the whisper adapter or engine factory
203
222
- Prefer fixing vendored target metadata from the top-level CMake when the issue is Mutterkey packaging or warning noise, instead of patching upstream vendored files directly
204
223
- If you must modify vendored code, document why in the final response and record the deviation in `third_party/whisper.cpp.UPSTREAM.md`
@@ -209,6 +228,9 @@ Apply the C++ Core Guidelines selectively and pragmatically. For this repo, the
209
228
- Repo-owned source is MIT-licensed in `LICENSE`
210
229
- Third-party licensing and provenance notes live in `THIRD_PARTY_NOTICES.md`
211
230
-`whisper.cpp` model files are not bundled; do not add model binaries to the repository
231
+
- Native Mutterkey model packages also must not be committed to the repository;
232
+
if a release needs to ship one, include it only in the release artifact or as a
233
+
separate release asset outside Git
212
234
- Do not introduce machine-specific home-directory paths, absolute local Markdown links, or generated build artifacts into tracked files
213
235
- If a task changes install layout or shipped assets, keep the CMake install rules and license installs aligned with the new behavior
214
236
- The installed shared-library payload is runtime-focused; do not start installing vendored upstream public headers unless the package contract intentionally changes
@@ -232,15 +254,24 @@ Default config path:
232
254
Typical model location:
233
255
234
256
```text
235
-
~/.local/share/mutterkey/models/ggml-base.en.bin
257
+
~/.local/share/mutterkey/models/<package-id>
236
258
```
237
259
260
+
Current `transcriber.model_path` semantics:
261
+
262
+
- package directory is the canonical target
263
+
-`model.json` manifest path is also accepted
264
+
- raw whisper.cpp-compatible `.bin` files are accepted only as a migration
265
+
compatibility path
266
+
238
267
## Agent Workflow
239
268
240
269
- Read `README.md` first, especially `Overview`, `Quick Start`, `Run As Service`, and `Development`, then read the touched source files before editing
241
270
- Prefer targeted changes over speculative cleanup
242
271
- 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`
243
272
- Update `README.md` and `config.example.json` when behavior or setup changes
273
+
- Update `RELEASE_CHECKLIST.md` too when release-facing model packaging, shipped
274
+
assets, or release-bundle guidance changes
244
275
- Update `contrib/mutterkey.service` and `contrib/org.mutterkey.mutterkey.desktop` when service/desktop behavior changes
245
276
- Update `LICENSE`, `THIRD_PARTY_NOTICES.md`, CMake install rules, and `third_party/whisper.cpp.UPSTREAM.md` when packaging, licensing, or vendored dependency behavior changes
246
277
- 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
@@ -262,7 +293,9 @@ Typical model location:
262
293
- Prefer the `lint` target for a full pre-handoff analyzer pass, and use the individual analyzer targets when iterating on one class of warnings
263
294
- Run `bash scripts/run-valgrind.sh "$BUILD_DIR"` before handoff when the task is specifically about memory, ownership, lifetime, shutdown, or release hardening
264
295
- Run `bash scripts/check-release-hygiene.sh` before handoff when the task touches publication-facing files or repository metadata
265
-
- Remember that the release-hygiene script now also enforces test commentary coverage, so changes to test structure or helper scripts may need both test updates and commentary updates
296
+
- Remember that the release-hygiene script now also enforces test commentary
297
+
coverage and rejects tracked `.bin` / `.gguf` artifacts, so release-facing or
298
+
helper-script changes may need both commentary updates and binary-artifact policy checks
266
299
- If `QT_QPA_PLATFORM=offscreen "$BUILD_DIR/mutterkey" diagnose 1` fails in a headless environment after model loading or during KDE/session-dependent startup, note that limitation explicitly rather than assuming the runtime seam or docs-only change regressed behavior
267
300
- A headless `diagnose 1` failure after whisper model loading still does not necessarily indicate a streaming-runtime regression; separate runtime-contract changes from KDE/session or headless-environment limits
268
301
- Do not leave generated artifacts in the repository tree at the end of the task
0 commit comments