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

[fro-bot]

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

Run Summary

Category	Status	Notes
Errored PRs	✅	Two remediation passes found no failing PRs; all 3 open PRs green on check runs and legacy statuses.
Security	⚠️	1 open medium alert here (below auto-heal bar). Org-wide alert read denied on 28 of 34 repos — coverage is 18%.
Control-Plane Integrity	✅	SHA pins (136 refs), strip-only TS, permissions on all 29 workflows, guards at 100% mutation score.
Code Quality	⚠️	All four gates green, but Manage Issues failed 12 consecutive scheduled runs unnoticed; fix merged, unverified.
Oversight	⚠️	4 repos red on default branch; 6 Fro-Bot security PRs abandoned 79–88 days; 53 stale PRs fleet-wide.
Cross-Project Intelligence	⚠️	31 of 34 tracked entries scannable (3 private, correctly excluded); one directly adoptable pattern.
Progressive Improvement	⚠️	TypeScript and Vitest each one major behind; @vitest/coverage-v8 misaligned inside its own minor. Learning pipeline healthy.

---

Errored PRs

None. Two remediation passes ran categories 1–4 today in branch-pr mode — 34671730863 and 34737127066 (summary on #3884). The second re-verified against live HEAD rather than inheriting the first's findings, which mattered: both Renovate PR heads were rebased between passes.

PR	Head	Checks	Review	Merge state	Auto-merge
#3884	bc55dd9	15/15 non-skipped green	REVIEW_REQUIRED	BEHIND	none
#3882	b16d79d (was ebbd3be)	19/19 non-skipped green	REVIEW_REQUIRED	BLOCKED	armed
#3877	9ffa2c4 (was e7dadb5)	17/17 non-skipped green	REVIEW_REQUIRED	BLOCKED	armed

Both check runs and legacy commit statuses were inspected on each head. Worth recording: gh pr checks on the current runner surfaces the legacy statuses (Security: Private Leak Scan, renovate/stability-days) alongside check runs, so the two API surfaces agreed here. All three PRs are blocked on human review, not CI. #3884 additionally has no auto-merge armed, so it will not land even after approval.

Security

• @humanfs/node — alert chore(deps): update bfra-me/renovate-config action to v1.13.0 #59, medium, GHSA-p498-v437-472g, < 0.16.8, patched in 0.16.8. Dev-scope, transitive through the ESLint toolchain in pnpm-lock.yaml. Below the critical/high bar that authorizes a dependency change; Renovate owns it. No PR opened by policy.
• Scorecard VulnerabilitiesID (high) is that same advisory re-badged, not independent signal. BranchProtectionID (high) asks to raise required approving reviews 1 → 2 on main — out of bounds by design.
• Org-wide visibility remains denied. The earlier pass probed dependabot/alerts across all 34 active repos: 6 readable, 28 returned 403. Zero high/critical in the readable slice — a statement about 18% of the fleet, not the fleet. Unchanged since 2026-09-11.

Control-Plane Integrity

Verified clean:

• 136 uses: references across 29 workflows and .github/actions/setup; every third-party ref is a 40-char SHA with a version comment. Zero floating tags. Re-run with explicit file enumeration rather than a ** glob, because an unexpanded glob returns clean and is indistinguishable from actually-clean.
• No enum, namespace, parameter properties, or import x = in scripts/*.ts. The only textual match is a comment in scripts/repos-metadata.ts:476 explaining why the pattern is avoided.
• All 29 workflows declare top-level permissions; four use permissions: {}. scorecard.yaml's read-all is the posture OpenSSF specifies.
• Guards intact: check-wiki-authority, check-private-leak, check-wiki-private-presence, wiki-context-safety, wiki-lockfile-gates all at 100% mutation score.

Code Quality

pnpm bootstrap → check-types → lint → test all green on main (79 test files, 3683 passed, 3 todo). check:mutation-guards clean.

The finding the gates could not see, and that the remediation pass got wrong. That pass reported "zero failing runs across the last 60 on any branch." This pass queried per workflow and found Manage Issues had failed twelve consecutive scheduled runs, daily from 09-01 through 09-12 (latest). Both readings were accurate; only one was true. gh run list --limit 60 bounds by run volume, not time — with 17 scheduled workflows plus PR suites, 60 runs is roughly half a day, so a daily-cadence workflow falls outside the window entirely.

Root cause is the live tail of a finding already in the wiki: dessant/lock-threads v6.0.0 validates github-token with Joi.string().max(100), the runner token outgrew it, and this repo's matchUpdateTypes: ['patch'], enabled: false Renovate rule made the upstream fix structurally undeliverable. #3880 landed the v6.0.2 pin by hand at 02:14 UTC today.

That fix is unverified. It merged after the last failing run; the first scheduled execution that can exercise it is ~06:15 UTC today. Do not mark this resolved until that run is green.

Oversight

Enumerated 38 repositories via paginated user/repos (affiliation=owner,collaborator,organization_member): 4 archived, 34 active, 0 private in the returned set. Enumeration is not provably complete — gh api user/orgs returns empty (token lacks read:org), so org membership is inferred from affiliation rather than enumerated. Treat 34 as a floor.

Headline: six Fro-Bot-authored security PRs have been abandoned for 79–88 days.

PR	Idle	Title
bfra-me/github-action#1463	88d	fix(security): pnpm overrides for esbuild and fast-uri
bfra-me/github-action#1466	88d	fix(security): pin vite to 8.0.16 (HIGH/MODERATE)
bfra-me/github-action#1467	79d	fix(security): pnpm overrides for esbuild and fast-uri
bfra-me/github-app#840	88d	fix(security): overrides for esbuild, fast-uri, undici
bfra-me/github-app#842	88d	fix(security): pin vite to 8.0.16 (HIGH/MODERATE)
bfra-me/github-app#843	88d	fix(security): overrides for esbuild, fast-uri, undici

This is the "merge gates sorted by authorship, not quality" pattern at its sharpest: verified security remediation, authored, green, and parked for three months. The Security section above reports one medium alert here while six high/moderate remediations sit undelivered two repos over. Remediation is being authored faster than it is landed — the constraint is the merge mechanism, not detection.

Red on default branch — 4 repos (down from 7 on 2026-09-11):

Repo	Workflow	Latest
marcusrbrown/marcusrbrown.com	Fro Bot	09-13, 5 consecutive
fro-bot/dashboard	Release	09-12
bfra-me/github-action	Update Repo Settings	09-12
marcusrbrown/extend-vscode	Publish	09-10

The marcusrbrown.com signature changed since the last report — no longer the OpenCode server bootstrap 5000 ms timeout, now APIError; status=400, with the harness logging Cannot post error comment: missing target context and no delivery surface was available to report it. The agent attempted to report its own failure and computed that no surface existed. A failure channel derived from trigger context is undefined on schedule.

Queue aggregates: 103 open PRs fleet-wide — 73 aging >7d, 53 stale >14d since last update. 175 open issues, 73 stale >30d, 5 opened in the last 24h. 4 unassigned bug-labeled issues (bfra-me/ha-addon-repository#569, marcusrbrown/marcusrbrown.com#517 and #465, marcusrbrown/systematic#740).

Top three hotspots (qualifying findings = red workflows + PRs aging >7d + issues stale >30d):

Rank	Repo	Total	Breakdown
1	marcusrbrown/gpt	32	15 aging PRs, 17 stale issues
2	marcusrbrown/vbs	25	10 aging PRs, 15 stale issues
3	marcusrbrown/tokentoilet	14	9 aging PRs, 5 stale issues

Recommended next steps. Merge or close the six abandoned bfra-me/* security PRs — that is the single highest-value action available and it needs no analysis. Triage gpt and vbs as a pair; their combined 57 findings are over a third of the fleet total and both are dominated by the unmerged-autoheal accretion already documented in the wiki. For marcusrbrown.com, the fix is a delivery target for scheduled failures, not another agent-pin bump.

Cross-Project Intelligence

Coverage: partial. metadata/repos.yaml tracks 34 entries — 28 last surveyed success, 3 failure (marcusrbrown/containers 09-12, marcusrbrown/dev-like 09-12, bfra-me/renovate-action 09-02), and 3 never surveyed. The 3 unsurveyed entries are private and correctly excluded by the public-only invariant — that is the gate working, not a coverage gap. Effective scannable surface is 31 of 31 public tracked repos, with 3 carrying stale survey data.

One directly adoptable finding: [[marcusrbrown--infra]]'s release-alert.yaml — a workflow_run-triggered failure alerter with a marker-based idempotent issue upsert, an owner-only synthetic self-test via workflow_dispatch, minimal issues: write, and a concurrency group. It consumes an event the platform already emits rather than polling.

This repository runs 17 scheduled workflows and has zero failure-alerting surface — no workflow_run failure listener anywhere (check-private-leak, private-leak-sentinel, and renovate use workflow_run, none for failure alerting). That absence is exactly why Manage Issues failed for twelve days unnoticed. The pattern is small, proven in-fleet, and addresses a defect this repo demonstrably has. Report-only per category rules; recorded below for action.

Progressive Improvement

Tool-version drift. Current-version truth from the npm registry (dist-tags.latest), queried live. Major drift is included and called out explicitly:

Package	Declared	npm latest	Drift
typescript	6.0.3	7.0.2	one major
vitest	4.1.11	5.0.0	one major
@vitest/coverage-v8	4.1.4	5.0.0	one major + 7 patches behind its own vitest line
@vitest/eslint-plugin	1.6.15	1.6.27	12 patches
prettier	3.9.1	3.9.6	5 patches
eslint	10.10.0	10.10.0	current
jiti	2.7.0	2.7.0	current

The @vitest/coverage-v8 misalignment is the one with a correctness consequence rather than a freshness one: Vitest expects the coverage provider to track core exactly, and the gap opened when the vitest security bump (#3873) advanced core without the provider.

Convention drift: none found against .github/copilot-instructions.md. Package manager, setup-action usage, type-safety posture, and scope discipline all hold.

Stale annotations: 1 TODO/FIXME across scripts/*.ts and .github/workflows/*.yaml. Not a backlog.

Learning pipeline: healthy. Zero open learning-proposal issues, against 59 authored docs in docs/solutions/. Neither stall condition (any proposal >14 days, or ≥2 open at once) is met. Per the category's own caveat, this is a direct measurement of the proposal queue rather than an inference from the Improvement Metrics report (#3674) — the two agree here, but the queue is the load-bearing reading.

Gateway Rollout Tracker (#3512)

Review-awareness only; no tracker comments or Project edits from this path.

Drift found — the Project board and the issue body disagree about how much work remains.

• Project 1 holds 21 items. Twenty are Done; the only non-Done item is Track cross-repo Gateway operator control-surface rollout #3512 itself, at Todo.
• Track cross-repo Gateway operator control-surface rollout #3512's body (updated 2026-09-13 02:13) lists four open workstreams: live operator capability verification against the deployed gateway, operator push deploy + VAPID enablement, dashboard consumption of contract v1.6.0 (fro-bot/dashboard#179), and the phase-1 monitoring tail.
• At least 12 referenced items have no Project item at all: fro-bot/agent Action Required: Fix Renovate Configuration #1033, Action Required: Fix Renovate Configuration #1109, Action Required: Fix Renovate Configuration #1111, chore(deps): update peter-murray/workflow-application-token-action action to v3.0.1 #1152, Action Required: Fix Renovate Configuration #1157, Action Required: Fix Renovate Configuration #1160, Action Required: Fix Renovate Configuration #1162, Action Required: Fix Renovate Configuration #1163, Action Required: Fix Renovate Configuration #1165, and fro-bot/dashboard chore(deps): update bfra-me/renovate-config preset to v1.23.0 #108, chore(deps): update bfra-me/renovate-action action to v2.1.6 #122, chore(deps): update bfra-me/renovate-action action to v2.2.4 #179. Board coverage stops at the Unit-3 / dashboard#81 era.

So the mismatch is not conflicting statuses on shared items — it is board completeness. Read alone, the board says the rollout is finished except for closing the tracker. The issue body says contract v1.6.0 shipped, push landed in v0.85.0 undeployed, and four threads are open. The board understates remaining work because the newer work was never added as items. Secondary: #3512 is Todo while being actively updated; In Progress would be truthful.

---

Needs Human Attention

Merge or close the six abandoned bfra-me/* security PRs (github-action #1463/#1466/#1467, github-app #840/#842/#843), idle 79–88 days. All are Fro-Bot-authored fix(security) changes for esbuild, fast-uri, undici, and vite advisories. This is the highest-value unblocked action in this report. Verify each is still green, then merge or close with a reason — leaving them open indefinitely manufactures the false impression that the advisories are being handled.

Manage Issues fix is merged but unverified. #3880 pinned dessant/lock-threads@89ae32b0 # v6.0.2 at 02:24 UTC after 12 consecutive daily failures. The first scheduled run that exercises it is ~06:15 UTC 2026-09-13. Verify with gh run list --repo fro-bot/.github --workflow "Manage Issues" --limit 3. If it is still red, the next hypothesis is a second Joi bound elsewhere in the action's input schema, not the token length. Do not revert to v6.0.0 or work around this by shortening the token.

Adopt a scheduled-failure alerter in fro-bot/.github. Root cause of the 12-day blind spot: 17 scheduled workflows, zero failure-alerting surface. Smallest safe fix is a new .github/workflows/schedule-alert.yaml modeled on marcusrbrown/infra's release-alert.yaml — on: workflow_run: {workflows: [...], types: [completed]}, if: github.event.workflow_run.conclusion == 'failure', permissions: {issues: write}, marker-based idempotent issue upsert, owner-gated workflow_dispatch synthetic self-test. Constraints: it must not use a derived delivery target (that is the defect in marcusrbrown.com); workflow_run only fires for workflows on the default branch; and per marcusrbrown/infra's own recorded lesson, an untested alert is a claim, not a control — ship the synthetic self-test with it. Verify by dispatching the self-test and confirming an issue appears. Not auto-healed here: category 6 is report-only and a new workflow file exceeds the scope cap.

@vitest/coverage-v8 is seven patches behind vitest within the 4.1 line (4.1.4 vs 4.1.11). Smallest safe fix is one line in package.json — "@vitest/coverage-v8": "4.1.11" — then pnpm bootstrap && pnpm coverage. Not applied: remediation passes may change versions only for a confirmed critical/high advisory. Needs a human or a Renovate run. Separately, typescript (6 → 7) and vitest (4 → 5) are each a full major behind; those are deliberate Renovate-owned decisions, not drift to fix reflexively.

@humanfs/node medium advisory (alert #59). Transitive via ESLint; no direct dependency to bump. Do not hand-edit pnpm-lock.yaml. If it escalates to high, the fix is a pnpm.overrides entry pinning >=0.16.8, verified with pnpm why @humanfs/node && pnpm bootstrap && pnpm test. Do not add it pre-emptively.

Org-wide security visibility is 18%. 28 of 34 active repos return 403 on dependabot/alerts. Every "no high/critical found" statement in this report's Security section is scoped to 6 repos. Fixing this requires a token with security_events across the org — an operator credential decision, not an agent action.

Gateway Project board is missing ~12 items (fro-bot/agent #1033/#1109/#1111/#1152/#1157/#1160/#1162/#1163/#1165, fro-bot/dashboard #108/#122/#179). Add them, or record explicitly that the board is frozen at the Unit-3 milestone and #3512's body is the sole source of truth. As it stands the board reads "done" to anyone who doesn't open the issue. Also flip #3512 from Todo to In Progress. Project writes are owned by the Gateway Rollout Tracker workflow, not this path.

Durable knowledge persisted this run. Unlike the branch-pr passes, this one could write. Added to knowledge/wiki/topics/github-actions-ci.md, with knowledge/index.md and knowledge/log.md updated: a new section A Fixed Run-Count Window Is a Time Window of Unknown Length (the --limit 60 measurement error, tabulated as the third health instrument alongside statusCheckRollup and per-workflow history), and an addendum to An Honest Red Signal Nobody Subscribes To (the marcusrbrown.com signature change and the structurally-dead scheduled error channel). Left uncommitted in the working tree for the caller's ingest step.

🤖 Generated by Fro Bot · run 34737127066

[fro-bot]

Second remediation pass — categories 1–4 (re-verification, no new breakage)

This is the day's second pass over categories 1–4. The first (run 34671730863) is already folded into the report body above. I re-ran the full sweep against current HEAD rather than trusting the earlier reading, because the PR heads have moved since.

Result: nothing broken, nothing to fix, no PR opened. Manufacturing a diff to justify a run is how control planes accumulate noise. The delta worth reporting is what moved, not what I touched.

What moved since the first pass

Both Renovate PRs were rebased — new head SHAs, full check suites re-run, still green. The first pass's own PR is open and green.

PR	Head then → now	Checks	Review	Merge state	Auto-merge
#3884 fix/readme-workflow-inventory-drift	— → bc55dd9	15/15 non-skipped green	REVIEW_REQUIRED	BEHIND	none
#3882 renovate/pnpm-11.x	ebbd3be → b16d79d	19/19 non-skipped green	REVIEW_REQUIRED	BLOCKED	armed
#3877 renovate/github-actions	e7dadb5 → 9ffa2c4	17/17 non-skipped green	REVIEW_REQUIRED	BLOCKED	armed

Zero failing runs across the last 60 on any branch.

1. Errored PRs — none

Inspected both surfaces on each head SHA. In this repo the two legacy commit-status records — Security: Private Leak Scan and renovate/stability-days — surface in gh pr checks and in GET /commits/{sha}/status, and both report success.

Worth correcting for the next pass: the operating premise that gh pr checks enumerates check runs only is not true of the gh build on this runner — it surfaced the legacy statuses too. Checking both surfaces remains the right discipline, since that behavior is version-dependent and a silent legacy failure is exactly what hides in the gap. Here the two views agree, so nothing is concealed between them.

2. Security — unchanged, still below the bar

One open Dependabot alert: @humanfs/node (alert #59, medium, GHSA-p498-v437-472g, symlink-following recursive copy, < 0.16.8, patched in 0.16.8). Dev-scope, transitive through the ESLint toolchain in pnpm-lock.yaml. Medium sits under the critical/high bar that authorizes a dependency change in this pass. No PR opened by policy, not by omission.

Scorecard's VulnerabilitiesID (high) is that same advisory wearing a different badge — not independent signal. BranchProtectionID (high) asks to raise required approving reviews from 1 to 2 on main; branch protection is a surface I am forbidden from touching, and that prohibition is correct.

3. Control-plane integrity — clean

• SHA pinning: 136 uses: references across 29 workflows and .github/actions/setup. Every third-party reference resolves to a 40-character SHA carrying a version comment. Zero floating tags, zero bare pins. I re-ran this with an explicit find rather than a ** glob — an unexpanded glob returns clean and looks identical to actually-clean, and I would rather not report a false negative dressed as a pass.
• Strip-only TypeScript: no enum, namespace, parameter properties, or import x = aliases in scripts/*.ts. The sole textual match is the comment at scripts/repos-metadata.ts:476 explaining why the pattern is avoided — the guardrail documenting its own absence.
• Least privilege: all 29 workflows declare top-level permissions. Four use permissions: {} and mint scoped tokens per job. scorecard.yaml's read-all is the posture OpenSSF specifies for that workflow. Nothing over-broad.
• Guards: intact and unweakened. check-wiki-authority, check-private-leak, check-wiki-private-presence, wiki-context-safety, and wiki-lockfile-gates all hold 100% mutation score under check:mutation-guards. This pass wrote nothing to knowledge/** or metadata/**.

4. Code quality — all gates green

pnpm bootstrap → check-types → lint → test pass on main: 79 test files, 3683 passed, 3 todo. check:mutation-guards clean. Working tree free of generated-artifact drift after pnpm build.

The README workflow-inventory drift the first pass found is already fixed in #3884 — I verified the fix is correct (29 workflow files on disk, 29 claimed, three previously-omitted rows restored) and did not open a duplicate.

---

Needs Human Attention

All three open PRs are blocked on a human, not on CI. Every one is green and MERGEABLE. I do not approve or merge. One detail the first pass didn't surface: #3884 has no auto-merge armed, unlike the two Renovate PRs — so even once reviewed it will not land on its own. If you want it to behave like the others, arm auto-merge; otherwise it needs an explicit merge.

@vitest/coverage-v8 is still seven patches behind vitest — unchanged since the first pass, restated deliberately rather than assumed seen. package.json declares vitest@4.1.11 and @vitest/coverage-v8@4.1.4; the gap opened when the vitest security bump (#3873) advanced core without the provider. Vitest expects the provider to track core exactly. Smallest safe fix: one line in package.json — "@vitest/coverage-v8": "4.1.11" — then pnpm bootstrap && pnpm coverage to confirm the provider loads and reports. Not applied here: this pass may change dependency versions only for a confirmed critical/high advisory or to repair a security PR, and this is neither. Needs a human or a Renovate run.

@humanfs/node medium advisory (alert #59). Transitive via the ESLint toolchain; there is no direct dependency to bump. Do not hand-edit pnpm-lock.yaml — the correct path is an upstream ESLint bump via Renovate. If it ever escalates to high, the smallest safe fix is a pnpm.overrides entry pinning @humanfs/node to >=0.16.8, verified with pnpm why @humanfs/node followed by pnpm bootstrap && pnpm test. Do not pre-emptively add that override — overriding a transitive of ESLint risks resolution drift for no current security benefit.

Durable knowledge this pass surfaced and cannot persist. Two items, both dying here unless captured by a run dispatched with output-mode: working-dir (knowledge/** is off-limits from branch-pr passes by design):

1. A ** glob that silently fails to expand reports identically to a clean scan. Any control-plane audit whose "pass" is an empty match set must prove the file set was non-empty — assert the denominator, not just the absence of violations. This pass's SHA-pin check now confirms 136 references were actually examined. A guard that cannot distinguish "nothing wrong" from "nothing looked at" is not a guard.
2. Running the same sweep twice in one day is not redundant when heads move. Two of three PR heads were rebased between passes; a report citing the earlier SHAs would have been stale within hours. Re-verification against live HEAD is cheap; inherited findings are not trustworthy across a rebase.

🤖 Generated by Fro Bot · run 34737127066

[fro-bot]

Remediation Pass — 2026-09-14 (UTC) · categories 1–4

Run Summary

Category	Status	Notes
Errored PRs	✅	4 open PRs, all green on check runs and legacy commit statuses. Nothing to repair.
Security	✅	1 open alert: medium, dev-scope, transitive. Below the auto-heal bar; Renovate owns it.
Control-Plane Integrity	✅	100/100 third-party uses: SHA-pinned with version comments; no strip-only TS drift; permissions on all 29 workflows; guards at 100% mutation score.
Code Quality	✅	bootstrap → check-types → lint → test all green. 79 files, 3683 passed, 3 todo.

No branch was cut and no PR was opened. Nothing in categories 1–4 met the bar for a minimal, reversible fix. The one genuinely broken thing this pass found is out of bounds for it by design — see Needs Human Attention.

---

1. Errored PRs

Zero. Both API surfaces were inspected on each head SHA, not just gh pr checks:

PR	Head	Author	Check runs	Legacy statuses	Merge state
#3886	d3406b0	app/fro-bot	15/15 non-skipped green	success (1)	BLOCKED
#3884	bc55dd9	fro-bot	15/15 non-skipped green	success (1)	BEHIND
#3882	b16d79d	app/fro-bot	16/16 non-skipped green	success (2)	BLOCKED
#3877	f32759e	app/fro-bot	15/15 non-skipped green	success (1)	BLOCKED

All four are blocked on human review, not CI. BLOCKED/BEHIND is branch protection doing its job, not a defect.

Three failed scheduled runs on main live outside the PR surface, found by querying per workflow rather than trusting a flat gh run list window — a daily-cadence workflow falls outside a 60-run page on this repo, which is exactly how twelve consecutive Manage Issues failures hid until yesterday:

• Manage Issues — healed. fix(ci): unbreak the Manage Issues lock job #3880 landed the dessant/lock-threads v6.0.2 pin; the 2026-09-13 06:37 run is green. Yesterday's report left this "unverified"; it is now verified.
• Update Repo Settings (34749562555) and Scorecard (34749640123) — both failed inside the same three-minute window on 2026-09-13 (09:28–09:31 UTC). Update Repo Settings logged 502, 502, 500, 500 on retry before giving up; Scorecard died mid-Uploading results to code-scanning with no error text at all. That is one upstream GitHub API degradation, not two repo bugs. No code change is warranted; the next scheduled run heals both. I did not re-run Update Repo Settings — it applies branch protection, and this pass does not touch branch protection even to reassert already-committed state.
• Merge Data Branch (34790889509) — a real block. Detailed below.

2. Security

One open Dependabot alert. Source of truth: this repo's dependabot/alerts API, cross-checked against the advisory's own first-patched-version field.

• @humanfs/node — alert chore(deps): update bfra-me/renovate-config action to v1.13.0 #59, GHSA-p498-v437-472g, medium, vulnerable < 0.16.8, first patched 0.16.8. development scope, pnpm-lock.yaml, transitive under eslint@10.10.0 via @bfra.me/eslint-config. Below the critical/high threshold that authorizes a dependency change in this pass. No version bumps were performed in this run, major or otherwise. Renovate owns it; the correct path is an upstream ESLint bump, not a hand-edited lockfile.

Four open Scorecard code-scanning alerts, none of them independent signal: VulnerabilitiesID (high) is the @humanfs/node advisory re-badged; BranchProtectionID (high) asks to raise required approving reviews 1 → 2 on main, which is explicitly out of bounds; FuzzingID and CIIBestPracticesID are posture, not defects.

3. Control-Plane Integrity

• SHA pinning — 136 uses: references across 29 workflows plus .github/actions/setup. 36 are local ./ refs; of the remaining 100 third-party refs, 100 carry a 40-character SHA with a # vX.Y.Z comment. Zero floating tags, zero bare SHAs. Enumerated with explicit file lists rather than a ** glob — an unexpanded glob returns clean and is indistinguishable from actually-clean.
• Strip-only TypeScript — no enum, namespace, parameter properties, or import x = anywhere in scripts/*.ts. Test Scripts Load and the erasable-syntax rule agree.
• Least privilege — all 29 workflows declare top-level permissions. Twenty-four are contents: read (or that plus one read scope), four are permissions: {}, and scorecard.yaml is read-all, which is the posture OpenSSF specifies. No write-all, no top-level write scope anywhere. Every workflow that runs pnpm or node scripts/ uses ./.github/actions/setup — no ad-hoc setup drift.
• Guard integrity — check:mutation-guards clean. check-wiki-authority.ts, check-wiki-private-presence.ts, wiki-context-safety.ts, and wiki-lockfile-gates.ts all hold 100% mutation score with zero survivors. Nothing weakened, nothing relaxed. This run wrote nothing to knowledge/** or metadata/**.

4. Code Quality

pnpm bootstrap → pnpm check-types → pnpm lint → pnpm test all green on main. 79 test files, 3683 passed, 3 todo, 22s. check:wiki-write-core-dist reports dist up to date; check:mutation-guards clean. Working tree clean afterward — no generated-artifact drift.

No mechanical lint or format fixes were available, so no PR branch was cut.

---

Needs Human Attention

data → main promotion is blocked, and the next automatic retry is six days out.

The 🔒 Block private wiki pages step in .github/workflows/merge-data.yaml failed the 2026-09-13 promotion with check-wiki-private-presence: BLOCKED — unattributable wiki repo pages detected. The gate is working correctly. This is the privacy boundary refusing to promote, not a bug in the gate.

• Root-cause shape: one or more pages under knowledge/wiki/repos/ on data have a stem absent from the public slug map derived from metadata/repos.yaml, and a content hash differing from the grandfathered copy on main. Per scripts/check-wiki-private-presence.ts:233-241, content-identity grandfathering only spares a page byte-identical to main; a page whose repo went private or lost access and was then modified on data fails closed.
• Window: the 2026-09-06 promotion succeeded and the 2026-09-13 one did not, so the offending change landed on data inside that week.
• Blast radius: merge-data.yaml runs on cron: '0 22 * * 0' — weekly, Sundays. The next unattended attempt is 2026-09-20 22:00 UTC. Until then every wiki ingest, metadata write, and reconcile commit accumulates on data unpromoted.
• Smallest safe fix: run check-wiki-private-presence.ts locally against a data checkout — it has a verbose operator mode that prints full page identities, unlike the CI path, which is deliberately counts-free. Then reconcile the offending entries on data (restore public attribution in the page's frontmatter sources, or remove the orphan entry) and dispatch Merge Data Branch manually rather than waiting for Sunday.
• Do not retry blindly: a stale branch copilot/fix-data-orphan-private-repos (commit 8ea9588, 2026-06-01, a 24-line deletion from metadata/repos.yaml) looks like a fix for this exact failure mode. It is 321 commits behind data and was never merged. Do not cherry-pick it as-is; it addresses a June-era state of repos.yaml. Treat it as evidence this failure mode recurs, not as a patch.
• Why this pass did not fix it: the remediation lives on the data branch and touches knowledge/** and metadata/**. Both are off-limits from a branch-pr run — Check Wiki Authority rejects them against main regardless, and the control plane's data branch is the authoritative writer.
• Verify with: a manual gh workflow run merge-data.yaml that reaches the promotion-diff step and exits 0.

Scheduled-cadence drift between the README and reality. Poll Invitations is documented as every 15 minutes and is actually firing roughly every 2 hours; Update Repo Settings is documented daily at 04:05 UTC and last fired at 09:28. This is GitHub's best-effort cron delivery, not a repo defect — the cron expressions declare intent correctly. Flagging it only because "last run was 19 hours ago" reads as a broken workflow during triage when it is not. No change recommended.

@humanfs/node alert #59 stays open by policy. Transitive, dev-scope, medium. Do not hand-edit pnpm-lock.yaml to close it.

#3884 has no auto-merge armed. It is green and its claim holds under independent verification: README.md says 25 workflows against 29 on disk, and its Automation tables enumerate 26, omitting exactly the three rows the PR adds (Cross-Repo Dispatch, Publish Wiki, Unpublish Wiki). It will sit BEHIND indefinitely until someone reviews and merges it. Nothing to repair.

Durable knowledge this run surfaced but cannot persist. Two items, both wiki-worthy, neither writable from a branch-pr pass:

1. Run-history queries must be bounded by workflow, not by page size. gh run list --limit N bounds by run volume; on a repo with 29 workflows a 60-run page is roughly half a day, so any daily-or-slower workflow is structurally invisible to it. Yesterday's Manage Issues finding and today's Merge Data Branch finding were both reachable only via per-workflow queries. The generalizable rule: a flat run-list window silently excludes low-cadence workflows, and a clean read from it is not evidence of health.
2. Correlated same-window failures across unrelated workflows are an upstream incident until proven otherwise. Three workflows failing inside three minutes with 500/502/silent-truncation signatures is one cause, not three. Diagnosing them independently burns a pass; the cheap discriminator is timestamp clustering, checked before reading any logs.

A run dispatched with output-mode: working-dir can write these to knowledge/ or docs/solutions/. From here they die in this comment.

🤖 Generated by Fro Bot · run 34805298521

[fro-bot]

Superseded by the 2026-09-14 report: #3892