get-tbd 0.2.0 → 0.2.2

package/dist/docs/guidelines/typescript-cli-tool-rules.md

@@ -14,8 +14,8 @@ Commander 14 moves to security-only maintenance until May 2027.
 **Related**:
 
 - [TypeScript Rules](./typescript-rules.md)
-- [Supply-Chain Mitigation](./pnpm-monorepo-patterns.md#supply-chain-mitigation) —
-  follow the 14-day package-age rule for every CLI dependency.
+- [Supply-Chain Mitigation](./pnpm-monorepo-patterns.md#supply-chain-mitigation)—follow
+  the 14-day package-age rule for every CLI dependency.
   Bundlers and CLI dependencies that execute at install time (`postinstall` scripts) are
   a primary attack surface.
 
@@ -368,10 +368,10 @@ context, output, and error handling.
 Strict separation of data and diagnostics enables pipeline composability.
 
 - **Data to stdout:** `data()`, `success()`, `notice()`, `dryRun()`, `table()`,
-  `list()`, `count()` — all go to `console.log` (stdout).
+  `list()`, `count()`—all go to `console.log` (stdout).
 
 - **Diagnostics to stderr:** `info()`, `warn()`, `error()`, `command()`, `debug()`,
-  `spinner` — all go to `console.error` (stderr) or `process.stderr.write`.
+  `spinner`—all go to `console.error` (stderr) or `process.stderr.write`.
 
 - **JSON mode wraps diagnostics:** `warn()` outputs `{"warning": "..."}` to stderr.
   `error()` outputs `{"error": "..."}` to stderr.
@@ -579,7 +579,7 @@ seamlessly in local dev and in remote environments.
   precedence logic, or runtime conditional loading from inside the CLI).
 
 - **Use `dotenv` only when needed:** Add `dotenv` only if your CLI must load env files
-  programmatically — e.g., it reads them after parsing command-line flags, performs
+  programmatically—e.g., it reads them after parsing command-line flags, performs
   variable expansion, or supports custom file paths the user cannot pre-bake into the
   `node` invocation.
 
@@ -615,11 +615,11 @@ seamlessly in local dev and in remote environments.
 
 - **Standard environment variables to respect:**
 
-  - `NO_COLOR` — disable colors (standard)
-  - `FORCE_COLOR` — force colors
-  - `CI` — detect CI environment, force non-interactive
-  - `DEBUG` — enable debug logging (or a namespaced equivalent like `<TOOL>_DEBUG`)
-  - `PAGER` — custom pager command for long output
+  - `NO_COLOR`—disable colors (standard)
+  - `FORCE_COLOR`—force colors
+  - `CI`—detect CI environment, force non-interactive
+  - `DEBUG`—enable debug logging (or a namespaced equivalent like `<TOOL>_DEBUG`)
+  - `PAGER`—custom pager command for long output
 
 ## Sub-Command Logging for Testability
 
@@ -705,27 +705,27 @@ runtimes, Cloudflare Workers, etc.).
 
 **Key patterns:**
 
-- **Base Command Pattern** — All handlers extend `BaseCommand`, which provides
+- **Base Command Pattern**—All handlers extend `BaseCommand`, which provides
   `CommandContext`, `OutputManager`, `execute()` error wrapping, and `checkDryRun()`
 
-- **Dual Output Mode** — `OutputManager.data(data, textFormatter)` switches between JSON
+- **Dual Output Mode**—`OutputManager.data(data, textFormatter)` switches between JSON
   and text formatting based on `--json` flag
 
-- **Handler + Command Structure** — Command definition (`.option()`, `.action()`) is
+- **Handler + Command Structure**—Command definition (`.option()`, `.action()`) is
   separate from handler class implementation.
   Action handlers do `new XxxHandler(command)` then `handler.run(options)`
 
-- **Version Handling** — Prefer deterministic runtime version resolution: build-time
+- **Version Handling**—Prefer deterministic runtime version resolution: build-time
   injection first, then environment override for dev/test, then `package.json` fallback
 
