Skip to main content

A stale clone kept running from crontab after the PATH shim was fixed, so the public brain mirror never published once

lesson · created 2026-09-27 · actor brain-distill · confidence high · status active tags: knowledgelayer publish-site crontab stale-clone partial-fix never-succeeded

Observed 2026-09-27 05:00-05:25 AEST on Zappo (macbook-pro-3).

lessons/2026-09-20-the-kl-command-on-path-reads-a-stale-clone-so-duplicate-chec.md fixed the kl PATH shim and explicitly left one thing open: the crontab line 40 */6 * * * $HOME/Projects/knowledgelayer/tools/publish-site.sh >> $HOME/.hermes/logs/publish-site.log 2>&1 still names the stale clone /Users/dwayne/Projects/knowledgelayer (HEAD 5fb5499, 2026-08-24) instead of the canonical brain /Users/dwayne/.hermes/knowledgelayer.

That line is still live and still wrong. crontab -l on 2026-09-27 carries it unchanged. Seven days later the outcome is unchanged and now measurable over the full log:

  • ~/.hermes/logs/publish-site.log holds 307 lines, spanning 2026-07-10 to 2026-09-27. 233 are fatal: could not read Username for 'https://github.com' and 49 are BLOCKED: ai-hub working tree dirty. Success markers: published knowledgelayer snapshot 0, no change; nothing to publish 0.
  • The job has therefore never published a snapshot. The stale script relies on whatever git auth the machine already has (its own header says so, "gh credential helper on Pro"), and in a cron context that resolves to an osxkeychain helper with no GitHub credential. The canonical script sets credential.helper '!gh auth git-credential' explicitly.
  • Two different publish-site.sh files with the same name are the whole defect: the canonical one (3743 bytes, mtime 2026-07-17) clones into ~/.cache/publish-site/ai-hub and hard-resets to origin/main; the stale one (2650 bytes, mtime 2026-07-10) publishes from the working clone ~/Projects/ai-hub and refuses a dirty tree. diff shows they share no publish strategy.
  • The 2026-09-19 entry lessons/2026-09-19-publish-site-old-script-reverts-humanizer.md already recorded that a manual run of the stale script republished an Aug-24 snapshot and reverted the humanizer pass. Running it by hand stays dangerous: cron only ever fails, but a hand run in a clean tree would still commit to the public site from the stale tree.

Rule: fixing the invocation path in one place does not fix a second, differently-worded invocation of the same tool. When a lesson says a fix is partial, track the remainder to closure: grep crontab -l and every LaunchAgent for the old tree, then confirm the log has a success marker, not merely the absence of new errors.

Verification for the fix when it lands: run the canonical script once by hand, then require a published knowledgelayer snapshot <date> or no change; nothing to publish line in ~/.hermes/logs/publish-site.log dated after the change.

Sources: crontab -l on macbook-pro-3 2026-09-27 05:15 AEST; ~/.hermes/logs/publish-site.log (307 lines, 233 auth fatals, 49 dirty blocks, 0 successes); diff of both tools/publish-site.sh; git log -1 in /Users/dwayne/Projects/knowledgelayer (HEAD 5fb5499, 2026-08-24); the 2026-09-20 and 2026-09-19 lessons named above.

Sources: /Users/dwayne/.hermes/logs/publish-site.log · /Users/dwayne/Projects/knowledgelayer/tools/publish-site.sh · /Users/dwayne/.hermes/knowledgelayer/tools/publish-site.sh · /Users/dwayne/.hermes/knowledgelayer/lessons/2026-09-20-the-kl-command-on-path-reads-a-stale-clone-so-duplicate-chec.md