You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Remediation pass found zero failing PRs. Both check-run and legacy-status sources inspected on the single open PR.
Security
❔
Local: 1 open medium dev-only alert, below the remediation bar. Org-wide: the Dependabot alerts API returned access-denied for 33 of 34 active repos under this token — that scan did not happen.
Control-Plane Integrity
✅
Remediation pass verified all 21 third-party action pins against upstream tag refs, strip-only TS, workflow permissions, and guard/branch-protection state.
Code Quality
✅
Remediation pass ran the full local gate green, including 100% mutation score on all four guard modules.
Oversight
⚠️
38 repos enumerated, 34 active. 6 repos with a failing latest default-branch run; 56 stale PRs; 26 stale issues; 9 unassigned bugs. Enumeration capped — see below.
Cross-Project Intelligence
⚠️
Coverage partial (31 of 34 registry entries scannable; 2 recorded survey failures). One adoptable finding, and it is about this repo's own trust boundary.
Progressive Improvement
⚠️
Learning pipeline is healthy (0 open proposals). Coverage tooling is skewed from the test runner and stuck behind a major-approval gate.
Errored PRs
Handled by the remediation pass, not this job. Evidence: its report comment.
Zero open Fro-Bot-authored remediation PRs exist, and none were opened — the pass found nothing to heal.
Only open PR: chore(deps): update Node.js to v24.21.0 #3874 (chore(deps): update Node.js to v24.21.0, Renovate). 15 check runs pass, 3 skipped-by-design; the legacy commit status (Security: Private Leak Scan) is success. mergeStateStatus: BLOCKED is the required approving review, not CI.
No failed, timed-out, or startup-failed runs in the last 100 on this repo across all branches.
Security
Local: 1 open Dependabot alert — @humanfs/node, medium, development scope, transitive via pnpm-lock.yaml. Below the critical/high remediation bar; Renovate retains ownership. Tracked on the Dependency Dashboard (Dependency Dashboard #2828).
Code-scanning alerts on this repo are OpenSSF Scorecard probe findings, not source vulnerabilities.
Org-wide security alerts unavailable.GET /repos/{owner}/{repo}/dependabot/alerts returned access-denied for every enumerated repo except this one (33 of 34 active). This token cannot read alert state across the fleet, so the org-wide security posture was not assessed today. Not an all-clear.
Control-Plane Integrity
Handled by the remediation pass. Verified clean on all four sub-checks; the pin audit went past shape-checking and resolved each pin against its upstream tag ref (17/17 matched, zero drift, verification only — no version bumps made). Details in the linked comment.
Code Quality
Handled by the remediation pass: pnpm bootstrap, check-types, lint, test (3670 passing), and check:mutation-guards all green, working tree clean afterward. No issues opened or updated.
Oversight
Enumerated 38 repositories via paginated user/repos for the authenticated account (affiliation=owner,collaborator,organization_member); the account belongs to no organizations, so no org listing applied. 34 active, 4 archived, all public. One repo (marcusrbrown/render-pgvector-demo) surfaced in search results but not in that listing — an affiliation-filter edge, noted rather than papered over.
Enumeration cap: the PR and issue searches both returned exactly 100 results, the API maximum. Every count below is a lower bound, not a total.
Failing latest default-branch run (push/schedule events):
Three of six are the Fro Bot daemon itself failing. Next step: the agent-pin gap is the first thing to check on each — a daemon that fails on its own schedule produces no report to tell you it failed.
PR queue (≥100 open): 71 aging past 7 days, 56 stale past 14 days without any update activity, 16 opened in the last day. Issues (≥100 open): 26 stale past 30 days, 15 opened in the last day.
Top three hotspots (ranked by qualifying findings in this snapshot):
marcusrbrown/gpt — 17 findings. 15 stale PRs including the Ollama a11y-contrast cluster (#2692, #2674, #2673, #2672, #2665, #2664) plus #2165 at 121 days. Next step: the contrast daemon keeps re-proposing the same fix and nothing lands — close five and merge one, or stop the category.
marcusrbrown/vbs — 13 findings. 8 stale PRs (several security remediations 30–60 days old) and 5 convention-drift issues. Next step: merge or close the security PRs first; they are the ones with a decaying reason to exist.
marcusrbrown/tokentoilet — 12 findings. 7 stale PRs, 5 stale issues, three of which are AGENTS.md/docs-drift reports. Next step: batch the docs-drift issues into one pass rather than letting each accrete its own PR.
Review-awareness only; no tracker comment posted and no Project field touched. That workflow owns those writes. Project 1 holds 21 items: 20 Done, and #3512 itself at Todo.
Four claim-vs-live mismatches in the #3512 body (last updated 2026-08-10):
Latest release v0.109.4 (2026-09-06, GitHub Releases on fro-bot/agent) — ~24 minors on
The release claim is the load-bearing one: the tracker's whole "deployed pin vs latest release" argument is computed against a number that moved a month ago. Its own acceptance criterion — "The Project matrix is current and reflects all shipped/closed rollout items" — is also unmet: the body cites agent #1033/#1109/#1111/#1152/#1157/#1160/#1162/#1163/#1165 and dashboard #108/#122/#179, none of which are items on the board.
Cross-Project Intelligence
Coverage: partial. metadata/repos.yaml carries 34 entries; 31 were scannable this pass and 3 were not. Two carry a recorded last_survey_status: failure — marcusrbrown/renovate-config (2026-08-26) and bfra-me/renovate-action (2026-09-02) — so their wiki knowledge is stale by construction, not by schedule.
One adoptable finding, and it points inward.
Adopt marcusrbrown/infra's capability-axis job split (2026-09-06) — this repo split on the wrong axis. Infra cut fro-bot.yaml into fro-bot-content (content-triggered, contents: read + pull-requests: read, no environment, no privileged credential) and fro-bot-storage (schedule/main-dispatch only, environment-gated, id-token: write, egress-blocked). The privileged job is unreachable by outsiders; the reachable job cannot write.
This repo split fro-bot.yaml into two jobs yesterday (#3872) along the delivery-mode axis — fro-bot-remediate (branch-pr) and fro-bot-observe (working-dir). Both are schedule/dispatch-only. The content-triggered fro-bot job was left exactly as it was, still holding FRO_BOT_PAT. Same shape of change, entirely different property purchased. Details under Needs Human Attention.
Nothing was changed in this category. Report only.
Progressive Improvement
Learning pipeline: healthy. Zero open learning-proposal issues. Five were authored into docs/solutions/ on 2026-09-08 (#3868) and closed the same day. No aging, no backlog of two-or-more. The compounding loop drained; treating the Improvement Metrics report (#3674) as evidence was unnecessary here because the direct count is available and is zero.
Tool-version drift. Authoritative source: the npm registry latest dist-tag (npm view <pkg> version), read 2026-09-09. Major drift was included in this comparison and is called out explicitly:
Package
Pinned
Registry latest
Read
eslint
10.10.0
10.10.0
current
@stryker-mutator/core
10.0.0
10.0.0
current
prettier
3.9.1
3.9.6
patch behind, within tolerance
typescript
6.0.3
7.0.2
major — deliberate, not drift
vitest
4.1.11
5.0.0
major, parked pending approval
@vitest/coverage-v8
4.1.4
5.0.0
major parked and skewed from the runner
The TypeScript gap is a documented hold, not neglect: .github/renovate.json5 pins allowedVersions: '<6.1.0' because typescript-eslint's peer range stops at <6.1.0 (upstream typescript-eslint#12518) and TS 7's native ts.Extension.Cjs behavior would break the parser hard rather than warn. Leave it. Lift it when the peer range moves — not before.
The real finding is the coverage skew. @vitest/coverage-v8 sits at 4.1.4 against a runner at 4.1.11. The dashboard offers 4.1.11 as an available update, but the vitest-monorepo group folds it in with the v5 major, and the whole group is parked behind an unchecked dependencyDashboardApproval box on #2828. So an in-range, low-risk patch that would re-align the coverage reporter with the runner is held hostage by a major nobody has decided on yet. Next step: either approve the v5 major deliberately or split the non-major out of that group so patch alignment is not gated on a major decision. Renovate owns the bump either way — no PR was opened here.
Convention drift / stale annotations: none. The only TODO|FIXME|HACK|XXX match outside tests, docs, and knowledge/ is inside the oversight prompt in fro-bot.yaml that asks for this very scan.
CI jobs: no missing or degraded jobs. All 14 required contexts on main are present and passing on the open PR.
Needs Human Attention
1. issues: [opened, edited] reaches a job holding the cross-repo PAT with no author gate
.github/workflows/fro-bot.yaml, job fro-bot (the content-triggered one), if: expression around lines 455–481.
Root cause: the if: joins four trigger branches with ||. The comment branch requires author_association ∈ {OWNER, MEMBER, COLLABORATOR} (line 479 — the file's only author_association reference in 1,115 lines). The issues branch requires only that the author is not a [bot] and not fro-bot. On a public repo, opening an issue is available to anyone. The job then checks out with token: ${{ secrets.FRO_BOT_PAT }} (line 487) and passes the same PAT as github-token to the agent (line 579). The file's own comment at line 83 describes that credential as carrying cross-repo write-tier authority (repo + read:org + project). Untrusted issue title and body flow into the agent prompt while that credential is in scope.
Smallest safe fix — pick one: (a) add the same author_association membership check to the issues branch of the if:, mirroring line 479; or (b) give the content-triggered job the default GITHUB_TOKEN under a narrow job-level permissions: block and keep FRO_BOT_PAT on fro-bot-remediate / fro-bot-observe. Option (b) is the stronger boundary and matches docs/solutions/workflow-issues/required-github-token-for-agent-steps-2026-06-22.md: restrict capability by scope, not by omission — the agent still authenticates, it just cannot reach across repos on an untrusted trigger.
Constraints: do not remove the github-token input to "fix" this. It is a required input; removing it fails the step at startup, which is the exact mistake that learning documents. Do not widen the comment branch to match the issues branch. This is a workflow edit, so it needs a human decision on which option — it was deliberately not auto-healed.
Verify: open a test issue from a non-collaborator account (or simulate the expression) and confirm the fro-bot job does not start under option (a); under option (b), confirm the job still runs on trusted triggers and that gh calls against another repo fail with a permissions error rather than succeeding.
Do not retry from a branch-pr autoheal run without a human decision recorded first — the boundaries forbid modifying workflows unless a failing run proves a bug in the file, and nothing is failing here. This is a latent reachability gap, not a broken run.
2. Gateway tracker #3512 carries four stale claims
Listed in the Oversight section above. This report is review-awareness only; the Gateway Rollout Tracker workflow owns tracker comments and Project field writes. Smallest safe fix: run that workflow, or edit #3512's body to correct the four rows and re-derive the "deployed vs latest" argument against v0.109.4 instead of v0.85.0. Verify: the four linked items' live states match the table, and the Project matrix either gains the missing items or the acceptance criterion is rewritten to stop claiming completeness it does not have.
3. Org-wide Dependabot alert visibility is missing
GET /repos/{owner}/{repo}/dependabot/alerts is access-denied for 33 of 34 active repos under this token. Every daily report will keep rendering ❔ for org-wide security until that changes. Smallest safe fix: grant the reporting credential security_events read across the fleet, or accept the gap and change the prompt to stop asking for a scan that structurally cannot run. Do not substitute inference from PR titles for alert data — a guessed all-clear is worse than an honest ❔. Verify: the endpoint returns 200 for a repo other than fro-bot/.github.
4. Three registry entries were not scannable
3 of 34 metadata/repos.yaml entries could not be scanned by this pass; counts only, no identifying detail. Two further entries carry last_survey_status: failure — marcusrbrown/renovate-config (2026-08-26) and bfra-me/renovate-action (2026-09-02) — so cross-project intelligence for those two is stale at the source. Smallest safe fix: re-dispatch survey-repo.yaml for the two failed public entries using their node_id from metadata/repos.yaml on the data branch. Verify:last_survey_status flips to success and the corresponding knowledge/wiki/repos/ page's updated advances.
broken-markdown-link in knowledge/wiki/topics/home-assistant.md, unresolved since 2026-09-06. It is not in the wiki-repair self-healing set, so it will not fix itself. The fix lands on the data branch through the wiki scripts, never via a PR to main — Check Wiki Authority rejects those by design. Full detail in the remediation pass comment.
Nothing broke today, which is a measurement and not a victory lap. The interesting finding is that yesterday's split of this workflow bought a delivery guarantee and left the trust boundary exactly where it was — two jobs where there was one, and the door still on the same hinge.
Daily Fro Bot Report — 2026-09-09 (UTC)
Run Summary
Errored PRs
Handled by the remediation pass, not this job. Evidence: its report comment.
chore(deps): update Node.js to v24.21.0, Renovate). 15 check runs pass, 3 skipped-by-design; the legacy commit status (Security: Private Leak Scan) issuccess.mergeStateStatus: BLOCKEDis the required approving review, not CI.Security
@humanfs/node, medium,developmentscope, transitive viapnpm-lock.yaml. Below the critical/high remediation bar; Renovate retains ownership. Tracked on the Dependency Dashboard (Dependency Dashboard #2828).GET /repos/{owner}/{repo}/dependabot/alertsreturned access-denied for every enumerated repo except this one (33 of 34 active). This token cannot read alert state across the fleet, so the org-wide security posture was not assessed today. Not an all-clear.Control-Plane Integrity
Handled by the remediation pass. Verified clean on all four sub-checks; the pin audit went past shape-checking and resolved each pin against its upstream tag ref (17/17 matched, zero drift, verification only — no version bumps made). Details in the linked comment.
Code Quality
Handled by the remediation pass:
pnpm bootstrap,check-types,lint,test(3670 passing), andcheck:mutation-guardsall green, working tree clean afterward. No issues opened or updated.Oversight
Enumerated 38 repositories via paginated
user/reposfor the authenticated account (affiliation=owner,collaborator,organization_member); the account belongs to no organizations, so no org listing applied. 34 active, 4 archived, all public. One repo (marcusrbrown/render-pgvector-demo) surfaced in search results but not in that listing — an affiliation-filter edge, noted rather than papered over.Enumeration cap: the PR and issue searches both returned exactly 100 results, the API maximum. Every count below is a lower bound, not a total.
Failing latest default-branch run (push/schedule events):
bfra-me/renovate-actionmarcusrbrown/containersmarcusrbrown/dev-likemarcusrbrown/esphome.lifemarcusrbrown/extend-vscodemarcusrbrown/marcusrbrown.comThree of six are the Fro Bot daemon itself failing. Next step: the agent-pin gap is the first thing to check on each — a daemon that fails on its own schedule produces no report to tell you it failed.
PR queue (≥100 open): 71 aging past 7 days, 56 stale past 14 days without any update activity, 16 opened in the last day. Issues (≥100 open): 26 stale past 30 days, 15 opened in the last day.
Top three hotspots (ranked by qualifying findings in this snapshot):
marcusrbrown/gpt— 17 findings. 15 stale PRs including the Ollama a11y-contrast cluster (#2692, #2674, #2673, #2672, #2665, #2664) plus #2165 at 121 days. Next step: the contrast daemon keeps re-proposing the same fix and nothing lands — close five and merge one, or stop the category.marcusrbrown/vbs— 13 findings. 8 stale PRs (several security remediations 30–60 days old) and 5 convention-drift issues. Next step: merge or close the security PRs first; they are the ones with a decaying reason to exist.marcusrbrown/tokentoilet— 12 findings. 7 stale PRs, 5 stale issues, three of which are AGENTS.md/docs-drift reports. Next step: batch the docs-drift issues into one pass rather than letting each accrete its own PR.Unassigned bugs (9):
marcusrbrown/infra#1292,#1278,#1277,#1258,#1234— five stranded-deploy findings, all approval-gate parked;bfra-me/ha-addon-repository#569;marcusrbrown/marcusrbrown.com#517,#465;marcusrbrown/systematic#740. Next step: the infra five are one root cause wearing five hats — arequired_reviewersenvironment gate nobody clears. One approval session closes all five.Gateway rollout tracker (#3512) — drift found
Review-awareness only; no tracker comment posted and no Project field touched. That workflow owns those writes. Project 1 holds 21 items: 20
Done, and #3512 itself atTodo.Four claim-vs-live mismatches in the #3512 body (last updated 2026-08-10):
fro-bot/dashboard#179(Cancel UI) — Openmarcusrbrown/infra#711(App key revocation runbook) — filed gap, openfro-bot/.github#3525(residual node_id gap) — "tracked"v0.85.0"v0.109.4(2026-09-06, GitHub Releases onfro-bot/agent) — ~24 minors onThe release claim is the load-bearing one: the tracker's whole "deployed pin vs latest release" argument is computed against a number that moved a month ago. Its own acceptance criterion — "The Project matrix is current and reflects all shipped/closed rollout items" — is also unmet: the body cites agent
#1033/#1109/#1111/#1152/#1157/#1160/#1162/#1163/#1165and dashboard#108/#122/#179, none of which are items on the board.Cross-Project Intelligence
Coverage: partial.
metadata/repos.yamlcarries 34 entries; 31 were scannable this pass and 3 were not. Two carry a recordedlast_survey_status: failure—marcusrbrown/renovate-config(2026-08-26) andbfra-me/renovate-action(2026-09-02) — so their wiki knowledge is stale by construction, not by schedule.One adoptable finding, and it points inward.
Adopt
marcusrbrown/infra's capability-axis job split (2026-09-06) — this repo split on the wrong axis. Infra cutfro-bot.yamlintofro-bot-content(content-triggered,contents: read+pull-requests: read, no environment, no privileged credential) andfro-bot-storage(schedule/main-dispatch only, environment-gated,id-token: write, egress-blocked). The privileged job is unreachable by outsiders; the reachable job cannot write.This repo split
fro-bot.yamlinto two jobs yesterday (#3872) along the delivery-mode axis —fro-bot-remediate(branch-pr) andfro-bot-observe(working-dir). Both are schedule/dispatch-only. The content-triggeredfro-botjob was left exactly as it was, still holdingFRO_BOT_PAT. Same shape of change, entirely different property purchased. Details under Needs Human Attention.Nothing was changed in this category. Report only.
Progressive Improvement
Learning pipeline: healthy. Zero open
learning-proposalissues. Five were authored intodocs/solutions/on 2026-09-08 (#3868) and closed the same day. No aging, no backlog of two-or-more. The compounding loop drained; treating the Improvement Metrics report (#3674) as evidence was unnecessary here because the direct count is available and is zero.Tool-version drift. Authoritative source: the npm registry
latestdist-tag (npm view <pkg> version), read 2026-09-09. Major drift was included in this comparison and is called out explicitly:eslint@stryker-mutator/coreprettiertypescriptvitest@vitest/coverage-v8The TypeScript gap is a documented hold, not neglect:
.github/renovate.json5pinsallowedVersions: '<6.1.0'because typescript-eslint's peer range stops at<6.1.0(upstreamtypescript-eslint#12518) and TS 7's nativets.Extension.Cjsbehavior would break the parser hard rather than warn. Leave it. Lift it when the peer range moves — not before.The real finding is the coverage skew.
@vitest/coverage-v8sits at 4.1.4 against a runner at 4.1.11. The dashboard offers4.1.11as an available update, but the vitest-monorepo group folds it in with the v5 major, and the whole group is parked behind an uncheckeddependencyDashboardApprovalbox on #2828. So an in-range, low-risk patch that would re-align the coverage reporter with the runner is held hostage by a major nobody has decided on yet. Next step: either approve the v5 major deliberately or split the non-major out of that group so patch alignment is not gated on a major decision. Renovate owns the bump either way — no PR was opened here.Convention drift / stale annotations: none. The only
TODO|FIXME|HACK|XXXmatch outside tests, docs, andknowledge/is inside the oversight prompt infro-bot.yamlthat asks for this very scan.CI jobs: no missing or degraded jobs. All 14 required contexts on
mainare present and passing on the open PR.Needs Human Attention
1.
issues: [opened, edited]reaches a job holding the cross-repo PAT with no author gate.github/workflows/fro-bot.yaml, jobfro-bot(the content-triggered one),if:expression around lines 455–481.if:joins four trigger branches with||. The comment branch requiresauthor_association∈{OWNER, MEMBER, COLLABORATOR}(line 479 — the file's onlyauthor_associationreference in 1,115 lines). Theissuesbranch requires only that the author is not a[bot]and notfro-bot. On a public repo, opening an issue is available to anyone. The job then checks out withtoken: ${{ secrets.FRO_BOT_PAT }}(line 487) and passes the same PAT asgithub-tokento the agent (line 579). The file's own comment at line 83 describes that credential as carrying cross-repo write-tier authority (repo +read:org+project). Untrusted issue title and body flow into the agent prompt while that credential is in scope.author_associationmembership check to theissuesbranch of theif:, mirroring line 479; or (b) give the content-triggered job the defaultGITHUB_TOKENunder a narrow job-levelpermissions:block and keepFRO_BOT_PATonfro-bot-remediate/fro-bot-observe. Option (b) is the stronger boundary and matchesdocs/solutions/workflow-issues/required-github-token-for-agent-steps-2026-06-22.md: restrict capability by scope, not by omission — the agent still authenticates, it just cannot reach across repos on an untrusted trigger.github-tokeninput to "fix" this. It is a required input; removing it fails the step at startup, which is the exact mistake that learning documents. Do not widen the comment branch to match theissuesbranch. This is a workflow edit, so it needs a human decision on which option — it was deliberately not auto-healed.fro-botjob does not start under option (a); under option (b), confirm the job still runs on trusted triggers and thatghcalls against another repo fail with a permissions error rather than succeeding.branch-prautoheal run without a human decision recorded first — the boundaries forbid modifying workflows unless a failing run proves a bug in the file, and nothing is failing here. This is a latent reachability gap, not a broken run.2. Gateway tracker #3512 carries four stale claims
Listed in the Oversight section above. This report is review-awareness only; the Gateway Rollout Tracker workflow owns tracker comments and Project field writes. Smallest safe fix: run that workflow, or edit #3512's body to correct the four rows and re-derive the "deployed vs latest" argument against
v0.109.4instead ofv0.85.0. Verify: the four linked items' live states match the table, and the Project matrix either gains the missing items or the acceptance criterion is rewritten to stop claiming completeness it does not have.3. Org-wide Dependabot alert visibility is missing
GET /repos/{owner}/{repo}/dependabot/alertsis access-denied for 33 of 34 active repos under this token. Every daily report will keep rendering ❔ for org-wide security until that changes. Smallest safe fix: grant the reporting credentialsecurity_eventsread across the fleet, or accept the gap and change the prompt to stop asking for a scan that structurally cannot run. Do not substitute inference from PR titles for alert data — a guessed all-clear is worse than an honest ❔. Verify: the endpoint returns 200 for a repo other thanfro-bot/.github.4. Three registry entries were not scannable
3 of 34
metadata/repos.yamlentries could not be scanned by this pass; counts only, no identifying detail. Two further entries carrylast_survey_status: failure—marcusrbrown/renovate-config(2026-08-26) andbfra-me/renovate-action(2026-09-02) — so cross-project intelligence for those two is stale at the source. Smallest safe fix: re-dispatchsurvey-repo.yamlfor the two failed public entries using theirnode_idfrommetadata/repos.yamlon thedatabranch. Verify:last_survey_statusflips tosuccessand the correspondingknowledge/wiki/repos/page'supdatedadvances.5. Wiki lint finding #3798 is still open
broken-markdown-linkinknowledge/wiki/topics/home-assistant.md, unresolved since 2026-09-06. It is not in thewiki-repairself-healing set, so it will not fix itself. The fix lands on thedatabranch through the wiki scripts, never via a PR tomain—Check Wiki Authorityrejects those by design. Full detail in the remediation pass comment.Nothing broke today, which is a measurement and not a victory lap. The interesting finding is that yesterday's split of this workflow bought a delivery guarantee and left the trust boundary exactly where it was — two jobs where there was one, and the door still on the same hinge.
Run Summary