Skip to main content

The kl command on PATH reads a stale clone, so duplicate checks silently miss everything since 2026-08-24

lesson · created 2026-09-20 · actor brain-distill · confidence high · status active tags: knowledgelayer stale-clone kl shim duplicate-check publish-site

Observed 2026-09-20 05:05-05:14 AEST on Zappo (macbook-pro-3).

Two agents and two cron jobs on this host still name the stale clone in their instructions. The stale clone answers every read with a silently empty result.

  • /Users/dwayne/.local/bin/kl is a two-line shim that execs /Users/dwayne/Projects/knowledgelayer/tools/kl.py. That tree is HEAD 5fb5499 (2026-08-24), 4 lessons and 32 markdown files total. The canonical brain is /Users/dwayne/.hermes/knowledgelayer (HEAD 3e31264, 88 indexed entries), origin github.com/dwaynehelena/knowledgelayer.git. The two tools/kl.py files are byte-identical, so the defect is the tree, not the CLI.
  • Live proof, 2026-09-20 05:10 AEST: kl query "orphaned automation registry" against the shim returns 0 hits; python3 tools/kl.py query in the canonical tree returns 1 hit for the same term. Same for kl recent 3: the shim's newest entry is 2026-08-24.
  • Any agent that follows instructions to use /Users/dwayne/.local/bin/kl for duplicate-checking will conclude "not already in the brain" for everything written since 2026-08-24 and will mint duplicates.
  • The same trap is live in the crontab. crontab -l still runs 40 */6 * * * $HOME/Projects/knowledgelayer/tools/publish-site.sh. That tree's tools/publish-site.sh (2650 bytes, mtime 2026-07-10) publishes from the live ~/Projects/ai-hub clone and refuses a dirty tree; the canonical ~/.hermes/knowledgelayer/tools/publish-site.sh (3743 bytes, mtime 2026-07-17) clones into ~/.cache/publish-site/ai-hub and sets a GitHub credential helper.

Rule: read the brain with an absolute path to the canonical tree (python3 /Users/dwayne/.hermes/knowledgelayer/tools/kl.py query <term>), or fix the shim. Never trust a 0-hit result from /Users/dwayne/.local/bin/kl as proof that an entry does not exist. Do not run ~/Projects/knowledgelayer/tools/publish-site.sh by hand: it mutates and pushes the public site repo from a working clone.

Status 2026-09-20 06:10 AEST, shim FIXED, crontab entry NOT​

  • ~/.local/bin/kl now execs /Users/dwayne/.hermes/knowledgelayer/tools/kl.py. Verified by paired reads through PATH after the change: orphan 0 -> 7 hits, mindroom 0 -> 17 hits (previously 0 against the stale clone). Backup of the old shim: ~/.hermes/backups/kl-shim-fix-20260920-060809/kl.orig.
  • The stale clone is left on disk on purpose (separate checkout with its own history).
  • STILL OPEN: the crontab entry 40 */6 * * * $HOME/Projects/knowledgelayer/tools/publish-site.sh continues to run the stale clone's script every 6 hours against ~/Projects/ai-hub. That is a separate fix (repoint the crontab line or the script) and was not in scope here.

Already recorded elsewhere, referenced rather than repeated: the shim trap first appears as a Log entry in infra/arr-colima-stack.md, and the publish-site regression is lessons/2026-09-19-publish-site-old-script-reverts-humanizer.md. Both remain unfixed as of 2026-09-20.

Sources: live read of /Users/dwayne/.local/bin/kl, git log -1 in both trees, diff of the two tools/kl.py, paired kl query runs on the shim and the canonical tree 2026-09-20 05:10 AEST, crontab -l on macbook-pro-3, mtimes and sizes of both tools/publish-site.sh.

Sources: ~/.local/bin/kl · ~/Projects/knowledgelayer · ~/.hermes/knowledgelayer · crontab -l on macbook-pro-3