Update daily report to 13.2 milestone burndown

[joperezr]

Summary

Refocuses the daily-repo-status agentic workflow to serve as a 13.2 release burndown report, helping the team track progress towards the 13.2 release.

Changes

Frontmatter

• Schedule: daily to daily around 9am
• Added discussions: read permission
• GitHub toolsets expanded to include discussions and search
• Added cache-memory tool for persistent day-over-day burndown data
• Added bash tool with safe commands for data formatting
• Issue prefix: [repo-status] to [13.2-burndown]
• Labels: [report, burndown]
• Enabled close-older-issues so only the latest report stays open

Report Content

The report now focuses on the 13.2 milestone with these sections:

1. Burndown Chart — Mermaid xychart rendered in the issue (accumulates over 7 days via cache-memory)
2. Milestone Progress — Open vs closed counts, percentage complete, net daily change
3. Issues Closed Today — Issues closed in the 13.2 milestone (last 24h)
4. New Bugs Found — New bug issues added to the 13.2 milestone
5. Notable Changes Merged — PRs merged to release/13.2 branch
6. PRs Awaiting Review — Open PRs targeting release/13.2 needing reviewer attention
7. Discussions — 13.2-related discussion activity
8. Triage Queue — Brief secondary section for un-milestoned issues

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 14563

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 14563"

[Copilot]

Pull request overview

Refocuses the existing daily-repo-status agentic workflow into a daily 13.2 milestone burndown report that tracks milestone progress and related repo activity, and persists 7-day history via cache-backed memory.

Changes:

• Updates the agent workflow prompt/content to report on the Aspire 13.2 milestone (burndown chart + progress, closures, new bugs, PR activity, discussions, triage).
• Expands GitHub tool access to include discussions and search, and introduces cache-memory + limited shell tooling for day-over-day snapshots.
• Regenerates the compiled .lock.yml workflow with newer gh-aw, adding the cache-memory restore/save plumbing and prompt artifact handling.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
.github/workflows/daily-repo-status.md	Rewrites the report spec to focus on 13.2 burndown, including cache-memory-backed 7-day chart and new report sections.
.github/workflows/daily-repo-status.lock.yml	Updates the generated workflow to support new toolsets and cache-memory persistence, and bumps gh-aw-generated wiring/version pins.

[Copilot]

Milestones can contain both issues and pull requests. The instructions here say to count “open issues” and “closed issues”, but without explicitly filtering is:issue (or stating that PRs should be included) the snapshot/burndown can be inconsistent depending on which API/query is used. Clarify whether to count issues only or all milestone items, and ensure the query/enumeration matches that choice.

Suggested change

	- Count the **total open issues** and **total closed issues** in the milestone.
	- Count the **total open issues** and **total closed issues** in the milestone, **excluding pull requests**. Use an issues-only filter (for example, a search query like `is:issue milestone:"13.2" state:open` / `state:closed`) so the counts are consistent across tools.

[Copilot]

The cache-memory snapshot is described as “append today’s data point”, but the expected on-disk format isn’t defined. Without a specified JSON/CSV schema (and guidance on trimming to last 7 points), the agent can end up writing incompatible formats across days and fail to parse/render the chart. Specify a concrete format (e.g., JSON array of {date, open, closed}) and how to handle duplicates for the same date.

Suggested change

	- Store today's snapshot (date, open count, closed count) using the **cache-memory** tool with the key `burndown-13.2-snapshot`. Append today's data point to any existing historical data so we accumulate day-over-day history.
	- Store today's snapshot (date, open count, closed count) using the **cache-memory** tool with the key `burndown-13.2-snapshot`.
	- The value for this key **must** be a JSON array of objects with the exact shape:<br>
	`[{ "date": "YYYY-MM-DD", "open": <number>, "closed": <number> }, ...]`
	- Use the repository's local date (no time component) formatted as `YYYY-MM-DD` for the `date` field.
	- When writing today's data:
	1. Read the existing cache value (if any) and parse it as JSON using the schema above. If the cache is empty or invalid, start from an empty array.
	2. If an entry for today's `date` already exists, **replace** that object's `open` and `closed` values instead of adding a duplicate.
	3. If no entry for today's `date` exists, append a new object for today's snapshot.
	4. Sort the array by `date` ascending and then trim it so it contains **only the most recent 7 entries**.
	5. Serialize the resulting array back to JSON and overwrite the cache value for `burndown-13.2-snapshot`.

