linear-sdk-cli 0.1.3 → 0.2.1

package/.claude-plugin/marketplace.json

@@ -14,7 +14,7 @@
         "name": "Eugene Beloded"
       },
       "source": "./",
-      "skills": ["./skills/linear-sdk-cli"]
+      "skills": ["./skills/linear-sdk-cli", "./skills/linear-sdk-cli-maintenance"]
     }
   ]
 }

package/.claude-plugin/plugin.json

@@ -5,5 +5,5 @@
   "author": {
     "name": "Eugene Beloded"
   },
-  "skills": ["./skills/linear-sdk-cli"]
+  "skills": ["./skills/linear-sdk-cli", "./skills/linear-sdk-cli-maintenance"]
 }

package/CHANGELOG.md

@@ -4,17 +4,38 @@ All notable changes to this project are documented here. The format is based on
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to
 [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## [0.1.3](https://github.com/zhendalf/linear-sdk-cli/compare/v0.1.2...v0.1.3) (2026-08-24)
+## [0.2.1](https://github.com/zhendalf/linear-sdk-cli/compare/v0.2.0...v0.2.1) (2026-08-24)
+
+### Bug Fixes
+
+- format generated release notes ([3bab1dd](https://github.com/zhendalf/linear-sdk-cli/commit/3bab1dda627cd83d1feb8a2e1c0a7da37bee10db))
+
+## [0.2.0](https://github.com/zhendalf/linear-sdk-cli/compare/v0.1.3...v0.2.0) (2026-08-24)
+
+### Features
 
+- expand CLI workflows and terminal UX ([0fe31cc](https://github.com/zhendalf/linear-sdk-cli/commit/0fe31cca7e71d0fa6eee2b7c1461ecaf0a01103f))
+
+### Bug Fixes
+
+- **ci:** give release dispatch repository context ([#15](https://github.com/zhendalf/linear-sdk-cli/issues/15)) ([e3f51e6](https://github.com/zhendalf/linear-sdk-cli/commit/e3f51e600102416f3bd3212578b364a13a452e49))
+
+## [0.1.3](https://github.com/zhendalf/linear-sdk-cli/compare/v0.1.2...v0.1.3) (2026-08-24)
 
 ### Bug Fixes
 
-* **ci:** grant OIDC to automated publisher ([#7](https://github.com/zhendalf/linear-sdk-cli/issues/7)) ([acc6e4b](https://github.com/zhendalf/linear-sdk-cli/commit/acc6e4b9c4ab485ce39eeec7eb2c835892016e59))
+- **ci:** grant OIDC to automated publisher ([#7](https://github.com/zhendalf/linear-sdk-cli/issues/7)) ([acc6e4b](https://github.com/zhendalf/linear-sdk-cli/commit/acc6e4b9c4ab485ce39eeec7eb2c835892016e59))
 
 ## [Unreleased]
 
 ### Added
 
+- **Explicit, notification-capable comment mentions (`--mention`, TES-738).** Ordinary `@name`
+  text remains literal Markdown. Comment-writing commands now accept repeatable
+  `--mention <name|email|me|id>`, resolve each user exactly, deduplicate repeats, and prepend real
+  Linear mention tokens as their own paragraph. The option is available on `issue comment`,
+  `comment add`, `comment reply`, and `comment update`, including the shared
+  `issue comment add/update` mounts.
 - **Every command declares its `--json` output, and `linear commands <path>` prints it (TES-610).**
   An agent driving the CLI cold guessed key names and filed false bugs (`.user` read as `.author`,
   `.parent` as `.parentId`); the field names were knowable only from the source. Each node of
@@ -23,7 +44,7 @@ All notable changes to this project are documented here. The format is based on
   `completion`), `fields` (key → `"string"`, `"number|null"`, `["string"]`, nested `{…}`,
   `{nullable: {…}}` for a relation that may be null, `"comments?"` for a key present only
   sometimes) and `variants` (the whole shape under `--web`, `--start`, `op=list`, …). New `linear
-  commands <path...>` describes one command — a bare object under `--json` (`.output.fields`),
+commands <path...>` describes one command — a bare object under `--json` (`.output.fields`),
   or usage, options and one `key: type` line per field for a human, plus its subcommands for a
   group; an unknown path is `not_found` (exit 3) with the nearest paths. The shapes are declared
   beside the interfaces they describe (`shape<IssueRow>({…})`, `src/lib/shape.ts`), where a field
@@ -68,9 +89,9 @@ All notable changes to this project are documented here. The format is based on
   TES-642).** `initiative add-project <initiative> <project>` (`--sort-order`) and
   `remove-project` (confirmed; finds the link on the project's side, so no workspace-wide paging)
   and `initiative unarchive <id>` (resolves among archived initiatives, refuses a live one). `initiative
-  list` gains `--status`, `--owner`, `--archived` — the list stays every-status by default, and
+list` gains `--status`, `--owner`, `--archived` — the list stays every-status by default, and
   the reference CLI's `--all-statuses` is accepted as the no-op it is here. `initiative
-  create/update` take `--icon`/`--color`, and `initiative view` shows `icon`, `archivedAt` and
+create/update` take `--icon`/`--color`, and `initiative view` shows `icon`, `archivedAt` and
   the linked `projects` (`{id, name, status}`).
 - **`project list --all-teams`, `team create --private`, health-only status updates (TES-642).**
   `project list` is scoped to the default team and the only way out was the accidental
@@ -111,7 +132,7 @@ All notable changes to this project are documented here. The format is based on
   a repository; `--path` to choose), taking `--team` or offering the workspace's teams in a prompt;
   it refuses to replace an existing file without `--force`. `config set <key> <value>` changes one
   of `team`, `workspace`, `sort`, `vcs` in the project config discovery would actually read — a
-  schpet-written `.config/linear.toml` included, in *its* spelling (`team_id`, `issue_sort`), so no
+  schpet-written `.config/linear.toml` included, in _its_ spelling (`team_id`, `issue_sort`), so no
   second competing key appears — or, with `--user`, in `~/.config/linear/config.toml`. The edit is
   textual, one line replaced or appended before the first table, so comments and layout survive;
   the result is parsed back to prove it, falling back to a full re-serialize only if a layout we
@@ -132,7 +153,7 @@ All notable changes to this project are documented here. The format is based on
     in exactly one state, so intersecting them would build a filter that can never match. A single
     `--team`/`--state` sends the exact filter it always did (`key: { eq }` / `type: { eq }`);
     several send `key: { in: [...] }` and an `or` of state clauses. `--state` keeps taking a state
-    *name* or a state *type*, mixed freely: names stay individual `eqIgnoreCase` clauses because
+    _name_ or a state _type_, mixed freely: names stay individual `eqIgnoreCase` clauses because
     `in` is exact-case, so `--state 'in progress'` still matches "In Progress".
     `--team` is repeatable **only on the three issue queries**. It is a global option that ~135
     commands use for something other than filtering — the team an issue is created in, the team a
@@ -146,7 +167,7 @@ All notable changes to this project are documented here. The format is based on
     ISO 8601. The date is validated locally first: `new Date()` accepts "1", "March 2024" and
     "yesterday", and a garbage bound is not an API error but an empty result set — a filter that
     silently matches nothing looks exactly like a query with no matches.
-  - **`--project-label`** — every issue whose *project* carries a label, matched case-insensitively
+  - **`--project-label`** — every issue whose _project_ carries a label, matched case-insensitively
     (`--project-label backend` finds the "Backend" label). Mutually exclusive with `--project`:
     one names a single project, the other a set of them.
   - **`--search-comments`** (`issue search` only) — match comment bodies as well as titles and
@@ -159,7 +180,7 @@ All notable changes to this project are documented here. The format is based on
     only changes precision: with `--project` the name is resolved to a milestone id inside that
     project, without it the milestone is matched by name across projects. A transplanted command
     always passes `--project` and behaves identically either way.
-- **`issue update --team <key>` now actually moves the issue between teams** (AUDIT.md #8: the flag
+- **`issue update --team <key>` now actually moves the issue between teams** (the flag
   was accepted and silently dropped — alone it produced a misleading "Nothing to update", and
   alongside another flag it moved nothing at all). Everything team-scoped in the same command is
   resolved against the **destination** team, so `issue update TES-42 --team ENG --state 'In Review'`
@@ -179,12 +200,12 @@ All notable changes to this project are documented here. The format is based on
   - **Short flags.** `-j` for the global `--json` (the reference's most-used flag, on 17 of its
     commands) and `-w` for `--web` on `issue view` / `issue pull-request`. Both letters were
     free in our tree, so neither costs an existing meaning — we still hold one meaning per
-    letter everywhere, which is exactly why we are *not* adopting their `-t`/`-p`/`-a`/`-l`/`-s`
-    (see `ALIGNMENT.md`: their own tree spells `-t` as both `--title` and `--team`).
+    letter everywhere, which is exactly why we are _not_ adopting their `-t`/`-p`/`-a`/`-l`/`-s`
+    (their own tree spells `-t` as both `--title` and `--team`).
   - **Long-flag spellings.** `--due-date` (`issue create`/`update`), `--target-date` (`project`,
     `milestone`, `initiative` create/update), `--start-date` (`project create`/`update`),
     `--search` (`issue list`/`mine`), and `--all-states` on `issue list`, where it is the
-    no-op it describes — `list` already spans every state. Aliases are registered *hidden*, so
+    no-op it describes — `list` already spans every state. Aliases are registered _hidden_, so
     `--help` and `linear commands --json` keep advertising exactly one spelling per flag; the
     full mapping lives in README's "Coming from linear-cli". Passing both spellings at once is a
     usage error rather than a silent pick: `--due 2026-01-01 --due-date 2026-02-01` is not a typo
@@ -203,12 +224,12 @@ All notable changes to this project are documented here. The format is based on
     `issue comment` gained `add`/`list`/`update`/`delete` subcommands mounted on the same
     handlers as the top-level `comment` group, so there is one implementation, not two.
     `issue comment <id> <body>` is unchanged — commander only dispatches to a subcommand when
-    the *first* operand is one of those four names, which is the one behavior this touches: a
+    the _first_ operand is one of those four names, which is the one behavior this touches: a
     lone `linear issue comment add` used to mean "comment the word 'add' on the branch's issue"
     and now reaches the subcommand (and says so loudly). The short aliases `ls`/`edit`/`rm` are
     deliberately not registered under `issue comment`, to keep that collision at four words.
 - **`issue mine` — your unstarted work.** The reference `linear-cli` makes this its
-  *default* listing (`issue list` there is an alias of `mine`), so a script or a habit carried
+  _default_ listing (`issue list` there is an alias of `mine`), so a script or a habit carried
   over from it silently saw only your own unstarted issues. We keep `list` general — a command
   named "list" should list — and add `mine` next to it with the reference's defaults: the
   viewer's issues, restricted to `unstarted` states, widened by `--all-states`. It takes the same
@@ -273,9 +294,9 @@ All notable changes to this project are documented here. The format is based on
   resolved by name (a team template outranks a shared one of the same name; a miss lists what
   there is), sent as `templateId`; every value you pass alongside overrides what the template
   fills. **The team's default template is now applied**, as Linear's own new-issue form and the
-  reference CLI do: the API applies it *only when asked* (verified live — a plain `issueCreate` on
+  reference CLI do: the API applies it _only when asked_ (verified live — a plain `issueCreate` on
   a team with a default template returns an issue with no description), so `useDefaultTemplate:
-  true` is sent unless `--no-default-template` (also accepted under the reference's spelling,
+true` is sent unless `--no-default-template` (also accepted under the reference's spelling,
   `--no-use-default-template`); an explicit `--template` replaces it rather than stacking. A
   `--parent` child now **joins its parent's project** unless `--project` says otherwise — the
   sub-issues we created landed outside the project their parent was in — and `--milestone` can
@@ -287,13 +308,18 @@ All notable changes to this project are documented here. The format is based on
 
 ### Changed
 
+- **Development linting now uses Oxlint instead of ESLint.** The migrated configuration preserves
+  the existing recommended JavaScript and TypeScript checks and underscore-prefixed unused-variable
+  exceptions while reducing the lint dependency tree and execution time.
+- **TypeScript 7 now powers type-checking.** The native compiler replaces TypeScript 6 without
+  source or configuration compatibility changes in this project.
 - **`--fields`, `--limit` and `--all` are refused on commands that never read them** (TES-637 (2),
   TES-596). All twelve globals are registered on every command so they can sit anywhere on the
-  line, but `--fields` projects a *rendered* result (a table or a detail block) and `--limit`/`--all`
-  cap or exhaust a *paged* query; on the ~90 commands that print a receipt (every mutation, `issue
-  id`, `commands`, …) all three used to vanish without a word. That silence cost data: schpet's `-f`
+  line, but `--fields` projects a _rendered_ result (a table or a detail block) and `--limit`/`--all`
+  cap or exhaust a _paged_ query; on the ~90 commands that print a receipt (every mutation, `issue
+id`, `commands`, …) all three used to vanish without a word. That silence cost data: schpet's `-f`
   is `--description-file` on `project create`, so `linear project create --name X -f desc.md`
-  parsed `-f` as *our* `--fields`, created the project with **no description**, and exited 0. Now a
+  parsed `-f` as _our_ `--fields`, created the project with **no description**, and exited 0. Now a
   root `preAction` hook (`assertGlobalsApply` in `lib/options.ts`, driven by two applicability
   tables keyed by command path — `FIELDS_COMMANDS`, `LIMIT_COMMANDS`) rejects them before the
   action runs, with a usage error that names the command and, where the command has one, the flag
@@ -302,7 +328,7 @@ All notable changes to this project are documented here. The format is based on
   `project create -n 5` gets "-n is --limit here; the name is --name". Every renderer and paged
   query is unchanged; the tables are pinned against the real program tree so a rename shows up
   in the tests, and a renderer missing from the table fails loudly (its `--fields` is refused),
-  never quietly. `--team` is deliberately *not* guarded this way: `alias lin='linear -t TES'` is a
+  never quietly. `--team` is deliberately _not_ guarded this way: `alias lin='linear -t TES'` is a
   real usage pattern and must keep working on workspace-scoped commands. Not adopted: a local
   `-f = --description-file` on the four commands — one letter, two meanings (see MIGRATING.md §5).
 - **`project create -t/--team` collects, as `--teams` does** (TES-637 (3)). The global `--team` is
@@ -310,7 +336,7 @@ All notable changes to this project are documented here. The format is based on
   `--team A --team B` created the project in **B alone**. `--team` is now declared locally there,
   repeatable and comma-separated, one list with `--teams`; both flags at once is a usage error
   ("Pass either --teams or --team, not both"). `project update --team` stays refused (that list
-  *replaces* the project's teams; the message points at `--teams`).
+  _replaces_ the project's teams; the message points at `--teams`).
 - **`user list --all` / `team members --all` say what `--all` did not do** (TES-637 (1)). schpet's
   `--all` there means "include inactive members"; ours is the global "exhaust pagination", and
   deactivated users are `--include-disabled`. Same line, both exit 0, different rows. `--all` keeps
@@ -328,17 +354,17 @@ All notable changes to this project are documented here. The format is based on
   the PR `ID Title` and stops copying the issue description into GitHub** (TES-637 (5)).
   `describe` used to print `Title`, a blank line, `Fixes ID`; it now prints `ID Title`, a blank
   line, `Linear-issue: Fixes ID`, `Linear-issue-url: <url>` — git trailers that `git
-  interpret-trailers` / `git log --format=%(trailers:key=Linear-issue)` and jj's `trailers`
+interpret-trailers` / `git log --format=%(trailers:key=Linear-issue)` and jj's `trailers`
   template read back, while Linear still sees the magic word directly before the id
   (linear.app/docs/github lists `fixes` and `references` among the recognized words) and links
   and closes the issue. `-r/--references` swaps the word. `--json` gains `url` and `message` (the
   full text as printed). `pull-request`: title `<ID> <title>` (a custom `--title` is prefixed the
   same way, as there); body the same two trailers — schpet sends the bare URL and relies on the
   branch name for the link, the `Fixes` line keeps the link (and auto-close) when the branch was
-  renamed. The issue *description* is no longer pasted into the PR body: a GitHub PR is a wider
+  renamed. The issue _description_ is no longer pasted into the PR body: a GitHub PR is a wider
   audience than a Linear issue, and Linear links from the trailer, not the prose.
 - **A team-scoped listing with no team says it is listing every team's** (TES-637 (8)). `issue
-  list`/`mine`/`search` and `project list` with no `--team`, no configured team and no
+list`/`mine`/`search` and `project list` with no `--team`, no configured team and no
   `--all-teams` list the whole workspace — by design; schpet errors there ("No default team…"), so
   someone arriving from it could read the workspace as the team. One `info` line on stderr ("No
   default team configured; listing every team's. Pass --team <KEY> …"), silenced by `--quiet`,
@@ -385,7 +411,7 @@ All notable changes to this project are documented here. The format is based on
   model has no `team`/`cycle` getter (both `[Internal]` in the schema, though they work with a
   plain API key), and the previous view spent three lazy fetches on what one query selects.
 - **Repeating `--label` now narrows instead of broadening.** `--label bug --label regression`
-  used to return issues carrying *either* label; it now returns only those carrying *both*.
+  used to return issues carrying _either_ label; it now returns only those carrying _both_.
   Every other repeatable filter in this CLI narrows, the reference CLI narrows, and the broadening
   reading was the surprising one — a ported script got a superset of what it asked for and no
   error to notice. A single `--label` is unchanged, and both forms stay case-insensitive.
@@ -396,7 +422,7 @@ All notable changes to this project are documented here. The format is based on
   workflow state **ascending** (active work above the backlog), then priority descending
   (no-priority last), then manual ascending. Membership is unchanged; only the ordering moved.
   `--sort updated` and `--sort created` (which the reference lacks) are untouched.
-  The reference CLI hardcodes state *descending* for this flag, which the API answers with Backlog
+  The reference CLI hardcodes state _descending_ for this flag, which the API answers with Backlog
   **before** In Progress — a Low-priority backlog item outranks an Urgent in-progress one there.
   We match the intent (state-grouped, UI-like) rather than that payload; verified against the API.
 - **`issue search` takes filters, and is now team-scoped by default.** Linear's `searchIssues`
@@ -441,7 +467,7 @@ All notable changes to this project are documented here. The format is based on
 
 - **`issue list`/`mine`/`search` rows omitted `milestone` and `cycle`** (TES-652). The list
   query selected project and labels but neither relation, so `issue list --project X --json | jq
-  'group_by(.milestone.name)'` put every issue in the null bucket while `issue view` showed the
+'group_by(.milestone.name)'` put every issue in the null bucket while `issue view` showed the
   milestone. Rows now carry `milestone: {id, name} | null` and `cycle: {id, number, name} | null`
   — the detail's exact object shapes, from the one existing query (two selections, no extra
   request; `LIST_QUERY` and `SEARCH_QUERY` share the relation block so they cannot drift again).
@@ -462,7 +488,7 @@ All notable changes to this project are documented here. The format is based on
   Non-interactively, `comment update <id>` with no body is a usage error, not an editor.
 - **`issue comment "<body>"` on a matching branch failed** (TES-619) — the README's headline
   example. `issue comment [id] [body]` read a lone operand as the id, so `linear issue comment
-  'shipped'` on `tes-615-…` produced "No comment body provided" (and, in a terminal, opened
+'shipped'` on `tes-615-…` produced "No comment body provided" (and, in a terminal, opened
   `$EDITOR` for the body first and only then rejected `'shipped'` as an id — work lost).
   `assign` and `state` already disambiguated a lone operand; `comment` now does the same: one
   operand that looks like an issue id is the id (body from `--body-file` or the editor), anything
@@ -492,7 +518,7 @@ All notable changes to this project are documented here. The format is based on
   `--help`; a bare group shows its help** (TES-633). The root has an action (bare `linear` shows the
   branch's issue) and `issue` has a default subcommand (`view`), so commander's own "unknown
   command" never fired for either: `linear issues list` was `too many arguments. Expected 0
-  arguments but got 2: issues, list.` and `linear issue lst` was `'lst' is not a valid issue id`.
+arguments but got 2: issues, list.` and `linear issue lst` was `'lst' is not a valid issue id`.
   Now: `Unknown command 'issues'. Did you mean 'issue'? Run 'linear --help' to see the commands.`
   and `'lst' is not a valid issue id (…). Did you mean 'linear issue list'?` — a prefix (`proj`),
   a small typo (`lable`, `isue`) or an alias (`docs`, `notif`) is close enough; two-letter aliases
@@ -510,7 +536,7 @@ All notable changes to this project are documented here. The format is based on
   window-title rewrite into a title, and every teammate's `linear issue list` ran it — verified live
   on a `clitest-esc` issue whose title carried `\e[31m` and an OSC-8 link. Every string that
   reaches a person now passes through one function (`sanitizeForTerminal`, `src/output/sanitize.ts`)
-  that strips *whole* sequences — CSI, OSC (BEL- or ST-terminated), DCS/SOS/PM/APC, other `ESC`
+  that strips _whole_ sequences — CSI, OSC (BEL- or ST-terminated), DCS/SOS/PM/APC, other `ESC`
   sequences, and their 8-bit C1 spellings — so `\e[31m` vanishes rather than leaving `[31m`
   behind, then whatever C0/C1/DEL and bidi-override characters remain (`\n` and `\t` stay: a
   description is multi-line). It is applied in `cell()` (every table cell and detail value) and in
@@ -527,7 +553,7 @@ All notable changes to this project are documented here. The format is based on
   resolves the name inside that project (names are unique per project only, the same rule
   `issue update --milestone` applies); a name without `--project` is a usage error that says so:
   `'…' is not a milestone id; pass --project <name|id> to look a milestone up by name.` `state view
-  <name-or-type>` resolves against `--team` or the configured default team, exactly as
+<name-or-type>` resolves against `--team` or the configured default team, exactly as
   `issue create --state` does, and says to pass `--team` when there is neither. UUIDs still go
   straight through.
 - **`milestone list`/`view` printed progress ×100 — `3846%`** (TES-648, found while fixing the
@@ -535,7 +561,7 @@ All notable changes to this project are documented here. The format is based on
   `Project.progress`, which is a fraction; the milestone renderers multiplied it by 100 anyway. The
   human output now reads `38%`; the JSON value stays as the API sends it.
 - **Detail views are one request each, not six to sixteen** (TES-622). Lists have always used a
-  tailored GraphQL query, but every *detail* path awaited the SDK model's lazy relation getters,
+  tailored GraphQL query, but every _detail_ path awaited the SDK model's lazy relation getters,
   each its own HTTP round-trip. Measured live with a fetch counter before/after:
   `getIssueDetail(TES-601)` **8 → 1**; `getProjectDetail(linear-sdk-cli)` **7 → 1**;
   `getMilestoneDetail` with 13 issues **16 → 1** (it awaited `issue.state` per issue, so `-n 50`
@@ -561,14 +587,14 @@ All notable changes to this project are documented here. The format is based on
 - **Rate-limit waits are announced through the Context's `Output`** rather than a bare stderr
   writer, so the "rate limited; retrying in Ns" line honours `--quiet` like every other status line
   and can never land on the JSON stdout a script is parsing.
-- **Mutations could report a success the API never gave** (AUDIT.md #6). Every Linear mutation
+- **Mutations could report a success the API never gave.** Every Linear mutation
   answers with a payload carrying `success: Boolean!`, and almost nothing here read it. The
-  create/update paths did have a guard, but it tested whether the *entity* came back, not whether
+  create/update paths did have a guard, but it tested whether the _entity_ came back, not whether
   the write happened — so a `{success: false}` that still carried an entity walked through it — and
   the deletes, archives, subscribes and notification writes discarded the payload unread. Driven
   against a client whose every write is refused, **50 of the 51 mutating service entry points
   resolved happily**; `comment delete` was the single one that checked. The sharpest case was
-  `issue update`, which fell back to the issue it had resolved *before* the mutation, so a
+  `issue update`, which fell back to the issue it had resolved _before_ the mutation, so a
   `{success: false, issue: null}` printed `Updated TES-1` and exited **0** — the shell would run the
   `&&` side of a command that changed nothing. All of it now goes through one helper
   (`unwrapMutation` / `assertMutation`, `src/lib/mutation.ts`) that requires `success === true` and,
@@ -583,27 +609,27 @@ All notable changes to this project are documented here. The format is based on
   to print `✓ Marked … read` and `{"read": true}` whatever the payload said.
 
 - **`notification read-all` claimed every notification was marked read.** It hardcoded
-  `success: true` and reported the number of *unread* notifications it found, not the number it
+  `success: true` and reported the number of _unread_ notifications it found, not the number it
   actually marked, so a batch where some writes were refused looked identical to one where none
   were. It now derives the aggregate: `count` is how many really went through, `attempted` how many
   it tried, and `failed` lists the ones that did not with the API's reason. A single refusal no
   longer aborts the rest — it is reported instead of hidden, and the human output names each one.
 
-- **`milestone view` reported `issuesTruncated: false` while hiding issues** (AUDIT.md #5). The
-  truncation check read `pageInfo.hasNextPage` off the connection *after* collecting from it, and
+- **`milestone view` reported `issuesTruncated: false` while hiding issues.** The
+  truncation check read `pageInfo.hasNextPage` off the connection _after_ collecting from it, and
   `fetchNext()` mutates that connection in place — so the flag described the last page fetched
   rather than the issues the limit hid. With 180 issues at `--limit 150` it returned 150 and said
   nothing was hidden, suppressing the `… more (use --all)` notice at exactly the moment it was
   needed. Truncation is now a fact rather than an inference: one extra item is requested (in the
   same page, so it costs no round-trip) and its presence is the answer. The unit test that shipped
-  alongside the bug passed because its mock's `fetchNext()` returned a *fresh object* instead of
+  alongside the bug passed because its mock's `fetchNext()` returned a _fresh object_ instead of
   mutating — every faked connection in the suite now comes from one faithful builder
   (`test/unit/_fakes.ts`) that appends in place and returns `this`, as the SDK does.
 
 - **Name resolution stopped at a fixed page, so a large workspace got false `not_found`s.** The
   resolvers that match client-side asked for a fixed `first: 100`/`first: 250` and searched only
   what came back: a team, workflow state, cycle or milestone that existed past the cap could not be
-  resolved by name, and — worse, because it is silent — the *ambiguity* check only ever saw a prefix,
+  resolved by name, and — worse, because it is silent — the _ambiguity_ check only ever saw a prefix,
   so a duplicate name past the cap was invisible and the CLI picked one arbitrarily. Resolution now
   follows the connection. The page size is 250 (Linear's maximum), so the ordinary workspace still
   costs the single request it always did and only workspaces that really have more than 250 of
@@ -617,7 +643,7 @@ All notable changes to this project are documented here. The format is based on
   `--status` is accepted as an alias for the same thing.
 - **`issue list --label` was case-sensitive.** The filter used an exact-case `in` comparator, so
   `--label bug` returned an empty list when the label is stored as `Bug` — wrong results with no
-  error, while label *resolution* everywhere else matches case-insensitively. (Repeating the flag
+  error, while label _resolution_ everywhere else matches case-insensitively. (Repeating the flag
   now narrows the match — see Changed.)
 - **Deactivated users were invisible.** `team members` and `user list` never sent
   `includeDisabled`, which Linear defaults to `false` — so deactivated users were never returned
@@ -650,7 +676,7 @@ All notable changes to this project are documented here. The format is based on
   issue id inferred from the current branch as usual. `issue describe [id]` prints the issue
   title plus a commit-message trailer using Linear's git magic words (`Fixes <ID>`, or
   `References <ID>` with `-r`/`--references`) — drop it into `git commit -m "$(linear issue
-  describe)"`. `issue pull-request [id]` (alias `pr`) creates a GitHub PR via the `gh` CLI:
+describe)"`. `issue pull-request [id]` (alias `pr`) creates a GitHub PR via the `gh` CLI:
   the title defaults to the issue title (`--title` to override) and the body is the issue
   description followed by a `Fixes <ID>` trailer and the Linear URL, so the PR and issue
   reference each other. Flags: `--base`, `--head`, `--draft`, `--web`. The created PR URL is the
@@ -659,8 +685,8 @@ All notable changes to this project are documented here. The format is based on
   or when `gh` itself fails.
 - **Multi-workspace credentials.** Store API keys for several workspaces and switch between
   them. New `auth` subcommands: `auth list` (configured workspaces + default), `auth default
-  <slug>` (set the default), and `auth token` (print the resolved key for scripting). `auth
-  login` now accepts the global `--workspace <slug>` (derived from the key's organization when
+<slug>` (set the default), and `auth token` (print the resolved key for scripting). `auth
+login` now accepts the global `--workspace <slug>` (derived from the key's organization when
   omitted) and `auth status` reports the active credential workspace. A new global
   `--workspace <slug>` selects which stored credential to use for any command. Credentials live
   in quoted `[workspaces."<slug>"]` tables under a top-level `default_workspace`. Credential
@@ -668,12 +694,12 @@ All notable changes to this project are documented here. The format is based on
   `--workspace`/`LINEAR_WORKSPACE`/`default_workspace`, and is never steered by project
   `.linear.toml`. When several workspaces are configured with no default, the error is deferred
   until a command actually needs the API — so `auth list`/`default`/`login` still work.
-- **`--no-input` did nothing** (AUDIT.md #3). It is the flag that makes the CLI safe to run
+- **`--no-input` did nothing.** It is the flag that makes the CLI safe to run
   unattended, and it had never once had an effect. Two independent faults, either of which alone
   was fatal. First, the key: commander stores a negation under the name with `no-` stripped, so the
   parser wrote `input: false` while `Context` read `noInput` — a field nothing ever set, so the
   guard was reading `undefined` forever. Second, and the reason fixing the key would not have been
-  enough: a lone negation is *also* seeded with a default of `true` on every command it is
+  enough: a lone negation is _also_ seeded with a default of `true` on every command it is
   registered on, including the root program, and `optsWithGlobals()` lets ancestors overwrite
   descendants. Because global options are usable in any position, the flag is parsed by the
   subcommand — so the root's default `true` then overwrote the subcommand's `false` on the way into
@@ -686,25 +712,25 @@ All notable changes to this project are documented here. The format is based on
   goes for a redirected stdout, which is where inquirer draws the prompt and would therefore write
   the question into the caller's output. Commands that need a missing value now fail with the usual
   usage error naming the flag to pass, instead of waiting forever.
-- **`--no-color` broke `label create`** (AUDIT.md #4). The global terminal-colour flag and the
+- **`--no-color` broke `label create`.** The global terminal-colour flag and the
   entity flag `--color <hex>` both reduced to commander's `color` attribute, so
   `label create --name x --team TES --no-color` put `color: false` into the mutation input and
   Linear rejected the call outright: `Variable "$input" got invalid value false at "input.color"`.
   `project` and `roadmap` escaped the crash only because their guards happened to be truthy-based —
   they dropped the flag instead. Beyond the crash, there was simply no way to set an entity colour
-  *and* turn off terminal colour in one command, because one flag overwrote the other. The global
+  _and_ turn off terminal colour in one command, because one flag overwrote the other. The global
   is now spelled **`--no-ansi`**, with `--no-color` kept as an alias on every command (it is the
   conventional spelling, and both write the same key, so they cannot drift). Terminal colour and
   entity colour are separate keys now, which makes the whole class of collision structurally
   impossible rather than fixed one command at a time — a test walks the command tree and asserts no
   option anywhere can write `false` into `color`.
-- **`auth login` echoed the API key** (AUDIT.md #9). The prompt used inquirer's `input`, so the
+- **`auth login` echoed the API key.** The prompt used inquirer's `input`, so the
   credential appeared on screen as it was typed and then stayed in the terminal's scrollback for as
   long as the window lived. It now uses inquirer's `password` prompt, which never renders the value.
   `--key` is unchanged for scripts, and nothing in the command logs or echoes the key — the receipt
   names the user and the file it was written to.
 - **`--json --debug` produced output that could not be parsed.** The debug detail was appended
-  *after* the error envelope as a second, plaintext block, so the one combination a caller reaches
+  _after_ the error envelope as a second, plaintext block, so the one combination a caller reaches
   for when a scripted call misbehaves was the one that broke the contract:
   `linear … --json --debug 2>&1 | jq` died with "Invalid numeric literal". In JSON mode the detail
   now lives inside the envelope as `error.detail`. Without `--debug`, or when the error carries no
@@ -724,15 +750,15 @@ All notable changes to this project are documented here. The format is based on
   different request from the one that was typed, executed without comment. A flag value must now be
   a complete integer. Priority additionally validates the 0–4 range locally, matching the wording
   `initiative` has used all along, so the two cannot read as different rules.
-- **`project update --team` was accepted and ignored** (AUDIT.md #8). It is rejected now, rather
-  than implemented: a project belongs to *several* teams, and the existing `--teams` **replaces**
+- **`project update --team` was accepted and ignored.** It is rejected now, rather
+  than implemented: a project belongs to _several_ teams, and the existing `--teams` **replaces**
   that whole set — so quietly treating `--team TES` as `--teams TES` would remove every other team
   from the project, which is a destructive reading of a flag the user most likely meant as "also
   this team". The error names `--teams` and says that it replaces. The flag is declared locally on
   the command (which is what stops the global from being injected over it) and hidden, so `--help`
   and `linear commands --json` advertise only the flag that works. `project create --team` is
   untouched — there it is the genuine fallback team.
-- **`api --operation` did nothing at all** (AUDIT.md #7). It was passed as a fourth argument to the
+- **`api --operation` did nothing at all.** It was passed as a fourth argument to the
   SDK's `rawRequest`, which takes three — so it was discarded, and a multi-operation document went
   to the API with no operation named. The API's answer to that is not "run the first one" but a
   flat `The operation does not exist on the query.`, which made multi-operation documents unusable
@@ -745,12 +771,12 @@ All notable changes to this project are documented here. The format is based on
   multi-operation document is now a usage error that lists the names, rather than a confusing error
   from the server, and `--operation` naming an operation the document does not define is caught here
   too.
-- **`api --paginate` never checked what it was re-running** (AUDIT.md #10). The loop re-executes the
-  whole document once per cursor, so a *mutation* whose payload happens to contain a paginatable
+- **`api --paginate` never checked what it was re-running.** The loop re-executes the
+  whole document once per cursor, so a _mutation_ whose payload happens to contain a paginatable
   connection would have been executed once per page — creating duplicate entities, silently, in
   proportion to how much data came back. It now refuses anything that is not a query, and refuses it
   **before the first request**, so the check cannot itself cost a side effect. The kind is read from
-  the same parse that `--operation` uses, which means it is the *selected* operation that is
+  the same parse that `--operation` uses, which means it is the _selected_ operation that is
   checked, not merely the first one in the file.
 - **`schema --json --output <file>` ignored the file.** The JSON branch returned before reaching the
   write, so the introspection result went to stdout and no file was ever created — silently, since
@@ -764,7 +790,7 @@ All notable changes to this project are documented here. The format is based on
   stderr, where it lands in scrollback, CI logs and bug reports. The same channel let a project
   `.linear.toml` — a file that is not ours and may arrive with a checkout — emit raw escape
   sequences through our error output. We now report only the reason and the position (`line 3,
-  column 36`), never an excerpt from a credential-bearing file, and strip control characters and
+column 36`), never an excerpt from a credential-bearing file, and strip control characters and
   bidi overrides from what remains. The error stays actionable: it still says exactly where to look.
 - **Credential writes could lose a config or leave a truncated one.** Writing the config in place
   truncates it first, so a crash or a concurrently-running `linear` could observe — or leave behind

package/COVERAGE.md

@@ -2,11 +2,11 @@
 
 Generated by `bun run audit:coverage`. Total LinearClient members: **470**.
 
-| Status | Count | Meaning |
-| --- | --- | --- |
-| curated | 102 | Has a first-class CLI command |
-| raw-only | 140 | Reachable via `linear api` (no bespoke command) |
-| excluded | 228 | Out of scope (admin/integration/SDK plumbing) |
+| Status   | Count | Meaning                                         |
+| -------- | ----- | ----------------------------------------------- |
+| curated  | 102   | Has a first-class CLI command                   |
+| raw-only | 140   | Reachable via `linear api` (no bespoke command) |
+| excluded | 228   | Out of scope (admin/integration/SDK plumbing)   |
 
 Every member is classified — CI fails otherwise. `raw-only` members are still
 100% reachable through the raw GraphQL escape hatch; they simply lack a tailored command.