@enrichlayer/el-linear 1.37.1 → 1.38.0

package/README.md

@@ -145,6 +145,16 @@ EL_LINEAR_PROFILE=forage el-linear teams list
 el-linear profile remove old-profile
 ```
 
+Fix or clean up a single member's aliases/handles without hand-editing
+`config.json` — `profile members` operates directly on the active profile's
+on-disk config (no Linear API round-trip):
+
+```bash
+el-linear profile members list                              # show configured members
+el-linear profile members clear "linear"                     # remove a mistaken/stale entry
+el-linear profile members set "Alice Anderson" --aliases ali,al,alex
+```
+
 Each profile lives at `~/.config/el-linear/profiles/<name>/` and owns:
 
 - `token` — its Linear API token (mode 0600)
@@ -267,8 +277,9 @@ el-linear can record each gate's fire/override decision to a local JSONL file so
 you can measure its **override-rate** and tell whether it's too aggressive. It is
 **off by default** and writes nothing unless you opt in (e.g.
 `export EL_TELEMETRY_DIR=<path>`); there is no server or database, and
-`EL_TELEMETRY_DISABLED=1` forces it off. Full opt-in rules, the event schema, and
-a `jq` reader are in [docs/telemetry.md](./docs/telemetry.md).
+`EL_TELEMETRY_DISABLED=1` forces it off. The active ledger rotates to one `.old`
+backup before append when it exceeds 2 MiB. Full opt-in rules, the event schema,
+and a `jq` reader are in [docs/telemetry.md](./docs/telemetry.md).
 
 ### Networking (IPv4 preference)
 
@@ -466,7 +477,7 @@ el-linear <command> --help       # detailed help for one command
 | Search | `search <query>` (semantic, cross-resource) |
 | Refs | `refs wrap` (rewrite issue identifiers in arbitrary text as links) |
 | Escape hatch | `graphql [query]` (with `--introspect`) |
-| Config | `config show`, `users list`, `teams list`, `templates list` |
+| Config | `config show`, `users {list, read}`, `teams list`, `templates list` |
 
 All `list` subcommands support `-l, --limit <n>`. All commands accept the
 top-level filters: `--format <json|summary>`, `--raw`, `--jq <expr>`, `--fields <list>`.

package/claude-skills/linear-operations/SKILL.md

@@ -237,6 +237,16 @@ el-linear issues search "keywords from proposed title" --include-closed 2>&1
    el-linear issues create "Title" --team ENG --related-to "ENG-456,ENG-789" ... 2>&1
    ```
 
+### Cross-linking: be generous, link proactively, don't wait ([DEV-5853](https://linear.app/verticalint/issue/DEV-5853/))
+
+**The default is to link, not to ask.** A cross-link is cheap and reversible; a *missing* link is invisible and costs reviewers and SOP tooling the context they need. When you identify an issue that is **related** / a **blocker** / a **follow-up** / the **origin** of the work in front of you, create the relation yourself — don't stage the candidates and wait for the human to name them, and don't hedge with "tell me if you want these linked."
+
+- **At create time**, pass `--related-to "<ids>"` / `--parent <id>` / `--blocked-by <id>` directly on `issues create` — this path typically passes the classifier, so link generously the moment you file.
+- **After the fact**, call `el-linear issues relate <source> --related-to "<ids>"` (or `--blocked-by` / `--blocks` / `--duplicate-of`) proactively, the same way.
+- Over-linking is self-correcting (a wrong relation is one command to remove); under-linking is not. When in doubt, link.
+
+The one exception is below: if the auto-mode permission classifier actually blocks a specific post-hoc `relate` call, that block — not caution — is your signal to surface the candidates for a one-word confirm.
+
 ### Existence check — before an "add capability X" issue ([DEV-5097](https://linear.app/verticalint/issue/DEV-5097/))
 
 The dup-check above guards against duplicating an *issue*. This guards against duplicating *reality*: before filing an issue to **add** a flag / guard / command / subcommand, confirm it doesn't **already exist**.
