📈 CI Daily Pulse

[radical]

🔴 GH CI main red at the tip — flaky VS Code E2E suite (0/13) · 🟡 outerloop 0% (lone run ~22h) · ⚪ internal 38% (green at tip) · 🔀 PR 53% (red at tip, bot-absorbed) · 🟢 release green — 1 item for a dev

🔴 For a dev — rolling main CI is red on all 13 runs; the VS Code extension E2E suite is chronically flaky and rolling has no auto-rerun

What: All 13 in-window main runs fail, but the cause is intermittent, not deterministic. The VS Code extension E2E suite flakes in 12 of the 13 runs, with the offending shard rotating run-to-run. The edge-cases (Windows) shard drove the first ~9 runs (the "shows debugger install guidance" test times out after 60s waiting for the Python-debugger CodeLens — commandTitles: []) but has been quiet ~10h (passed the last 4 runs); since then each run fails on a different shard (workspace-target-proof / apphost-lifecycle-tools / azure-functions E2E timeouts). No single revert clears it, and rolling main has no auto-rerun, so it stays red until a clean push — a dev has to stabilize the flaky suite.
Do: a dev should stabilize the VS Code extension E2E suite — the edge-cases install-hint CodeLens break (run, extension/src/test-e2e/edgeCases.e2e.test.ts:162) plus the workspace-target-proof / apphost-lifecycle-tools / azure-functions shard timeouts (run). The very latest red is a one-off NuGet-restore drop, not the suite: tip run.
_{Secondary LIVE signals: an Azure.Npgsql (Windows) host hang on one run (hang dump — test timed out, infra-looking); the tip's red is a transient NuGet dotnet tool restore drop that clears on a clean push. Everything else red = noise / quiet — see § 🧩 below.}

_{Window: Tue Aug 25 12:43 → Thu Aug 27 00:43 UTC (last 36h) · Δ = 36h rate vs the same lane's 7-day average · Aug 27, 2026.}

📊 Last 36h by lane — activity, pass rate & Δ vs 7d

Lane	36h activity	36h pass rate (Δ vs 7d)	Latest build
🌳 GH CI — main	🟥🟥🟥🟥🟥🟥🟥	🔴 0% (0/13) · ▼ 23.2	🔴 Aug 26 20:09
🧪 GH CI outerloop — main	🟥🟥	🔴 0% (0/1, 95% CI 0–79%) · ▼ 85.7	🔴 Aug 26 02:29
🏗️ Internal (AzDO) — main	🟩🟩🟥🟥🟥🟥	🔴 38% (3/8, 95% CI 14–69%) · ▼ 26.1	🟢 Aug 26 20:16
🏗️ Internal (AzDO) — release/13.5	🟩🟩	🟢 100% (1/1, 95% CI 21–100%) · ▲ 14.3	🟢 Aug 25 19:31
🔀 GH CI — PR validation ⭐	🟩🟩🟩🟩🟩🟩🟥🟥🟥🟥🟥🟥	🔴 53% (51/96) · ▼ 12.1	🔴 Aug 27 00:06

🧱 Mostly flaky-test + infra, not a confirmed live code regression: the rolling-main red is intermittent VS Code E2E-shard flakiness (12/13 runs, offending shard rotates), a now-quiet installer-prep cluster, an Azure.Npgsql host hang, and a transient NuGet-restore network drop at the tip — but with no auto-rerun on rolling it stays red until a clean push. Internal AzDO (🏗️) had a rough mid-window patch (5 failed) but is partiallySucceeded (green) at the tip; failures are counts-only; latest failed internal build in window: 3057549 (~24h ago).

_{bar length = sample size / confidence (short = read its % with care) · Δ vs 7d = 36h rate minus the lane's 7-day average · Latest build = red/green of the lane's most recent in-window run, linked to it · lane names link to the workflow / pipeline. GH CI release/13.5 push had no runs in the window (row omitted). The internal AzDO link 401s for non-members (expected).}

🧩 What's broken & why

One thing needs a human: rolling main is kept red run-after-run by a chronically flaky VS Code extension E2E suite — rolling has no auto-rerun, so no bot will clear it. Everything else is flaky noise the rerun bot is absorbing on PRs, a lone outerloop run, or yesterday's fires already gone quiet.

	What's broken	Who's on it	Since
🔴	GH CI main red on all 13 runs — the VS Code extension E2E suite flakes in 12/13, a different shard most runs; the edge-cases install-hint test led early, now other shards time out. No single revert clears it. run	Needs a dev to triage — no auto-rerun on rolling	red all window (36h), still red at tip
🟡	PR validation flaky — about half the PR runs go red before the bot reruns them; same E2E flakiness plus assorted test flake. runs	Rerun bot is absorbing these (PR-only)	ongoing, red at tip
🟡	Outerloop — one scheduled run failed on the Dashboard tests (both OSes); lone run, outerloop self-reruns. run	Watch — one run, too early to call	~22h ago
⚪	Internal AzDO main — rough mid-window patch (5 failed builds), now green at the tip. build	Looks recovered — green at tip	last failed ~24h ago

🧱 Product vs infra: the load-bearing driver is a flaky VS Code E2E test suite (product/test-side, no auto-rerun on rolling) — not a confirmed deterministic code regression; the tip red is a transient NuGet dotnet tool restore drop and an early installer-prep cluster that has since gone quiet. Internal AzDO is green at the tip; latest failed internal build 3057549 (~24h ago).

exact tests, jobs & counts

🔴 GH CI main — VS Code extension E2E suite (12 of 13 in-window runs), offending shard rotates:

• edge-cases (Windows) shard — test shows debugger install guidance while the Aspire panel and AppHost source are closed (extension/src/test-e2e/edgeCases.e2e.test.ts:162, DebuggerInstallHintApp): 5 passing, 1 failing — Error: Timed out after 60000ms waiting for the Python debugger CodeLens. Last provider result: … "commandTitles":[]. Failed 9 consecutive runs Aug 25 15:11 → Aug 26 14:12 (32864200821 … 32978808010); quiet since (~10h, passed last 4 runs).
• Later runs rotate shard, one per run: workspace-target-proof (Linux) 32994724407; apphost-lifecycle-tools (Windows) + azure-functions (Linux) 32997866203; azure-functions (Linux) 32999137654 — all E2E timeouts.
• Tip run 33008969799 (Aug 26 20:09): NOT the E2E suite — Tests / Hosting.Browsers (windows-latest) Build test project failed on error MSB3073: … dotnet.exe tool restore … exited with code 1 (transient NuGet restore drop, clears on clean push).
• Now-quiet early cluster (runs Aug 25 15:11 → 20:55 only): Prepare Homebrew installer artifacts / Prepare Homebrew cask + Prepare WinGet installer artifacts / Prepare WinGet manifests.
• One-off job failures across the window: Dashboard (windows-latest) / Dashboard (ubuntu-latest), Hosting-1 (windows-latest), Azure.Npgsql (windows-latest) (host hang, hang-dump — test timed out).

🟡 Outerloop: scheduled run 32922923673 (Aug 26 02:29) — outerloop_tests / Dashboard (ubuntu-latest) + Dashboard (windows-latest). Only 1 scheduled run in window (0/1).

⚪ Internal AzDO main (counts only): 8 completed builds in window — 3 partiallySucceeded (green), 5 failed. Failed build IDs 3057169, 3057283, 3057353, 3057434, 3057549 (last, Aug 26 01:11 — ~24h ago); green at tip 3058236 (Aug 26 20:16).

_{Attention dots (action priority, distinct from the lane table's 🔴/🟢 run-outcome dots): 🔴 needs a human now · 🟡 keep an eye on it · ⚪ looks resolved.}

🔁 Reruns & flaky tax

The auto-rerun bot carries the vast majority of the rerun load (169 reruns rescuing 30 PRs red→green), with a little human toil on top (20 manual reruns) — that bot volume is the flaky tax the broken/flaky VS Code E2E suite is imposing on PRs. (Auto-rerun is PR-only — rolling main gets none, which is why it stays red above.)

rerun actor split (last 36h, PR lane)

• 🤖 Auto-rerun bot: 169 reruns across 81 PR runs → 30 rescued red→green; 39 still red, 12 cancelled.
• 🧑 Manual (human) reruns: 20 reruns across 5 PR runs (3 branches the bot also reran) → on the 1 human-only branches: 0 rescued, 1 still red, 0 cancelled.
• 🔗 Combined: 86 distinct PR runs needed a rerun in the window (30 went green, 43 still red, 13 cancelled); 3 PR branches needed both bot + human.

_{Sources: gh api …/ci.yml/runs (pass rates + rerun split) · az pipelines build list def 1602 (internal, counts only). ciinsights unavailable this run — cluster detail derived directly from GH failed-job logs (see footer). Window = last 36h. Backlog & trend: see the weekly CI Health report (#18231). Generated Aug 27, 2026 00:43 UTC.}

[joperezr]

🤖 Aspire triage pass — 2026-06-16 06:54 UTC

Area: �rea-engineering-systems
Kind: docs (informational CI health report — [pipeline trial] per title)
Repro: n/a — this is a generated dashboard, not a bug report
Affected version(s): n/a (CI health snapshot, window: last 36h ending 2026-06-16)
Severity: S4 — informational; no product regression. Body flags real CI breakage (SqlServer conformance cluster, outerloop on main red 7+ days), but those are tracked as separate test-failure issues.

Urgency: ⚪ backlog — no milestone
Reason: informational dashboard / pipeline trial output, not a fix candidate. CI health concerns it surfaces are already being tracked under �rea-engineering-systems work.

Suggested owner(s): Jose Perez Rodriguez (@joperezr) (score 6)
Evidence:

• joperezr merged Merge release/13.4 to main after v13.4.0 release #17817, Merge release/13.3 to main after v13.3.5 release (supersedes #17337) #17343 in �rea-engineering-systems (last 90d)
• Issue author (Ankit Jain (@radical)) is the originator of this pipeline trial and is excluded from owner suggestions per policy

Confidence: medium
Needs human?: no — informational; Ankit Jain (@radical) is driving the trial and can dismiss/close when the experiment is over.

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.

[radical]

🔧 Post-run review — 2026-06-18 19:48 UTC

First run of the new two-tier Pulse spec (aspire-ci-pulse.prompt.txt + shared aspire-ci-report-common.prompt.txt, both committed today). The prior body here was produced by the older combined prompt, so a straight diff looks like a big regression — most of it is the intended split, but two things are worth a human's eye.

Regressions vs previous run: none that are true regressions — but two intended discontinuities a watcher will notice:

• Dropped sections (intended): the trend PNG, the <details> per-day grid, and the old "Newly…" flaky block are gone. The new spec explicitly moves trend/grid/build-time to the Weekly (🩺 CI Health — Last 7 days #18231); the Pulse is now current-state-only. Lane labels also moved to the canonical 🌳🌿🧪🏗️🔀 set. Deliberate, not a regression.
• Pass rates jumped sharply (methodology correction, NOT a real swing): PR validation reads 83% (76/92) vs the prior body's 38% (76/200); main reads 30% (6/20) vs 26% (6/23). Same passing counts — the denominator shrank because the new shared counting rule excludes cancelled / in-progress / queued runs, and PR ci.yml has heavy cancellation (65 cancelled in 36h alone). The new numbers are spec-correct; the jump reflects the rule, not reality. Calling this out so nobody reads it as "CI suddenly healed overnight."

Readability / improvement ideas:

• The headline blockquote is dense (lane + 3 tests + rerun split + two healthy lanes + watch clause). Skimmable but near the limit — accept: consider trimming the "PR + internal are healthy" clause to a half-sentence, since the table shows it. Reject if the contrast is the point.
• The activity bars are in a fenced code block so the emoji columns align on every client — reads cleanly. Keep.

Data-gathering issues this run:

• ciinsights query_test_failures threw An error occurred invoking 'query_test_failures'; get_failure_summary worked and supplied the top breakages + infra/flaky counts, so the Pulse was unaffected. The connection status also reported a DB index-creation warning (IX_TestResults_FullyQualifiedName_CapturedAt already exists) — API healthy, but flag if failure data ever looks stale.
• ciinsights test data can lag the last ~30 min (noted in-body); the rerun split is computed live from gh api .../ci.yml/runs, so it's current.
• First --paginate | jq pass silently produced per-page arrays (mangled counts); re-running with --slurp fixed it. The 36h ci.yml window held 194 runs across pages — a non-slurped read would have undercounted.

Suggested prompt change (for a human to apply):

• aspire-ci-report-common.prompt.txt, infra-share rule. It says NN% (failed-infra/failed-total) / "share of failed builds", but the only figure ciinsights exposes is infrastructureFailureCount vs failingTestCount (test-result level: this run, 77/134 = 57%), not a build-level ratio. Pin the metric to one definition + one ciinsights field so successive runs don't silently switch denominators (build-level vs test-result-level). Small wording fix, durable payoff.

[radical]

🔧 Post-run review — 2026-06-18 20:48 UTC

Regressions vs previous run: none. The diff vs the 19:46 run is entirely genuine state movement — window slid ~1h, MongoDB ReplicaSet overtook the CLI TypeScript-apphost smoke as the single loudest test (11 vs 8), rerun split drifted (56/17 → 55/16), infra share recomputed (77/134 → 78/136), and 7d-avg deltas moved a fraction. No lost structure, no flipped statuses, no format churn. (Also trimmed a few trailing blank lines the prior body had accumulated.)

Readability / improvement ideas:

• (accept/reject) The headline now distinguishes the single loudest test (MongoDB ReplicaSet) from the loudest family (Aspire.Cli.*) in the 👀 Watch clause. This reads better than the prior run, which conflated the two. Suggest keeping this single-test-vs-family split as the headline convention.

Data-gathering issues this run (the valuable one):

• The rerun-split fetch via gh api .../ci.yml/runs?...&created=>2026-06-17... silently truncated to 82 of 169 runs on the first attempt because the > in the created filter was not URL-encoded — the shell/gh mangled the operator and the API ignored the lower bound, returning only one partial slice. I caught it only because I cross-checked against the gh run list count (94 completed PR runs in 36h) and against the API's own total_count (169). Without that reconcile, the rerun split would have been undercounted by ~50% (≈27 bot reruns instead of 55), badly distorting the flaky-tax section.
  • Fix that worked: URL-encode the operator (created=%3E2026-06-17T08%3A38%3A49Z) and --paginate, then assert jq -s length == .total_count.

Suggested prompt change (for a human to apply):

• File aspire-ci-report-common.prompt.txt, "Reruns & the flaky tax" section (or the "Fetch-enough-then-filter" section, which today only warns about gh run list --limit undercounts, not the runs-API created filter). Add one line: "When using gh api .../ci.yml/runs with a created=>… bound, URL-encode the operator (%3E) and verify the fetched run count equals the response's total_count — an unencoded > is silently dropped and truncates the window, halving the rerun split." This is a recurring trap (it will bite every run that fetches the rerun split this way), so it clears the "helps every future run" bar.
• Minor: the prompt never states the infra-share denominator. I inferred infra / (infra + failing) from the prior run's 77/134; this run's 78/136 matches the same formula. Worth one explicit line in the "Infra-share line" section so the figure is reproducible and doesn't drift between runs/authors.

[radical]

🔧 Post-run review — 2026-06-18 21:48 UTC

Regressions vs previous run: none. The diff vs the 20:46 run is entirely genuine state movement — window slid ~1h; MongoDB ReplicaSet ticked 11→12; the CLI TypeScript-apphost smoke (LatestCliCanStartStableChannelTypeScriptAppHost) aged out of the 36h window and StartAsync_…GracefulSignaler… took the #3 slot; rerun split drifted (55/16 → 58/20); infra share recomputed (78/136 → 79/135); 7d-avg deltas moved a fraction as the baseline window also slid. No lost structure, no flipped statuses, no format churn.

Readability / improvement ideas: none new — the headline + first table still convey "what's on fire" without scrolling.

Data-gathering issues this run (the new one):

• ciinsights.query_test_failures failed outright this run (An error occurred invoking 'query_test_failures'), and get_connection_status reported the backend DB as unhealthy (index ... 'IX_TestResults_FullyQualifiedName_CapturedAt' already exists — a stuck server-side migration). I fell back to ciinsights.get_failure_summary (its topFailingTests array) for the §3 breakages list, which worked. Without that fallback the loudest-breakages section would have had no source.
• This is plausibly recurring while the DB stays in that migration state, so it clears the "helps every future run" bar.
• I avoided the prior run's gh api .../ci.yml/runs created=> truncation trap by fetching paginated pages (per_page=100&page=N, 6 pages) and filtering by timestamp in code instead of an API-side created bound — confirms that prior finding's value.

Suggested prompt change (for a human to apply):

• (new — common file, "Reruns & the flaky tax" / data-sources) Add one line: "If ciinsights.query_test_failures errors, fall back to get_failure_summary.topFailingTests for the loudest-breakages list (same fail-count ranking, narrower window control)." Codifies a working mitigation for a tool that was down this run.
• (carried forward from 20:46, still unapplied — restated here because that comment is now resolved) (a) "Fetch-enough-then-filter": warn that an unencoded > in a runs-API created=>… bound is silently dropped and halves the rerun split — URL-encode (%3E) and assert fetched count == total_count, or fetch by page and filter in code. (b) "Infra-share line": state the denominator explicitly — infra / (infra + failing) (this run 79/135) — so the figure is reproducible and doesn't drift between authors.

[radical]

🔧 Post-run review — 2026-06-18 22:52 UTC

Regressions vs previous run: none. Diff against the prior body (published ~1h earlier) is all genuine state movement — window slid forward ~1h, main 6/20→6/21, internal main 14/16→14/17, PR validation 82/98→89/104, latest failed internal build 3003323→3003488, rerun counts 58/32→59/33. No section, column, link, or legend was dropped; no frozen value moved (the Pulse has no frozen history); no status emoji flipped without a real change.

Readability / improvement ideas:

• (accept/reject) The Watch clause was sharpened from last run's broad Aspire.Cli.* to the specific graceful-shutdown Signaler…Escalates family (3 named tests, repeating). This is more actionable — a reader can grep three exact test names. Suggest keeping Watch clauses this specific going forward rather than naming a whole namespace.
• The report is skimmable in ~15s: headline → lane table → reruns → breakages. No change needed.

Data-gathering issues this run:

• recentTrends.last24h.newFailingTests is a names-only list with NO per-test counts, and a large block in it is often ONE build's worth of a whole test class failing once — not N independent signals. This run it listed ~33 DistributedApplicationPipelineTests.* entries; cross-checking via search_tests showed every one had totalRuns=1, failures=1, all at the same timestamp (2026-06-17T23:03:34) — a single-build setup/compile blip, not a repeating breakage. Had I trusted the raw block I'd have featured a phantom "loud new family." Always validate newFailingTests entries against search_tests/failCount before featuring them.
• PR-validation 7d denominator needed a much larger fetch than the common prompt's --limit 300. At ~90–150 runs/day, 300 runs only spanned ~2.5 days (back to Jun 16) — short of the 7-day window. Refetched at --limit 1200 (reached Jun 7). The "fetch-enough-then-filter" rule held, but the suggested 300 floor silently undercounts this lane's 7d average.
• ciinsights get_connection_status reported a DB index warning (IX_TestResults_FullyQualifiedName_CapturedAt already exists); all queries still returned complete data. One-off, no impact this run.

Suggested prompt change (for a human to apply):

• aspire-ci-report-common.prompt.txt, the "Fetch-enough-then-filter" section: add a note that for the 7-day average on PR validation specifically, --limit 300 is insufficient (covers only ~2–3 days); use --limit ~1200 (or paginate to the 7d start) for that lane. The 36h window is fine at 300.
• aspire-ci-report-common.prompt.txt (or the Pulse §3 / headline Watch guidance): add a caution that recentTrends.newFailingTests carries no counts and a bulk block is frequently a single failed run of one test class — verify against search_tests before treating it as a flaky/broken family or featuring it in the Watch clause.

[radical]

🔧 Post-run review — 2026-06-18 23:52 UTC

Regressions vs previous run: none. Diffed the prior body against this one — every section, column, link, the bar-length legend, and both <sub> lines are intact. The only changes are state-driven value updates (window slid ~1h, so the MongoDB ReplicaSet 36h count fell 12→8 as older fails aged out; internal main 82→88%, PR validation 86→85%, infra share 59→60%). Pulse freezes no history, so there is no frozen-cell drift to check.

Readability / improvement ideas:

• (accept/reject) The report can be built from one ciinsights call: get_health_summary returns both failureBreakdown (testFailures + infrastructureFailures + total → the 🧱 infra-share fraction) and topFailingTests (the §3 loudest-breakage list). This run, query_test_failures failed outright (server-side DB index error: IX_TestResults_FullyQualifiedName_CapturedAt already exists), but get_health_summary + get_failure_summary covered everything. Suggest the prompt name get_health_summary as the primary §1-infra/§3-breakages source so a future run doesn't get blocked on the flaky query_test_failures endpoint.

Data-gathering issues this run:

• Rerun split is methodology-sensitive and the prompt under-specifies it. The window moved only ~1h vs the prior run, yet bot reruns jumped 59→89 and human 20→23. Two unpinned choices drive this: (a) what counts as one "rerun" — I used Σ(run_attempt−1) per run, attributed to the latest-attempt actor; (b) how to identify a PR — 38 of 80 rerun-bearing ci.yml runs were fork PRs with an empty pull_requests array, so I fell back to head_branch as the PR-identity key (raising distinct-PR from 23 to 48, much closer to the prior run's 46). Without these pinned, two runs an hour apart can legitimately disagree by ~50%.

Suggested prompt change (for a human to apply):

• aspire-ci-report-common.prompt.txt, the "Reruns & the flaky tax" section: pin the counting unit and the join key explicitly — (1) a "rerun" = each attempt beyond the first, i.e. Σ(run_attempt−1); (2) attribute a run's reruns to its latest-attempt triggering_actor (github-actions[bot] = bot, else human); (3) when pull_requests is empty (fork PRs), key the PR by head_branch. This is additive — it doesn't contradict the existing "split by who triggered it" rule, just makes it reproducible run-to-run.
• aspire-ci-pulse.prompt.txt / common data sources: note get_health_summary as the single source for both the infra-share fraction and the loudest-breakage list, with query_test_failures flagged as currently erroring.

[radical]

🔧 Post-run review — 2026-06-19 18:52 UTC

Regressions vs previous run: none. All deltas vs the prior body reflect genuine state changes. Structure preserved (header, headline, single lane table, infra line, legend, rerun split, loudest breakages, footer). The PR-validation activity bar shrank 12→11 cells — expected, not a regression: bar length is log-scaled to sample size and the lane's 36h run count dropped (109→72). The Internal AzDO release/13.4 row was omitted correctly (0 builds in window) and the omission is annotated inline so a reader doesn't think the lane was dropped silently.

Readability / improvement ideas:

• (accept/reject) The headline now carries two distinct test clusters (analyzer pair + EF Core Enrich) plus the "loudest by count vs most-recently-active" nuance. It's accurate but dense — at ~5 lines it's near the edge of skimmable. Consider a soft cap: lead with the single loudest cluster, push the "most-recently-active" distinction to §3 only. Reject if the recency caveat is considered load-bearing for "what's on fire now."

Data-gathering issues this run:

• Rerun-split attribution is an approximation. I bucketed reruns by triggering_actor of the latest attempt and counted run_attempt − 1 reruns per run, all assigned to that one actor. A run rerun first by the bot then by a human (or vice-versa) is attributed entirely to whoever triggered last; mixed-actor runs are only partially captured (I could detect "needed both" = 1 only via PR-set overlap, not per-attempt). This likely explains some of the large magnitude swing from the prior run (bot 89/human 23 → bot 43/human 16) — part real drop, part method variance. The prompts do not pin an exact counting method, so two runs can compute this differently.
• Infra-share denominator is ambiguous. The common prompt defines 🧱 infra share = failed-infra/failed-total as "share of failed builds", but ciinsights returns failure-occurrence counts (infrastructureFailureCount vs failingTestCount). I used 62/102 (infra ÷ infra+test signals); the prior run used 83/138 — a different denominator entirely. The metric isn't reproducible run-to-run without pinning the source + denominator.
• ciinsights get_test_history returned empty for an exact FQN (...MSBuildTests.AspireExportAnalyzers...) that get_failure_summary simultaneously reported with 34 fails in the same 36h window. So I could not use it to attribute the loudest test to a specific lane; the headline characterizes the analyzer pair by suite/family from the summary alone, not by lane. get_flagged_tests(problemType=broken) also did not surface the 34-fail pair in its top rows (it ranks multi-context broken tests; the pair appears single-context), so neither tool corroborated a lane for it.
• ciinsights get_connection_status reported the API healthy but the DB "unhealthy" (a duplicate-index warning, IX_TestResults_FullyQualifiedName_CapturedAt). All queries still returned data; flagging in case it foreshadows stale/partial results on a future run.

Suggested prompt change (for a human to apply):

• aspire-ci-report-common.prompt.txt, "Reruns & the flaky tax" section: pin the exact rerun-counting method — e.g. "count reruns as Σ(run_attempt − 1) over completed ci.yml runs in the window; attribute each run's reruns to the triggering_actor of the latest attempt (a known limitation for mixed bot+human runs); bot = login ending [bot]." Without this, the bot-vs-human magnitudes are not comparable across runs.
• Same file, "Infra-share line" section: pin the denominator and source — state whether it's failed builds or failed signals, and that ciinsights failingTestCount / infrastructureFailureCount are the inputs (or specify the build-level alternative). This run (62/102) and the prior (83/138) used different denominators for the same metric.