# Dependency Lock Boundary Design

## Goal

Keep the dependency system reproducible where it matters, without forcing exact
version matching for tools that are normally owned by the system package
manager.

## Scope

This change narrows `deps.lock` to downloaded artifacts only.

In scope:

- `nvim`
- `ghostty`
- `yazi`
- `zoxide`
- `starship`
- `eza`
- `lazygit`

Out of scope for lock enforcement:

- `git`
- `make`
- `tmux`
- other system/bootstrap tools

`deps.toml` continues to describe the full dependency strategy for every tool.
Only the lock and the strict install/check behavior change.

## Behavior

### `deps.lock`

`deps.lock` records concrete artifact details only for downloaded tools.
System tools remain in `deps.toml`, but they do not produce lock entries and do
not need `version`, `checksum`, or `source_url` in the lock.

### `make deps`

`make deps` continues to ensure required tools exist.

For system tools:

- verify the command exists
- install or upgrade only through the configured system package path
- do not require exact lock matching

For downloaded tools:

- require the matching lock entry for the current platform and architecture
- verify version and checksum when the installer type supports them
- fail if the lock entry is missing or mismatched

### `make deps-check`

`make deps-check` mirrors the same boundary:

- system tools: check presence and report the installed version for visibility
- downloaded tools: require lock consistency

### `make doctor`

`make doctor` should remain pragmatic:

- system tools: report whether the command is available
- downloaded tools: report whether the command is available and the symlink
  layout is correct
- do not fail because a system tool does not match a lock version

## Rationale

This matches how the machine is actually used:

- `git`, `make`, and `tmux` are usually already present on a new machine
- their exact versions are controlled by the operating system or package
  manager, not by the dotfiles project
- enforcing lock equality on those tools would create avoidable failures without
  improving the setup

The lock should stay focused on the tools that are downloaded directly from an
upstream release or installer and therefore benefit from pinned artifacts and
checksums.

## Test Plan

- `make check`
- `make deps-check`
- `make doctor`
- one Linux container smoke test for the downloaded tools
- one macOS smoke test for the system-tool boundary behavior