@enrichlayer/el-linear 1.37.1 → 1.37.2

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)
@@ -466,7 +476,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/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.js

@@ -7,7 +7,7 @@ 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";
@@ -477,18 +477,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 +519,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 +554,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,
@@ -1268,7 +1292,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/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;

package/dist/commands/profile/members.js

@@ -0,0 +1,132 @@
+/**
+ * `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 { outputSuccess } from "../../utils/output.js";
+import { applyMemberAliasUpdate } from "../init/aliases.js";
+import { parseCsvList, readConfig, updateConfig, } from "../init/shared.js";
+/**
+ * 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 function listMembers(config) {
+    const aliases = config.members?.aliases ?? {};
+    const github = config.members?.handles?.github ?? {};
+    const gitlab = config.members?.handles?.gitlab ?? {};
+    const byName = new Map();
+    const ensure = (name) => {
+        let entry = byName.get(name);
+        if (!entry) {
+            entry = { displayName: name, aliases: [] };
+            byName.set(name, entry);
+        }
+        return entry;
+    };
+    for (const [alias, name] of Object.entries(aliases)) {
+        if (name === undefined)
+            continue;
+        ensure(name).aliases.push(alias);
+    }
+    for (const [handle, name] of Object.entries(github)) {
+        if (name === undefined)
+            continue;
+        ensure(name).github = handle;
+    }
+    for (const [handle, name] of Object.entries(gitlab)) {
+        if (name === undefined)
+            continue;
+        ensure(name).gitlab = handle;
+    }
+    return [...byName.values()].sort((a, b) => a.displayName.localeCompare(b.displayName));
+}
+/**
+ * Translate a `--github`/`--gitlab` flag value into a HandleAction:
+ *   - flag absent          → keep (leave any existing handle alone)
+ *   - flag present, empty  → clear
+ *   - flag present, value  → set
+ */
+function handleActionFromFlag(raw) {
+    if (raw === undefined)
+        return { kind: "keep" };
+    const trimmed = raw.trim();
+    return trimmed ? { kind: "set", value: trimmed } : { kind: "clear" };
+}
+/** `el-linear profile members list` — exported for direct testing. */
+export async function runMembersList() {
+    const config = await readConfig();
+    return listMembers(config);
+}
+/** `el-linear profile members clear <name>` — exported for direct testing. */
+export async function runMembersClear(name) {
+    await updateConfig((current) => applyMemberAliasUpdate(current, name, {
+        mode: "clear",
+        aliases: [],
+        github: { kind: "clear" },
+        gitlab: { kind: "clear" },
+    }));
+}
+/** `el-linear profile members set <name>` — exported for direct testing. */
+export async function runMembersSet(name, opts) {
+    if (opts.aliases === undefined &&
+        opts.github === undefined &&
+        opts.gitlab === undefined) {
+        throw new Error("Pass at least one of --aliases, --github, --gitlab.");
+    }
+    await updateConfig((current) => applyMemberAliasUpdate(current, name, {
+        mode: opts.aliases !== undefined ? "edit" : "keep",
+        aliases: opts.aliases !== undefined ? parseCsvList(opts.aliases) : [],
+        github: handleActionFromFlag(opts.github),
+        gitlab: handleActionFromFlag(opts.gitlab),
+    }));
+}
+export function registerMembersCommands(profile) {
+    const members = profile
+        .command("members")
+        .description("Directly edit or clear a member's aliases/handles without hand-editing config.json (DEV-5612).");
+    members.action(() => members.help());
+    members
+        .command("list")
+        .description("List members with configured aliases/GitHub/GitLab handles.")
+        .action(async () => {
+        const data = await runMembersList();
+        outputSuccess({ data, meta: { count: data.length } });
+    });
+    members
+        .command("clear <name>")
+        .description("Remove all aliases + GitHub/GitLab handles for <name> (exact display name, see `members list`).")
+        .action(async (name) => {
+        await runMembersClear(name);
+        outputSuccess({ data: { cleared: name } });
+    });
+    members
+        .command("set <name>")
+        .description("Replace aliases/handles for <name> (exact display name). Omit a flag to leave that field unchanged; pass an empty value to clear just that field.")
+        .option("--aliases <csv>", "comma-separated aliases; replaces the existing set for this member")
+        .option("--github <handle>", "GitHub handle; pass an empty string to clear")
+        .option("--gitlab <handle>", "GitLab handle; pass an empty string to clear")
+        .action(async (name, opts) => {
+        await runMembersSet(name, opts);
+        outputSuccess({ data: { updated: name } });
+    });
+}

