@kyaukyuai/linear-cli 2.12.1 → 2.12.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -2,6 +2,18 @@
2
2
 
3
3
  ## [Unreleased]
4
4
 
5
+ ## [2.12.3] - 2026-03-31
6
+
7
+ ### Fixed
8
+
9
+ - strengthened `timeout_error` write contracts with machine-readable `appliedState` and `callerGuidance` so callers can distinguish between applied, uncertain, and failed outcomes after reconciliation
10
+
11
+ ## [2.12.2] - 2026-03-31
12
+
13
+ ### Fixed
14
+
15
+ - restored `linear capabilities --json` to a startup-safe `v1` machine-readable shape by default, while requiring `--compat v2` for richer schema metadata
16
+
5
17
  ## [2.12.1] - 2026-03-30
6
18
 
7
19
  ### Added
package/README.md CHANGED
@@ -6,6 +6,7 @@ if you want an agent to read Linear state, preview a write, apply it, and return
6
6
 
7
7
  ```bash
8
8
  linear capabilities --json
9
+ linear capabilities --json --compat v2
9
10
  linear issue list --json
10
11
  linear issue view ENG-123 --json
11
12
  linear issue create -t "Backfill webhook contract docs" --team ENG --dry-run --json
@@ -20,7 +21,7 @@ interactive commands still exist for humans, but the primary design goal is that
20
21
 
21
22
  If an agent only reads one page, it should be this README plus the two contract docs below.
22
23
 
23
- - start with `linear capabilities --json` to discover which commands support `--json`, `--dry-run`, stdin, confirmation bypass, and stable automation contracts
24
+ - start with `linear capabilities --json` for the stable startup-safe shape; use `linear capabilities --json --compat v2` when you also need primary input schema and output semantics
24
25
  - prefer stable read surfaces such as `issue`, `project`, `cycle`, `milestone`, `document`, `webhook`, `notification`, `team`, `user`, `workflow-state`, `label`, `initiative`, and update feeds with `--json`
25
26
  - preview writes with `--dry-run --json` before mutating Linear
26
27
  - apply writes with `--json`, then inspect exit codes and `error.details` instead of parsing terminal text
@@ -124,7 +125,7 @@ deno task install
124
125
  compared to upstream, this fork adds and maintains capabilities aimed at automation-heavy workflows:
125
126
 
126
127
  - stable JSON contracts for the automation tier, with machine-readable failures for parser, validation, and runtime errors
127
- - a self-describing `linear capabilities --json` surface so agents can discover contract coverage, primary input schema, output semantics, and command traits without scraping docs
128
+ - a self-describing `linear capabilities --json` surface with a backward-compatible default and an explicit `--compat v2` mode for richer schema and output metadata
128
129
  - `--dry-run` previews for high-value write commands, including `issue start`, issue writes, and non-issue writes
129
130
  - stdin and pipeline support for high-value write paths
130
131
  - retry-safe semantics for relation add/delete, project label add/remove, notification read/archive, and structured partial-failure details
@@ -155,7 +156,7 @@ Use the docs in this order if you are building an agent integration:
155
156
 
156
157
  for bot and org-wide automation use cases, `linear-cli` defines a stable JSON contract for a focused automation tier.
157
158
 
158
- to discover the curated agent-facing command surface programmatically, use `linear capabilities --json`. it reports stable contract versions, automation-tier membership, and per-command support for `--json`, `--dry-run`, stdin, confirmation bypass, idempotency category, primary arguments and flags, and success/failure output semantics.
159
+ 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 primary arguments, flags, and output semantics, opt into `linear capabilities --json --compat v2`.
159
160
 
160
161
  - 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`
161
162
  - v2 additions: `project list/view --json`, `cycle list/view/current/next --json`, `milestone list/view --json`
@@ -168,7 +169,7 @@ the contract fixes top-level success payload shapes and requires machine-readabl
168
169
 
169
170
  for automation consumers, auth and authorization failures now use exit code `4`, free-plan or workspace-plan limit failures use exit code `5`, and client-side write confirmation timeouts use exit code `6`. other contract failures remain non-zero and currently use `1`. rate-limited responses remain on exit code `1`, but now include retry guidance and, when available, `error.details.rateLimit` metadata.
170
171
 
171
- high-value write commands honor `LINEAR_WRITE_TIMEOUT_MS` and accept `--timeout-ms` for per-command overrides. timeout failures return a distinct machine-readable failure mode, `timeout_error`, with `error.details.failureMode = "timeout_waiting_for_confirmation"`. when reconciliation runs after the timeout, `error.details.outcome` now distinguishes `definitely_failed`, `probably_succeeded`, and `partial_success` from the fallback `unknown` state. notification `read` and `archive` now use the same timeout contract as issue write commands.
172
+ high-value write commands honor `LINEAR_WRITE_TIMEOUT_MS` and accept `--timeout-ms` for per-command overrides. timeout failures return a distinct machine-readable failure mode, `timeout_error`, with `error.details.failureMode = "timeout_waiting_for_confirmation"`. when reconciliation runs after the timeout, `error.details.outcome` still captures the high-level result, while `error.details.appliedState` and `error.details.callerGuidance` tell callers whether the write looks applied, partially applied, not applied, or still uncertain and whether they should retry, resume, or read first. notification `read` and `archive` now use the same timeout contract as issue write commands.
172
173
 
173
174
  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.
174
175
 
@@ -23,7 +23,7 @@
23
23
  "hasInstallScript": true,
24
24
  "license": "MIT",
25
25
  "name": "@kyaukyuai/linear-cli",
26
- "version": "2.12.1"
26
+ "version": "2.12.3"
27
27
  },
28
28
  "node_modules/@isaacs/cliui": {
29
29
  "engines": {
@@ -542,5 +542,5 @@
542
542
  }
543
543
  },
544
544
  "requires": true,
545
- "version": "2.12.1"
545
+ "version": "2.12.3"
546
546
  }
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "artifactDownloadUrls": [
3
- "https://github.com/kyaukyuai/linear-cli/releases/download/v2.12.1"
3
+ "https://github.com/kyaukyuai/linear-cli/releases/download/v2.12.3"
4
4
  ],
5
5
  "bin": {
6
6
  "linear": "run-linear.js"
@@ -85,7 +85,7 @@
85
85
  "zipExt": ".tar.xz"
86
86
  }
87
87
  },
88
- "version": "2.12.1",
88
+ "version": "2.12.3",
89
89
  "volta": {
90
90
  "node": "18.14.1",
91
91
  "npm": "9.5.0"