Daily Fro Bot Report — 2026-09-10 (UTC) #3881

Daily Fro Bot Report — 2026-09-10 (UTC)

Run Summary

Errored PRs

Handled by the remediation pass, not this job. Evidence: its report comment.

• Three pre-existing open PRs — chore(deps): update GitHub Actions #3877, fix(ci): gate issue runs and avoid persisted credentials #3878, chore(deps): update bfra-me/.github action to v4.27.0 #3879 — all green on both signal sources. Check runs pass (skips are by design); the legacy commit status (Security: Private Leak Scan) is success on each head SHA. Authors are fro-bot (bot) and marcusrbrown; all head branches are local.
• No failed, timed-out, or startup-failed runs on main in the last 100 across all branches.
• The pass opened fix(ci): unbreak the Manage Issues lock job #3880 — not for a broken PR, but for a broken scheduled workflow. All 18 checks green. See Progressive Improvement for the mechanism.

Security

• Local: 1 open Dependabot alert — @humanfs/node < 0.16.8, medium, development scope, transitive under eslint via @bfra.me/eslint-config. Below the critical/high remediation bar. pnpm audit --prod is clean across all 32 production dependencies.
• Code-scanning alerts on this repo remain OpenSSF Scorecard probe findings (VulnerabilitiesID, BranchProtectionID, FuzzingID, CIIBestPracticesID), not source vulnerabilities. BranchProtectionID is a guardrail report and was not touched.
• Org-wide alert visibility is structural, not transient. GET /repos/{owner}/{repo}/dependabot/alerts succeeded for exactly 6 of 34 active repos, and the boundary is clean: all six are fro-bot/* repos this account owns. Every bfra-me/* and marcusrbrown/* repo returned access-denied despite this account holding push. Write access does not imply security_events read. Yesterday's report called this "1 of 34" and framed it as a token gap; the sharper reading is that it is an ownership boundary, and no scope grant on the existing credential will move it. Across the six readable repos there is exactly one open alert — the local medium above. This is not an org-wide all-clear. 28 repos were not assessed.

Control-Plane Integrity

Handled by the remediation pass. All four sub-checks clean:

• SHA pinning: 137 uses: references across .github/workflows/ and .github/actions/. Every third-party one is a full 40-char commit SHA carrying a # vX.Y.Z comment; the remainder are local ./ refs. Zero floating tags, zero bare pins.
• Strip-only TypeScript: no enum, namespace, parameter properties, or import x = require(...) in scripts/*.ts. erasable-syntax-only and Test Scripts Load agree.
• Least privilege: every workflow declares a top-level permissions: block. Eleven job-level write grants, each narrow and justified (security-events for CodeQL/Scorecard, issues/pull-requests for the issue loops, id-token for OIDC publish). scorecard.yaml sits at read-all.
• Guard integrity: wiki-authority guard, privacy gates, and branch protection untouched. The remediation pass wrote nothing under knowledge/** or metadata/**.

Code Quality

Handled by the remediation pass: pnpm bootstrap, check-types, lint, test all green — 79 test files, 3672 tests, 3 todo, zero failures — on both main and the #3880 branch. No lint or format autofixes were available to apply. No issues opened or updated.

Oversight

Enumerated 39 repositories via paginated user/repos (affiliation=owner,collaborator,organization_member); the account belongs to no organizations, so no org listing applied. 34 active, 5 archived, all public, all with push. Nothing failed to enumerate.

No enumeration cap this pass. Yesterday's counts were lower bounds because the search API truncates at 100. This pass listed PRs and issues per-repo with pagination instead, so the numbers below are totals: 102 open PRs, 195 open issues fleet-wide.

Failing latest default-branch run (push/schedule events), down from six to two:

The four Fro Bot daemon failures flagged yesterday (bfra-me/renovate-action, marcusrbrown/containers, marcusrbrown/esphome.life, marcusrbrown/marcusrbrown.com) have all cleared without intervention from this loop. Next step: extend-vscode's Publish is the one that matters — it fails at Pre-Release Validation (vulnerabilities) on pnpm audit --audit-level moderate and has for three weeks, which means that repo cannot ship a release at all. See Cross-Project Intelligence for why that repo in particular is a suspicious place for a moderate-audit gate to jam.

PR queue (102 open): 69 aging past 7 days, 53 stale past 14 days without any update activity, 12 opened in the last day. Issues (195 open): 73 stale past 30 days, 14 opened in the last day.

The oldest stale PRs are not noise — six of the top ten are Fro Bot's own security remediations, unmerged for 85 days:

Next step: these are duplicates of each other across two repos and they have been rotting for a quarter. A security PR that nobody merges is worse than one nobody opened — it converts a known exposure into a known, documented, ignored exposure. Merge one pair or close all six and record why.

Top three hotspots (ranked by qualifying findings in this snapshot):

1. marcusrbrown/gpt — 47 findings. Still led by the Ollama a11y-contrast cluster (#2664 63d, #2665 62d, plus siblings) and #2165 at 165 days. Next step: unchanged from yesterday, and that is the finding — the contrast daemon re-proposes and nothing lands. Merge one or disable the category.
2. marcusrbrown/vbs — 33 findings. Includes the four Responsive UI & Testing Infrastructure phase issues (#152–#155) untouched for 393 days. Next step: a four-phase plan nobody has touched in over a year is a decision, not a backlog. Close it or restart it.
3. marcusrbrown/tokentoilet — 21 findings. Next step: unchanged — batch the docs-drift issues into one pass.

Unassigned bugs (9), same set as yesterday:

• marcusrbrown/infra #1292, #1278, #1277, #1258, #1234 — five stranded-deploy findings. Four were updated within the last 24h, so the detector is still firing daily; nothing has cleared.
• bfra-me/ha-addon-repository#569 — settings job failing with 500.
• marcusrbrown/marcusrbrown.com #517 (31d), #465 (63d) — a11y defects.
• marcusrbrown/systematic#740 (38d).

Next step: the infra five remain one root cause wearing five hats — a required_reviewers environment gate nobody clears. One approval session closes all five, and the detector will keep re-reporting them daily until someone does.

Gateway rollout tracker (#3512) — drift found, and it grew

Review-awareness only. No tracker comment posted, no Project field touched; the Gateway Rollout Tracker workflow owns those writes and has run green daily through 2026-09-09.

Project 1 holds 21 items: 20 Done, and #3512 itself at Todo. The issue body was last updated 2026-09-09, and all four mismatches reported yesterday are still present, plus two more:

The deployed-pin row is new today and it inverts the tracker's central argument. #3512 says operator push (v0.85.0) is "released but not yet deployed" and derives the whole remaining-work section from that. The deployed pin is v0.93.1, which is eight minors past v0.85.0 — the push code has been deployed for some time, and the only genuine remaining gate is VAPID secret provisioning, which the issue also names but subordinates to a deploy that already happened.

Every one of these six rows moves in the same direction: the tracker is more pessimistic than reality. It is not stale in a way that hides risk; it is stale in a way that manufactures it, and then spends its acceptance criteria arguing against work that is done.

Cross-Project Intelligence

Coverage: partial. metadata/repos.yaml carries 34 entries. 29 surveyed successfully; 2 carry a recorded last_survey_status: failure — marcusrbrown/renovate-config (2026-08-26) and bfra-me/renovate-action (2026-09-02), unchanged from yesterday, so those two wiki pages are stale by construction; 3 have never been surveyed (counts only — those entries are private and stay out of this report). Registry coverage of automation: 27 of 34 carry a Fro Bot workflow, 30 of 34 carry Renovate.

One adoptable finding, and this repo is on the wrong side of it.

Scanning every accessible repo's Renovate config for the matchUpdateTypes: ['patch'] → enabled: false shape produced a clean census: exactly 3 of 34 carry it — fro-bot/.github, marcusrbrown/containers, and marcusrbrown/extend-vscode — all three with the near-identical description "Disable patch updates except for select dependencies", exempting only typescript/python. The other 30 repos let patch updates flow. (marcusrbrown/.dotfiles matched the grep and is a false positive — its rule enables patch for devcontainer/dockerfile/mise.)

So the convention this repo follows is a minority of three, and today one of the three broke. The wiki already knew the pattern — the marcusrbrown/extend-vscode page recorded it on 2026-08-31 as an invisible-drift generator — but nobody checked whether the control plane itself had the same rule. It did.

Worth flagging without overclaiming: extend-vscode is also the repo whose Publish workflow has been red for 21 days on pnpm audit --audit-level moderate. Moderate advisories are exactly the class Renovate's security bypass does not reliably escalate past a patch-disable rule. That is a correlation with a plausible mechanism, not a proven link — someone should check it directly rather than take this report's word for it.

Persisted to the github-actions-ci wiki topic as Patch Suppression Eventually Breaks CI, Not Just Freshness. Nothing was changed in any other repository.

Progressive Improvement

Learning pipeline: healthy. Zero open learning-proposal issues. No aging, no two-or-more backlog. The direct count is available and is zero, so the Improvement Metrics report (#3674) was not relied on.

Tool-version drift. Authoritative source: the npm registry latest dist-tag (npm view <pkg> version), read 2026-09-10. Major drift was included and is called out:

The TypeScript gap remains a documented hold (allowedVersions: '<6.1.0' mirroring typescript-eslint's peer ceiling, upstream typescript-eslint#12518). Leave it.

The real finding is that the patch channel is closed, and today it cost a workflow.

.github/renovate.json5 disables patch updates repo-wide except for python and typescript. The Dependency Dashboard (#2828) faithfully lists 11 patch-shaped updates that will never become a PR:

• Actions (5): actions/checkout v7.0.0→v7.0.1, actions/deploy-pages v5.0.0→v5.0.1, dessant/lock-threads v6.0.0→v6.0.2, fro-bot/agent v0.109.0→v0.109.4, ossf/scorecard-action v2.4.3→v2.4.4
• npm (6): @bfra.me/prettier-config 0.16.0→0.16.11, @vitest/coverage-v8 4.1.4→4.1.11, @vitest/eslint-plugin 1.6.15→1.6.27, eslint-config-prettier 10.1.1→10.1.8, eslint-plugin-prettier 5.5.0→5.5.6, prettier 3.9.1→3.9.6

Minor-shaped updates in the same dashboard did get PRs (#3877, #3879), which confirms the rule is the discriminator and not queue congestion.

Three of those eleven deserve naming:

1. dessant/lock-threads v6.0.0→v6.0.2 was a CI-breaking bug fix. Manage Issues → Lock failed ten consecutive scheduled runs with "github-token" length must be less than or equal to 100 characters long — v6.0.0 validates the input at Joi.string().trim().max(100) and the runner token outgrew it. v6.0.2 raises the bound to 1000 (upstream dessant/lock-threads#55). Fixed in fix(ci): unbreak the Manage Issues lock job #3880. Version truth: the upstream releases/tags API plus src/schema.js read at each tag SHA. No major drift — two patch releases inside one major.
2. fro-bot/agent v0.109.0→v0.109.4 freezes the daemon writing this report. All six agent pins in this repo sit at v0.109.0. The harness versions in the patch slot, so the rule that suppresses dependency churn also suppresses harness updates — and a frozen harness still produces green runs.
3. @vitest/coverage-v8 4.1.4→4.1.11 corrects yesterday's diagnosis. Yesterday's report blamed the vitest-monorepo group's dependencyDashboardApproval gate. That is half the story: even if the v5 major were rejected outright, the 4.1.11 alignment with the 4.1.11 runner is separately blocked by the patch rule. Approving or rejecting the major would not fix the skew.

Next step: add a narrower packageRules entry after the disable rule re-enabling patch for matchManagers: ['github-actions']. That restores the bug-fix channel for pinned actions — the case that just broke — while leaving npm patch churn suppressed. Not auto-healed: changing dependency-update policy repo-wide is a decision, not a repair.

Convention drift / stale annotations: none. The only TODO|FIXME|HACK|XXX matches outside tests, docs, and knowledge/ are inside the oversight prompt in fro-bot.yaml that asks for this scan.

CI jobs: no missing or degraded jobs. All required contexts on main are present and passing on every open PR.

Needs Human Attention

1. Renovate's patch-disable rule has no exception for upstream bug fixes

• Path: .github/renovate.json5, the first packageRules entry (matchUpdateTypes: ['patch'], enabled: false, exempting only python and typescript).
• Root cause: the rule cannot distinguish patch churn from patch repair, so it declines both. Renovate's vulnerability-alert bypass rescues CVEs but not correctness bugs. Result: 11 suppressed updates, one of which was the fix for a ten-day CI outage, and one of which freezes the agent pin.
• Smallest safe fix: append a packageRules entry after the disable rule with matchManagers: ['github-actions'], matchUpdateTypes: ['patch'], enabled: true. Order matters — Renovate applies rules in sequence, so a re-enable placed before the disable is a no-op.
• Constraint: do not delete the disable rule. It is deliberate and npm patch volume here is high. Do not widen this to all managers in one step.
• Verify: after merge, the next Renovate run should propose the four remaining suppressed action patches (actions/checkout v7.0.1, actions/deploy-pages v5.0.1, fro-bot/agent v0.109.4, ossf/scorecard-action v2.4.4 — lock-threads is already fixed by fix(ci): unbreak the Manage Issues lock job #3880) and no npm patch PRs. If npm patches appear, the rule ordering or matchManagers value is wrong.
• Related: Renovate: reusable-workflow deps fall outside the GitHub Actions group rule #3792 and CI: no Renovate config validation gate on a preset that ships org-wide #3793 are adjacent Renovate coverage gaps. Consider addressing all three in one pass.

2. Gateway tracker #3512 now carries six stale claims, and the newest one inverts its conclusion

• Full table in Oversight above. The load-bearing error: Track cross-repo Gateway operator control-surface rollout #3512 asserts the deployed gateway pin is v0.83.0 in five places and builds its remaining-work section on "push is released but not deployed." marcusrbrown/infra's apps/gateway/upstream.json reads {"repo":"fro-bot/agent","ref":"v0.93.1"}.
• Smallest safe fix: run the Gateway Rollout Tracker workflow (it owns tracker writes; this report path must not), or edit Track cross-repo Gateway operator control-surface rollout #3512's body to correct the six rows and re-derive the deploy argument against v0.93.1 / latest v0.109.4.
• Constraint: do not post tracker comments or edit Project fields from the daily-report path.
• Verify: the six linked items' live states match the table, and the "Project matrix is current" acceptance criterion either gains the ~12 cited-but-unlisted items or is rewritten to stop claiming completeness it does not have.

3. Org-wide Dependabot visibility is an ownership boundary, not a scope gap

• GET /repos/{owner}/{repo}/dependabot/alerts succeeds for exactly the 6 repos this account owns and fails for all 28 where it is a collaborator with push. Yesterday's framing ("grant the reporting credential security_events read across the fleet") is not actionable as stated — collaborator-level access does not expose alert data regardless of scope.
• Smallest safe fix: either install a GitHub App with security_events: read on the bfra-me and marcusrbrown accounts and use its installation token for this scan, or amend the oversight prompt to stop requesting a fleet-wide scan that structurally cannot run under the current credential model.
• Do not infer alert state from PR titles or dependency manifests. A guessed all-clear is worse than an honest ❔.
• Verify: the endpoint returns 200 for a repo this account does not own.

4. Six Fro-Bot security PRs have been open for ~85 days across two repos

• bfra-me/github-action Action Required: Fix Renovate Configuration #1463, Action Required: Fix Renovate Configuration #1466, Action Required: Fix Renovate Configuration #1467; bfra-me/github-app Action Required: Fix Renovate Configuration #840, Action Required: Fix Renovate Configuration #842, Action Required: Fix Renovate Configuration #843. All are vite pins or esbuild/fast-uri/undici override floors, duplicated across the two repos.
• Root cause is not CI. These are unmerged, not failing.
• Smallest safe fix: review one pair, merge or close all six together, and record the decision. If the advisories they address are no longer live, closing them is the correct outcome and should be stated explicitly rather than left to rot.
• Constraint: this loop must not merge, approve, or close PRs. Human action required.
• Verify: zero open Fro-Bot-authored PRs older than 60 days in either repo.

5. marcusrbrown/extend-vscode cannot ship a release

• Publish has failed since 2026-08-20 at Pre-Release Validation (vulnerabilities) — pnpm audit --audit-level moderate exits non-zero. Run 32322662640.
• Hypothesis worth testing, not a conclusion: that repo carries the same patch-disable rule as this one, and moderate-severity advisories are the class most likely to be remediated by an ordinary patch release that the rule suppresses.
• Smallest safe fix: run pnpm audit --audit-level moderate in that repo, check whether the flagged advisories have patched versions reachable by a patch bump, and if so apply the same narrow re-enable proposed in item 1.
• Verify: Publish reaches a green run.

6. Wiki lint finding #3798 is still open

• broken-markdown-link in knowledge/wiki/topics/home-assistant.md, unresolved since 2026-09-06 — four days. It is not in the wiki-repair self-healing set, so it will not fix itself.
• Constraint: the fix lands on the data branch through the wiki scripts, never via a PR to main — Check Wiki Authority rejects those by design.
• Verify: the next Wiki Lint scan closes Wiki lint: broken-markdown-link in knowledge/wiki/topics/home-assistant.md #3798 on clear.

7. Two registry entries are stale at the source; three have never been surveyed

• marcusrbrown/renovate-config (last_survey_status: failure, 2026-08-26) and bfra-me/renovate-action (failure, 2026-09-02) — unchanged for a second day, so this is not transient.
• Smallest safe fix: re-dispatch survey-repo.yaml with each entry's 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.
• Three further entries have never been surveyed (counts only — no identifying detail, by policy). They sit at onboarding_status: pending, two added 2026-06-01 and one 2026-07-18, so the pending state is months old and worth a decision rather than continued deferral.

Yesterday's report closed on the observation that splitting this workflow bought a delivery guarantee and left the trust boundary untouched. Today's is smaller and sharper: a rule written to keep the dependency queue quiet worked exactly as designed, and the quiet is what kept a broken job invisible for ten days. The wiki had already recorded that pattern on another repo two weeks ago. Nobody thought to check the control plane against its own filed lesson — which is the more interesting failure, and the one worth fixing structurally.