원클릭으로 Manus에서 모든 스킬 실행

grafema-haskell-binary-stale-priority

스타36

포크2

업데이트2026년 4월 25일 18:12

Fix stale Haskell analyzer binaries silently being used by the orchestrator even after a successful rebuild. Use when: (1) modified `packages/js-analyzer/` or other Haskell analyzer source, ran `scripts/build-native.sh ... cabal install`, but a subsequent `grafema analyze` shows old behavior (missing new edges, no new node types, etc.), (2) `~/.cabal/bin/grafema-analyzer` has fresh timestamp but `grafema analyze` produces output as if the change didn't happen, (3) a test verifying new analyzer output passes locally in unit tests but fails in end-to-end runs that go through the orchestrator. Root cause: the Rust orchestrator's `resolve_binary` checks `~/.grafema/bin/<name>` BEFORE `~/.cabal/bin/<name>`, so any stale copy that was once installed there (possibly months ago) shadows the fresh `cabal install` output.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

Disentinel

Disentinel/grafema

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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"

이 저장소의 다른 Skills

같은 저장소

rfdb-v2-clear-ephemeral-trap

Disentinel/grafema

Fix RFDB V2 graph data silently not persisting to disk after analysis. Use when: (1) rfdb-server reports "0 nodes, 0 edges" on restart despite successful analysis, (2) segment directories exist but are empty (no .bin files), (3) manifest_index.json shows total_nodes: 0 despite analysis logging 70k+ nodes, (4) Docker builds produce empty graph databases, (5) --clear flag used before analyze command. Root cause: GraphEngineV2::clear() replaces the store with MultiShardStore::ephemeral() which has path: None, causing all flush operations to write to in-memory buffers only.

2026-06-1236

lean4-theorem-value-access

Disentinel/grafema

Fix missing theorem proof terms when analyzing Lean 4 environments via importModules. Use when: (1) ConstantInfo.value? returns none for theorems despite TheoremVal.value being Expr, (2) building code graph / dependency extractor for Lean 4 and getting 0 proof dependency edges, (3) Lean 4.30+ project where theorem proofs appear missing from loaded environment, (4) analyzing Mathlib or any Lean 4 project and proof terms are empty. Root cause: breaking change in Lean 4.30 — value? treats theorems as opaque by default.

2026-05-2436

rfdb-metadata-gotchas

Disentinel/grafema

Fix silent metadata issues in RFDB node storage. Covers two traps: (1) metadata flattening — nested metadata fields become top-level after serialization, so node.metadata.field is undefined but node.field works. (2) reserved keys — fields named "type", "id", "name", "file", "exported" are silently stripped from metadata by _parseNode() to prevent overwriting top-level node fields.

2026-05-0336

grafema-release

Disentinel/grafema

Grafema release procedure for publishing new versions to npm. Covers happy path, pitfalls, rfdb binary lifecycle, and rollback. Use when user says "release", "publish", "bump version".

2026-05-0336

gui-perf-profiling-cdp

Disentinel/grafema

Diagnose React + Three.js (or any browser canvas) frame stutter by capturing a CDP CPU profile via Playwright instead of guessing from `[perf]` console logs. Use when: (1) frame time is bad but `[perf]` instrumentation doesn't pinpoint the offender, (2) you've spent more than ~30 minutes "fixing" suspects without measuring, (3) hot paths involve animation systems, allocation bursts, or invisible scene-graph traversal, (4) you need self-time per function with line numbers, not aggregate "render slow". The `console.warn` pattern is good for monitoring; CDP is needed for diagnosis. Covers script template, sourcemap setup so minified function names are decoded, and interactive variant where the user drives the interaction and signals stop via `touch /tmp/<flag>`.

2026-05-0236

rust-embed-rebuild-invalidation

Disentinel/grafema

Force `rust-embed` to re-embed assets from `$GRAFEMA_UI_DIST` (or any env-driven path) when cargo's incremental compilation skips the macro re-expansion. Use when: (1) you rebuilt the GUI bundle but the rust-server binary still serves the OLD bundle, (2) `cargo build --release` finishes in seconds (incremental hit) and `strings target/release/binary | grep <new-hash>` finds nothing, (3) any rust-embed pipeline where assets live outside the cargo source tree and are picked up via env var or symlink. Cargo only re-runs the proc macro when the rust file declaring `#[derive(RustEmbed)]` changes — env var changes alone don't trigger it.

2026-05-0236

name	grafema-haskell-binary-stale-priority
description	Fix stale Haskell analyzer binaries silently being used by the orchestrator even after a successful rebuild. Use when: (1) modified `packages/js-analyzer/` or other Haskell analyzer source, ran `scripts/build-native.sh ... cabal install`, but a subsequent `grafema analyze` shows old behavior (missing new edges, no new node types, etc.), (2) `~/.cabal/bin/grafema-analyzer` has fresh timestamp but `grafema analyze` produces output as if the change didn't happen, (3) a test verifying new analyzer output passes locally in unit tests but fails in end-to-end runs that go through the orchestrator. Root cause: the Rust orchestrator's `resolve_binary` checks `~/.grafema/bin/<name>` BEFORE `~/.cabal/bin/<name>`, so any stale copy that was once installed there (possibly months ago) shadows the fresh `cabal install` output.
author	Claude Code
version	1.0.0
date	"2026-04-25T00:00:00.000Z"

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

Problem

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

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

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"