compile auto-discovery resolves source path relative to cwd instead of lock file dir (Windows)

[jamesadevine]

Summary

ado-aw compile (auto-discovery mode, no args) on Windows fails to find the source markdown file for a discovered lock file, reporting:

Warning: source 'agentic-failure-analysis.md' not found for azure-pipelines\templates\agentic-failure-analysis.yml, skipping

The source file does exist next to the lock file. The path appears to be resolved relative to the current working directory instead of the directory containing the lock file.

Environment

• ado-aw version: 0.30.1 (latest release at time of report)
• Binary: ado-aw-windows-x64.exe
• OS: Windows 11 (Windows_NT)
• Shell: PowerShell
• Repo layout: lock file and source markdown both live in azure-pipelines\templates\, invocation is from the repo root.

Reproduction

Repo layout (relevant files):

C:\software\exp23-yocto\
  azure-pipelines\
    templates\
      agentic-failure-analysis.md      <-- source
      agentic-failure-analysis.yml     <-- compiled lock file

Lock file header:

# This file is auto-generated by ado-aw. Do not edit manually.
# @ado-aw source="agentic-failure-analysis.md" version=0.28.0

Run from repo root:

PS C:\software\exp23-yocto> ado-aw -d compile
[INFO]  [ado_aw::compile] Auto-discovering agentic pipelines for recompilation
[INFO]  [ado_aw::detect] Scanning for agentic pipelines in: .
[DEBUG] [ado_aw::detect] Detected agentic pipeline: .\azure-pipelines\templates\agentic-failure-analysis.yml
[INFO]  [ado_aw::detect] Found 1 agentic pipeline(s)
Found 1 agentic pipeline(s):
  azure-pipelines\templates\agentic-failure-analysis.yml (source: agentic-failure-analysis.md, version: 0.30.1)
Done: 0 compiled, 1 skipped, 0 failed.
  Warning: source 'agentic-failure-analysis.md' not found for azure-pipelines\templates\agentic-failure-analysis.yml, skipping

The compiler discovers the lock file at .\azure-pipelines\templates\agentic-failure-analysis.yml correctly, but then tries to read the source as .\agentic-failure-analysis.md (relative to cwd) rather than .\azure-pipelines\templates\agentic-failure-analysis.md (relative to the lock file).

Workarounds (confirm the root cause)

Both of these succeed:

1. cd into the directory containing the lock file, then run discovery:

   PS C:\software\exp23-yocto\azure-pipelines\templates> ado-aw compile
   Generated stage template: .\agentic-failure-analysis.yml
   Done: 1 compiled, 0 skipped, 0 failed.
   

2. Pass the source markdown explicitly:

   PS C:\software\exp23-yocto> ado-aw compile azure-pipelines\templates\agentic-failure-analysis.md
   Generated stage template: azure-pipelines\templates\agentic-failure-analysis.lock.yml
   

   Note: this produces a *.lock.yml filename, but the original lock file at agentic-failure-analysis.yml (no .lock) is what discovery picks up. So a one-off explicit compile doesn't replace the file discovery would target — the user has to know to also delete or rename. This is a secondary inconsistency between the discovery output filename and the explicit-compile output filename.

Expected Behavior

When ado-aw compile auto-discovers a lock file, the embedded source=... reference (which is a bare filename) should be resolved relative to the directory containing the lock file, not relative to the process cwd.

Likely Fix Location

Wherever compile's recompile path opens the source markdown after auto-discovery — the source path should be joined to lockfile.parent_dir() before opening, e.g. lockfile_path.parent().join(source).

Notes

• Searched existing issues (open + closed) for windows source not found compile, source not found skipping — no matches.
• The same project compiles fine when run from the templates directory, confirming the lock file and source are correct.

Diagnostic Classification

Field	Value
Component	ado-aw CLI — compile (auto-discovery)
Stage	N/A (compile-time, not a pipeline run)
Platform	Windows
Severity	Medium — blocks recompile-all workflow on Windows when lock files are not in repo root
Confidence	High — reproduced with minimal repro, two independent workarounds confirm the path-resolution hypothesis
Known Pattern	No