@@ -248,38 +258,29 @@ Skipping it cost real rework across sessions: a hook guard and `--jq`/`--fields`
 
 When `el-linear issues search` (or the cross-resource `search`) returns rows
 carrying issue identifiers, the JSON envelope embeds a `_warnings` line
-starting with `relation_candidates:` that enumerates the candidate IDs and
-asks the user to reply with which ones to link, and states the skip phrase.
-
-That warning is the authoritative instruction — surface it to the user
-verbatim and follow it literally: **do not call `el-linear issues relate`
-until the user replies naming the IDs to link.** Only user-named IDs go into
-the `issues relate <source> --related-to "<ids>"` call — never pass an ID the
-user did not name, even one your own search obviously surfaced. The CLI emits
-the full procedure (every candidate ID, the example reply, the skip phrase) in
-that one line, so follow it rather than re-deriving or paraphrasing it away.
-
-Why this matters: Claude Code's auto-mode permission classifier blocks
-`issues relate --related-to "<ids>"` when the IDs were *agent-inferred*
-(came from your own search) rather than *user-specified* (typed by the human),
-because each listed peer is a write target. Routing the IDs through an
-explicit human reply converts them from agent-inferred → user-specified;
-the existing search step (above) stays intact; auto-mode's guard is not
-weakened. The fix is the loop shape, not the guard.
-
-Anti-patterns:
-
-- **Calling `issues relate` directly off your own search output** — even if
-  the IDs are real and the candidates look obvious, this is the exact path
-  the auto-mode guard refuses.
-- **Splitting one relate call into N single-ID calls** to "look smaller" —
-  same provenance problem, same block, just multiplied.
-- **Asking the user a yes/no question** ("Should I link these?") instead of
-  having them name the IDs — yes answers stay agent-inferred, the reply
-  must carry the IDs to convert them to user-specified.
+starting with `relation_candidates:` enumerating the candidate IDs. Treat it
+as a **convenience list of link candidates, not a stop sign** — under the
+proactive default above, relate the ones that are genuinely related/blocking
+without waiting to be told. Prefer create-time `--related-to` when the search
+ran as part of filing a new issue (create-time relations typically pass the
+classifier); otherwise call `issues relate` directly.
+
+**Residual auto-mode constraint (the only reason to pause).** Claude Code's
+auto-mode permission classifier *may* block a standalone `issues relate
+--related-to "<ids>"` when it judges the IDs *agent-inferred* (surfaced by
+your own search) rather than *user-specified*, because each peer is a write
+target. A standing user instruction to cross-link generously is itself
+authorization — so proceed by default. But if a specific `relate` call is
+**actually blocked** by the classifier, that block is your cue: surface the
+candidate IDs to the user for a one-word confirm, then re-run with the
+user-named IDs (which pass). This is the **exception path**, not the default —
+do not pre-emptively withhold links the classifier would have allowed. Two
+ways to keep it frictionless: file relations at create time (`--related-to`),
+or the operator adds a permission rule / runs non-auto-mode so post-hoc
+`relate` never trips.
 
 If `--include-closed` search returns no matches, no `relation_candidates:`
-warning is emitted (nothing to confirm) and the flow proceeds normally.
+warning is emitted and the flow proceeds normally.
 
 ### Viewing existing relations
 

package/dist/commands/comments.js

@@ -4,6 +4,7 @@ import { CREATE_COMMENT_MUTATION, DELETE_COMMENT_MUTATION, GET_COMMENT_QUERY, LI
 import { autoLinkReferences, } from "../utils/auto-link-references.js";
 import { applyFooter } from "../utils/footer.js";
 import { createGraphQLService, } from "../utils/graphql-service.js";
+import { normalizeInlineTextInput } from "../utils/inline-text-input.js";
 import { extractIssueReferences } from "../utils/issue-reference-extractor.js";
 import { wrapIssueReferencesAsLinks } from "../utils/issue-reference-wrapper.js";
 import { createLinearService, } from "../utils/linear-service.js";
@@ -79,7 +80,7 @@ function readBody(options) {
         return readFileSync(options.bodyFile, "utf-8");
     }
     if (options.body) {
-        return options.body;
+        return normalizeInlineTextInput(options.body);
     }
     throw new Error("Either --body or --body-file is required");
 }

