Expose richer issue fields in JSON output

[dubscode]

Summary

Please expose more of Linear's issue fields in the normalized JSON output for issues list and issues get.

Requested fields

Useful fields for agent and script workflows:

• assigneeId
• assigneeName
• labels
• estimate
• cycleId / cycleName
• projectName
• stateId
• stateType
• creatorId / creatorName
• completedAt
• canceledAt
• archivedAt
• dueDate

Why this matters

The current normalized output is pleasant and compact, but it is too thin for many automation tasks. Scripts often need to know whether an issue is assigned, labeled, in a cycle, completed, or canceled before deciding what to do.

For example, an agent cleaning up issue titles should be able to avoid completed/canceled issues or preserve project/cycle context without needing a direct SDK/GraphQL fallback.

Possible design

If always returning these fields feels too noisy, a field-selection option could work well:

linear issues list --fields id,identifier,title,stateName,stateType,assigneeName,labels,parentId --json
linear issues get BB-418 --fields all --json

Expected behavior

• Keep existing JSON fields stable.
• Add fields as optional properties where Linear data exists.
• Consider --fields or --verbose-json if compact output is a goal.

[dubscode]

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Expand normalized issue JSON with automation-friendly fields.

Current behavior:
The normalized issue shape already includes several useful fields such as assignee, estimate, due date, team, project, cycle, parent, labels, child count, and relation count. The remaining gap is that JSON consumers still lack some important state, creator, lifecycle, and naming fields.

Desired behavior:
linear issues list --json and linear issues get <id> --json should expose a richer, stable issue record suitable for scripts and agents deciding whether and how to act on issues.

Key interfaces:

• The normalized issue record should add missing fields such as stateId, stateType, creatorId, creatorName, and lifecycle timestamps when Linear provides them.
• Label output should be easy for JSON consumers to use. If existing output uses label names, preserve it and consider adding a clearer labels field without breaking compatibility.
• Existing issue JSON fields should remain backward-compatible.

Acceptance criteria:

• Issue JSON includes state id and state type when available.
• Issue JSON includes creator id/name when available.
• Issue JSON includes completion, cancellation, archive, and due-date timestamps when available.
• Label data is exposed in a consumer-friendly way without removing existing label output.
• issues list --json and issues get <id> --json expose the same normalized fields where available.
• Tests cover new fields and backward compatibility for existing fields.

Out of scope:

• A full field-selection language for JSON output unless already supported cleanly.
• Removing compact human table output.
• Implementing new issue filters; those belong to the richer filtering issue.