Community labels deleted in skill Step 9 cleanup — wiki/obsidian/HTML degrade to 'Community N' on every recluster

[johnp3004]

Problem

The graphify skill's Step 5 has Claude write semantic community labels to graphify-out/.graphify_labels.json (e.g. "Attention Mechanism", "Training Pipeline" in the Karpathy worked example). Step 6 reads that file to render obsidian/, wiki/, graph.html, and GRAPH_REPORT.md with the human-readable names.

Step 9 (cleanup) then deletes .graphify_labels.json.

This means labels live ONLY inside the rendered output files. Every subsequent operation that re-runs clustering or regenerates outputs from graph.json directly — --update, --cluster-only, the graphify cluster-only CLI subcommand, or any user-side maintenance script that calls cluster() + to_obsidian() / to_wiki() / to_html() — produces output without the labels. They become Community 0, Community 1, …, Community N, even though graph.json still has the same well-clustered partition.

Symptom: wiki/index.md becomes a sorted list of [[Community 0]] — 178 nodes ... [[Community 156]] — 1 nodes, which is unbrowsable.

Repro

1. Build a graph: /graphify <path> → labels written, outputs use them.
2. Make any change that triggers a re-cluster, e.g. /graphify <path> --cluster-only or /graphify <path> --update with new files.
3. Open graphify-out/wiki/index.md — community names are now Community 0..N.

Real-world impact

In a 1900-node business corpus that's been through several --update + dedup cycles, all 157 communities ended up as numeric IDs. Top 15 cover 84% of the graph, but they're listed as [[Community 0]] — 178 nodes etc. The wiki and obsidian outputs become navigation-useless until labels are manually re-applied. (My corpus shipped with 5,234 obsidian notes + 1,381 wiki articles indexed only by community number.)

Proposed fixes (any one of these would help)

1. Persist labels inside graph.json — store community labels as a top-level community_labels key (alongside directed, nodes, links). Then they survive every regeneration that loads the graph.
2. Don't delete .graphify_labels.json in cleanup — drop that one line from the cleanup rm. The file is small and idempotent.
3. Persist a separate non-dotfile — write graphify-out/community_labels.json (no leading dot) alongside the dotfile. Cleanup leaves it. The skill / cluster-only flow reads from it on the next run if .graphify_labels.json is missing.
4. Add a label-carry-forward step to cluster() — after re-partitioning, match new communities to old by node-membership overlap and propagate the old label to the most-overlapping new community. Avoids having to re-run Claude's labelling step every time.

Workaround in the meantime

I built a local helper that does (3) + (4): persistent community_labels.json + best-match carry-forward across reclusters. Linked from my CLAUDE.md gotcha #12 if useful as reference: https://github.com/safishamsi/graphify/issues (this issue).

Related: #595 covers other hygiene primitives but doesn't address label persistence specifically. #590 covers the directedness flip in cluster-only which is a sibling regression in the same code path.

[safishamsi]

Fixed in v5: removed .graphify_labels.json from Step 9 cleanup. Labels now persist across --update and --cluster-only runs.