Feature request

The # Workflow lock metadata block at the top of each generated *.lock.yml includes hashes only of the workflow's frontmatter, not of the ## Steps body. Edits to the agent prompt body that don't touch frontmatter can drift the body away from the compiled lock without any signal -- and without re-running gh aw compile --approve.

This is a meaningful gap because most prompt-engineering work happens in the body, not the frontmatter.

Concrete consequence

We hit this during R1 fixup work on prompt-hardening PRs. A .md body change was made; gh aw compile --approve was assumed to have run; nothing complained; the lock was actually stale; CI didn't catch it because nothing covers the body in the lock metadata.

Workaround we shipped (sidecar manifest)

We maintain .github/aw/md-body-hashes.txt, a sidecar file mapping each .github/workflows/*.md to a SHA256 of its body (frontmatter stripped). A small refresh script (scripts/refresh_md_hashes.sh) updates it. A CI lint asserts that the manifest matches the current bodies; mismatch means a body changed but the lock wasn't refreshed.

This works, but it's strictly a workaround. The right place for it is inside gh-aw's lock metadata.

Proposed shape

The generated lock metadata block already includes a frontmatter hash. Add a body hash alongside it:

# Workflow lock metadata
#   workflow: policy-dispatcher
#   frontmatter sha256: <existing>
#   body sha256: <new>

Then gh aw compile can detect body drift the same way it currently detects frontmatter drift.

Cross-reference

dfrysinger/policy-driven-agent-poc#139 (original signal), PR #151 (sidecar workaround landed).

Filed by

@dfrysinger via the policy-driven-agent-poc project.