스킬 찾기

Decide what to PERSIST in your data structures (graph nodes, DB tables, cache layouts) based on the QUERIES you must answer, not the DEFINITIONS that justify the data. Definitions tell you logical identity; storage strategy is independent. Materializing every definitional component leads to O(N×M) blow-ups that masquerade as memory leaks. Use when: (1) designing a new graph-node type, edge type, DB table, or cache layout; (2) about to name a `subgraph` / `comprises` / `members` / `contains` collection on a parent entity; (3) memory growth proportional to (entities × per-entity-elements); (4) "memory leak" debugging that survives multiple targeted patches — the leak may be storage shape, not retention; (5) pre-implementation sketch includes "for each X, store all reached nodes"; (6) research/spec doc says "X = ⟨A, B, C⟩" and you're tempted to make it three storage edges per X.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Continuous self-reflection routine combining Schön (reflection-in-action / reflection-on-action) and Mezirow (content / process / premise) levels, anchored on KAMI values (val-002 глубина, val-007 честность перед собой, принцип 1 правда, принцип 2 нулевая толерантность к бреду). Triggers FIRE DURING THE TURN, not at end. Use when: (1) about to make a 2nd+ patch attempt at the same problem, (2) user pushes back with "стоп / нет / опять / так, ещё раз / не то / пиздёж", (3) noticing self drifting into "I think that..." without evidence, (4) about to report "готово", (5) copying a pattern from one place to another, (6) task took >2× expected time. Embeds scientific method (explicit hypotheses + falsifiability + prediction-first + alternatives) as substrate for premise-level reflection, not as ceremony.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Fix nodes silently disappearing from RFDB when an enricher or post-resolution pass writes new nodes via BatchHandle. Use when: (1) writing a TypeScript enricher that should ADD nodes/edges to existing files, (2) after calling `client.createBatch()` + `batch.addNode({file: 'X', ...})` + `batch.commit()` the original nodes in file X have vanished, (3) tests that load a graph fixture, run an enricher, then query original nodes get empty results, (4) a verification step shows expected nodes pre-enrichment but 0 post-enrichment. Root cause: `BatchHandle.commit()` invokes RFDB's `commit_batch` which AUTO-POPULATES `changed_files` from each added node's `file` field, then the server DELETES all existing nodes whose `file` matches before inserting new ones — file-level upsert semantics. This is correct for the JS/Haskell analyzers (which fully re-emit a file's contents) but catastrophic for enrichers that only ADD to existing files.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Diagnose and fix RFDB data disappearing after compaction, where rfdb-server reports a tiny node count (e.g. "15 nodes") on startup despite manifest_index.json showing hundreds of thousands of nodes and segment files existing on disk. Use when: (1) rfdb-server logs "Default database: N nodes" with N orders of magnitude smaller than recent analysis output, (2) /api/stats returns only the most recent commit's nodes, (3) the issue appears AFTER a compaction event (manifest with l1_node_segments populated and node_segments: []), (4) subsequent commits dropped L1 references. Root cause: ManifestStore::create_manifest() initializes l1_node_segments/l1_edge_segments to Vec::new() instead of cloning from current manifest, so any commit AFTER compaction silently orphans all L1 data even though segment .seg files still exist on disk. Compaction injects L1 fields explicitly after create_manifest, but regular commits do not.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Recover from stale RFDB nodes that survive `commit_batch` cleanup despite having their `file` field listed in `changed_files`. Use when: (1) re-running an enricher/orchestrator step but old data with the same file field stays in the graph, (2) `commit_batch(changed_files=[X], ...)` reports success but a query later still returns nodes with `file = X`, (3) you re-pointed structural nodes (e.g., DIRECTORY/FILE) from a synthetic file path to real file paths and the old synthetic-path nodes won't go away, (4) graph-stream / find_by_type returns a mix of "stale" and "new" nodes for the same logical entity. Root cause: `handle_commit_batch` calls `engine.find_by_attr({file: X})` to enumerate nodes-to-delete, but that query path returns only a PARTIAL set after compaction (L1 segments and the file→nodes index can desync). Workaround: enumerate stale nodes via the TS rfdb client `queryNodes({file: X})` (different code path that finds all of them) and call `deleteNode(id)` per node, then re-commit the intended state. Related: rfdb-manifest-l1-carryforward (same L1 family).

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

RFDB server becomes unresponsive (60s+ timeouts) during enricher addEdges write storms. Use when: (1) RFDB CPU spikes to 60-90% after addEdges calls; (2) subsequent reads time out at 60s; (3) server stays catatonic for 5-15 min after a write storm; (4) Tokio main thread parked (write-lock contention). Root cause: add_edges() calls maybe_auto_flush() which has a memory-pressure path that fires on NODE count — not edge count — and holds the exclusive write lock during disk I/O. Fix: separate maybe_auto_flush_edges() uses byte-limit only.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Speed up Rust development iteration when `cargo build --release` takes 10+ minutes even for one-line edits. Use when: (1) every release rebuild takes minutes despite tiny edits, (2) Cargo.toml has `lto = "fat"` and/or `codegen-units = 1` in `[profile.release]`, (3) you want a production- shaped build for testing without paying the LTO cost on every iteration, (4) you suspect cargo is re-linking the whole binary instead of doing incremental work, (5) developing rfdb/grafema-orchestrator/large Rust binaries where full LTO is enabled for shipped builds. Adds a `fast` profile that inherits release but disables LTO, raises codegen-units, enables incremental compilation — first build still slow because it populates a fresh `target/fast/` dep cache, but every subsequent rebuild drops from ~13 min to ~13 s (≈60×).

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Build all packages, reinstall VS Code extension, commit and push. Use when: user says "ship", or wants to build+install+commit+push in one go.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

SWE-bench pipeline for A/B testing Grafema with Claude Code. Use when: (1) running SWE-bench experiments, (2) comparing baseline vs grafema conditions, (3) evaluating results, (4) debugging container issues.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Verify which process actually owns a TCP port before assuming your fresh restart succeeded. Use when: (1) you killed an old server and started a new one but behaviour matches the OLD code/data, (2) `pkill -f pattern` returned 0 but old behaviour persists, (3) you embedded a new asset/binary but the served version is stale, (4) any "I just restarted X but I'm getting old results" situation. `pkill -f` matches against the process command line — if the live old process was started with `--port 0` (auto-assigned) and got the port you now want, the pattern won't match it. Always verify with `lsof -i :PORT` before debugging deeper.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Analyze codebases using a graph database instead of reading source files. Use when understanding code architecture, finding functions or call patterns, tracing data flow, checking dependencies, or answering "where is X used?" questions. Grafema builds a queryable code graph from static analysis — prefer querying the graph over reading files manually.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Design guide + benchmarked pitfalls for building Monte-Carlo / Simulated Annealing refinement layers on top of greedy hex-grid layouts for code visualization (packages/gui/src/store/hexLayout.ts, sandbox/hex-sandbox, future Rust ports). Use when: (1) planning to add MC/SA on top of an existing hex-grid pack, (2) deciding whether a simpler SA would match a hierarchical MC with force-directed + chain drag, (3) budgeting wall-clock for million-node cold-start, (4) debugging "blob turns Swiss-cheese" or "folders stop nucleating" during MC refinement, (5) choosing between folder cohesion and raw Σ-link-length as cost function. Contains four hard-won, quantified lessons and anti-patterns that would take a full day of experiments to rediscover.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.