gh aw list: 'Compiled: No' false positive after git checkout due to mtime comparison

[yskopets]

Problem

gh aw list reports Compiled: No for all workflows immediately after a fresh git clone or git checkout, even when the .lock.yml files are fully up-to-date and match their .md sources.

Root Cause

The compiled status check in pkg/cli/list_workflows_command.go compares file modification times:

if mdStat.ModTime().After(lockStat.ModTime()) {
    compiled = "No"   // .md is newer than .lock.yml
} else {
    compiled = "Yes"
}

When git checks out files, it writes them in internal order. Because .lock.yml sorts before .md alphabetically, git writes the lock file first and the markdown file a few hundred nanoseconds later. On filesystems with nanosecond-precision timestamps (e.g., macOS APFS, Linux ext4), this makes every .md appear newer than its corresponding .lock.yml, triggering Compiled: No for every workflow — even though the content is perfectly in sync.

This also affects git worktrees, where the same checkout ordering occurs.

Reproduction

git clone <repo-with-compiled-workflows>
cd <repo>
gh aw list
# All workflows show Compiled: No

Expected Behavior

gh aw list should report Compiled: Yes for workflows whose .lock.yml content is genuinely up-to-date with their .md source, regardless of file timestamps.

Suggested Fix

Replace the mtime comparison with a content-based check — for example, compare a hash of the relevant .md content against a hash stored in the .lock.yml frontmatter (if one already exists), or regenerate the expected lock content in memory and compare it byte-for-byte against the file on disk.

A simpler short-term workaround that preserves the current approach: check if mtime difference is below a small threshold (e.g., 1 ms) and treat it as "compiled", since real edits will differ by much more. But a content-based check is more robust.

Workaround

Users can touch the lock files after checkout to reset mtimes:

touch .github/workflows/*.lock.yml

---

🤖 Analyzed and reported by Claude Code

[pelikhan]

@copilot use front matter hash check