Stale Haskell binary in /.grafema/bin shadows fresh /.cabal/bin

Problem

The Grafema orchestrator looks for Haskell analyzer binaries in ~/.grafema/bin/ BEFORE ~/.cabal/bin/. After running scripts/build-native.sh packages/js-analyzer cabal install --install-method=copy --overwrite-policy=always, the freshly-built binary lands in ~/.cabal/bin/grafema-analyzer, but if a copy was previously placed in ~/.grafema/bin/ (e.g., months ago), the orchestrator picks that one up instead. End-to-end tests then run with the old analyzer, and the symptom is that source-level changes appear "to work" in unit tests but produce zero effect in grafema analyze output.

Context / Trigger Conditions

• Modified Haskell source in packages/js-analyzer/, packages/grafema-resolve/, packages/python-analyzer/, or any Haskell analyzer package.
• Ran scripts/build-native.sh <pkg> cabal install ... and saw "build succeeded".
• Ran grafema analyze (or end-to-end test) and the new behavior is missing — no new edge type, no new node type, etc.
• Unit tests against the newly-built ~/.cabal/bin/<binary> directly DO show the new behavior.
• ls -la ~/.cabal/bin/<binary> shows fresh mtime, ls -la ~/.grafema/bin/<binary> shows OLD mtime (the smoking gun).

Solution

After cabal install (or any binary rebuild), force-update ~/.grafema/bin/ with the fresh binary:

cp ~/.cabal/bin/grafema-analyzer ~/.grafema/bin/grafema-analyzer
cp ~/.cabal/bin/grafema-resolve ~/.grafema/bin/grafema-resolve
# ...for each affected binary

Or symlink once and forget:

ln -sf ~/.cabal/bin/grafema-analyzer ~/.grafema/bin/grafema-analyzer

Permanent fix candidates (not done at the time of writing — see follow-up task): change scripts/build-native.sh to also update ~/.grafema/bin/ after cabal install, OR change the orchestrator's resolve_binary to prefer ~/.cabal/bin/ when its mtime is newer than ~/.grafema/bin/'s, OR refuse to use ~/.grafema/bin/ when its .build-hash doesn't match the source hash.

Verification

# 1. Source hash updated
cat packages/js-analyzer/.build-hash

# 2. Both binaries point to recent build
ls -la ~/.cabal/bin/grafema-analyzer ~/.grafema/bin/grafema-analyzer
# Both timestamps should be from the recent build

# 3. End-to-end test
node packages/cli/dist/cli.js analyze
# Verify the new edge type / node type now appears in the graph

Example

During Library Callback Resolver work (April 2026), Change 3 added a RECEIVER_CALL edge to the JS analyzer. cabal install succeeded. End-to-end verification on Grafema's own codebase produced 0 RECEIVER_CALL edges. After investigation: ~/.cabal/bin/grafema-analyzer was dated April 25; ~/.grafema/bin/grafema-analyzer was dated March 31. After manual cp, the edges appeared correctly and the entire feature pipeline worked end-to-end on the second grafema analyze run.

Notes

• This issue is more dangerous than a normal stale-build problem because unit tests can pass (they invoke the fresh binary directly) while the orchestrator silently uses the stale copy.
• The .build-hash sidecar in packages/<pkg>/.build-hash reflects source state but isn't currently checked at runtime against the chosen binary's origin — that's a feature gap (see follow-up task).
• A user-friendly heuristic during debugging: if a unit-level Haskell test shows X but grafema analyze shows ¬X, suspect binary staleness FIRST, before suspecting a bug in the orchestrator wiring.

References

• Build script: scripts/build-native.sh
• Binary resolver: packages/grafema-orchestrator/src/ (search resolve_binary)
• Memory note: MEMORY.md → "Stale Binary Protection"