fix(1634): a node read by id returns its full widget value, not a survey clip

[artokun]

Fixes #1634

The filed hypothesis is not what happens

The issue proposed that panel_graph_outline sheds widget values on an over-budget graph, so an agent quoting a prompt out of the outline hands back a value cut off by design — with a falsifiable prediction attached: "If the prompt is truncated on a small graph, this analysis is wrong and the bug is elsewhere."

I measured it. It reproduces on a four-node graph, where no ladder rung degrades and nothing is near a budget:

PROMPT length = 300 chars

===== fields:'compact'  (ids:["2"]) =====
#2 CLIPTextEncode "Positive Prompt" · text=masterpiece, best quality, ultra detailed, a lone astronaut…  ← clip:1  → 4
(1 widget value(s) clipped to 60 chars by `fields`:"compact" — read fuller values with `fields`:"detail", …)

-> contains the FULL prompt? NO      -> reply length 301 chars   [budget: 12000]

301 characters against a 12000-character budget. The clip was not protecting anything — it was starving the one value that was asked for. So the prediction lands on the "this analysis is wrong" side, and the truncation is not graph-size dependent. That also explains the reporter's "always": a fixed clip fires every time, where a ladder rung would not.

What actually happens

The compact projection clips widget values at a fixed 60 chars. That is a survey cap — it keeps a 200-node listing of nodes you have not identified yet small.

It was also applied when the caller named the node explicitly by ids, which is the opposite case: the node is already identified, so the clip only starves the value that was asked for. panel_query_graph's own description calls ids "THE way to read ONE node's exact slot/widget detail", so the default did not match the documented intent.

And the shortfall is silent in the way the issue describes: a clipped prompt ends in an ellipsis that a real prompt could plausibly contain, so it gets quoted back to the user as the node's content. That is why it reads as a bug in the prompt node rather than in the retrieval.

The fix

A single-id read renders its widget values at the same per-value cap the detail projection uses — but only when the generous row demonstrably fits the budget. If it does not fit, we render exactly what main renders.

Two deliberate restrictions, both of which I got wrong first and the gate caught:

• Only one id is a pinpoint. Treating any ids list as one cost rows the caller explicitly asked for: 20 ordinary 600-char prompts at the default budget went 20/20 → 18/20.
• A fit test, not an arithmetic reserve. Every reserve I tried leaked — a per-widget floor still grows without bound across many widgets, so a 24-widget node breached max_chars on default parameters while reporting truncated:false. A fit test cannot leak.

Deliberately unchanged: the compact shape (still one line per node), the survey path, max_chars, and the outline ladder, which the issue flagged as carrying expensive #809/#1184/#1203 invariants. This change does not touch it.

Never worse than main — measured, not argued

Swept this branch against origin/main across 1316 shape × budget × projection cases (1–300 widgets, 10–9000 chars each, 1–60 nodes, budgets 500 → 60000, with and without ids):

cases=1316  breaches-vs-main=0  lost-rows=0  shorter=0  richer=92

Zero replies breach max_chars where main did not, zero lose a row main returned, zero come back shorter. 92 come back richer — the pinpoint reads this issue is about.

The gate's own independent fuzz (4000 hostile single-id shapes) agrees on the direction and adds a caveat I've since written into the source: the max_chars bound is already soft, because clipLine bounds the LINE while the header and clip note ride outside it. Main overshoots by ~173 chars on 1893 of those 4000; this branch does so on 80, by the same magnitude. It does not make that softness worse, and it does not fix it.

Verification

• 43/43 in graph-query.test.ts (32 pre-existing + 11 new); 516 files / 9690 tests green across the full suite; tsc --noEmit clean.
• Mutation-tested: reverting graph-query.ts to origin/main with the tests in place fails 3. Mutating the fit test's reserve constant fails 1 (the gate found that constant unpinned; it now is).
• The new tests pin the survey path, the multi-id row count, the max_chars bound and the note's honesty — not just the happy path.

Both engines

src/services/graph-query.ts is the semantic spec for the panel's hand-mirrored twin, and its own header mandates the port. The orchestrator change alone would not have fixed the reporter, who reads the live canvas:

• this PR — queryApiGraph, reached in production by get_workflow action:"query" (src/tools/workflow-library.ts:690)
• fix(1634): a node read by id returns its full widget value, not a survey clip comfyui-mcp-panel#1281 — the live-canvas twin the reporter actually hits, browser-verified

What this PR does NOT do — symptom B

The issue also reports unrelated questions triggering reflexive graph lookups. I have not fixed that, and I don't want to imply coverage I don't have.

It is model-steering, not a code path: the candidate sites are the unconditional "read it FIRST to get oriented" in the outline's tool description and "ALWAYS start with panel_graph_outline" in ollama-backend.ts:353. Two reasons I left it:

1. There is no test that can fail-on-revert — "the model stopped calling a tool" is not assertable, and a description-string assertion would be the tested-but-unreachable class rather than evidence.
2. The reporter is on Gemini (ACP), so the ollama-backend.ts line was never in their path. Changing it could not have produced their symptom and would not demonstrably fix it.

The tool descriptions are also byte-pinned by the tool-surface ratchet, so conditioning that guidance is a deliberate product edit, not a drive-by. Left for a separate decision.

Gate

codex was unavailable (account exhausted until 2026-08-19); gated by an independent adversarial review instead (claude-gate.mjs), which spawns a fresh reviewer that has never seen my reasoning. Disclosing the substitution is the condition it was accepted under.

It returned NO-SHIP twice before SHIP, and both rejections were right:

round	finding	outcome
1	the protected first row breached max_chars (740/500 where main returned 465)	fixed
1	the note pointed at fields:"detail" where detail applies the same cap — a dead retry	fixed
2	P0 the per-widget floor leaked: 24 widgets breached on default params reporting truncated:false	replaced arithmetic with the fit test
2	any ids list treated as pinpoint — multi-id reads lost rows main returned	pinpoint is now a single id
2	the note named a cap in force for no widget	cap is uniform per row again
3	SHIP — plus two non-blocking notes (unpinned reserve constant, overstated source comment)	both addressed in the last commit

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.