fix(pyproject): track uv.lock relative to target workdir

[nguyeda]

Current Behavior

The pyproject autodiscovery crawler generates a broken shell target for any pyproject.toml discovered in a subdirectory. The generated target sets:

• workdir: <subdir> — the uv lock command runs here and succeeds, and
• a changedif (file/checksum) tracking <subdir>/uv.lock.

Because the shell resource resolves changedif files relative to workdir, the path doubles (e.g. foo/bar/foo/bar/uv.lock). That path doesn't exist, so the post-command file check reports Missing files and the target fails — even though uv lock succeeded. Projects at the scan root are unaffected because workdir is ..

Fix

Record the lockfile path relative to the target's own workdir (just uv.lock) instead of joining workdir into it. The workdir is already emitted into the target, and the shell resource prepends it, so joining it twice was the bug. This also matches how sibling crawlers (golang, npm, cargo) reference their lock files as plain literals.

-	relLockFile := filepath.Join(workdir, "uv.lock")
-	...
-		LockFile:                   relLockFile,
+		LockFile:                   "uv.lock",

Tests

Added a regression scenario (Scenario 12) using a nested subdirectory project (testdata/subdir_project/foo/bar) to prove the fix holds at arbitrary depth. With the bug present this scenario fails (files: - "foo/bar/uv.lock"); with the fix it passes (files: - "uv.lock", workdir: 'foo/bar'). Existing scan-root scenarios are unchanged.

Verified end-to-end against a real subdirectory project: updatecli apply runs uv lock in the subdir and rewrites <subdir>/uv.lock correctly, with no <subdir>/<subdir>/ ever created.

Fixes #9265

🤖 Generated with Claude Code

[loispostula]

thanks @nguyeda for your first contribution!

Lgtm

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request