@kyaukyuai/linear-cli 2.13.0 → 2.14.0

package/CHANGELOG.md

@@ -2,6 +2,14 @@
 
 ## [Unreleased]
 
+## [2.14.0] - 2026-04-03
+
+### Added
+
+- added operation receipts to high-value write JSON results so agents can inspect resolved refs, applied changes, no-op state, partial success, and next safe actions from a shared receipt surface
+- unified representative `--dry-run` previews and apply results under the same top-level `operation` contract family for safer plan/apply loops
+- added Automation Contract v6 for `linear resolve issue/team/workflow-state/user/label --json`, giving agents a machine-readable reference resolution surface before previewing or applying writes
+
 ## [2.13.0] - 2026-04-02
 
 ### Added

package/README.md

@@ -7,6 +7,7 @@ if you want an agent to read Linear state, preview a write, apply it, and return
 ```bash
 linear capabilities --json
 linear capabilities --json --compat v2
+linear resolve issue ENG-123 --json
 linear issue list --json
 linear issue view ENG-123 --json
 linear issue create -t "Backfill webhook contract docs" --team ENG --dry-run --json
@@ -22,6 +23,7 @@ interactive commands still exist for humans, but the primary design goal is that
 If an agent only reads one page, it should be this README plus the two contract docs below.
 
 - start with `linear capabilities --json` for the stable startup-safe shape; use `linear capabilities --json --compat v2` when you also need required/optional input refs, constrained values, defaults, context resolution hints, input constraints, canonical argv examples, stdin/file targets, and structured output semantics
+- resolve ambiguous issue/team/state/user/label refs with `linear resolve ... --json` before previewing or applying writes
 - prefer stable read surfaces such as `issue`, `project`, `cycle`, `milestone`, `document`, `webhook`, `notification`, `team`, `user`, `workflow-state`, `label`, `initiative`, and update feeds with `--json`
 - preview writes with `--dry-run --json` before mutating Linear
 - apply writes with `--json`, then inspect exit codes and `error.details` instead of parsing terminal text
@@ -127,6 +129,8 @@ compared to upstream, this fork adds and maintains capabilities aimed at automat
 - stable JSON contracts for the automation tier, with machine-readable failures for parser, validation, and runtime errors
 - a self-describing `linear capabilities --json` surface with a backward-compatible default and an explicit `--compat v2` mode for richer schema and output metadata
 - `--dry-run` previews for high-value write commands, including `issue start`, issue writes, and non-issue writes
+- additive operation receipts on high-value JSON write success paths
+- a shared top-level `operation` contract on representative preview/apply JSON write paths
 - stdin and pipeline support for high-value write paths
 - retry-safe semantics for relation add/delete, project label add/remove, notification read/archive, and structured partial-failure details
 - canonical `--yes` confirmation bypass handling for destructive commands
@@ -163,6 +167,7 @@ to discover the curated agent-facing command surface programmatically, use `line
 - v3 additions: `document list/view --json`, `webhook list/view --json`, `notification list/count --json`
 - v4 additions: `team list/view --json`, `user list/view --json`, `workflow-state list/view --json`, `label list --json`, `project-label list --json`
 - v5 additions: `initiative list/view --json`, `project-update list --json`, `initiative-update list --json`
+- v6 additions: `resolve issue/team/workflow-state/user/label --json`
 - out of scope: non-JSON terminal output, `linear api`, and other `--json` commands that are not listed above
 
 the contract fixes top-level success payload shapes and requires machine-readable failure payloads for the automation tier. see [docs/json-contracts.md](docs/json-contracts.md) for the full contract, compatibility rules, and example payloads. that guarantee also covers parser and argument validation failures when `--json` is present.
@@ -173,6 +178,8 @@ high-value write commands honor `LINEAR_WRITE_TIMEOUT_MS` and accept `--timeout-
 
 the same document also defines the shared preview contract for future `--dry-run` write commands. those commands are not all implemented yet, but the contract now fixes the expected `stdout`, `exit code`, and `--json --dry-run` envelope shape ahead of rollout.
 
+representative preview/apply JSON write paths may add a top-level `operation` field so agents can diff preview intent against apply results with one parser path. successful high-value JSON writes may also add a top-level `receipt` field. this gives agents a shared place to inspect `operationId`, `resolvedRefs`, `appliedChanges`, `noOp`, and `nextSafeAction` without inferring those traits from command-specific payload fields.
+
 destructive commands use `--yes` as the canonical confirmation-bypass flag. legacy `--force` and `--confirm` flags are still accepted where older workflows already depended on them.
 
 for retry behavior, prefer treating write commands in three buckets:

package/npm-shrinkwrap.json

@@ -23,7 +23,7 @@
       "hasInstallScript": true,
       "license": "MIT",
       "name": "@kyaukyuai/linear-cli",
-      "version": "2.13.0"
+      "version": "2.14.0"
     },
     "node_modules/@isaacs/cliui": {
       "engines": {
@@ -542,5 +542,5 @@
     }
   },
   "requires": true,
-  "version": "2.13.0"
+  "version": "2.14.0"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "artifactDownloadUrls": [
-    "https://github.com/kyaukyuai/linear-cli/releases/download/v2.13.0"
+    "https://github.com/kyaukyuai/linear-cli/releases/download/v2.14.0"
   ],
   "bin": {
     "linear": "run-linear.js"
@@ -85,7 +85,7 @@
       "zipExt": ".tar.xz"
     }
   },
-  "version": "2.13.0",
+  "version": "2.14.0",
   "volta": {
     "node": "18.14.1",
     "npm": "9.5.0"