fix: eliminate cache-memory dependency in update-instructions workflow

[vhvb1989]

Summary

Fixes #8702

Replace the cache-memory tool with a GitHub API query for the last successful workflow run in the update-instructions-from-pr-reviews agentic workflow.

Problem

On first run, last-run.txt didn't exist in cache. The agent correctly called missing_data with cache_memory_miss (as instructed by the cache-memory system), but gh-aw's detection layer interpreted this as a prompt misconfiguration rather than a legitimate first-run condition.

Fix

Eliminate the cache entirely. Instead of reading/writing last-run.txt in cache-memory, the agent now queries the GitHub API for the most recent successful run of this workflow to determine the PR range starting point.

Changes

• Removed cache-memory: tool from the workflow frontmatter
• Rewrote Step 1 fallback to query the last successful workflow run via GitHub API
• Removed Step 8 ("Record the run") — no cache to write to; the workflow run history IS the state
• Added actions: read permission so the agent can list workflow runs

Why not just fix the prompt?

The cache-memory approach is inherently fragile for a weekly workflow:

• GitHub Actions cache has a 7-day unused-entry eviction policy
• A weekly Monday schedule sits right at the eviction edge — a skipped week means cache loss and redundant 6-month mining every time
• The GitHub API workflow run history is always available and is the natural source of truth

Per richardpark-msft's comment: "If you can get it to just query that detail directly you can eliminate a dependency on that cache altogether."

[Copilot]

Pull request overview

This PR updates the Update Instructions From PR Reviews agentic workflow definition to remove reliance on cache-memory and instead derive the “since last run” starting point from GitHub Actions workflow run history.

Changes:

• Removes the cache-memory tool dependency and the “record the run” step (state now lives in workflow run history).
• Adds actions: read permission and updates the range-determination logic to use the last successful run timestamp.

[github-actions]

📋 Prioritization Note

Thanks for the contribution! The linked issue isn't in the current milestone yet.
Thank you for logging this issue; our team is reviewing it. If you need urgent prioritization, tag @RickWinter and @kristenwomack to let us know.

[jongio]

Clean fix. Replacing the cache-memory tool with a workflow-run-history query is the right call: you eliminate a 7-day eviction hazard and gain a source of truth that's always available. The fallback chain (explicit date > last successful run timestamp > 6-month cap) handles the edge cases well.

Two quick notes:

1. Lock file: the .lock.yml wasn't regenerated in this branch (same SHA as main). You'll need a gh aw compile pass before merge so the runtime picks up the new logic.

2. Bot comment on workflow name is a false positive: the instruction says "list recent workflow runs for this workflow (Update Instructions From PR Reviews)" and the lock.yml's name: field is exactly that string, so the agent will resolve it correctly.

Good to go once the lock file is refreshed.

[RickWinter]

This replaces the cache-memory high-water mark with a query against the workflow's own successful-run history, which is the right direction and drops a fragile weekly-eviction dependency. The one thing blocking it is that the new step 2 relies on listing workflow runs, and the github tool only enables the pull_requests, issues, and repos toolsets. Listing workflow runs lives in the actions toolset, so the added actions: read permission has no tool to drive it, and step 2 will silently fall through to the 6 month scan (step 3) on every run, which is the exact redundant mining this PR is trying to remove. Enabling the actions toolset on the github: tool should close that gap. The updated_at of the last successful run is a reasonable starting point; there is a small window where PRs merged while the previous run was executing could be reprocessed, but for a weekly instruction-mining job that is harmless. Please address the toolset before merge.

[RickWinter]

This step now depends on listing workflow runs, but the github tool above only enables toolsets: [pull_requests, issues, repos]. The workflow-run listing lives in the github MCP actions toolset, which is not turned on here, so granting actions: read at the permissions level is not enough on its own. As written the agent has no tool to satisfy step 2 and will fall through to the 6 month scan in step 3 on every run, which is the redundant mining this PR is trying to avoid. Can we add actions to the toolsets list on the github: tool so the run-history query actually has a tool backing it?

[jongio]

Two things need fixing:

1. Missing actions toolset: toolsets: [pull_requests, issues, repos] doesn't include actions. The workflow-run listing API lives in that toolset, so step 2 will silently fail and the agent will always fall through to the 6-month scan. Add actions to the array.

2. Lock file stale: The .lock.yml still reflects old cache-memory logic. Run gh aw compile to regenerate.