test(daemon): add locking module tests (RED phase)

[galligan]

• 23 tests for locking functionality
• Tests acquireDaemonLock, releaseDaemonLock, isProcessAlive, isDaemonAlive
• 2 failing tests identify real bugs:
  • isProcessAlive doesn't validate negative PIDs
  • releaseDaemonLock clears instead of unlinking

Co-Authored-By: Claude Opus 4.5 noreply@anthropic.com

Contributes to #56

[galligan]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• chore(outfitter): sync templates on pack #108
• chore(changesets): ignore app package #107
• fix(errors): avoid TaggedError extends warnings #106
• chore(release): align package versions to 0.1.0 #105
• docs: add README and CHANGELOG for testing, kit, outfitter #95
• feat(templates): add daemon project template #94
• feat(templates): add MCP server project template #93
• feat(templates): add CLI project template #92
• fix(cli): implement confirmDestructive prompts #104
• fix(cli): implement createCLI and command builder #103
• feat(kit): add @outfitter/kit meta-package #91
• docs(daemon): add README and CHANGELOG #90
• fix(daemon): fix locking module bugs (GREEN phase) #89
• test(daemon): add locking module tests (RED phase) #88 👈 (View in Graphite)
• feat(daemon): add errors, platform, and locking module stubs #87
• feat(outfitter): add doctor command for environment validation #86
• feat(outfitter): add init command with project scaffolding #85
• feat(daemon): add IPC communication and health checks #84
• feat(daemon): add types and lifecycle management #83
• feat(index): add FTS5 full-text search implementation #82
• feat(index): add types for FTS5 full-text search #81
• feat(testing): add MCP and CLI test harnesses #80
• feat(testing): add test fixture utilities #79
• feat(mcp): add MCP server implementation with typed handlers #78
• feat(mcp): add types and interfaces for MCP server #77
• feat(ui): add Shape discriminated union and render() #76
• feat(ui): add createTokens semantic color layer #75
• feat(state): add pagination helpers #74
• feat(logging): add DEFAULT_PATTERNS for common secret redaction #73
• feat(ui): add formatRelative() for human-readable timestamps #72
• feat(state): add encodeCursor/decodeCursor for pagination #71
• feat(types): add hashId() for deterministic short identifiers #70
• feat(contracts): add Logger.child() and fix AssertionError category #69
• feat(config): centralize environment variable access with Zod validation #42
• fix(logging): enable redaction by default when global rules exist #41
• docs(ui): add README, CHANGELOG, and TSDoc comments #39
• docs(state): add README, CHANGELOG, and TSDoc comments #38
• docs(file-ops): add README, CHANGELOG, and TSDoc comments #37
• docs(logging): add README, CHANGELOG, and TSDoc comments #36
• docs(config): add README, CHANGELOG, and TSDoc comments #35
• fix(cli): enforce cursor TTL #114
• fix(tests): remove placeholder tests #113
• chore(gitattributes): prefer ours for bun lockfiles #115
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Greptile Summary

• Implements comprehensive test suite for daemon locking module with 23 tests covering process liveness, lock acquisition/release, and stale lock handling
• Follows strict TDD RED phase approach by writing failing tests first to document expected behavior before implementation
• Tests intentionally identify 2 real implementation bugs: negative PID validation and improper lock file deletion

Important Files Changed

Filename	Overview
packages/daemon/src/tests/locking.test.ts	New comprehensive test suite for daemon locking functionality; includes 2 intentionally failing tests to document bugs

Confidence score: 4/5

• This PR is safe to merge as it only adds tests without modifying production code
• Score reflects high-quality TDD approach with comprehensive test coverage, though intentional failing tests lower confidence slightly
• Pay close attention to the test file to understand documented bugs that need fixing in implementation

Sequence Diagram

sequenceDiagram
    participant User
    participant Test as "Test Suite"
    participant Locking as "Locking Module"
    participant FS as "File System"
    participant OS as "Operating System"

    User->>Test: "Run locking tests"
    Test->>Locking: "isProcessAlive(alivePid)"
    Locking->>OS: "Check process exists"
    OS-->>Locking: "Process exists"
    Locking-->>Test: "true"

    Test->>Locking: "isProcessAlive(deadPid)"
    Locking->>OS: "Check process exists"
    OS-->>Locking: "Process not found"
    Locking-->>Test: "false"

    Test->>FS: "Create lock file with PID"
    FS-->>Test: "Lock file created"
    Test->>Locking: "isDaemonAlive(lockPath)"
    Locking->>FS: "Read lock file"
    FS-->>Locking: "PID content"
    Locking->>OS: "Check PID alive"
    OS-->>Locking: "Process status"
    Locking-->>Test: "true/false"

    Test->>Locking: "acquireDaemonLock(lockPath)"
    Locking->>FS: "Check lock file exists"
    FS-->>Locking: "File not found"
    Locking->>FS: "Write PID to lock file"
    FS-->>Locking: "Lock file written"
    Locking-->>Test: "LockHandle"

    Test->>Locking: "releaseDaemonLock(handle)"
    Locking->>FS: "Read current lock PID"
    FS-->>Locking: "Lock PID"
    Locking->>Locking: "Verify PID matches handle"
    Locking->>FS: "Delete lock file"
    FS-->>Locking: "File deleted"
    Locking-->>Test: "Lock released"

    Test->>Locking: "readLockPid(lockPath)"
    Locking->>FS: "Read lock file content"
    FS-->>Locking: "PID string"
    Locking->>Locking: "Parse PID number"
    Locking-->>Test: "PID number"

Loading

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

style: Consider using a more reliable method to get a guaranteed non-existent PID. High PIDs might still exist on some systems

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/daemon/src/__tests__/locking.test.ts
Line: 54:58

Comment:
**style:** Consider using a more reliable method to get a guaranteed non-existent PID. High PIDs might still exist on some systems

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

How can I resolve this? If you propose a fix, please make it concise.

[galligan]

Restacked and re-submitted this RED-phase test PR. Pre-push hook skipped tests as expected for RED phase.

[galligan]

Tweaked locking tests to derive a dead PID via ESRCH scan instead of hardcoding a high PID.

[galligan]

Restacked after downstack update (formatRelative test stabilization); no additional changes in this PR.

[galligan]

Greptile note: getDeadPid already probes for an ESRCH candidate (scan loop) instead of assuming a high PID, so we should be safe here. Restacked and resubmitted.