--diagnostic-mode appears ignored by kibi-mcp; no query usage log is produced

[Looted]

Description

When `kibi-mcp` is launched with `--diagnostic-mode` from OpenCode, no `usage.log` is created under `.kb`, even though MCP queries are definitely executed successfully.

Reproduction

1. Configure OpenCode with a local Kibi MCP server, for example:

   ```json
   {
   "mcp": {
   "kibi": {
   "type": "local",
   "command": [
   "node",
   "node_modules/kibi-mcp/bin/kibi-mcp",
   "--diagnostic-mode"
   ],
   "enabled": true
   }
   }
   }
   ```

2. Start OpenCode in a repo with Kibi initialized.

3. Run MCP queries such as `kb_query`.

4. Inspect `.kb/` and `.kb/branches//`.

Expected

One of these should happen:

• `--diagnostic-mode` creates a diagnostic/query usage log (for example `usage.log`), or
• docs clearly describe where diagnostic output goes, or
• startup fails fast if `--diagnostic-mode` is not actually supported.

Actual

• The MCP server connects successfully.
• MCP queries succeed.
• `.kb/branches//audit.log` exists.
• No `usage.log` is created anywhere under `.kb`.
• `audit.log` appears to contain only write-side changesets, not query/read traffic.

Evidence / suspected cause

A few things suggest the flag is currently a no-op:

• This repo's own `opencode.json` launches `packages/mcp/bin/kibi-mcp --diagnostic-mode`, so the flag appears intended to be supported.
• `packages/mcp/bin/kibi-mcp` does not parse CLI arguments; it just starts the server.
• Debug behavior in the MCP server is gated by `KIBI_MCP_DEBUG`, not by `--diagnostic-mode`.
• `packages/core/src/kb.pl` attaches `audit.log`, not `usage.log`.
• The audit persistence looks write-oriented (`upsert`, `delete`, `upsert_rel`), so read/query activity is not persisted there.

This makes `--diagnostic-mode` effectively silent for MCP query diagnostics, and it is unclear whether:

• `usage.log` was intended but never implemented,
• `audit.log` replaced it and docs/config are stale, or
• diagnostic mode is supposed to map to `KIBI_MCP_DEBUG` but currently does not.

Environment

• OpenCode `1.2.27`
• `kibi-cli` `0.2.7`
• `kibi-mcp` `0.3.2`
• Linux
• branch: `develop`

Additional observation

`packages/mcp/src/server.ts` reports MCP server version `0.2.1` even though the installed `kibi-mcp` package version is `0.3.2`, which may indicate some packaging/version drift.

[Looted]

Follow-up after re-testing from a separate consumer repo (bizzwords).

What I checked:

• This repo is using the npm-installed packages, not the /home/looted/projects/kibi source tree:

  • npm ls resolves kibi-mcp@0.3.3, kibi-cli@0.2.8, kibi-core@0.1.10
  • the live MCP child is node node_modules/kibi-mcp/bin/kibi-mcp --diagnostic-mode
  • after the first KB call, the lazy Prolog child was swipl -g use_module('/home/looted/projects/bizzwords/node_modules/kibi-core/src/kb.pl') ...

• I then ran a controlled kb_query from the bizzwords session.

• That immediately created /home/looted/projects/bizzwords/.kb/usage.log with a kb_query entry.

• Existing logs in /home/looted/projects/kibi/.kb/usage.log and /home/looted/projects/align/.kb/usage.log did not change.

So for this repo, there is no package/source mixup: diagnostic output is repo-local as expected.

The missing usage.log here was simply because the file is created lazily on the first successful kb_* invocation. Before forcing a real KB call in this session, the local MCP process had not yet handled one, so no /home/looted/projects/bizzwords/.kb/usage.log existed yet.

Also, my earlier /home/looted/projects/kibi clue was a red herring from the dogfooding repo on the same machine, not evidence that bizzwords was resolving Kibi from source.