@kyaukyuai/linear-cli 2.13.0 → 2.15.0

package/CHANGELOG.md

@@ -2,6 +2,24 @@
 
 ## [Unreleased]
 
+## [2.15.0] - 2026-04-03
+
+### Added
+
+- added a global `--profile agent-safe` execution profile that disables pager by default, extends write timeouts, and requires explicit `--yes` for destructive confirmation flows in automation contexts
+
+### Changed
+
+- added downstream consumer certification to the release gate so startup discovery, resolve, preview/apply, and timeout-recovery paths used by real agent workflows cannot drift silently
+
+## [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,8 @@ 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 --profile agent-safe issue update ENG-123 --state done --dry-run --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 +24,8 @@ 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
+- use `linear --profile agent-safe ...` when you want predictable non-interactive defaults for an automation run
+- 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 +131,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
@@ -158,11 +164,20 @@ for bot and org-wide automation use cases, `linear-cli` defines a stable JSON co
 
 to discover the curated agent-facing command surface programmatically, use `linear capabilities --json`. the default shape preserves the v1-compatible startup contract for existing bots. when you need richer metadata such as required vs optional primary inputs, constrained values, defaults, context resolution hints, input constraints, canonical argv examples, stdin/file targets, structured output semantics, and timeout/no-op traits, opt into `linear capabilities --json --compat v2`.
 
+`linear --profile agent-safe ...` is the opt-in execution profile for agent-controlled runs. it currently disables pager-by-default behavior, extends the built-in write timeout to `45000ms` unless `--timeout-ms` or `LINEAR_WRITE_TIMEOUT_MS` is set, and rejects destructive confirmation prompts unless the caller passes `--yes`.
+
+non-goals:
+
+- it does not force `--json`
+- it does not auto-confirm destructive actions
+- it does not replace every interactive data-entry fallback; callers should still pass explicit flags, stdin, or file inputs
+
 - v1 in scope: `issue list/view/create/update --json`, `issue relation add/delete/list --json`, `issue comment add --json`, `team members --json`, `issue parent/children/create-batch --json`
 - v2 additions: `project list/view --json`, `cycle list/view/current/next --json`, `milestone list/view --json`
 - 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 +188,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.15.0"
     },
     "node_modules/@isaacs/cliui": {
       "engines": {
@@ -542,5 +542,5 @@
     }
   },
   "requires": true,
-  "version": "2.13.0"
+  "version": "2.15.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.15.0"
   ],
   "bin": {
     "linear": "run-linear.js"
@@ -85,7 +85,7 @@
       "zipExt": ".tar.xz"
     }
   },
-  "version": "2.13.0",
+  "version": "2.15.0",
   "volta": {
     "node": "18.14.1",
     "npm": "9.5.0"