Cross-Pollination Brief — October 29, 2026

Klatch surfaced two git CLI traps on the same day, both in verification tooling. One is a subtle argument-passing ambiguity in git log; the other is a fingerprinting design error that produces silent false resets. Neither involves a bug in git — both are correct uses of the CLI that produce results inconsistent with the caller's intent.

Letters to xian: have a question for xian about anything here or elsewhere in his work? File question-{from}-{date}-{topic}.md to dispatch mail. AI prompts human; one letter featured at the end of each brief.

Key Insights

git log <branch> -1 <sha> passes two revisions; only git show -s <sha> reads the right commit

From: Klatch — Theseus session log 2026-10-28, wrap verifier docs/research/unit-464t2-denial/verify-wrap.mjs Relevant to: Any project writing commit-verification scripts

When Klatch's session wrap verifier checked whether each fire's commits were on origin/main, it ran git log origin/main --format=... -1 <sha>. That call passes two revisions — the branch ref and the sha — and git logs their union; -1 then returns the newest, which is always the branch tip. Every row printed the same tip commit and was graded as present off a line that was not the commit it named. The per-commit --is-ancestor leg beside it was correct the whole time, which made the output look plausible. The defect was caught because the verifier graded itself: it was not yet committed when it ran, so its own MISSING row was honest even as the other seven rows were not.

Repair: git show -s <sha> takes exactly one revision and cannot be silently redirected by a second ref.

Suggested action: Any verification script that checks "is commit X on branch B?" should not pass both B and X to git log — use git log B --ancestry-path X^..X or git merge-base --is-ancestor X B for the ancestry question, and git show -s X to read a single commit's metadata. A correct leg alongside an incorrect one does not catch the incorrect one.

A fingerprint keyed on git status output resets silently when a commit moves the bracket

From: Klatch — Argus, scripts/lib/tree-fingerprint.mts, commit 41ae8657 Relevant to: Any project building change-detection or fingerprinting tools on top of git

Klatch's tree-fingerprint module computed a working-tree hash from git status and git diff HEAD output. Argus found that when a git commit landed under a bracketed pathspec mid-window, the P: and D: parts of the fingerprint silently reset to sha256("") — not because any file content changed, but because git diff HEAD shifted reference and the previous diff output no longer materialized. The resulting false positive looked like a completely clean tree even when real work was present.

Fix: enumerate every path via git ls-files (tracked) and git ls-files --others --exclude-standard (untracked), then hash actual file content directly. The result is one opaque sha with no git-metadata limbs that can be invalidated by a commit. The fix also closed a separate false-positive where a clean 200-file window hashed identically to a 0-file window, since both previously keyed on a git --porcelain summary that resolves the same way under both states.

Suggested action: When building a fingerprint or change-detection snapshot that must survive git operations within the window, key on file content, not on git status output. git status reports what has changed relative to HEAD; if HEAD changes, so does the output, and a "nothing changed" hash becomes "everything changed."

Sources Read

• Klatch — docs/logs/2026-10-28-1047-theseus-opus-log.md (Theseus session log); commits d64637b9 (wrap verifier log), 99804334 (wrap verifier implementation), 41ae8657 (tree-fingerprint re-key)
• Piper Morgan — docs/omnibus-logs/2026-10-27-omnibus-log.md; recent commit stream; no new brief-worthy findings
• Globe — f208228 (cpu-declarations expired-row pruning wired into mechanism, implementing yesterday's brief insight); not-brief-worthy — confirmatory of 10-28 insight, no new transferable lesson
• One Job — 1439515 (pre-commit guard 3: board reconcile wired into hook, citing 10-28 brief); ba35ce3 (Todoist write-back alpha); not-brief-worthy — cross-pollination loop closed in <24h (confirmatory), Todoist shipping event
• Weather, NYT-Crossword, Mediajunkie — scanned; no brief-worthy findings

Canonical archive: designinproduct.com/internal — if your local copy is missing or stale, fetch the latest from the hub.