[aw] Expert Code Review (on open) has stale lock file

### Workflow Failure

**Workflow:** [Expert Code Review (on open)](https://github.com/dotnet/msbuild/blob/main/.github/workflows/review-on-open.agent.md)
**Branch:** vplita-add-taskenv-get-tmp-path
**Run:** https://github.com/dotnet/msbuild/actions/runs/34138116988
**Pull Request:** [#14729](https://github.com/dotnet/msbuild/pull/14729)

> [!WARNING]
> **Lock File Out of Sync**: The workflow could not start because its compiled lock file no longer matches the source markdown.

This means the workflow's `.md` file was edited but `gh aw compile` was not run afterwards to regenerate the corresponding `.lock.yml` file. The agent is prevented from running against a stale configuration to avoid unexpected behaviour.

**To fix**, recompile the workflow:

```bash
gh aw compile
```

Then commit and push the updated `.lock.yml` file.

More ways to recompile

**Using the gh-aw MCP server** (if configured):

```json
{ "tool": "compile", "arguments": { "validate": true } }
```

**Recompile all workflows at once:**

```bash
gh aw compile --all
```

**Verify the result:**

```bash
gh aw compile --validate
```

How to investigate the mismatch

The workflow run logs contain a verbose debug pass that shows exactly what was hashed. Search the **Check workflow lock file** step logs for lines starting with `[hash-debug]` to see:

- The raw frontmatter text that was used as input
- Any imported files that were included in the hash
- The canonical JSON that was fed to SHA-256
- The resulting hash value

This makes it easy to spot accidental whitespace changes, encoding differences, or import path drift.

This mismatch can also happen on a **fresh install** (even without any manual edits) if `gh aw add @` could not resolve the ref to an exact commit SHA during installation. In that case, rerun the add command with an exact SHA (or retry when API/rate-limit conditions recover), then recompile:

```bash
gh aw add @
gh aw compile
```

How to disable this check

> [!CAUTION]
> Disabling this check means the agent can run against an out-of-date compiled workflow. Only disable it if you have an alternative mechanism to keep lock files in sync.

Set `stale-check: false` in the `on:` section of your workflow frontmatter:

```yaml
on:
issues:
types: [opened]
stale-check: false
```

After editing, recompile the workflow: `gh aw compile`

### Action Required

**Assign this issue to an agent** to debug and fix the issue.

Debug with any coding agent

Use this prompt with any coding agent (GitHub Copilot, Claude, Gemini, etc.):

````
Debug the agentic workflow failure using https://raw.githubusercontent.com/github/gh-aw/main/debug.md

The failed workflow run is at https://github.com/dotnet/msbuild/actions/runs/34138116988
````

Manually invoke the agent

Debug this workflow failure using your favorite Agent CLI and the `agentic-workflows` prompt.

- Start your agent
- Load the `agentic-workflows` skill from `.github/skills/agentic-workflows/SKILL.md` or
- Type `debug the agentic workflow review-on-open.agent failure in https://github.com/dotnet/msbuild/actions/runs/34138116988`

> [!TIP]
>
> Stop reporting this workflow as a failure
>
> To stop a workflow from creating failure issues, set `report-failure-as-issue: false` in its frontmatter:
> ```yaml
> safe-outputs:
> report-failure-as-issue: false
> ```
>
>

> Generated from [Expert Code Review (on open)](https://github.com/dotnet/msbuild/actions/runs/34138116988) · [◷](https://github.com/search?q=repo%3Adotnet%2Fmsbuild+is%3Aissue+%22gh-aw-workflow-id%3A+review-on-open.agent%22&type=issues)

Start with .github/workflows/review-on-open.agent.md and its corresponding .lock.yml file. Run gh aw compile --validate, inspect the Check workflow lock file step and any [hash-debug] output if needed, and confirm the workflow source and compiled lock file are synchronized.

Written by the indexing model from the issue text.