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

[fro-bot]

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

Run Summary

Category	Status	Notes
Errored PRs	✅	Remediation pass found none. Both open PRs (#3897, #3882) green on check runs and legacy commit statuses. Three non-PR run failures in the last 200 runs all self-healed. Evidence: remediation comment.
Security	⚠️	This repo: 1 open alert (@humanfs/node, medium, dev-scope, transitive) — below the auto-heal bar, Renovate owns it. Org-wide partial: Dependabot readable for 6 repos, 403 for 28.
Control-Plane Integrity	❌	Pinning / strip-only TS / least-privilege / guards all clean. Merge Data Branch still blocked at its privacy gate since 2026-09-13; stranded commits on data 47 → 52. Next unattended retry 2026-09-20.
Code Quality	✅	Remediation pass ran the full gate on clean main: bootstrap → check-types → lint → test, 79 files / 3687 passed / 21.3s, zero autofixable drift.
Oversight	❌	38 repos enumerated, all public, 4 archived. 112 open PRs, 68 fro-bot-authored, 48 of those stale >30d. 3 repos genuinely red on default branch — including a 3-day silent Fro Bot outage at marcusrbrown/marcusrbrown.com.
Cross-Project Intelligence	⚠️	34 tracked entries scanned (3 private, withheld). Coverage partial — 2 surveys concluded failure, 3 never surveyed. One directly adoptable pattern found; cross_repo_receipts declared in schema and set on zero entries.
Progressive Improvement	⚠️	5 learning-proposal issues open, all 4 days old, zero authored; newest docs/solutions/ entry is 10 days old. Four tools a major behind per the npm registry. TODO/FIXME debt zero.

---

Errored PRs

None. Not re-analyzed here — the remediation pass covered categories 1–4 in branch-pr mode and left its evidence at issue #3898, remediation comment. It cut no branch, made no commit, opened no PR, because nothing cleared the minimal-and-reversible bar.

• #3897 chore(deps): update bfra-me/.github action to v4.30.0 — check runs green, legacy status Security: Private Leak Scan green, combined state success.
• #3882 chore(deps): update pnpm to v11.27.0 — check runs green, legacy statuses renovate/stability-days + Security: Private Leak Scan green.

Both Renovate-authored under the fro-bot identity, both MERGEABLE, both waiting on a required approving review. Review latency, not CI failure.

The remediation pass also swept 200 recent workflow runs and cleared three non-success conclusions as self-healed: two Renovate transients (2026-09-15, 2026-09-17) superseded by green runs, and a Survey Repo failure (2026-09-15) fixed in ab09c24 / #3895 with four consecutive green surveys since.

Security

This repo (⚠️): one open Dependabot alert, unchanged for a third day — #59, @humanfs/node / GHSA-p498-v437-472g, medium, CVSS 0, scope development, patched in 0.16.8. pnpm why confirms it arrives solely through eslint@10.10.0 via @bfra.me/eslint-config. Below the critical/high threshold that authorizes a dependency change; Renovate owns routine bumps. No version changed.

The four open code-scanning alerts remain OpenSSF Scorecard results, not code findings: VulnerabilitiesID re-reports the same advisory, BranchProtectionID wants 2 required approving reviews on main against the current 1.

Org-wide (❔ coverage, unchanged posture): Dependabot alerts were readable for 6 repositories (all fro-bot/*, all reporting 0 open) and returned 403 Resource not accessible by personal access token for 28 others across marcusrbrown/* and bfra-me/*. Org-wide security posture is unknown, not clean.

Control-Plane Integrity

Verified clean by the remediation pass and not re-derived here: 100 uses: references across 29 workflows and .github/actions/setup/action.yaml, covering 21 distinct third-party actions, every one a full 40-hex SHA with a version comment; no enum/namespace/parameter-properties/import-alias in scripts/*.ts (erasableSyntaxOnly: true at eslint.config.ts:28 plus Test Scripts Load); all 29 workflows declaring top-level permissions, 24 at contents: read; Check Wiki Authority intact and all 14 required contexts still listed in .github/settings.yml.

The promotion block is now five days old and compounding.

origin/main..origin/data   52 commits   (47 on 2026-09-17, +5)
oldest  2026-09-06
newest  2026-09-17

Merge Data Branch failed 2026-09-13 at 🔒 Block private wiki pages (run 34790889509) and is a Sunday-only cron, so 2026-09-20 is the next unattended attempt. Twelve days of wiki and metadata writes sit behind a gate that is working exactly as designed. Diagnosis is on #3896 and unchanged; remediation requires writing data's metadata/repos.yaml, which neither pass today is permitted to touch.

Code Quality

Not re-run here. The remediation pass executed the repository's own gate on a clean tree at ab09c24:

pnpm bootstrap    ✅
pnpm check-types  ✅   build-wiki-write-core + tsc --noEmit
pnpm lint         ✅   md-links, override-floors, solutions-examples, eslint
pnpm test         ✅   79 files | 3687 passed | 3 todo | 21.3s

git status clean afterward — no mechanical fix existed to commit.

Oversight

Enumeration. 38 repositories returned with read access via paginated user/repos (affiliation=owner,collaborator,organization_member): 14 fro-bot/*, 17 marcusrbrown/*, 7 bfra-me/*. All public. 4 archived. GET /user/orgs returned zero organizations — the fro-bot account holds no org membership, so every repo above is reached by collaborator affiliation. One coverage caveat worth naming: issue/PR search surfaced 5 additional marcusrbrown/* repositories (dormant forks, all last touched 2016–2024) that the affiliation listing did not return. Enumeration is therefore near-complete, not provably complete.

Queue. 112 open PRs and 159 open issues across the three owners.

Cut	Count
Open PRs	112
— fro-bot / fro-bot[bot] authored	68
— aging >7d (by creation)	83
— stale >14d (by last activity)	63
— fro-bot-authored and stale >30d	48
Open issues	159
— stale >30d	61
— opened in the last 24h	13
— bug-labeled and unassigned	6

Every one of the 63 PRs stale past 14 days is also stale past 30. There is no middle band — the queue is bimodal: recently-touched or abandoned, nothing in between. 48 of the 63 are Fro Bot's own.

Three repos genuinely red on their default branch. This number required care, and the methodology matters more than the number:

Query	Repos reported red
any failure in /commits/{ref}/check-runs	15
latest record per check name	3

Check runs append per re-run rather than replacing, so the raw endpoint returns every transient failure a long-lived main commit ever experienced. The naive query manufactures a fleet-wide emergency out of Renovate retry noise. The legacy /commits/{ref}/status rollup fails the opposite way — state read pending for all 34 non-archived repos while three were broken. Persisted to the wiki as a durable methodology finding.

• marcusrbrown/marcusrbrown.com — Fro Bot red. Four consecutive scheduled-run failures (2026-09-16 15:37 → 2026-09-18 03:36 UTC), each dying on APIError; status=400 after three grace cycles, each ending on Agent execution failed with a recoverable LLM error, and no delivery surface was available to report it (latest run). Every non-schedule trigger in the window concluded skipped, so the run list reads as routine. A sibling repo's autoheal loop has been dead for three days and the only artifact saying so is a red check. Next step: this is a fro-bot/agent harness-side failure, not a repo-config failure — investigate the persistent 400 against that account's model routing before touching the workflow.
• bfra-me/github-action — Update Repo Settings / Update Repository Settings red since 2026-09-17 19:41. Log tail shows only post-job cleanup plus a deprecation warning (Input 'app-id' has been deprecated with message: Use 'client-id' instead); the real failure is upstream of the visible tail. Next step: owned by bfra-me, not this control plane — report only.
• marcusrbrown/extend-vscode — Pre-Release Validation (vulnerabilities) red since 2026-09-17 01:03. A vulnerability gate failing is a finding, not a flake. Next step: the repo still has no Fro Bot workflow (~11 weeks per the wiki), so nothing will autoheal this; it needs a human or an onboarding.

Top three hotspots, ranked by qualifying findings in this snapshot (stale PRs + stale issues + unassigned bugs + red CI, the last weighted ×3):

1. marcusrbrown/gpt — 34. 15 stale PRs, 19 stale issues. Includes the ollama-contrast cluster the wiki has tracked across three surveys: six open Fro Bot PRs for one defect (#2664, #2665, #2672, #2673, #2674, #2692), oldest from 2026-07-08. Next step: close five, rebase one — a daemon that re-derives the same fix weekly is reporting a severed merge path, not a hard bug.
2. marcusrbrown/marcusrbrown.com — 14. 6 stale PRs, 3 stale issues, 2 unassigned bugs, red CI. Next step: the dead autoheal loop above is the root; the stale queue is downstream of it.
3. marcusrbrown/vbs — 13. 8 stale PRs (7 of them fix(security): remediations dating to July), 5 stale issues. Next step: the security overrides are one-line lockfile pins with no reviewer; batch-review them or turn on automerge for fro-bot-authored security PRs the way mrbro-bot[bot] already has.

Unassigned bug-labeled issues (6): marcusrbrown/infra#1365, marcusrbrown/systematic#992, marcusrbrown/systematic#740, marcusrbrown/marcusrbrown.com#517, marcusrbrown/marcusrbrown.com#465, bfra-me/ha-addon-repository#569. Two opened in the last 24 hours. Next step: triage the two fresh ones; the other four have aged past the point where assignment alone helps.

No issue or PR was modified, labeled, or commented on from this category.

Cross-Project Intelligence

Coverage: partial. All 34 entries in metadata/repos.yaml were read (the authoritative data-branch snapshot restored into this run's working tree). Three are private and are neither named nor described here. Breakdown: 30 private: false, 3 private: true, 1 with the field absent. Survey state: 29 success, 2 failure (marcusrbrown/containers and marcusrbrown/dev-like, both 2026-09-12), 3 never surveyed (all pending, all private). Onboarding: 30 onboarded, 1 lost-access, 3 pending.

Automation coverage gaps among tracked entries: 7 carry no Fro Bot workflow (marcusrbrown/ha-config, marcusrbrown/.github, marcusrbrown/esphome.life, marcusrbrown/extend-vscode, fro-bot/fro-bot.github.io, fro-bot/systematic, marcusrbrown/Presentations) and 4 carry no Renovate. marcusrbrown/extend-vscode appears in both that list and today's red-CI list, which is not a coincidence — it has no loop that could have caught it.

One directly adoptable pattern, and it addresses today's worst finding.

marcusrbrown/infra/.github/workflows/release-alert.yaml is a 60-line workflow_run consumer: types: [completed], permissions: issues: write and nothing else, if: conclusion == 'failure', marker-keyed issue upsert so an N-run outage yields one issue rather than N — plus an owner-gated workflow_dispatch synthetic self-test that exercises the alert path without needing a real failure. Two independent failures today are exactly what it catches: this repo's Merge Data Branch (silent between Sundays) and marcusrbrown/marcusrbrown.com's schedule-mode agent (silent for three days). The wiki already carried the pattern; today supplies the second and third measured instances of not having adopted it. Adoption cost is one file and one permission.

One documented capability with zero instances. metadata/README.md specifies cross_repo_receipts: coordination-issue-v1 as an operator-declared capability on tracked entries and names three backfill candidates from #3652 (marcusrbrown/gpt, fro-bot/agent, fro-bot/dashboard, all of which posted accepted coordination receipts). Zero of 34 entries set the field. Every cross-repo dispatch target is therefore classified legacy-best-effort, and a missing receipt is diagnostic-only fleet-wide. That is the documented default and not a bug — but the gap between a documented routing gate and zero instances of it is worth naming before the next cross-repo goal runs. Writing it requires the data branch; out of scope for both passes today.

Two other patterns observed but not recommended for adoption here: bfra-me/.github's single unified fro-bot.yaml (this repo already splits into fro-bot / fro-bot-remediate / fro-bot-observe, which is the stronger form) and marcusrbrown/infra's disjoint-capability job split (already the effective structure here).

No changes were made in this category.

Progressive Improvement

Tool-version drift. Current-version truth is the npm registry (npm view <pkg> version), queried this run. Major drift was included in the comparison and is called out explicitly:

Tool	Pinned	Registry latest	Drift
typescript	6.0.3	7.0.2	major
vitest	4.1.11	5.0.1	major
@vitest/coverage-v8	4.1.4	5.0.1	major
pnpm (packageManager)	11.25.0	12.4.2	major
prettier	3.9.1	3.9.8	patch
eslint-plugin-prettier	5.5.0	5.5.6	patch
eslint-config-prettier	10.1.1	10.1.8	patch
@bfra.me/eslint-config	0.52.1	0.52.2	patch
@bfra.me/prettier-config	0.16.0	0.16.11	patch
@bfra.me/tsconfig	0.13.0	0.13.2	patch
eslint	10.10.0	10.10.0	current
@stryker-mutator/core	10.0.0	10.0.0	current

@types/node sits at 24.13.2 against a registry latest of 26.6.1, deliberately — it tracks the Node 24 runtime pinned in mise.toml, so that is a floor decision, not drift. Worth noting that the open pnpm PR #3882 moves 11.25.0 → 11.27.0, which is still a full major behind the registry; merging it does not close the gap it appears to address. Renovate owns all of these; nothing was changed.

The compounding pipeline is stalled, and the metrics report cannot see it. Five learning-proposal issues are open — #3887, #3888, #3889, #3890, #3891 — all created 2026-09-14, all 4 days old, none yet authored into docs/solutions/. The expected action for each is one document. Two or more open at once is the stall threshold, and this is five. None has crossed 14 days yet, so the age signal is still recoverable; the count signal is not.

The corroborating evidence is the corpus itself: 59 documents in docs/solutions/, and the newest is dated 2026-09-08 — ten days ago, four days before the current proposals were even raised. Meanwhile Improvement Metrics (#3674) last ran 2026-09-14 and reports healthy with discovery 26 against prior-window 14. That reading is structurally incapable of contradicting the stall: unauthored proposals never become codified classes, so they never enter the discovery count, and the report stays green precisely while the queue backs up. The report is also now 4 days stale (workflow_dispatch-only, no schedule).

Convention drift: none found. README.md's claim of 29 workflows matches the tree exactly. TODO/FIXME annotations in scripts/*.ts: zero outside a test fixture string. No missing or degraded CI jobs in this repo — all 14 required contexts present and green on both open PRs.

Gateway Rollout Tracker (#3512)

Review-awareness only; no tracker comment posted and no Project field edited. Both values reported, as required.

Drift 1 — a closed issue tracked as open, for 68 days. #3512's workstream table row reads:

| Dashboard | Cancel UI (fro-bot/dashboard#179) | Open | Cancel button consuming POST /operator/runs/:runId/cancel …

Live state: fro-bot/dashboard#179 is CLOSED, last updated 2026-07-11. Tracker says Open; GitHub says CLOSED.

Drift 2 — release evidence ~28 minors stale. #3512 records releases since advanced to v0.85.0; deployed gateway pinned at v0.83.0. The live fro-bot/agent latest release is v0.113.2, published 2026-09-16. Tracker says v0.85.0; the release source says v0.113.2. The deployed-pin claim (v0.83.0) is not independently verifiable from here and is reported as unconfirmed rather than wrong.

Drift 3 — the Project board and the tracker issue describe different projects. Project 1 holds 21 items: 20 Done, 1 Todo — and the single Todo is #3512 itself. But the board's Done items are the early gateway spine (agent#907, #929, #931–#944, infra#579–#581, dashboard#24–#81), while #3512's table tracks a later set — agent#1033, #1109, #1111, the operator-push cluster #1152/#1157/#1160/#1162/#1163/#1165, dashboard#108, dashboard#179 — none of which appear on the board at all. A reader of Project 1 sees 20/21 Done and concludes the rollout is essentially finished; a reader of #3512 sees Released but not deployed items blocked on VAPID secrets and an owed production-shaped R8 runtime confirmation. Board status Todo on #3512 versus issue body "stays open until deploy/live verification and security/R8 checks are done" is the only point where the two agree, and only by accident.

Summary: the tracker issue is the more accurate of the two surfaces and is itself wrong on at least two machine-checkable claims. The board has not been updated since the spine phase.

Needs Human Attention

1. data → main promotion, day 5. Stranded commits 47 → 52.

• Files: metadata/repos.yaml on the data branch (not main); scripts/check-wiki-private-presence.ts.
• Root cause (from #3896, unchanged): the blocking wiki page is an orphan with no repos.yaml entry on data, whose slug matches no repository the fro-bot token can enumerate, and whose content-identity grandfather dissolved when a re-survey changed it.
• Smallest safe fix: audit data's metadata/repos.yaml for entries lacking an explicit private field and resolve each to true/false. Exactly one entry currently lacks it (marcusrbrown/copiloting, onboarding_status: lost-access, public and archived), and it passes today on hash-match alone — it is the next page to fire.
• Do not: weaken or bypass the gate, add a slug allowlist, or dispatch Merge Data Branch hoping it clears. It will fail identically and produce no new diagnostic signal.
• Verify: local --operator-report run showing zero leaks → successful Merge Data Branch dispatch → git rev-list --count origin/main..origin/data returns 0.
• Requires a human on data. Neither of today's passes can write that path.

2. marcusrbrown/marcusrbrown.com autoheal has been dead for three days and cannot say so.

• Evidence: four consecutive scheduled-run failures, 2026-09-16 15:37 → 2026-09-18 03:36 UTC, all error: name=APIError; status=400 persisting through a 3-cycle grace period, all terminating on Cannot post error comment: missing target context → no delivery surface was available to report it. Latest: run 35303867785.
• Root cause is upstream of the repo. A persistent APIError 400 from the model API is not a workflow-config bug; the wiki records the same signature at that repo spanning six agent versions (v0.107.0 → v0.113.1), so version bumps neither caused nor fixed it. Start at the account's model routing / request shape, not at fro-bot.yaml.
• Do not "fix" this by removing the schedule trigger or relaxing the failure condition — that converts a visible outage into an invisible one.
• Verify: one scheduled run reaching the report-writing step, or a workflow_dispatch with an issue target that produces a comment.

3. No failure alarm exists for any fail-closed scheduled loop in this repo.

• Root cause: Merge Data Branch is a Sunday-only cron that fails closed and announces nothing. Detection latency therefore equals the cron period (up to 7 days), which is how a 5-day block reached day 5 with the only evidence being an agent running git rev-list --count twice on consecutive mornings.
• Smallest safe fix: add a workflow_run consumer keyed on Merge Data Branch completion that upserts a single marker-keyed issue when conclusion == 'failure'. Copy the shape from marcusrbrown/infra/.github/workflows/release-alert.yaml: permissions: issues: write only, no checkout, if: github.event.workflow_run.conclusion == 'failure', marker <!-- merge-data-failure:v1 -->, plus the owner-gated workflow_dispatch synthetic self-test that file already implements.
• Constraint: the alert body must carry counts and run URLs only — never wiki page slugs, page paths, or repo names. The entire reason the gate fires is that a slug cannot be proven public; leaking it into a public issue would defeat the gate it reports on.
• Not auto-healed because it is a new workflow file, which is neither minimal nor reversible under the scope cap.
• Verify: dispatch the synthetic self-test, confirm exactly one issue opens; dispatch again, confirm it updates rather than duplicating.

4. marcusrbrown/gpt has six open Fro Bot PRs for one defect.

• Files: #2664, #2665, #2672, #2673, #2674, #2692 — all targeting ollama status/settings contrast, oldest 2026-07-08.
• Root cause: the fix is being re-derived because none of the prior attempts merged. This is a severed merge path presenting as a recurring bug.
• Smallest safe fix: review and merge the newest, close the other five referencing it. Do not have an agent author a seventh.
• Constraint: a human must merge; Fro Bot must not close its own PRs from an oversight pass.

5. The learning pipeline needs five documents written, and the metrics loop will not tell you when it is fixed.

• Files: five learning-proposal issues (Learning proposal: (e86b0877) #3887–Learning proposal: (31309d62) #3891), destination docs/solutions/<category>/<slug>-2026-09-DD.md with the YAML frontmatter the existing 59 entries use.
• Root cause: proposals accumulate; authoring is manual and has not happened since 2026-09-08.
• Constraint / warning: do not read #3674's healthy state as evidence this is fine. Unauthored proposals never become codified classes, so they cannot appear in its discovery count. The report is green because of the stall, not despite it. It is additionally 4 days stale (dispatch-only, no schedule).
• Verify: docs/solutions/ gains entries dated after 2026-09-08 and the open learning-proposal count drops below 2.

6. cross_repo_receipts is specified, documented, and set on zero of 34 tracked entries.

• Files: metadata/repos.yaml on the data branch; spec at metadata/README.md.
• Root cause: the field is operator-declared and no operator has declared it. Every dispatch target is legacy-best-effort by default, so a missing receipt is diagnostic-only fleet-wide.
• Smallest safe fix: set cross_repo_receipts: coordination-issue-v1 on the three entries metadata/README.md already names as backfill candidates from Triage PR and dependency queues across active repos #3652 — marcusrbrown/gpt, fro-bot/agent, fro-bot/dashboard. Leave marcusrbrown/containers and marcusrbrown/opencode-copilot-delegate unset; they completed Triage PR and dependency queues across active repos #3652 without accepted receipts.
• Do not write this on a main-targeting branch. repos.yaml is a data-branch sole-writer contract and a both-sides edit conflicts the promotion — which is already blocked (item 1).
• Verify: classifyReceiptCapability in scripts/cross-repo-dispatch.ts classifies those three as declared at dispatch time.

7. Gateway tracker #3512 carries two stale machine-checkable claims; Project 1 tracks a different phase entirely.

• Files: the workstream table in #3512's body.
• Corrections: fro-bot/dashboard#179 row Open → CLOSED since 2026-07-11; agent release evidence v0.85.0 → v0.113.2 (2026-09-16). The deployed gateway pinned at v0.83.0 claim is not verifiable from this pass and should be re-confirmed rather than assumed wrong.
• Separately: Project 1's 21 items cover only the early spine; none of Track cross-repo Gateway operator control-surface rollout #3512's later workstream rows are on the board, so its 20/21-Done reading is misleading about rollout completeness.
• Do not edit the tracker body or Project fields from the daily-report path — the dedicated Gateway Rollout Tracker workflow owns tracker writes. This is a report-only finding.

8. Repository enumeration is near-complete, not provably complete.

• GET /user/orgs returns zero organizations for the fro-bot identity, so all 38 repositories are reached by collaborator affiliation. Issue/PR search surfaced 5 additional marcusrbrown/* repositories (dormant forks, 2016–2024) that user/repos did not return. No finding was suppressed by this, but any future claim of "all repositories" should say which enumeration produced it.

Durable knowledge from this run was persisted. Two additions landed in knowledge/wiki/topics/github-actions-ci.md in this run's working tree, per knowledge/schema.md, both additive: a new section on check-run enumeration returning history rather than state (the 15-vs-3 false-positive result above), and a dated amendment under the existing A Scheduled Run That Fails Has No Delivery Surface section recording the four-run/three-day recurrence and pairing it with this repo's own Sunday-cron blind spot into the generalization that a fail-closed guard's detection latency is its trigger period, not its failure time. Logged to knowledge/log.md as a manual-edit entry with run-URL sources. No private repository is named or implied.

🤖 Generated by Fro Bot · run 35305361462

[fro-bot]

Remediation Pass — 2026-09-19 (UTC), categories 1–4

Delivery mode branch-pr. No branch cut, no commit, no PR opened. Nothing cleared the minimal-and-reversible bar, and the one finding worth acting on is out of reach from this run's write scope. Details below, including the two things that are genuinely broken and why I left them alone.

Category	Status	Outcome
1. Errored PRs	✅	2 open PRs, both green on check runs and legacy commit statuses. Nothing to repair.
2. Security	⚠️	1 open alert: medium, dev-scope, transitive. Below the critical/high bar that authorizes a dependency change. No version touched.
3. Control-Plane Integrity	❌	Pinning / strip-only TS / least-privilege / guards all clean. data → main promotion blocked 6 days; stranded commits 52 → 57. New finding: the Renovate global-config input is inert.
4. Code Quality	✅	Full gate green on clean main at ab09c24. Zero autofixable drift.

---

1. Errored PRs

None. Both open PRs inspected through both sources — gh pr checks for check runs and /commits/{sha}/status for legacy statuses, because those are separate record types and a green check-run list says nothing about the legacy set.

• #3897 chore(deps): update bfra-me/.github action to v4.30.0 — 16 check runs pass, 3 skipped by design (Fro Bot, Fro Bot — Observe, Fro Bot — Remediate). Legacy: Security: Private Leak Scan success. Combined state success.
• #3882 chore(deps): update pnpm to v11.27.0 — check runs pass. Legacy: renovate/stability-days + Security: Private Leak Scan success. Combined state success.

Both Renovate-authored under the fro-bot identity, both MERGEABLE. #3882 has been green and waiting since 2026-09-10 — nine days. That is review latency, not CI failure, and not something I'm permitted to resolve.

Workflow-run sweep across the last 60 runs found exactly one non-success: run 35267053073, Renovate, 2026-09-17. Six subsequent Renovate runs are green, the most recent at 2026-09-18T22:47. Self-healed as a run, but it left a real finding — see §3.

2. Security

One open Dependabot alert, unchanged for a fourth day: #59, @humanfs/node / GHSA-p498-v437-472g, medium, scope development, transitive via eslint. Medium does not authorize a dependency change under this run's rules; Renovate owns routine bumps. No version changed, no PR opened.

Four open code-scanning alerts, all OpenSSF Scorecard results rather than code findings:

Alert	Rule	Severity	Substance
9	VulnerabilitiesID	high	Re-reports the same GHSA-p498-v437-472g. Not an independent finding.
1	BranchProtectionID	high	Wants 2 required approving reviews on main; current is 1.
7	FuzzingID	medium	No fuzzing harness.
5	CIIBestPracticesID	low	No CII badge.

BranchProtectionID is a branch-protection setting. Out of bounds by construction — reported, not touched.

3. Control-Plane Integrity

Clean:

• SHA pinning — every third-party uses: across .github/workflows/*.yaml and .github/actions/**/action.yaml resolves to a full 40-hex SHA with a version comment. Regex sweep for floating tags (@v1, @main, @master, @latest) and for SHA pins missing a trailing comment both returned zero.
• Strip-only TypeScript — no enum, namespace, parameter properties, or TS import aliases in scripts/*.ts. erasableSyntaxOnly: true still live at eslint.config.ts:28, eslint-plugin-erasable-syntax-only still in package.json, Test Scripts Load still green.
• Least privilege — all 29 workflows declare a top-level permissions: block. No write-all. The only two contents: write grants are app-token scopes in status-truth.yaml:378 and wiki-lint.yaml:192, both for data-branch writes.
• Guards — Check Wiki Authority and Check Mutation Guards intact in main.yaml, both contents: read + pull-requests: read, both still PR-gated. Nothing weakened.

Broken — data → main promotion, day 6:

origin/main..origin/data   57 commits   (52 yesterday, 47 on 2026-09-17)
oldest  2026-09-06         newest  2026-09-18

Merge Data Branch last failed 2026-09-13 at its privacy gate (run 34790889509) and is a Sunday-only cron. Next unattended attempt is 2026-09-20. The gate is working exactly as designed; what's accruing is the cost of a fail-closed guard whose refusal nobody hears between Sundays. Diagnosis lives on #3896 and is unchanged. The fix requires writing metadata/repos.yaml on data, which this run is explicitly forbidden to touch. Carried to Needs Human Attention.

New finding — the Renovate global-config input is inert, and has been on every run:

.github/workflows/renovate.yaml:53-55 passes global-config: '{"autodiscover": false}' with a comment asserting it keeps Renovate scoped to this repository. It does not. The input is discarded on every single run, green ones included:

Error: Invalid JSON syntax in user global-config
Warning: User global-config is not valid JSON, falling back to base config

Root cause is upstream, in bfra-me/renovate-action@f9052be (10.39.0), reached through bfra-me/.github@0e881c3 (v4.29.0). The action interpolates the input into a double-quoted bash assignment:

user_global_config="${{ env.global_config }}"

GitHub substitutes textually, so bash sees user_global_config="{"autodiscover": false}", eats the inner quotes, and produces {autodiscover: false} — unquoted key, rejected by jq. Reproduced locally:

resolved -> [{autodiscover: false}]
jq: INVALID

Any JSON value passed to that input dies the same way. The quotes are the payload, and the shell eats them before jq ever sees them.

Second, independent reason the input can't work: the same reusable workflow computes autodiscover itself and passes it as an explicit action input —

AUTODISCOVER: ${{ github.event.repository.name == '.github' && !contains('["issues", "pull_request"]', github.event_name) && github.ref == 'refs/heads/main' }}

This repo is named .github, so on workflow_dispatch against main that evaluates true and Renovate autodiscovers regardless of any global config. The 2026-09-17 failure is the proof: that run scanned fro-bot/fro-bot.github.io and fro-bot/systematic, and a transient HTTPError 404 during the sweep took the whole run down with Repository has unknown error.

Not auto-healed, deliberately. No edit to our file prevents that failure — upstream forces autodiscover on, so deleting the inert input changes nothing at runtime and correcting the comment is cosmetics. Modifying a workflow file is gated on a failing run being caused by a genuine bug in that file, and the bug is two repos upstream. A comment-only edit that fixes no behavior does not earn that exception. Carried to Needs Human Attention with the full diagnosis.

4. Code Quality

Full gate, clean tree, main at ab09c24:

pnpm bootstrap    ✅
pnpm check-types  ✅   build-wiki-write-core + tsc --noEmit
pnpm lint         ✅   md-links, override-floors, solutions-examples, eslint
pnpm test         ✅   79 files | 3687 passed | 3 todo | 15.54s

git status clean after the full run. No lint or format autofix to commit, so no PR to open.

---

Needs Human Attention

1. data → main promotion, day 6. 57 commits stranded, growing ~5/day.

• Files: metadata/repos.yaml on the data branch (not main), scripts/check-wiki-private-presence.ts.
• Root cause: see #3896. The blocking page is an orphan with no metadata/repos.yaml entry on data, whose slug matches no repository the fro-bot token can enumerate.
• Smallest safe fix: audit data's metadata/repos.yaml for entries lacking an explicit private field and resolve each to true/false. Drains the tripwire class rather than defusing one instance.
• Do not: weaken or bypass the gate, add a slug allowlist, or dispatch Merge Data Branch hoping it clears — it will fail identically and produce no new diagnostic signal.
• Verify: local --operator-report run showing zero leaks → successful Merge Data Branch dispatch → git rev-list --count origin/main..origin/data returns 0.
• Reachable only from a working-dir run or a human on data. Not from branch-pr.

2. renovate.yaml's global-config input is a no-op and its comment documents a guarantee that does not exist.

• File: .github/workflows/renovate.yaml:52-56.
• Root cause: two independent failures, both upstream. (a) bfra-me/renovate-action@f9052be interpolates global-config into a double-quoted bash assignment, stripping the JSON's quotes and failing its own jq validation — any JSON value breaks identically. (b) bfra-me/.github@0e881c3 computes autodiscover from the repo name and passes it as an explicit action input, which overrides global config anyway; this repo is literally named .github, so autodiscover is forced on for workflow_dispatch/schedule runs against main.
• Smallest safe fix, in order of preference: file an upstream issue on bfra-me/renovate-action to quote the expansion (env-var indirection rather than textual interpolation), and one on bfra-me/.github for the unconditional .github-name autodiscover. Until then, correct the comment at renovate.yaml:53-55 so it states the input is currently inert and why — do not leave a comment asserting an isolation property the control plane does not have.
• Do not: delete the global-config input as a "fix." It is inert, not harmful, and removing it erases the declared intent that an upstream fix would restore. Do not try to work around the quote-stripping by reshaping the JSON — there is no valid JSON without double quotes.
• Verify: a Renovate run log that does not contain Invalid JSON syntax in user global-config, and whose repository sweep names only fro-bot/.github.
• Blast radius beyond this repo: every consumer of bfra-me/.github's reusable Renovate workflow that passes global-config is silently falling back to base config. Worth checking the marcusrbrown/* and bfra-me/* fleet.

3. Stale branch frobot/readme-pnpm-version-2026-08-17, 3 weeks old, no PR, now obsolete.

• Carries one commit (3e35723) changing README's pnpm pin from 11.9.0 to 11.19.0. main has since moved past it — the README now reads "pnpm 11 (exact version pinned in package.json under packageManager)", which is the strictly better version-agnostic fix.
• Action: delete the branch. Not done here — branch deletion is a hard boundary for this run.

4. Durable knowledge from this run, not persisted by design. branch-pr cannot write knowledge/**. Two items worth a working-dir run:

• A config input that fails validation silently is worse than one that fails loudly. The upstream action logs Error: and then continues with Warning: ... falling back to base config, exit 0. Months of green runs, and the isolation property the input was added to guarantee never once held. The tell was in the logs of the successful runs, not the failed one — which is the general lesson: a fallback path that logs at Error: severity but doesn't fail the step trains everyone to read the word "Error" as noise.
• Shell interpolation of workflow expressions is a quoting hazard, and JSON is its worst case. foo="${{ inputs.bar }}" is textual substitution, not variable expansion. Any value containing double quotes is restructured by the shell before the program sees it. JSON is pure double quotes, so it is maximally exposed. The fix is always env-var indirection — env: binding, then foo="$bar". Relates to the existing learning at docs/solutions/workflow-issues/required-github-token-for-agent-steps-2026-06-22.md, whose closing guidance — keep the comments honest about the mechanism, because a stale comment documents a false guarantee for the next reviewer — is exactly the failure in item 2.

🤖 Generated by Fro Bot · run 35420036459

[fro-bot]

Superseded by the 2026-09-19 report: #3900