package/dist/commands/init/aliases.d.ts

@@ -17,6 +17,17 @@ export interface User {
     displayName: string;
 }
 export declare function fetchAllUsers(token: string): Promise<User[]>;
+/**
+ * Detect the synthetic Linear-internal "system actor" surfaced by the Users
+ * API alongside real people — DEV-5612. Its email is a
+ * `<uuid>@linear.linear.app` address (the documented pattern for Linear's own
+ * automation account); it isn't a person and should never be offered as an
+ * assignable alias target. A user setting up the alias wizard for the first
+ * time mistook it for themselves (`linear <linear-…@linear.linear.app>`
+ * presented as an ordinary numbered member) and typed their own nicknames as
+ * its aliases.
+ */
+export declare function isLinearSystemActor(user: User): boolean;
 /**
  * Find groups of users sharing the same display name. The current alias
  * config keys aliases by display name, so colliding users would silently
@@ -25,11 +36,29 @@ export declare function fetchAllUsers(token: string): Promise<User[]>;
  * schema to UUID-keyed maps.
  */
 export declare function findDisplayNameCollisions(users: User[]): Map<string, User[]>;
+/** The alias/handle-mutation slice of {@link AliasUpdate}, without the user
+ * identity fields — shared by the UUID-keyed wizard merge and the by-name
+ * direct-edit path (DEV-5612), which has no UUID to record. */
+export type MemberAliasMutation = Pick<AliasUpdate, "mode" | "aliases" | "github" | "gitlab">;
 /**
  * Merge new alias entries into existing config without dropping unrelated
  * fields. Pure function — no I/O. Exported for testing.
  */
 export declare function mergeAliasesIntoConfig(existing: WizardConfig, updates: Map<string, AliasUpdate>): WizardConfig;
