fix: kb_view_query parse error, formula module discovery, state-server→daemon naming - #61
Merged
Merged
Conversation
…daemon naming Three fixes surfaced by running the MCP self-test suite on the macOS install: 1. kb_view_query — all stored views (agenda/kanban/backlog/sprint/timeline/ orphans) failed with "CozoDB: unexpected input at 0..0". Root cause: `raw_query` Debug-formats cells, so the `query` column comes back quoted + escaped (e.g. `"?[...] kind = \"task\""`), and `execute_kb_view_query` ran it verbatim — the leading quote is unexpected input at position 0. Recover the clean string (new `unquote_dv`, mirroring the test helper) before executing, and return a clear error instead of a raw parser error on an empty query. +unit test. 2. module discovery — the Homebrew/FHS `bin/mae` layout keeps modules at `../share/mae/modules` (e.g. /opt/homebrew/opt/mae/share/mae/modules), which the bare `exe_dir/modules` check missed, so the formula `mae` couldn't find its bundled modules (only MAE.app via MAE_FONT_DIR-style env, or source builds via CARGO_MANIFEST_DIR, worked). Add the `../share/mae/modules` discovery path. 3. naming — `mae-state-server` was merged into `mae-daemon` (v0.13.2), but "state server" lingered in the audit_configuration JSON field (`state_server_binary_found` → `daemon_binary_found`), the self-test collab note, and several option/tool/manual descriptions. Renamed to mae-daemon. (The binary check already used `mae-daemon` correctly.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…lures loud Surfaced while debugging why `SPC C` (collab) was missing from which-key on a Homebrew macOS install: the keymap-doom module silently never loaded, yet ~90% of the leader tree still worked (from kernel keymaps.rs transitional defaults), so nothing looked broken. Root causes in module discovery/observability: 1. Divergent discovery paths. `bootstrap::load_modules` had an inline search list; `pkg/cli.rs` had its OWN `module_search_dirs()` that checked only `./modules` + the user *packages* dir. So `mae list` reported "No modules found" even when the editor loaded them fine — useless as a diagnostic. Extracted one canonical `builtin_module_dirs()` (bootstrap) used by both. 2. macOS data dir not searched. The data-dir candidate used XDG `~/.local/share` even on macOS. Added the platform-native dir via `dirs::data_dir()` (`~/Library/Application Support/mae/modules`) so `make install`/user installs work regardless of convention. (The Homebrew/FHS `../share/mae/modules` path added earlier covers brew.) 3. Silent failure. Zero-discovery was a `debug!`; a missing keymap-doom had no branch at all. Both now `warn!` with the searched paths and an explicit note that module-only bindings (collab, KB sharing) will be missing — the log that would have diagnosed this immediately. + unit tests for builtin_module_dirs (env override precedence, no duplicates). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jul 25, 2026
Closed
cuttlefisch
added a commit
that referenced
this pull request
Aug 5, 2026
Takes dependabot's rust-dependencies group bump directly rather than landing it as a separate PR that would immediately conflict with this branch's lockfiles. clap 4.6.4 -> 4.6.5 and clap_builder 4.6.2 -> 4.6.5, applied to BOTH workspaces (the daemon keeps its own Cargo.lock per ADR-014, and dependabot only ever touches the root one). Also carries the 0.14.89 -> 0.14.92 workspace-internal version sync that appears in every one of these PRs — issue #61: the version-bump workflow does not update Cargo.lock, so the locks drift behind the released version and every branch rediscovers it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
cuttlefisch
added a commit
that referenced
this pull request
Aug 5, 2026
Both lockfiles still claimed 0.14.92 while both `Cargo.toml`s said 0.14.93 — `version-bump.yml` bumps the manifests but never regenerates the locks, so every release leaves a tree where the committed lock disagrees with the version it is tagged as (#61). Any build regenerates it and dirties the tree. Mechanical: version strings only, no dependency changes. Committed here rather than left dirty because deploy provenance should not inherit a lock that doesn't match its tag — but this does NOT fix #61 itself, which is the workflow. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three fixes surfaced by running the MCP
self_test_suiteon the macOS (Homebrew) install.1.
kb_view_queryparse error (🔴 real bug)Every stored view (
agenda/kanban/backlog/sprint/timeline/orphans) failed withCozoDB: unexpected input … at 0..0.Root cause:
CozoKbStore::raw_queryDebug-formats every cell, so thequerycolumn reads back quoted + escaped (e.g."?[...] kind = \"task\"").execute_kb_view_queryran that verbatim — the leading"is the "unexpected input at 0..0". (The store-level test only passed because it unescapes viadv_str; the tool path was never covered.)Fix: recover the clean string (new
unquote_dv) before executing, and return a clear error instead of a raw parser error on an empty query. + unit test.2. Module discovery on Homebrew installs (🟡)
The formula
maeinstalls modules at…/share/mae/modules(FHS:bin/mae→../share/mae/modules), but discovery only checkedexe_dir/modules, so the formula binary couldn't find its bundled modules (onlyMAE.appand source builds could). Added the../share/mae/modulespath.3.
state-server→mae-daemonnaming (🟡)mae-state-servermerged intomae-daemonin v0.13.2, but the old name lingered: theaudit_configurationJSON field (state_server_binary_found→daemon_binary_found), the self-test collab note, and several option/tool/manual descriptions. Renamed throughout. (The binary check already usedmae-daemon.)Verified:
cargo check --workspaceclean, fmt + clippy clean,unquote_dv+view_queries_are_executabletests pass.🤖 Generated with Claude Code