Add a regression test pinning --kb resolution for a single-entry default registry

[williamthorsen]

Problem

This issue originally reported that kb-add --kb <name> rejects every value with no-kb-resolvable, even when <name> is the exact top-level key of a registered KB. Investigation against main shows the explicit---kb path is already correct and passing: resolveWritableKb loads config.entries once and matches entry.name === explicitKb, where the loader sets entry.name to the kbs: top-level key. The reported failure does not reproduce — it was almost certainly an artifact of a stale installed bundle (predating the #673 extraction and #689 loader consolidation).

The existing suite covers --kb overriding discovery/default, naming a nonexistent entry, naming a read-only entry, and naming the writable entry alongside a read-only default. The one scenario it does not mirror is the exact shape this issue described, and whose "likely cause" was hypothesized to be specific: a single-entry registry whose sole entry is both default: true and the explicitly-requested entry. That case is logically equivalent to covered cases, but leaving it untested means the precise reported scenario has no durable in-code guard.

Context

• Resolution logic: packages/agents/src/kb-shared/resolve-writable-kb.ts. All three selection paths (explicit -> discovered -> registry-default) match against a single config.entries array, so it is structurally impossible for registry-default to succeed while --kb fails on the same key.
• Loader: packages/kb-core/src/discovery/load-config.ts keys each entry by its kbs: top-level name.
• Existing tests and fixtures: packages/agents/src/kb-shared/__tests__/resolve-writable-kb.test.ts with fixtures under __tests__/fixtures/.
• The bug was reported against the installed ~/.rovodev/.../kb-add.mjs bundle, which is opaque and not rebuilt from current source.

Proposed solution

Add a single regression test at the resolveWritableKb unit level (the layer that owns entry matching), backed by a new single-entry home-registry fixture that mirrors the issue's registry exactly. The test asserts that --kb coding resolves to the registered path with source: 'explicit' when the registry holds exactly one entry that is also the default. No production code changes — the behavior is already correct. Once merged, close this issue as already-fixed, referencing the regression test.

Acceptance criteria

Must have

• A new fixture registers a single KB entry that is default: true, in its own home directory (not a reuse of a multi-entry fixture).
• A new test in resolve-writable-kb.test.ts asserts --kb <name> against that single-entry-default registry resolves { ok: true, kb: { name, path, source: 'explicit' } }.
• The new test passes and the full agents test suite remains green.
• This issue is closed as already-fixed, with a comment pointing at the regression test and noting the stale-bundle root cause.

Nice to have

• The test name references Add a regression test pinning --kb resolution for a single-entry default registry #684 so the regression's origin is discoverable from the code.

---

Original report retained below for reference.

Original report

kb-add --kb <name> rejects every value with no-kb-resolvable, even when <name> is the exact top-level key of a registered KB in ~/.rovodev/kb.yaml. The documented contract of --kb is not honoured: the flag should override discovery and the registry default to name a specific entry, but in practice it never resolves.

Reproduction registry (~/.rovodev/kb.yaml):

kbs:
  coding:
    path: ~/repos/vaults/coding
    description: Personal coding knowledge base
    default: true

Running echo 'body' | node ~/.rovodev/skills/kb-add/kb-add.mjs --kb coding --type howto --title 'repro' from any cwd returned { "ok": false, "error": "no-kb-resolvable", "message": "--kb \"coding\" does not match any registered knowledge base" }. Omitting --kb and relying on discovery or the registry default worked.

Environment: Node v22.22.0, macOS, kb-add bundled helper as installed by codeassembly-agents install.

Workaround: cd into the target KB before running kb-add, so discovery resolves the KB instead of the flag.