-- **Global Options** — Define `--dry-run`, `--verbose`, `--quiet`, `--json`, `--color`,
+- **Global Options**—Define `--dry-run`, `--verbose`, `--quiet`, `--json`, `--color`,
   and `--debug` at program level, plus tool-specific options as needed.
   Only add `--non-interactive` and `--yes` if the CLI has interactive prompts
 
-- **Stdout/Stderr Separation** — Data to stdout, diagnostics to stderr for pipeline
+- **Stdout/Stderr Separation**—Data to stdout, diagnostics to stderr for pipeline
   compatibility. See the Stdout/Stderr Separation section above for details
 
-- **Terminal Width Management** — Cap help text and formatted output at a maximum width
+- **Terminal Width Management**—Cap help text and formatted output at a maximum width
   (e.g., 88 chars) for readability, using narrower if the terminal is smaller
 
 ## Best Practices

package/dist/docs/guidelines/typescript-code-coverage.md

@@ -7,14 +7,14 @@ author: Joshua Levy (github.com/jlevy) with LLM assistance
 
 **Last Updated**: 2026-05-21
 
-**Tracks**: Vitest `^4.1.7`, `@vitest/coverage-v8` `^4.1.7`. Vitest 5.0 is in beta — do
+**Tracks**: Vitest `^4.1.7`, `@vitest/coverage-v8` `^4.1.7`. Vitest 5.0 is in beta—do
 not adopt yet.
 
 **Related**:
 
