linear-sdk-cli 0.1.0 → 0.1.1

package/CHANGELOG.md

@@ -16,7 +16,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
@@ -61,9 +61,9 @@ commands <path...>` describes one command — a bare object under `--json` (`.ou
   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
@@ -104,7 +104,7 @@ create/update` take `--icon`/`--color`, and `initiative view` shows `icon`, `arc
   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
@@ -125,7 +125,7 @@ create/update` take `--icon`/`--color`, and `initiative view` shows `icon`, `arc
     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
@@ -139,7 +139,7 @@ create/update` take `--icon`/`--color`, and `initiative view` shows `icon`, `arc
     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
@@ -172,12 +172,12 @@ create/update` take `--icon`/`--color`, and `initiative view` shows `icon`, `arc
   - **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`
+    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`).
   - **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
@@ -196,12 +196,12 @@ create/update` take `--icon`/`--color`, and `initiative view` shows `icon`, `arc
     `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
@@ -266,9 +266,9 @@ create/update` take `--icon`/`--color`, and `initiative view` shows `icon`, `arc
   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
@@ -282,11 +282,11 @@ true` is sent unless `--no-default-template` (also accepted under the reference'
 
 - **`--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
@@ -295,7 +295,7 @@ id`, `commands`, …) all three used to vanish without a word. That silence cost
   `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
@@ -303,7 +303,7 @@ id`, `commands`, …) all three used to vanish without a word. That silence cost
   `--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
@@ -321,17 +321,17 @@ id`, `commands`, …) all three used to vanish without a word. That silence cost
   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`,
@@ -378,7 +378,7 @@ list`/`mine`/`search` and `project list` with no `--team`, no configured team an
   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.
@@ -389,7 +389,7 @@ list`/`mine`/`search` and `project list` with no `--team`, no configured team an
   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`
@@ -434,7 +434,7 @@ list`/`mine`/`search` and `project list` with no `--team`, no configured team an
 
 - **`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).
@@ -455,7 +455,7 @@ list`/`mine`/`search` and `project list` with no `--team`, no configured team an
   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
@@ -485,7 +485,7 @@ list`/`mine`/`search` and `project list` with no `--team`, no configured team an
   `--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
@@ -503,7 +503,7 @@ arguments but got 2: issues, list.` and `linear issue lst` was `'lst' is not a v
   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
@@ -520,7 +520,7 @@ arguments but got 2: issues, list.` and `linear issue lst` was `'lst' is not a v
   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
@@ -528,7 +528,7 @@ arguments but got 2: issues, list.` and `linear issue lst` was `'lst' is not a v
   `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`
@@ -556,12 +556,12 @@ arguments but got 2: issues, list.` and `linear issue lst` was `'lst' is not a v
   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
   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,
@@ -576,27 +576,27 @@ arguments but got 2: issues, list.` and `linear issue lst` was `'lst' is not a v
   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
+  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
@@ -610,7 +610,7 @@ arguments but got 2: issues, list.` and `linear issue lst` was `'lst' is not a v
   `--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
@@ -643,7 +643,7 @@ arguments but got 2: issues, list.` and `linear issue lst` was `'lst' is not a v
   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
@@ -652,8 +652,8 @@ describe)"`. `issue pull-request [id]` (alias `pr`) creates a GitHub PR via the
   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
@@ -666,7 +666,7 @@ login` now accepts the global `--workspace <slug>` (derived from the key's organ
   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
@@ -685,7 +685,7 @@ login` now accepts the global `--workspace <slug>` (derived from the key's organ
   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
@@ -697,7 +697,7 @@ login` now accepts the global `--workspace <slug>` (derived from the key's organ
   `--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
@@ -718,7 +718,7 @@ login` now accepts the global `--workspace <slug>` (derived from the key's organ
   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**
+  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
@@ -739,11 +739,11 @@ login` now accepts the global `--workspace <slug>` (derived from the key's organ
   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
+  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
@@ -757,7 +757,7 @@ login` now accepts the global `--workspace <slug>` (derived from the key's organ
   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.