[BUG] Can no longer depend on other skills etc in the same repo

[OskarKlintrot]

Describe the bug

I think that when #857 got fixed it broke referencing other skills as dependency (at least on ADO). I did the same as #857 (comment) (see Additional context down below).

To Reproduce
Steps to reproduce the behavior:

1. Reference a package or skill (instructions seems to work) in apm.yaml as a dependency
2. Run apm install

Expected behavior
Same as with 0.10.0, it just works.

Environment (please complete the following information):

• Windows 11
• APM Version: 0.12.1

Logs

> apm install dev.azure.com/<org>/tools/github-copilot-agent-skills/packages/<project>
[*] Created apm.yml
[*] Validating 1 package...
[+] dev.azure.com/<org>/tools/github-copilot-agent-skills/packages/<project>
[*] Updated apm.yml with 1 new package(s)
[>] Installing 1 new package...
[>] Resolving github-copilot-agent-skills-<project>...
[>] Resolving github-copilot-agent-skills-csharp...
[>] Resolving github-copilot-agent-skills-testing...
[>] Resolving github-copilot-agent-skills-run-coverage...
  [+] dev.azure.com/<org>/tools/github-copilot-agent-skills/packages/<project> @0a3ba4ab
  |-- (files unchanged)
  [+] dev.azure.com/<org>/tools/github-copilot-agent-skills/.apm/instructions/testing.instructions.md
  |-- 1 instruction(s) integrated -> .github/instructions/
[i] Trusting direct dependency MCP 'NuGet' from '<project>-skills'
+- MCP Servers (3)
|  + NuGet (already configured)
+- All servers up to date
  [!] 2 dependencies unpinned: <org>/tools/github-copilot-agent-skills -- add #tag or #sha to prevent drift
  [x] 2 packages failed:
    +- github-copilot-agent-skills-run-coverage -- Failed to resolve transitive dep <org>/tools/github-copilot-agent-skills (via github-copilot-agent-skills-<project> > github-copilot-agent-skills-run-coverage): Subdirectory
'.apm/skills/run-coverage' not found in repository
    +- github-copilot-agent-skills-csharp -- Failed to resolve transitive dep <org>/tools/github-copilot-agent-skills (via github-copilot-agent-skills-<project> > github-copilot-agent-skills-csharp): Subdirectory 'packages/csharp' not found
in repository
[!] Installed 2 APM dependencies in 13.0s with 2 error(s).

Additional context
apm.yml:

name: <project>-skills
version: 1.0.0
description: '<Project> skills and agent for GitHub Copilot.'
author: Oskar Klintrot
target: vscode
dependencies:
  apm:
  - dev.azure.com/<org>/tools/github-copilot-agent-skills/packages/csharp
  - dev.azure.com/<org>/tools/github-copilot-agent-skills/.apm/skills/run-coverage
  - dev.azure.com/<org>/tools/github-copilot-agent-skills/.apm/instructions/testing.instructions.md
  mcp:
  - name: NuGet
    registry: false
    transport: stdio
    command: dnx
    args:
    - NuGet.Mcp.Server
    - --source
    - https://api.nuget.org/v3/index.json
    - --yes

[OskarKlintrot]

This might be a duplicate of #1126. If I do a clean install with apm install a few times after (rm -Force -Recurse .\apm.yml, .\apm_modules\, .\apm.lock.yaml, .\.github\; apm install dev.azure.com/<org>/tools/github-copilot-agent-skills/packages/<project>; apm install) it seems to work eventually.

[danielmeppiel]

Thanks for the detailed report (and the workaround note in your follow-up).

This is a duplicate of #1126 (parallel sparse-checkout race in SharedCloneCache), not a regression from the #857 fix:

• The error wording Subdirectory '<sub>' not found in repository is exactly what [BUG] Parallel sparse-checkout race condition when two subdirectory deps reference the same repository #1126 raises when two deps from the same repo+ref race through the in-install clone cache and the second consumer finds the working tree configured for the first one's subdir.
• Your "running apm install a few times eventually works" matches [BUG] Parallel sparse-checkout race condition when two subdirectory deps reference the same repository #1126's second-run-wins behavior — the bare clone gets cached, so the next run skips the racy materialization step.
• The Local relative paths in transitive deps resolve against root consumer instead of declaring package #857 fix (PR fix(install): anchor transitive local_path deps on declaring package (#857) #1111) only changed local_path resolution semantics; your deps are all remote ADO sub-path URLs, so they don't touch that code path.

The fix already landed on main in PR #1135 (commit 2753f72) — SharedCloneCache now stores subdir-agnostic bare clones and each consumer materializes its own working tree, so two parallel sub-path deps from the same repo+ref no longer race. The PR also added an ADO bearer-401 retry on the bare clone path, so this covers your ADO scenario, not just GitHub.

Closing as duplicate of #1126. The fix will ship in v0.12.2 (release PR open). Until then, the two-runs-from-clean workaround you found is the right call.