-- [Companion: pnpm Monorepo Patterns — Testing](./pnpm-monorepo-patterns.md#8-testing)
-- [Supply-Chain Mitigation](./pnpm-monorepo-patterns.md#supply-chain-mitigation) —
-  follow the 14-day package-age rule when installing or upgrading `vitest` and
+- [Companion: pnpm Monorepo Patterns—Testing](./pnpm-monorepo-patterns.md#8-testing)
+- [Supply-Chain Mitigation](./pnpm-monorepo-patterns.md#supply-chain-mitigation)—follow
+  the 14-day package-age rule when installing or upgrading `vitest` and
   `@vitest/coverage-v8`.
 
 ## Coverage Metrics
@@ -95,7 +95,7 @@ upgrade: use `ncu --cooldown 14` or `pnpm install --frozen-lockfile`.
 - **`coverage.all` was removed** in Vitest 4. Use `coverage.include` and
   `coverage.exclude` to define exactly which files are reported.
 - Coverage reporters and v8 provider now ship as part of `@vitest/coverage-v8` aligned
-  with the Vitest major version — pin them together.
+  with the Vitest major version—pin them together.
 
 ### Example Configuration
 

package/dist/docs/guidelines/typescript-rules.md

@@ -11,7 +11,7 @@ alwaysApply: true
 
 **Tracks**: TypeScript `^6.0.3` (stable).
 TypeScript 7.0 Beta (`@typescript/native-preview`, binary `tsgo`) is available but **not
-yet production-ready** — do not adopt for shipped builds.
+yet production-ready**—do not adopt for shipped builds.
 
 **Related**:
 
@@ -21,7 +21,7 @@ yet production-ready** — do not adopt for shipped builds.
 - [TypeScript Code Coverage](./typescript-code-coverage.md)
 - [pnpm Monorepo Patterns](./pnpm-monorepo-patterns.md) and
   [Bun Monorepo Patterns](./bun-monorepo-patterns.md)
-- [Supply-Chain Mitigation](./pnpm-monorepo-patterns.md#supply-chain-mitigation) — the
+- [Supply-Chain Mitigation](./pnpm-monorepo-patterns.md#supply-chain-mitigation)—the
   14-day package-age rule applies to every TypeScript dependency (`zod`, `commander`,
   `vitest`, `eslint`, type packages, etc.).
 
@@ -352,7 +352,7 @@ yet production-ready** — do not adopt for shipped builds.
 
 - **Barrel files:** The rules differ for libraries vs applications.
 
-  **For libraries:** Use exactly ONE barrel file — the root `index.ts` that defines the
+  **For libraries:** Use exactly ONE barrel file—the root `index.ts` that defines the
   public API. This is essential for consumers who `import { X } from 'your-library'`. Do
   NOT create module-level barrels (like `utils/index.ts` or `harness/index.ts`).
   Internal code should import directly from source files.

package/dist/docs/guidelines/typescript-yaml-handling-rules.md

@@ -9,14 +9,14 @@ globs: "*.ts"
 **Last Updated**: 2026-05-21
 
 **Tracks**: `yaml@^2.8.4` (latest stable; 2026-05-02). The `yaml@3.0.0-1` release is
-tagged `next` (pre-release) — do not adopt yet.
+tagged `next` (pre-release)—do not adopt yet.
 Zod 4.x is the recommended validation companion.
 
 **Related**:
 
 - [TypeScript Rules](./typescript-rules.md)
-- [Supply-Chain Mitigation](./pnpm-monorepo-patterns.md#supply-chain-mitigation) —
-  follow the 14-day package-age rule for `yaml`, `zod`, and `gray-matter`.
+- [Supply-Chain Mitigation](./pnpm-monorepo-patterns.md#supply-chain-mitigation)—follow
+  the 14-day package-age rule for `yaml`, `zod`, and `gray-matter`.
 
 These guidelines ensure consistent, safe, and readable YAML handling across TypeScript
 codebases. YAML is deceptively tricky—inconsistent quoting, serialization differences,

package/dist/docs/shortcuts/system/skill-baseline.md

@@ -130,7 +130,7 @@ working branch. See `tbd guidelines tbd-sync-troubleshooting` for details.
 
 | Command | Purpose |
 | --- | --- |
-| `tbd create "title" --type task\|bug\|feature --priority=P2` | New bead (P0-P4, not “high/medium/low”) |
+| `tbd create "title" --type=bug --priority=1` | New bead; run `tbd create --help` for all types and priorities (P0-P4, not “high/medium/low”) |
 | `tbd update <id> --status in_progress` | Claim work |
 | `tbd close <id> [--reason "..."]` | Mark complete |
 
@@ -168,6 +168,6 @@ working branch. See `tbd guidelines tbd-sync-troubleshooting` for details.
 ## Quick Reference
 
 - **Priority**: P0=critical, P1=high, P2=medium (default), P3=low, P4=backlog
-- **Types**: task, bug, feature, epic
+- **Types**: issues default to `task`; run `tbd create --help` for the valid types
 - **Status**: open, in_progress, closed
 - **JSON output**: Add `--json` to any command

package/dist/docs/tbd-design.md

@@ -235,23 +235,23 @@ on demand.
 
 tbd provides **three integrated capabilities**:
 
-1. **Task tracking (beads)** — Git-native issues, bugs, epics, and dependencies that
+1. **Task tracking (beads)**—Git-native issues, bugs, epics, and dependencies that
    persist across sessions.
    This alone is a step change in what agents can do.
-2. **Spec-driven planning** — Workflows for writing specs, breaking them into issues,
-   and implementing systematically.
-3. **Instant knowledge injection** — 17+ detailed guideline docs covering TypeScript,
-   Python, Convex, monorepo architecture, TDD, and more — injected into the agent’s
+2. **Spec-driven planning**—Workflows for writing specs, breaking them into issues, and
+   implementing systematically.
+3. **Instant knowledge injection**—17+ detailed guideline docs covering TypeScript,
+   Python, Convex, monorepo architecture, TDD, and more—injected into the agent’s
    context on demand via shortcuts, guidelines, and templates.
 
 The **issue tracking layer** has four core principles:
 
-- **Durable storage in git** — Issues are version-controlled and distributed via
-  standard git
-- **Works in almost any environment** — No daemon, no SQLite, no file locking issues on
+- **Durable storage in git**—Issues are version-controlled and distributed via standard
+  git
+- **Works in almost any environment**—No daemon, no SQLite, no file locking issues on
   network drives
-- **Simple, self-documenting CLI** — Designed for both AI agents and humans
-- **Transparent internal format** — Markdown/YAML files that are debuggable and friendly
+- **Simple, self-documenting CLI**—Designed for both AI agents and humans
+- **Transparent internal format**—Markdown/YAML files that are debuggable and friendly
   to other tooling
 
 It does *not* aim to be a full solution for real-time agent coordination.
@@ -291,17 +291,17 @@ layered on top of tbd or handled by other tools.
 
 **Related Projects:**
 
-- [Beads](https://github.com/steveyegge/beads) — The original git-backed issue tracker
-  tbd is designed to replace
-- [Agent Mail](https://github.com/Dicklesworthstone/mcp_agent_mail) — Real-time agent
+- [Beads](https://github.com/steveyegge/beads)—The original git-backed issue tracker tbd
+  is designed to replace
+- [Agent Mail](https://github.com/Dicklesworthstone/mcp_agent_mail)—Real-time agent
   messaging via MCP (complementary to tbd for coordination)
-- [Gas Town](https://github.com/steveyegge/gastown) — Multi-agent orchestration platform
+- [Gas Town](https://github.com/steveyegge/gastown)—Multi-agent orchestration platform
   (complementary to tbd for real-time coordination)
-- [ticket](https://github.com/wedow/ticket) — Bash-based Markdown+YAML tracker (~1900
+- [ticket](https://github.com/wedow/ticket)—Bash-based Markdown+YAML tracker (~1900
   tickets in production)
-- [git-bug](https://github.com/git-bug/git-bug) — Issues stored as git objects
-- [git-issue](https://github.com/dspinellis/git-issue) — Shell-based with optional
-  GitHub sync
+- [git-bug](https://github.com/git-bug/git-bug)—Issues stored as git objects
+- [git-issue](https://github.com/dspinellis/git-issue)—Shell-based with optional GitHub
+  sync
 
 ### 1.2 When to Use tbd vs Beads
 
@@ -790,10 +790,10 @@ $GIT_COMMON_DIR/tbd/
     └── meta.yml               # Metadata (schema version)
 ```
 
-> **Future: Simple Mode** — For users who don’t need multi-machine sync, tbd could
-> support a “simple mode” where `data-sync/` is committed directly to main instead of
-> using a worktree. This would be enabled by removing `data-sync` from `.tbd/.gitignore`.
-> Not implemented in V1, but the naming structure supports this future option.
+> **Future: Simple Mode**—For users who don’t need multi-machine sync, tbd could support
+> a “simple mode” where `data-sync/` is committed directly to main instead of using a
+> worktree. This would be enabled by removing `data-sync` from `.tbd/.gitignore`. Not
+> implemented in V1, but the naming structure supports this future option.
 
 **Why this structure?**
 
@@ -887,7 +887,7 @@ backups/
 > Both differ from `.tbd/data-sync/attic/` on the sync branch which stores merge
 > conflict losers.
 > 
-> **Note:** `workspaces/` must not be gitignored — it stores outbox data that must be
+> **Note:** `workspaces/` must not be gitignored—it stores outbox data that must be
 > committed to the working branch.
 
 #### .tbd/.gitattributes Contents
@@ -904,7 +904,7 @@ that directory.
 ```
 
 > **Why this is needed:** When a feature branch with outbox changes is merged back to
-> main (which has no outbox), git’s 3-way merge can delete `ids.yml` entirely — treating
+> main (which has no outbox), git’s 3-way merge can delete `ids.yml` entirely—treating
 > “no file” on main as the correct state.
 > This causes all tbd commands to crash with “No short ID mapping found”.
 > The `merge=union` built-in merge driver keeps all lines from both sides, preventing
@@ -1037,8 +1037,8 @@ async function checkWorktreeHealth(baseDir: string): Promise<{
 
 | Term | Path | Purpose |
 | --- | --- | --- |
-| **Worktree path** | `$GIT_COMMON_DIR/tbd/data-sync-worktree/.tbd/data-sync/` | **Production path** — inside hidden worktree checkout |
-| **Direct path** | `.tbd/data-sync/` | **Legacy fallback path** — gitignored on main, should NEVER contain data in production |
+| **Worktree path** | `$GIT_COMMON_DIR/tbd/data-sync-worktree/.tbd/data-sync/` | **Production path**—inside hidden worktree checkout |
+| **Direct path** | `.tbd/data-sync/` | **Legacy fallback path**—gitignored on main, should NEVER contain data in production |
 
 **Invariant:** In production, the worktree path is the ONLY correct path for issue data.
 The direct path exists ONLY for test fixtures that don’t use git.
@@ -1082,7 +1082,7 @@ async function resolveDataSyncDir(
 
 1. Production code MUST call `resolveDataSyncDir()` without `allowFallback`
 2. Only test code may use `allowFallback: true`
-3. If `.tbd/data-sync/issues/` contains data on main branch, this indicates a bug — data
+3. If `.tbd/data-sync/issues/` contains data on main branch, this indicates a bug—data
    was written to wrong location due to missing worktree
 
 #### Worktree Error Classes
@@ -1114,7 +1114,7 @@ export class SyncBranchError extends TbdError {
 Workspaces are directories under `.tbd/workspaces/` that store issue data for sync
 failure recovery, backups, and bulk editing workflows.
 
-> **Note:** `.tbd/workspaces/` must not be gitignored — outbox data must be committed to
+> **Note:** `.tbd/workspaces/` must not be gitignored—outbox data must be committed to
 > the working branch.
 
 #### Workspace Structure
@@ -2147,7 +2147,7 @@ SYNC(options):
 ```
 
 **Critical Invariant:** All operations in steps 1-6 MUST use the resolved `dataSyncDir`
-path consistently. Never read from or write to `.tbd/data-sync/` directly — always go
+path consistently. Never read from or write to `.tbd/data-sync/` directly—always go
 through the shared worktree at `$GIT_COMMON_DIR/tbd/data-sync-worktree/.tbd/data-sync/`.
 
 **Why most syncs are trivial (no merge needed):**
@@ -2374,8 +2374,8 @@ The CLI Layer provides a Beads-compatible command interface.
 
 All tbd commands require the repository to be initialized, except:
 
-- `tbd init` — Creates a new tbd repository
-- `tbd import --from-beads` — Can initialize and import in one step (auto-runs init if
+- `tbd init`—Creates a new tbd repository
+- `tbd import --from-beads`—Can initialize and import in one step (auto-runs init if
   needed)
 
 **Behavior when not initialized:**
@@ -2572,8 +2572,8 @@ Options:
 created/updated: newest first).
 The tiebreaker for issues with equal primary values is the internal ULID, which sorts
 lexicographically in chronological creation order.
-This ensures deterministic, stable ordering — issues created earlier always appear
-before issues created later within the same priority level.
+This ensures deterministic, stable ordering—issues created earlier always appear before
+issues created later within the same priority level.
 
 **Examples:**
 
@@ -3498,9 +3498,9 @@ This follows the same convention as `git`, `ls`, `grep`, and other Unix tools.
 The actor name (used for `created_by` and recorded in sync commits) is resolved in this
 order:
 
-1. `--actor <name>` CLI flag (highest priority) — *not yet implemented*
+1. `--actor <name>` CLI flag (highest priority)—*not yet implemented*
 
-2. `TBD_ACTOR` environment variable — *not yet implemented*
+2. `TBD_ACTOR` environment variable—*not yet implemented*
 
 3. Git user.email from git config
 
@@ -4571,8 +4571,8 @@ all environments including cloud sandboxes.
 
 Claude Code hooks are always installed to the **project-local** `.claude/` directory,
 adjacent to `.git/` and `.tbd/` at the git repository root.
-There is no global/user-level installation — this avoids confusion and ensures hooks
-work in any environment (local dev, Claude Code Cloud, etc.).
+There is no global/user-level installation—this avoids confusion and ensures hooks work
+in any environment (local dev, Claude Code Cloud, etc.).
 
 **A. JSON Settings Hooks** (installed to `.claude/settings.json` at project root)
 
@@ -4674,7 +4674,7 @@ Options:
 - `tbd list --status=in_progress` - Your active work
 - `tbd show <id>` - Detailed issue view with dependencies
 
-### Creating & Updating
+### Creating and Updating
 - `tbd create "title" --type=task|bug|feature --priority=P2` - New issue
   - Priority: P0-P4 (P0=critical, P2=medium, P4=backlog)
 - `tbd update <id> --status=in_progress` - Claim work
@@ -4682,12 +4682,12 @@ Options:
 - `tbd close <id>` - Mark complete
 - `tbd close <id> --reason "explanation"` - Close with reason
 
-### Dependencies & Blocking
+### Dependencies and Blocking
 - `tbd dep add <issue> <depends-on>` - Add dependency
 - `tbd blocked` - Show all blocked issues
 - `tbd show <id>` - See what's blocking/blocked by this issue
 
-### Sync & Collaboration
+### Sync and Collaboration
 - `tbd sync` - Sync with git remote (run at session end)
 - `tbd sync --status` - Check sync status without syncing
 

package/dist/docs/tbd-docs.md

@@ -30,7 +30,7 @@ Why a separate branch?
 - No conflicts across main or feature branches
 - Issues shared across all branches
 
-## File format
+## File Format
 
 You usually don’t need to worry about where issues are stored, but it may be comforting
 to know that internally it’s very simple and transparent.

package/dist/docs/tbd-prime.md

@@ -52,7 +52,7 @@ Every session must end with tbd in a clean state:
 - `tbd show <id>` - Detailed issue view with dependencies
   - Auto-displays parent context for child issues (use `--no-parent` to suppress)
 
-### Creating & Updating
+### Creating and Updating
 
 - `tbd create "title" --type task|bug|feature --priority 2` - New issue
   - Priority: 0-4 (0=critical, 2=medium, 4=backlog).
@@ -63,13 +63,13 @@ Every session must end with tbd in a clean state:
 - `tbd close <id> --reason "explanation"` - Close with reason
 - **Tip**: When creating multiple issues, use parallel subagents for efficiency
 
-### Dependencies & Blocking
+### Dependencies and Blocking
 
 - `tbd dep add <issue> <depends-on>` - Add dependency (issue depends on depends-on)
 - `tbd blocked` - Show all blocked issues
 - `tbd show <id>` - See what’s blocking/blocked by this issue
 
-### Sync & Collaboration
+### Sync and Collaboration
 
 - `tbd sync` - Sync with git remote (run at session end)
 - `tbd sync --status` - Check sync status without syncing

package/dist/{id-mapping-CtfTfGIh.mjs → id-mapping-687_UEsy.mjs}

@@ -1,10 +1,10 @@
 import { b as IdMappingYamlSchema } from "./schemas-f0EcuAVu.mjs";
 import { i as parseYamlToleratingDuplicateKeys, r as hasMergeConflictMarkers, s as stringifyYaml } from "./yaml-utils-BPy991by.mjs";
-import { mkdir, readFile, rmdir, stat } from "node:fs/promises";
+import { mkdir, readFile, rename, rmdir, stat } from "node:fs/promises";
 import { dirname, join } from "node:path";
 import { writeFile } from "atomically";
+import { randomBytes, randomUUID } from "node:crypto";
 import { monotonicFactory } from "ulid";
-import { randomBytes } from "node:crypto";
 
 //#region src/utils/lockfile.ts
 /**
@@ -36,10 +36,15 @@ import { randomBytes } from "node:crypto";
 *
 * 1. **Acquire**: `mkdir(lockDir)` — fails with EEXIST if held by another process
 * 2. **Hold**: Execute the critical section
-* 3. **Release**: `rmdir(lockDir)` — in a finally block
+* 3. **Release**: `rmdir(lockDir)` — in a finally block, with a bounded retry to
+*    absorb transient Windows failures (EBUSY/EPERM from AV scanners or lingering
+*    handles) that would otherwise orphan the lock directory.
 * 4. **Stale detection**: If lock mtime exceeds a threshold, assume the holder
-*    crashed and break the lock. This is a heuristic — safe when the critical
-*    section is short-lived (sub-second for file I/O).
+*    crashed and break the lock. Breaking is done **atomically** by renaming the
+*    stale directory aside (only one waiter can win the rename), so two waiters can
+*    never both break the same lock and end up running concurrently. This is a
+*    heuristic — safe when the critical section is short-lived (sub-second for
+*    file I/O).
 *
 * ## Failure on timeout
 *
@@ -87,6 +92,53 @@ var LockAcquisitionError = class extends Error {
 		this.name = "LockAcquisitionError";
 	}
 };
+/** Filesystem error codes that are transient on Windows and worth retrying. */
+const TRANSIENT_RMDIR_CODES = new Set([
+	"EBUSY",
+	"EPERM",
+	"EACCES",
+	"ENOTEMPTY"
+]);
+/**
+* Remove a lock directory, tolerating transient Windows failures.
+*
+* `rmdir` can intermittently fail with EBUSY/EPERM on Windows (antivirus scanners
+* or lingering directory handles). A few short retries make release reliable; if it
+* still fails, we give up and let stale detection reclaim the directory rather than
+* throwing from a best-effort cleanup path.
+*/
+async function removeLockDir(lockPath, attempts = 5) {
+	for (let attempt = 0; attempt < attempts; attempt++) try {
+		await rmdir(lockPath);
+		return;
+	} catch (error) {
+		const code = error.code;
+		if (code === "ENOENT") return;
+		if (attempt < attempts - 1 && code && TRANSIENT_RMDIR_CODES.has(code)) {
+			await new Promise((resolve) => setTimeout(resolve, 20 * (attempt + 1)));
+			continue;
+		}
+		return;
+	}
+}
+/**
+* Atomically break a stale lock.
+*
+* Renames the stale directory to a unique sidecar path and removes it. `rename` is
+* atomic, so when several waiters race to break the same stale lock only one wins the
+* rename; the losers see ENOENT and simply retry. This prevents the classic
+* non-atomic break race (rmdir + mkdir) where two waiters both break the lock and both
+* acquire it, defeating mutual exclusion.
+*/
+async function breakStaleLock(lockPath) {
+	const sidecar = `${lockPath}.stale-${randomUUID()}`;
+	try {
+		await rename(lockPath, sidecar);
+	} catch {
+		return;
+	}
+	await removeLockDir(sidecar);
+}
 /**
 * Execute `fn` while holding a lockfile.
 *
@@ -125,26 +177,24 @@ async function withLockfile(lockPath, fn, options) {
 		break;
 	} catch (error) {
 		if (error.code !== "EEXIST") throw error;
+		let lockStat;
 		try {
-			const lockStat = await stat(lockPath);
-			if (Date.now() - lockStat.mtimeMs > staleMs) {
-				try {
-					await rmdir(lockPath);
-				} catch {}
-				continue;
-			}
+			lockStat = await stat(lockPath);
 		} catch {
 			continue;
 		}
+		if (!lockStat.isDirectory()) throw new Error(`Lock path exists but is not a directory: ${lockPath}. Refusing to break it; remove the conflicting file and retry.`);
+		if (Date.now() - lockStat.mtimeMs > staleMs) {
+			await breakStaleLock(lockPath);
+			continue;
+		}
 		await new Promise((resolve) => setTimeout(resolve, pollMs));
 	}
 	if (!acquired) throw new LockAcquisitionError(lockPath, timeoutMs);
 	try {
 		return await fn();
 	} finally {
-		try {
-			await rmdir(lockPath);
-		} catch {}
+		await removeLockDir(lockPath);
 	}
 }
 
@@ -723,4 +773,4 @@ function resolveIdMappingConflicts(content) {
 
 //#endregion
 export { withLockfile as C, DATA_SYNC_LOCK_OPTIONS as S, formatDisplayId as _, hasShortId as a, normalizeIssueId as b, parseIdMappingFromYaml as c, resolveToInternalId as d, saveIdMapping as f, formatDebugId as g, extractUlidFromInternalId as h, generateUniqueShortId as i, reconcileMappings as l, extractShortId as m, calculateOptimalLength as n, loadIdMapping as o, extractPrefix as p, createShortIdMapping as r, mergeIdMappings as s, addIdMapping as t, resolveIdMappingConflicts as u, generateInternalId as v, validateIssueId as x, makeInternalId as y };
-//# sourceMappingURL=id-mapping-CtfTfGIh.mjs.map
+//# sourceMappingURL=id-mapping-687_UEsy.mjs.map