+/**
+ * Apply a single member alias/handle mutation directly by display name — the
+ * non-interactive counterpart to the `init aliases` walk (DEV-5612). Used by
+ * `el-linear profile members clear <name>` / `members set <name>` so a
+ * mistaken or unwanted entry (e.g. the Linear system actor, or a stale
+ * alias) can be fixed without hand-editing config.json or re-walking every
+ * user interactively.
+ *
+ * Unlike {@link mergeAliasesIntoConfig} (keyed by Linear user UUID, populated
+ * by the `init aliases` walk against the live Users API), this operates
+ * purely on the on-disk config by display name — the `uuids`/`fullNames`
+ * maps are left untouched since there's no fresh UUID to record here.
+ */
+export declare function applyMemberAliasUpdate(existing: WizardConfig, displayName: string, update: MemberAliasMutation): WizardConfig;
 /**
  * What to do with a single platform handle (github/gitlab/...) when applying
  * an AliasUpdate. Discriminated union; no sentinel strings.

package/dist/commands/init/aliases.js

@@ -46,6 +46,19 @@ export async function fetchAllUsers(token) {
     }
     return out;
 }
+/**
+ * Detect the synthetic Linear-internal "system actor" surfaced by the Users
+ * API alongside real people — DEV-5612. Its email is a
+ * `<uuid>@linear.linear.app` address (the documented pattern for Linear's own
+ * automation account); it isn't a person and should never be offered as an
+ * assignable alias target. A user setting up the alias wizard for the first
+ * time mistook it for themselves (`linear <linear-…@linear.linear.app>`
+ * presented as an ordinary numbered member) and typed their own nicknames as
+ * its aliases.
+ */
+export function isLinearSystemActor(user) {
+    return Boolean(user.email && /@linear\.linear\.app$/i.test(user.email));
+}
 /**
  * Find groups of users sharing the same display name. The current alias
  * config keys aliases by display name, so colliding users would silently
@@ -82,6 +95,45 @@ function applyHandleAction(handlesMap, fullName, action) {
         handlesMap[action.value.trim()] = fullName;
     }
 }
+/**
+ * Apply one member's alias/handle mutation into `next` (mutated in place).
+ * Ensures the `members.aliases`/`members.handles.{github,gitlab}` sub-trees
+ * exist first. Pure with respect to `fullName`/`update` — the only side
+ * effect is on `next`.
+ */
+function applyAliasMutation(next, fullName, update) {
+    next.members = next.members ?? {};
+    next.members.aliases = next.members.aliases ?? {};
+    next.members.handles = next.members.handles ?? {};
+    next.members.handles.github = next.members.handles.github ?? {};
+    next.members.handles.gitlab = next.members.handles.gitlab ?? {};
+    // Aliases: replace this user's entries based on the update mode.
+    // We track aliases as { aliasKey: fullName }, so removing means deleting
+    // any keys whose value is this fullName.
+    const currentAliasKeys = Object.entries(next.members.aliases)
+        .filter(([_, v]) => v === fullName)
+        .map(([k]) => k);
+    if (update.mode === "clear") {
+        for (const k of currentAliasKeys)
+            delete next.members.aliases[k];
+    }
+    else if (update.mode === "edit") {
+        for (const k of currentAliasKeys)
+            delete next.members.aliases[k];
+        for (const a of update.aliases)
+            next.members.aliases[a] = fullName;
+    }
+    else if (update.mode === "append") {
+        for (const a of update.aliases)
+            next.members.aliases[a] = fullName;
+    }
+    // "keep" → no changes.
+    // GitHub / GitLab handles use the same edit/append/clear semantics,
+    // driven by the discriminated HandleAction per platform.
+    for (const platform of HANDLE_PLATFORMS) {
+        applyHandleAction(next.members.handles[platform], fullName, update[platform]);
+    }
+}
 /**
  * Merge new alias entries into existing config without dropping unrelated
  * fields. Pure function — no I/O. Exported for testing.
@@ -89,45 +141,34 @@ function applyHandleAction(handlesMap, fullName, action) {
 export function mergeAliasesIntoConfig(existing, updates) {
     const next = JSON.parse(JSON.stringify(existing));
     next.members = next.members ?? {};
-    next.members.aliases = next.members.aliases ?? {};
     next.members.fullNames = next.members.fullNames ?? {};
-    next.members.handles = next.members.handles ?? {};
     next.members.uuids = next.members.uuids ?? {};
-    next.members.handles.github = next.members.handles.github ?? {};
-    next.members.handles.gitlab = next.members.handles.gitlab ?? {};
     for (const [userId, update] of updates) {
         const fullName = update.displayName;
         next.members.uuids[fullName] = userId;
         next.members.fullNames[userId] = fullName;
-        // Aliases: replace this user's entries based on the update mode.
-        // We track aliases as { aliasKey: fullName }, so removing means deleting
-        // any keys whose value is this fullName.
-        const currentAliasKeys = Object.entries(next.members.aliases)
-            .filter(([_, v]) => v === fullName)
-            .map(([k]) => k);
-        if (update.mode === "clear") {
-            for (const k of currentAliasKeys)
-                delete next.members.aliases[k];
-        }
-        else if (update.mode === "edit") {
-            for (const k of currentAliasKeys)
-                delete next.members.aliases[k];
-            for (const a of update.aliases)
-                next.members.aliases[a] = fullName;
-        }
-        else if (update.mode === "append") {
-            for (const a of update.aliases)
-                next.members.aliases[a] = fullName;
-        }
-        // "keep" → no changes.
-        // GitHub / GitLab handles use the same edit/append/clear semantics,
-        // driven by the discriminated HandleAction per platform.
-        for (const platform of HANDLE_PLATFORMS) {
-            applyHandleAction(next.members.handles[platform], fullName, update[platform]);
-        }
+        applyAliasMutation(next, fullName, update);
     }
     return next;
 }
+/**
+ * Apply a single member alias/handle mutation directly by display name — the
+ * non-interactive counterpart to the `init aliases` walk (DEV-5612). Used by
+ * `el-linear profile members clear <name>` / `members set <name>` so a
+ * mistaken or unwanted entry (e.g. the Linear system actor, or a stale
+ * alias) can be fixed without hand-editing config.json or re-walking every
+ * user interactively.
+ *
+ * Unlike {@link mergeAliasesIntoConfig} (keyed by Linear user UUID, populated
+ * by the `init aliases` walk against the live Users API), this operates
+ * purely on the on-disk config by display name — the `uuids`/`fullNames`
+ * maps are left untouched since there's no fresh UUID to record here.
+ */
+export function applyMemberAliasUpdate(existing, displayName, update) {
+    const next = JSON.parse(JSON.stringify(existing));
+    applyAliasMutation(next, displayName, update);
+    return next;
+}
 /** Set of supported platforms for member handle keys. */
 export const HANDLE_PLATFORMS = ["github", "gitlab"];
 function currentAliasesFor(config, fullName) {
@@ -162,11 +203,24 @@ export async function runAliasesStep(token, existing, options = {}) {
         console.log("  Skipped — run `el-linear init aliases` to add or edit aliases later.");
         return new Map();
     }
-    const allUsers = await fetchAllUsers(token);
-    if (allUsers.length === 0) {
+    const fetchedUsers = await fetchAllUsers(token);
+    if (fetchedUsers.length === 0) {
         console.log("  No active users visible to this token.");
         return new Map();
     }
+    // Skip the Linear system actor(s) — not real people, never alias targets
+    // (DEV-5612). Filtered before collision detection so it can't spuriously
+    // collide with (or mask) a real display-name collision.
+    const systemActors = fetchedUsers.filter(isLinearSystemActor);
+    if (systemActors.length > 0) {
+        console.log(`  Skipping ${systemActors.length} Linear system actor(s) — not real people, never alias targets: ` +
+            `${systemActors.map((u) => u.email ?? u.id).join(", ")}`);
+    }
+    const allUsers = fetchedUsers.filter((u) => !isLinearSystemActor(u));
+    if (allUsers.length === 0) {
+        console.log("  No human users remain after filtering system actors.");
+        return new Map();
+    }
     // Skip users whose display name collides with another active user. The
     // current schema keys aliases by display name, so writing aliases for a
     // colliding user would corrupt the other user's entries. A schema migration

package/dist/commands/issues/description.js

@@ -20,6 +20,7 @@ import fs from "node:fs";
 import { loadConfig } from "../../config/config.js";
 import { UPDATE_ISSUE_MUTATION } from "../../queries/issues.js";
 import { autoLinkReferences, } from "../../utils/auto-link-references.js";
+import { normalizeInlineTextInput } from "../../utils/inline-text-input.js";
 import { extractIssueReferences } from "../../utils/issue-reference-extractor.js";
 import { wrapIssueReferencesAsLinks } from "../../utils/issue-reference-wrapper.js";
 import { validateReferences } from "../../utils/validate-references.js";
@@ -59,7 +60,7 @@ export function resolveDescription(options) {
         return readDescriptionFile(options.descriptionFile);
     }
     if (hasInline) {
-        return options.description;
+        return normalizeInlineTextInput(options.description);
     }
     if (hasTemplate) {
         const templates = loadConfig().descriptionTemplates ?? {};

package/dist/commands/issues.js

@@ -7,12 +7,13 @@ import { formatSopParentBlock, getSopLabelGateConfig, hasSopLabel, isUnresolvabl
 import { resolveDefaultStatus } from "../config/status-defaults.js";
 import { enforceTerms } from "../config/term-enforcer.js";
 import { GET_ISSUE_RELATIONS_QUERY, GET_ISSUE_STATE_HISTORY_QUERY, } from "../queries/issues.js";
-import { DEFAULT_DUPLICATE_THRESHOLD, formatDuplicateBlock, scoreDuplicateCandidates, tokenizeTitle, } from "../utils/duplicate-detection.js";
+import { DEFAULT_DUPLICATE_THRESHOLD, DEFAULT_HARD_BLOCK_THRESHOLD, formatDuplicateBlock, scoreDuplicateCandidates, tokenizeTitle, } from "../utils/duplicate-detection.js";
 import { createFileService } from "../utils/file-service.js";
 import { applyFooter } from "../utils/footer.js";
 import { emitGateEvent } from "../utils/gate-telemetry.js";
 import { createGraphQLAttachmentsService } from "../utils/graphql-attachments-service.js";
 import { createGraphQLService, } from "../utils/graphql-service.js";
+import { normalizeInlineTextInput } from "../utils/inline-text-input.js";
 import { createIssuesService } from "../utils/issues-service-bootstrap.js";
 import { createLinearService, } from "../utils/linear-service.js";
 import { logger } from "../utils/logger.js";
@@ -205,7 +206,8 @@ async function handleListIssues(options, command) {
     // user passes --include-closed OR explicit --status. Explicit status
     // wins because the user already named the workflow states they want.
     const excludeTerminalStates = !options.includeClosed && explicitStatus === undefined;
-    const hasOtherFilters = options.team ||
+    const hasOtherFilters = options.search ||
+        options.team ||
         options.labels ||
         options.status ||
         options.assignee ||
@@ -223,6 +225,7 @@ async function handleListIssues(options, command) {
     // (DEV-4478 cycle-1.)
     if (hasOtherFilters || excludeTerminalStates || options.includeClosed) {
         const searchArgs = {
+            query: options.search,
             teamId: options.team ? resolveTeam(options.team) : undefined,
             assigneeId: options.assignee
                 ? await resolveAssignee(options.assignee, rootOpts)
@@ -244,8 +247,15 @@ async function handleListIssues(options, command) {
         if (excludeTerminalStates) {
             outputWarning("excluded terminal states (Done / Canceled) by default; pass --include-closed to include them");
         }
+        if (options.search) {
+            const relationPrompt = buildRelationCandidatePrompt(result);
+            if (relationPrompt) {
+                outputWarning(relationPrompt);
+            }
+        }
         warnIfTruncated(result.length, limit);
         outputIssues(result, command, {
+            query: options.search,
             team: options.team,
         });
     }
@@ -477,18 +487,28 @@ function buildDescriptionWithAttachments(baseDescription, uploadResults) {
 /**
  * DEV-4823: create-time duplicate-detection gate. Searches the title's
  * salient keywords (including closed issues), scores candidates by Jaccard
- * title-overlap, and throws — listing the matches — when one is at/above the
- * configured similarity threshold.
+ * title-overlap, and — for a candidate at/above the hard-block threshold —
+ * throws, listing the matches.
+ *
+ * DEV-5590: two-tier since the single-threshold gate measured a 52.2%
+ * override rate (score alone didn't separate genuine duplicates from
+ * legitimate distinct issues — see {@link DEFAULT_HARD_BLOCK_THRESHOLD} for
+ * the data). A candidate at/above `duplicateThreshold` (detection floor) but
+ * below `duplicateHardBlockThreshold` (hard-block floor) is ADVISORY: printed
+ * as a warning, creation proceeds, and the fire is recorded as `advisory` —
+ * excluded from the override-rate denominator (only `blocked`/`overridden`
+ * count). At/above the hard-block floor, behavior is unchanged from DEV-4823.
  *
  * Bypassed by `--skip-validation` and
  * `config.validation.duplicateDetection: false` / `validation.enabled: false`.
  * `--allow-duplicate` does NOT skip the search — the gate still runs and, on a
- * would-fire, records an `overridden` telemetry event (DEV-4834) before
- * proceeding, so `el-telemetry gates` can measure the override-rate. (A blocked
- * fire records `blocked`.) `--skip-validation` is a blanket bypass and emits
- * nothing — it's not a gate-specific override, so counting it would dilute the
- * signal. The search itself is best-effort: a network/API failure warns and
- * proceeds rather than blocking legitimate issue creation on infra trouble.
+ * would-hard-block, records an `overridden` telemetry event (DEV-4834) before
+ * proceeding, so `el-telemetry gates` can measure the override-rate. (A
+ * hard-blocked fire records `blocked`.) `--skip-validation` is a blanket
+ * bypass and emits nothing — it's not a gate-specific override, so counting
+ * it would dilute the signal. The search itself is best-effort: a network/API
+ * failure warns and proceeds rather than blocking legitimate issue creation
+ * on infra trouble.
  */
 async function enforceNoDuplicateIssue(title, options, issuesService) {
     if (options.skipValidation) {
@@ -509,6 +529,9 @@ async function enforceNoDuplicateIssue(title, options, issuesService) {
     const threshold = typeof validation?.duplicateThreshold === "number"
         ? validation.duplicateThreshold
         : DEFAULT_DUPLICATE_THRESHOLD;
+    const hardBlockThreshold = typeof validation?.duplicateHardBlockThreshold === "number"
+        ? validation.duplicateHardBlockThreshold
+        : DEFAULT_HARD_BLOCK_THRESHOLD;
     let candidates;
     try {
         candidates = await issuesService.searchIssues({
@@ -541,14 +564,25 @@ async function enforceNoDuplicateIssue(title, options, issuesService) {
     if (matches.length === 0) {
         return;
     }
-    // The gate would fire. Record the decision so `el-telemetry gates` can
-    // compute override-rate (DEV-4834): `overridden` when the user passed
-    // --allow-duplicate and we proceed anyway, `blocked` when we stop creation.
     const gateEvent = {
         gate: "issues-create-dup",
         topScore: matches[0].score,
         candidateCount: matches.length,
     };
+    // DEV-5590: below the hard-block floor, warn and proceed — never forces a
+    // stop, so there's nothing to "override". Recorded as `advisory` (visible
+    // in the raw ledger, excluded from the override-rate metric).
+    if (matches[0].score < hardBlockThreshold) {
+        await emitGateEvent("el-linear", "issues create", {
+            ...gateEvent,
+            outcome: "advisory",
+        });
+        outputWarning(formatDuplicateBlock(matches, "advisory"));
+        return;
+    }
+    // The gate would hard-block. Record the decision so `el-telemetry gates`
+    // can compute override-rate (DEV-4834): `overridden` when the user passed
+    // --allow-duplicate and we proceed anyway, `blocked` when we stop creation.
     if (options.allowDuplicate) {
         await emitGateEvent("el-linear", "issues create", {
             ...gateEvent,
@@ -923,6 +957,12 @@ async function handleUpdateIssue(issueId, options, command) {
     if (options.descriptionFile) {
         options.description = readDescriptionFile(options.descriptionFile);
     }
+    else if (typeof options.description === "string") {
+        options.description = normalizeInlineTextInput(options.description);
+    }
+    if (typeof options.appendDescription === "string") {
+        options.appendDescription = normalizeInlineTextInput(options.appendDescription);
+    }
     validateUpdateOptions(options);
     const rootOpts = getRootOpts(command);
     const { graphQLService, linearService, issuesService } = await createIssuesService(rootOpts);
@@ -1204,6 +1244,7 @@ export function setupIssuesCommands(program) {
         .command("list")
         .description("List issues.")
         .option("-l, --limit <number>", "limit results", "25")
+        .option("--search <query>", "full-text search term; composes with list filters")
         .option("--team <team>", "filter by team key (EL: resolves names)")
         .option("--assignee <assignee>", "filter by assignee (name, alias, or ID)")
         .option("--delegate <delegate>", "filter by delegated agent (name, alias, or ID)")
@@ -1268,7 +1309,7 @@ export function setupIssuesCommands(program) {
         .option("--checkout", "create and checkout a git branch named after the issue")
         .option("--no-claim", "with --checkout, skip assigning the issue to the current Linear user and moving it to the first started state")
         .option("--skip-validation", "skip all validation (labels, description, assignee, project, duplicate detection, SOP-parent gate)")
-        .option("--allow-duplicate", "skip the duplicate-detection gate and create even if a similar issue already exists")
+        .option("--allow-duplicate", "silence the duplicate-detection hard block and create even if a near-identical issue already exists (DEV-5590: only matters at/above the hard-block threshold — below it the gate is advisory-only and never blocks)")
         .option("--allow-unparented-sop", "skip the SOP-label parent gate and create an SOP-labeled issue without a parent SOP")
         .option("--no-auto-link", "skip auto-linking issue references found in the description")
         .option("--footer <text>", "text appended to the description (overrides config.messageFooter)")

package/dist/commands/labels.js

@@ -9,8 +9,9 @@ import { getRootOpts } from "../utils/root-opts.js";
 import { parsePositiveInt, validateHexColor } from "../utils/validators.js";
 async function handleCreateLabel(name, options, command) {
     const rootOpts = getRootOpts(command);
-    const teamId = resolveTeam(options.team);
     const graphQLService = await createGraphQLService(rootOpts);
+    const linearService = await createLinearService(rootOpts);
+    const teamId = await linearService.resolveTeamId(resolveTeam(options.team));
     const input = { name, teamId };
     if (options.color) {
         input.color = validateHexColor(options.color);

package/dist/commands/profile/members.d.ts

@@ -0,0 +1,50 @@
+/**
+ * `el-linear profile members` — direct, non-interactive alias/handle edits
+ * on the active profile's on-disk config — DEV-5612.
+ *
+ * `init aliases` (the interactive wizard walk) is the right tool for a
+ * first-time setup or a bulk pass over many users, but fixing ONE entry
+ * (e.g. clearing a mistaken alias, or the Linear system actor a user
+ * accidentally aliased before DEV-5612's wizard-side skip existed) meant
+ * either re-walking every user interactively or hand-editing
+ * `~/.config/el-linear/config.json`. These commands are the direct path:
+ *
+ *   el-linear profile members list                      — show configured members
+ *   el-linear profile members clear <name>               — remove all aliases/handles for <name>
+ *   el-linear profile members set <name> [options]        — replace aliases/handles for <name>
+ *
+ * `<name>` is the exact Linear display name as it appears in
+ * `members.aliases`/`members.handles.*` values (see `profile members list`).
+ * These commands operate purely on the local config file — no Linear API
+ * call, no UUID resolution — so they also work to clean up a stale/mistaken
+ * entry for a user no longer in the workspace.
+ */
+import type { Command } from "commander";
+import { type WizardConfig } from "../init/shared.js";
+export interface MemberListEntry {
+    displayName: string;
+    aliases: string[];
+    github?: string;
+    gitlab?: string;
+}
+/**
+ * Reconstruct a per-member view from the on-disk `members.aliases` /
+ * `members.handles.{github,gitlab}` maps (each `{ key: displayName }`).
+ * `WizardConfig`'s maps are `Record<string, string | undefined>` (DeepPartial
+ * over an index signature) — an `undefined` value can't happen in practice
+ * (JSON never round-trips one), but we guard it defensively rather than cast.
+ * Pure — exported for testing.
+ */
+export declare function listMembers(config: WizardConfig): MemberListEntry[];
+/** `el-linear profile members list` — exported for direct testing. */
+export declare function runMembersList(): Promise<MemberListEntry[]>;
+/** `el-linear profile members clear <name>` — exported for direct testing. */
+export declare function runMembersClear(name: string): Promise<void>;
+export interface MembersSetOptions {
+    aliases?: string;
+    github?: string;
+    gitlab?: string;
+}
+/** `el-linear profile members set <name>` — exported for direct testing. */
+export declare function runMembersSet(name: string, opts: MembersSetOptions): Promise<void>;
+export declare function registerMembersCommands(profile: Command): void;