chore(release): 0.2.92 — ship the merged multi-tag data-loss fix (#34) that was never published

[andrei-hasna]

Why

No source change. This releases a fix that is already on main and has never reached a single install.

-t/--tag silent data loss on knowledge add was fixed by #34 (fix(cli): stop silently dropping repeated -t tags on add/update/upsert), merged 2026-07-27T19:39:04Z, commit 78db6e1 — confirmed an ancestor of origin/main.

npm 0.2.91 was published 2026-07-24T15:52:10Z, three days earlier, and package.json was never bumped. package.json at 78db6e1 and at its parent both read 0.2.91.

So main and the registry both claim 0.2.91 while behaving differently, and npm publish cannot ship the fix at all — that version already exists. Since the version numbers match, nothing signals the difference.

Measured

Installed 0.2.91, five repeated flags:

knowledge add "…" "…" -t convention -t naming -t repos -t github -t proposed --json
→ "tags": ["proposed"]        # exit 0, four tags discarded silently

main's committed bundle, same five flags:

tags = ['convention', 'naming', 'repos', 'github', 'proposed']   # add
tags = ['alpha', 'beta', 'gamma']                                # -t "alpha,beta, gamma"
tags = ['one', 'two', 'three', 'four']                           # update -t appends, unregressed
exit=1  "no tag name found"                                      # -t " , " fails loudly

Tags are the retrieval surface, so a dropped tag makes an entry invisible to every --tag query — indistinguishable from never having written it. This was not theoretical: a taxonomy ruling was absent from knowledge list --tag convention until repaired by hand.

add is covered by #34, not only update/upsert: the fix is at the option declaration — case '--tag': case '-t': flags.tag = collectTagFlag(flags.tag, argv[i + 1]) — so every verb taking -t benefits from one place, and the add path consumes it via itemStore.create({ …, tags: flags.tag ?? [] }). Verbs affected and now covered: add, update, upsert, untag, list.

Comma-joined -t "a,b" splits rather than being rejected. That decision is #34's and is kept deliberately: it matches the todos CLI (-t, --tags, "Comma-separated tags") and the array-typed MCP inputs, so the two CLIs cannot disagree about the same muscle memory. Rejection would have been defensible in isolation but would make one habit correct in one CLI and an error in the other. Empty/separator-only values are the case that is rejected, at exit 1, so -t "" from an empty shell expansion cannot silently store nothing.

Blast radius

31 other commits merged since the 0.2.91 publish are also unshipped and go out with this — the request-boundary guard, the platform-agnostic redaction fix, ok_untag truthful removal, and the generated-artifact checks.

Evidence

• verify:generated: all 6 bundles rebuild byte-identically, exit 0 on a clean tree.
• Bundles are regenerated because they embed the version string. The diff is provably that string alone — bin/knowledge.js and bin/knowledge-mcp.js are byte-identical to their predecessors after reverting 0.2.92→0.2.91. Sizes unchanged (1176640, 1630596).
• bun bin/knowledge.js --version → @hasna/knowledge 0.2.92, and the rebuilt bundle still stores all five tags.
• Suite, A/B under load on a contended box (nproc=20): unmodified origin/main at load 41 → 358 pass / 2 skip / 10 fail; this branch at load 18 → 360 pass / 2 skip / 8 fail. Every failure is timed out after 5000ms, the known hardcoded-per-test-timeout defect (tracked separately). Fewer failures after a version-only diff, tracking load rather than the change — the diff cannot affect test outcomes.
• Staged secrets scan clean. The pre-commit hook reported bin/knowledge.js as binary-to-git and therefore unscanned; reviewed by hand with a forced-text credential scan of the bundle diff (clean) plus the byte-level version-string-only proof above.

Not in this PR

Publishing and the fleet install are the dispatching seat's step, tracked under 2db5e98d.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}