[Copilot]

“Opened or added to the 13.2 milestone in the last 24 hours” is not directly representable via standard GitHub search qualifiers (you can query created:/updated: but not “milestone assigned in timeframe” specifically). As written, the workflow is likely to over/under-report ‘new issues added’. Consider limiting this to “issues opened in last 24h with milestone 13.2” or explicitly describing an approximation (e.g., milestone:13.2 updated:>=… plus checking timeline events when available).

Suggested change

	- Search for issues in this repository that were **opened or added to the 13.2 milestone in the last 24 hours**.
	- Search for issues in this repository that were **opened in the last 24 hours** and are assigned to the **13.2 milestone**.

[Copilot]

The cache key in this job uses env.GH_AW_WORKFLOW_ID_SANITIZED, but that env var is only defined in the agent job. In update_cache_memory it will be empty, so the saved cache key won’t match the restore key used earlier, and the burndown history won’t persist across runs. Define GH_AW_WORKFLOW_ID_SANITIZED at the workflow level or in this job (or inline the same literal) so save/restore use identical keys.

[Copilot]

update_cache_memory only runs when needs.detection.outputs.success == 'true'. If the detection job is skipped (e.g., no safe-outputs were produced) but cache-memory was still updated, the cache won’t be saved and the 7‑day history will reset. Consider allowing this job to run when needs.detection.result == 'skipped' as well, and only block on an explicit detection failure.

Suggested change

	if: always() && needs.detection.outputs.success == 'true'
	if: always() && (needs.detection.result == 'skipped' || needs.detection.outputs.success == 'true')

[github-actions]

🎬 CLI E2E Test Recordings

The following terminal recordings are available for commit 8b163b2:

Test	Recording
AgentCommands_AllHelpOutputs_AreCorrect	▶️ View Recording
AgentInitCommand_MigratesDeprecatedConfig	▶️ View Recording
Banner_DisplayedOnFirstRun	▶️ View Recording
Banner_DisplayedWithExplicitFlag	▶️ View Recording
CreateAndDeployToDockerCompose	▶️ View Recording
CreateAndDeployToDockerComposeInteractive	▶️ View Recording
CreateAndPublishToKubernetes	▶️ View Recording
CreateAndRunAspireStarterProject	▶️ View Recording
CreateAndRunAspireStarterProjectWithBundle	▶️ View Recording
CreateAndRunJsReactProject	▶️ View Recording
CreateAndRunPythonReactProject	▶️ View Recording
CreateEmptyAppHostProject	▶️ View Recording
CreateStartAndStopAspireProject	▶️ View Recording
CreateStartWaitAndStopAspireProject	▶️ View Recording
CreateTypeScriptAppHostWithViteApp	▶️ View Recording
DoctorCommand_DetectsDeprecatedAgentConfig	▶️ View Recording
DoctorCommand_WithSslCertDir_ShowsTrusted	▶️ View Recording
DoctorCommand_WithoutSslCertDir_ShowsPartiallyTrusted	▶️ View Recording
LogsCommandShowsResourceLogs	▶️ View Recording
PsCommandListsRunningAppHost	▶️ View Recording
ResourcesCommandShowsRunningResources	▶️ View Recording
StagingChannel_ConfigureAndVerifySettings_ThenSwitchChannels	▶️ View Recording

---

_{📹 Recordings uploaded automatically from CI run #22164566004}