package/dist/commands/profile.js

@@ -26,6 +26,7 @@ import { confirm } from "@inquirer/prompts";
 import { ACTIVE_PROFILE_FILE, CONFIG_DIR, CONFIG_PATH, isSafeProfileName as isSafeName, PROFILES_DIR, profilePaths, readActiveProfileMarker, resolveActiveProfile, setActiveProfileForSession, TOKEN_PATH, } from "../config/paths.js";
 import { outputSuccess, outputWarning } from "../utils/output.js";
 import { runFullWizard } from "./init/index.js";
+import { registerMembersCommands } from "./profile/members.js";
 import { registerMigrateLegacy } from "./profile/migrate-legacy.js";
 export function setupProfileCommands(program) {
     const profile = program
@@ -79,6 +80,9 @@ export function setupProfileCommands(program) {
     // self-contained and unit-testable without dragging in the full
     // profile-management surface.
     registerMigrateLegacy(profile);
+    // `el-linear profile members {list,clear,set}` — DEV-5612: direct,
+    // non-interactive alias/handle edits without hand-editing config.json.
+    registerMembersCommands(profile);
 }
 export async function runProfileList() {
     const active = resolveActiveProfile();

package/dist/commands/users.js

@@ -5,6 +5,15 @@ import { parsePositiveInt } from "../utils/validators.js";
 export function setupUsersCommands(program) {
     const users = program.command("users").description("User operations");
     users.action(() => users.help());
+    users
+        .command("read <id>")
+        .description("Look up a single user by UUID, email, or name (resolves ambiguity the same way as other --assignee-style lookups).")
+        .action(handleAsyncCommand(async (id, _options, command) => {
+        const rootOpts = getRootOpts(command);
+        const service = await createLinearService(rootOpts);
+        const result = await service.getUser(id);
+        outputSuccess({ data: result });
+    }));
     users
         .command("list")
         .description("List all users")

package/dist/config/config.d.ts

@@ -69,6 +69,17 @@ export interface ElLinearConfig {
          * `DEFAULT_DUPLICATE_THRESHOLD` (0.35). Lower = more aggressive.
          */
         duplicateThreshold?: number;
+        /**
+         * Jaccard title-similarity threshold (0-1) above which a duplicate
+         * candidate HARD blocks creation (throws, requires `--allow-duplicate`).
+         * A candidate scoring at/above `duplicateThreshold` but below this is
+         * advisory only — printed, creation proceeds. Defaults to
+         * `DEFAULT_HARD_BLOCK_THRESHOLD` (0.6). See DEV-5590 for why the gate
+         * is two-tier: single-threshold override-rate telemetry showed score
+         * alone doesn't separate genuine duplicates from legitimate distinct
+         * issues in the 0.35-0.6 range.
+         */
+        duplicateHardBlockThreshold?: number;
         /**
          * OPT-IN SOP-label parent gate (DEV-5378). When `true`, `issues create`
          * requires an issue carrying an SOP-type label (see `sopLabels`) to point

package/dist/utils/duplicate-detection.d.ts

@@ -32,6 +32,44 @@ import type { LinearIssue } from "../types/linear.js";
  * Overridable via `config.validation.duplicateThreshold`.
  */
 export declare const DEFAULT_DUPLICATE_THRESHOLD = 0.35;
+/**
+ * Threshold above which a candidate is a HARD block (creation refuses without
+ * `--allow-duplicate`). Below this (but at/above {@link DEFAULT_DUPLICATE_THRESHOLD})
+ * a candidate is ADVISORY ONLY — printed, but creation proceeds — DEV-5590.
+ *
+ * Why a second threshold instead of just retuning the first: `el-telemetry
+ * gates` measured a 52.2% override rate on the single-threshold (0.35) gate
+ * over 144 real fires. Analyzing the real ledger (`top_score` + `outcome` per
+ * fire, no title text is ever recorded — el-linear collects nothing by
+ * default) falsifies the obvious fix of "just raise the threshold": mean/
+ * median `top_score` for `blocked` fires (0.414 / 0.40) and `overridden`
+ * fires (0.421 / 0.40) are statistically indistinguishable, and simulating
+ * every cutoff from 0.35 to 0.56 against the real corpus held the override
+ * rate flat at 52–63% — *increasing* at some higher cutoffs. Score alone does
+ * not separate genuine duplicates from legitimate distinct issues in this
+ * workspace's real usage; no single threshold in the observed range is
+ * better than a coin flip.
+ *
+ * Given that, blocking hard on a weak signal is worse than not blocking at
+ * all: over half the stops were wrong. 0.6 sits above the entire analyzed
+ * range (only 1/144 historical fires scored this high) and is reserved for
+ * near-verbatim title overlap — at Jaccard >= 0.6, more than 6 of every 10
+ * combined salient tokens are shared, which is a qualitatively different
+ * (and much rarer) signal than the "shares a few topical words" fires that
+ * dominate the false-positive population. This preserves a real backstop for
+ * the obvious copy-paste case while no longer forcing a stop-and-override
+ * ritual on the ambiguous 0.35-0.6 band, where the data shows we're wrong
+ * about as often as we're right.
+ *
+ * Caveat for future tuning: this corpus has no title text, so it cannot
+ * validate a *tokenization* fix (further stopwording per DEV-4830) — only a
+ * threshold-shape fix. A real precision improvement (distinguishing WHICH
+ * 0.35-0.6 fires are genuine) needs the title corpus, which is intentionally
+ * not collected. Revisit if `el-telemetry gates` after this ships still shows
+ * an unhealthy override rate on the >=0.6 hard-block tier specifically.
+ * Overridable via `config.validation.duplicateHardBlockThreshold`.
+ */
+export declare const DEFAULT_HARD_BLOCK_THRESHOLD = 0.6;
 /** A scored duplicate candidate, ready to print in the block. */
 export interface DuplicateCandidate {
     identifier: string;
@@ -71,6 +109,12 @@ export declare function scoreDuplicateCandidates(title: string, candidates: Line
 /**
  * Render the human/agent-facing block listing duplicate candidates, matching
  * the shape of the validation "Suggestions:" blocks (id · title · state ·
- * assignee). Used as the body of the thrown error when the gate fires.
+ * assignee).
+ *
+ * `mode: "block"` (default) is the body of the thrown error when the gate
+ * hard-blocks (score >= the hard-block threshold — DEV-5590). `mode:
+ * "advisory"` is printed as a warning when the score is below the hard-block
+ * threshold: creation already proceeded, so the trailing hint differs (no
+ * "re-run" — there's nothing to re-run).
  */
-export declare function formatDuplicateBlock(candidates: DuplicateCandidate[]): string;
+export declare function formatDuplicateBlock(candidates: DuplicateCandidate[], mode?: "block" | "advisory"): string;

package/dist/utils/duplicate-detection.js

@@ -31,6 +31,44 @@
  * Overridable via `config.validation.duplicateThreshold`.
  */
 export const DEFAULT_DUPLICATE_THRESHOLD = 0.35;
+/**
+ * Threshold above which a candidate is a HARD block (creation refuses without
+ * `--allow-duplicate`). Below this (but at/above {@link DEFAULT_DUPLICATE_THRESHOLD})
+ * a candidate is ADVISORY ONLY — printed, but creation proceeds — DEV-5590.
+ *
+ * Why a second threshold instead of just retuning the first: `el-telemetry
+ * gates` measured a 52.2% override rate on the single-threshold (0.35) gate
+ * over 144 real fires. Analyzing the real ledger (`top_score` + `outcome` per
+ * fire, no title text is ever recorded — el-linear collects nothing by
+ * default) falsifies the obvious fix of "just raise the threshold": mean/
+ * median `top_score` for `blocked` fires (0.414 / 0.40) and `overridden`
+ * fires (0.421 / 0.40) are statistically indistinguishable, and simulating
+ * every cutoff from 0.35 to 0.56 against the real corpus held the override
+ * rate flat at 52–63% — *increasing* at some higher cutoffs. Score alone does
+ * not separate genuine duplicates from legitimate distinct issues in this
+ * workspace's real usage; no single threshold in the observed range is
+ * better than a coin flip.
+ *
+ * Given that, blocking hard on a weak signal is worse than not blocking at
+ * all: over half the stops were wrong. 0.6 sits above the entire analyzed
+ * range (only 1/144 historical fires scored this high) and is reserved for
+ * near-verbatim title overlap — at Jaccard >= 0.6, more than 6 of every 10
+ * combined salient tokens are shared, which is a qualitatively different
+ * (and much rarer) signal than the "shares a few topical words" fires that
+ * dominate the false-positive population. This preserves a real backstop for
+ * the obvious copy-paste case while no longer forcing a stop-and-override
+ * ritual on the ambiguous 0.35-0.6 band, where the data shows we're wrong
+ * about as often as we're right.
+ *
+ * Caveat for future tuning: this corpus has no title text, so it cannot
+ * validate a *tokenization* fix (further stopwording per DEV-4830) — only a
+ * threshold-shape fix. A real precision improvement (distinguishing WHICH
+ * 0.35-0.6 fires are genuine) needs the title corpus, which is intentionally
+ * not collected. Revisit if `el-telemetry gates` after this ships still shows
+ * an unhealthy override rate on the >=0.6 hard-block tier specifically.
+ * Overridable via `config.validation.duplicateHardBlockThreshold`.
+ */
+export const DEFAULT_HARD_BLOCK_THRESHOLD = 0.6;
 /**
  * Function words and issue-boilerplate tokens that carry no topical signal.
  * Dropping them keeps the Jaccard score driven by the distinctive nouns
@@ -174,14 +212,26 @@ export function scoreDuplicateCandidates(title, candidates, threshold = DEFAULT_
 /**
  * Render the human/agent-facing block listing duplicate candidates, matching
  * the shape of the validation "Suggestions:" blocks (id · title · state ·
- * assignee). Used as the body of the thrown error when the gate fires.
+ * assignee).
+ *
+ * `mode: "block"` (default) is the body of the thrown error when the gate
+ * hard-blocks (score >= the hard-block threshold — DEV-5590). `mode:
+ * "advisory"` is printed as a warning when the score is below the hard-block
+ * threshold: creation already proceeded, so the trailing hint differs (no
+ * "re-run" — there's nothing to re-run).
  */
-export function formatDuplicateBlock(candidates) {
+export function formatDuplicateBlock(candidates, mode = "block") {
     const lines = candidates.map((c) => `    ${c.identifier} · ${c.title} · ${c.state} · ${c.assignee}  (similarity ${c.score})`);
-    return (`Possible duplicate issue${candidates.length > 1 ? "s" : ""} found ` +
+    const header = `Possible duplicate issue${candidates.length > 1 ? "s" : ""} found ` +
         "(by title-keyword overlap):\n" +
         `${lines.join("\n")}\n\n` +
-        "  If one of these is the same work, comment on it instead of creating a new issue.\n" +
+        "  If one of these is the same work, comment on it instead of creating a new issue.\n";
+    if (mode === "advisory") {
+        return (header +
+            "  This is advisory only (DEV-5590) — creation is proceeding. Pass " +
+            "--allow-duplicate to silence this notice next time.");
+    }
+    return (header +
         "  If this is genuinely distinct, re-run with --allow-duplicate to proceed " +
         "(and consider --related-to to link the related issue).");
 }

package/dist/utils/gate-telemetry.d.ts

@@ -29,9 +29,15 @@ export interface GateEvent {
      * `blocked` — the gate stopped creation. `overridden` — a gate-specific
      * override flag let a would-block proceed. `fail-open` — the gate could not
      * evaluate (infra/service error) and let creation proceed rather than block
-     * on trouble; tracked so degradation is measurable (DEV-5378).
+     * on trouble; tracked so degradation is measurable (DEV-5378). `advisory` —
+     * the gate fired below its hard-block threshold: printed, but never forced
+     * a stop (DEV-5590). Like `fail-open`, the tools-repo reader
+     * (`el-telemetry gates`) only recognizes `blocked`/`overridden` for the
+     * override-rate denominator — an unrecognized outcome is skipped rather
+     * than counted, so `advisory` fires are visible in the raw ledger but
+     * intentionally excluded from the metric.
      */
-    outcome: "blocked" | "overridden" | "fail-open";
+    outcome: "blocked" | "overridden" | "fail-open" | "advisory";
     /** Highest candidate similarity that triggered the gate (0–1). */
     topScore?: number;
     /** How many candidates crossed the threshold. */

package/dist/utils/linear-service.d.ts

@@ -14,6 +14,14 @@ export declare class LinearService {
     resolveIssueId(issueId: string): Promise<string>;
     getTeams(limit?: number): Promise<LinearTeam[]>;
     resolveUserId(nameOrEmailOrId: string): Promise<string>;
+    /**
+     * Single-user lookup by UUID, email, or name (DEV-5612) — the natural
+     * complement to `getUsers`/`users list`, so identifying one actor (e.g. an
+     * unrecognized member surfaced by the alias wizard) doesn't require
+     * dumping the whole workspace. Resolution/ambiguity semantics match every
+     * other `--assignee`-style lookup in the CLI via {@link resolveUserId}.
+     */
+    getUser(nameOrEmailOrId: string): Promise<LinearUser>;
     getUsers(activeOnly?: boolean, limit?: number, nameFilter?: string): Promise<LinearUser[]>;
     getProjects(limit?: number, options?: {
         nameFilter?: string;

package/dist/utils/linear-service.js

@@ -99,6 +99,24 @@ export class LinearService {
         }
         throw notFoundError("User", nameOrEmailOrId);
     }
+    /**
+     * Single-user lookup by UUID, email, or name (DEV-5612) — the natural
+     * complement to `getUsers`/`users list`, so identifying one actor (e.g. an
+     * unrecognized member surfaced by the alias wizard) doesn't require
+     * dumping the whole workspace. Resolution/ambiguity semantics match every
+     * other `--assignee`-style lookup in the CLI via {@link resolveUserId}.
+     */
+    async getUser(nameOrEmailOrId) {
+        const id = await this.resolveUserId(nameOrEmailOrId);
+        const user = await this.client.user(id);
+        return {
+            id: user.id,
+            name: user.name,
+            displayName: user.displayName,
+            email: user.email,
+            active: user.active,
+        };
+    }
     async getUsers(activeOnly, limit = 100, nameFilter) {
         const filter = {};
         if (activeOnly) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@enrichlayer/el-linear",
-  "version": "1.37.1",
+  "version": "1.37.2",
   "description": "A pragmatic CLI for Linear.app — deterministic team/label/member resolution, structured issue validation, configurable term enforcement, and a GraphQL escape hatch.",
   "main": "dist/main.js",
   "types": "dist/main.d.ts",