relationship get returns an empty success when a reverseName is combined with --direction in, instead of the helpful error an undeclared name gets #2791

Summary

nodespace relationship get <id> --type <reverseName> --direction in resolves the reverse name to its declared form and then applies --direction in to the already-reversed name. The double reversal matches nothing, and the command returns count: 0 with exit 0 — indistinguishable from "no edges exist."

An undeclared name on the same command gets a genuinely excellent error. A declared name with the wrong direction gets silence.

Reproduction

Schema: Invoice.billed_to → Customer, reverseName: "invoices". Two invoices billed to the customer.

The failing response shows the mechanism — the name was resolved, then reversed again:

{
  "node_id": "7e8c5490-...",
  "related_nodes": [],
  "relationship_name": "billed_to"
}

Contrast, an undeclared name:

status: InvalidArgument, message: "Relationship 'totally_bogus_name' is not declared
for node type 'customer' in either direction (available: billing_contact, invoices;
available with --direction in: billed_to). Built-in relationships (member_of,
has_child, mentions, has_role) are universal."

That message is excellent — it enumerates availability per direction. The bug is only that the reverseName+in combination never reaches it.

Why it matters

references/cli.md:301 correctly documents both working spellings and warns "An empty result means no edges exist, not that reverse traversal is unsupported" — good guidance that becomes actively misleading here, because in this one case an empty result means the query was malformed. A caller who combines reverse-name with --direction in (intuitively "the most reverse" form) reads the empty result as missing data and may go on to recreate edges that already exist.

Suggested fix

When the resolved name came from a reverseName lookup and --direction in was also given, either treat it as the equivalent forward query or reject it with the same enumerating error the undeclared-name path produces. Silence is the one response that shouldn't happen.

Separate, minor: response key inconsistency

relationship get returns its array under related_nodes; node query, search, and schema list all use nodes. Not wrong, but it makes .nodes[] silently yield empty against this command — the same class of confusion as above. Noting it here rather than filing separately; split it out if it's worth changing.

Found via

Agent session using the nodespace skill. Cost several calls chasing edges that had been created correctly all along.