cluster-only labels fails: Expecting value: line 1 column 6 (char 5)

[vdgbcrypto]

Bug Description

graphify cluster-only <path> fails to label communities and falls back to Community N placeholders with a JSON decode error.

Steps to Reproduce

1. Install graphify on Windows/Hermes: pip install graphifyy && graphify install --platform hermes
2. Use a corpus with mixed code + 1 doc file and set a working LLM key, e.g.:
   • export GOOGLE_API_KEY=...
   • graphify "H:/path/to/small-project"
3. Run: graphify cluster-only "H:/path/to/small-project"

Expected Behavior

All communities are labeled with meaningful names and the report is generated.

Actual Behavior

[graphify label] batch 1/1 (6 communities) failed: Expecting value: line 1 column 6 (char 5)
[graphify label] warning: community labeling failed (Expecting value: line 1 column 6 (char 5)); using Community N placeholders.

GRAPH_REPORT.md is still written, but all community names remain Community N.

Environment

• OS: Windows 10
• Shell: Git Bash / MSYS2
• graphify: 0.9.6
• Hermes: installed via graphify install --platform hermes
• LLM backend: gemini via GOOGLE_API_KEY / --backend

Notes

• Initial extraction succeeds, including semantic extraction via gemini.
• Re-running cluster-only on the existing graph still reproduces the JSON parse failure.
• Related: issue bug: graphify install --platform hermes installs skill to wrong directory on Windows #1403 was fixed for Windows install path; this appears unrelated.

[safishamsi]

Fixed on v8 (21b851b), shipping in the next release.

Expecting value: line 1 column 6 (char 5) is a reply that failed a strict json.loads (typically truncated mid-object, or a model preamble before the JSON). Two changes:

• _parse_label_response now salvages the complete "id": "name" pairs from a reply that fails json.loads, raising only when no pairs can be recovered. So a partial reply now yields the names that did arrive instead of failing the whole batch (the missing cids fall back to Community N).
• The per-batch token budget was raised (256 + 48*n, was 64 + 24*n) to give models that prepend a short preamble enough headroom to finish the JSON.

Honest caveat: I could not reproduce the exact provider-side truncation without a live key, so this fixes the parsing/budget mechanism rather than a confirmed byte-for-byte repro. If it still recurs, the salvage path now logs the offending batch to stderr. Thanks for the report.