fix(issues): create --output json reports the labels it applied

[FelixLisczyk]

The problem

linear issues create --labels "Bug" --output json always reported "labels": null, even though the labels were applied correctly.

$ linear issues create "Example" --team ENG --labels "Bug" --priority 2 --output json
  "priority": null,
  "labels": null,

$ linear issues get ENG-123 --output json
  "priority": 2,
  "labels": [{"id": "5fce89ca-…", "name": "Bug"}]

The write succeeded; only the response was wrong. A scripted or agentic caller that reads the create response to confirm label application gets a false negative, and has to pay an extra issues get round-trip to discover the labels were there all along.

Root causes

Two independent defects, both fixed here.

1. The issueCreate selection set never asked for labels back. labelIds was sent correctly in the mutation input — which is why Linear applied the labels — but the issue { … } selection set requested neither labels nor four sibling fields the caller can also set: priority, estimate, dueDate, cycle. Each carried the identical "I set it, the response says null, did it work?" failure.

All five are now requested, copying the shapes from GetIssue verbatim so the two selection sets read as siblings. delegate and attachments are deliberately left out: issueCreate cannot set a delegate, and a new issue has no attachments, so requesting them could never surface caller-supplied data.

2. The JSON DTO layer rendered an empty collection as null. That is ambiguous between "this issue has none" and "this renderer does not report them" — the same confusion, one layer down. populateIssueBase now always allocates, so labels, children, and attachments render as [].

delegate deliberately keeps omitempty and still vanishes when nil: an absent object unambiguously means "no delegate", whereas an absent or null collection is ambiguous. A comment on populateIssueBase records this so the two are not later "harmonised" back together.

Behaviour change to read paths — please read

populateIssueBase is shared, so this also changes issues get, issues list, and search at --format detailed|full: empty labels, children, attachments, and comments now render as [] instead of null.

Consumers using length, select, or truthiness tests are unaffected. jq expressions along the lines of has("labels"), .labels == null, or .labels // "none" will behave differently.

Confining the fix to create would mean duplicating the DTO layer and making create's output structurally diverge from get's — undercutting the very parity this fix exists to establish. Text output is unchanged.

Tests

Layered, because no single layer covers this bug:

• pkg/linear/issues/client_create_test.go (new) — an httptest-backed test that captures the outgoing mutation body. This is the only guard that fails if the selection-set fix is reverted; verified by removing the fields and watching it go red. Assertions are line-anchored, since a bare labels substring also matches labelIds in the mutation input and would pass against the unfixed code. Also covers response mapping (including a label with a parent), success: false, and metadata extraction.
• internal/format/json_dtos_test.go (new) — raw-JSON assertions that empty collections marshal to [] and not null, that a nil connection and a present-but-empty one both render [], that LabelDTO still drops color/parent, and that a nil delegate stays omitted.
• internal/service/issue_create_test.go — serialized-output assertions through the real formatter: one label, two labels, no labels, label resolution failure, CreateIssue failure, and text mode unchanged.

Service-level tests build their own core.Issue via the mock, so they prove the DTO path but would stay green on a selection-set regression — hence the client-layer test.

make test passes; go vet ./... is clean.

Verified live

Against a real Linear team, comparing the released binary with this branch:

Check	Before	After
--labels "A,B"	null	both reported with id+name
--priority 2 --estimate 3	null, null	2, 3
--due 2026-12-31	null	"2026-12-31"
Label id/name vs issues get	—	match (as a set)
Create with no labels	null	[]
Unresolvable label name	error, exit 1	unchanged
Text-mode output	ABC-123: <title> + URL	unchanged

The five-field selection set is valid against Linear's live schema.

Out of scope

• issues update has the same gap in its client-layer selection set, but no --output/-o flag at all, so it is unreachable from the CLI. Adding JSON output there is a feature addition and needs to cover all three label modes (--labels, --add-labels, --remove-labels).
• Extending LabelDTO with color/parent. The mutation selects them (to stay identical to the read paths), but the DTO still drops them, so the output surface is unchanged.
• A shared GraphQL fragment. This bug is one instance of a class — the label selection is copy-pasted across seven query strings. A fragment IssueFields on Issue would structurally prevent the drift, but rewriting seven live queries is disproportionate risk for a bug fix.