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

[fro-bot]

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

Run Summary

Category	Status	Notes
Errored PRs	⚠️	No failing PRs — all 4 open PRs green on check runs and legacy statuses. But Merge Data Branch is blocked and the next unattended retry is 2026-09-20.
Security	⚠️	1 open alert here (medium, dev-scope, below the auto-heal bar). Org-wide alert read denied on 28 of 34 repos — coverage 18%. 20 Fro-Bot security PRs abandoned 34–89 days.
Control-Plane Integrity	✅	100/100 third-party uses: SHA-pinned with version comments, strip-only TS clean, permissions on all 29 workflows, four guard modules at 100% mutation score.
Code Quality	✅	bootstrap → check-types → lint → test all green. 79 files, 3683 passed, 3 todo.
Oversight	⚠️	7 repos red on default branch; marcusrbrown.com's Fro Bot has failed 15 consecutive scheduled runs since 09-07; 63 stale PRs, 82 stale issues, 4 of 4 bug-labeled issues unassigned. Enumeration is a floor, not a census.
Cross-Project Intelligence	⚠️	31 of 34 tracked entries surveyed, 28 successfully (3 private correctly excluded, 3 survey failures). One directly adoptable pattern with three confirmations of what its absence costs.
Progressive Improvement	⚠️	TypeScript, Vitest, and pnpm each one major behind; @vitest/coverage-v8 still misaligned inside its own minor. Learning pipeline healthy despite the ≥2-open trip.

---

Errored PRs

None failing. Reported by the remediation pass (run 34805298521, summary on #3885). That pass cut no branch and opened no PR — nothing in categories 1–4 met the minimal-and-reversible bar. Both check runs and legacy commit statuses were inspected on each head SHA:

PR	Head	Author	Checks	Merge state
#3886	d3406b0	app/fro-bot	15/15 non-skipped green + 1 legacy success	BLOCKED
#3884	bc55dd9	fro-bot	15/15 non-skipped green + 1 legacy success	BEHIND
#3882	b16d79d	app/fro-bot	16/16 non-skipped green + 2 legacy success	BLOCKED
#3877	f32759e	app/fro-bot	15/15 non-skipped green + 1 legacy success	BLOCKED

All four wait on human review, not CI. #3884 additionally has no auto-merge armed.

Off the PR surface, three scheduled failures on main:

• Manage Issues — healed and now verified. fix(ci): unbreak the Manage Issues lock job #3880's dessant/lock-threads v6.0.2 pin landed; the 09-13 06:37 run is green, closing yesterday's "unverified" caveat.
• Update Repo Settings (34749562555) and Scorecard (34749640123) — one upstream GitHub API degradation on 09-13 between 09:28 and 09:31 UTC (502,502,500,500 on one; silent mid-upload truncation on the other), not two repo bugs. Next scheduled run heals both.
• Merge Data Branch (34790889509) — genuinely blocked. Detailed under Needs Human Attention.

Security

• @humanfs/node — alert chore(deps): update bfra-me/renovate-config action to v1.13.0 #59, GHSA-p498-v437-472g, medium, < 0.16.8, patched in 0.16.8. Dev-scope, transitive under eslint@10.10.0 via @bfra.me/eslint-config. Below the critical/high threshold; Renovate owns it. No version bumps were performed this cycle.
• Scorecard alerts here are not independent signal: VulnerabilitiesID (high) is the same advisory re-badged; BranchProtectionID (high) asks to raise required approvals 1 → 2 on main, out of bounds by design; FuzzingID/CIIBestPracticesID are posture.
• Org-wide visibility is still 18%. Probed dependabot/alerts across all 34 active repos: 6 readable, 28 returned 403. Every readable repo is in the fro-bot org; zero high/critical among them. That is a statement about six repos, not about the fleet. Unchanged since 2026-09-11.
• 20 Fro-Bot-authored security PRs are abandoned. Idle 34–89 days, spanning six repos. Ranked by idle time: bfra-me/github-app#843, #842, #840 (89–90d); bfra-me/github-action#1466, #1463, #1467 (80–89d); marcusrbrown/vbs#672, #688, #701, #697, #717; marcusrbrown/tokentoilet#1326, #1309, #1327, #1370, #1303, #1310; marcusrbrown/gpt#2587, #2586; marcusrbrown/containers#727. Next step: these are the fleet's actual security posture, not the alert counts. Triage as one batch per repo — the wiki's consolidation rule applies, since several edit the same overrides hunk.

Control-Plane Integrity

Verified clean by the remediation pass:

• 136 uses: refs across 29 workflows plus .github/actions/setup; 36 local ./, and 100 of 100 third-party refs carry a 40-char SHA with a # vX.Y.Z comment. Zero floating tags. Enumerated with explicit file lists, not a ** glob.
• No enum, namespace, parameter properties, or import x = in scripts/*.ts.
• All 29 workflows declare top-level permissions; 24 contents: read-class, 4 permissions: {}, scorecard.yaml read-all per OpenSSF. No write-all, no top-level write scope. Every workflow running pnpm/node scripts/ uses ./.github/actions/setup.
• check-wiki-authority.ts, check-wiki-private-presence.ts, wiki-context-safety.ts, wiki-lockfile-gates.ts — 100% mutation score, zero survivors. Nothing weakened.

Code Quality

pnpm bootstrap → check-types → lint → test green on main: 79 test files, 3683 passed, 3 todo. check:wiki-write-core-dist up to date, check:mutation-guards clean, working tree free of generated-artifact drift. One TODO string exists in scripts/check-private-leak.test.ts:219 and is a deliberate test fixture, not an annotation.

Oversight

Enumeration is a floor, not a census — and this run can prove it. Paginated user/repos?affiliation=owner,collaborator,organization_member returned 38 repositories (34 active, 4 archived, 0 private). But cross-checking against gh search for open PRs and issues surfaced 11 repositories the listing never returned: marcusrbrown/ECIPs, awesome-unreal, black, cpp-ethereum, django-startproject, panthe.ai, react-templates, render-pgvector-demo, spliffy, zlugger, zsh-vscode. gh api user/orgs also returns empty, so org membership is inferred from affiliation rather than enumerated. Treat 38 as a lower bound and 34-active as the scanned population; 11 repos with live open items were outside every per-repo check below.

Failing default branches — 7 of 34 scanned:

Repo	Failing check	Read
marcusrbrown/marcusrbrown.com	Fro Bot ×13 on HEAD	15 consecutive scheduled failures since 09-07. OpenCode server bootstrap failed: Timeout waiting for server to start after 5000ms. Agent pin frozen at v0.107.0 (last moved 08-31) while .github runs v0.109.0 and infra runs v0.111.0 — both healthy.
bfra-me/github-action	Update Repo Settings	Same 500-class signature as bfra-me/ha-addon-repository#569 (13d open, unassigned).
marcusrbrown/containers	Renovate / Renovate
marcusrbrown/.github	Renovate / Renovate	Consistent with the chronic Renovate failure series already on the wiki page for that repo.
bfra-me/ha-addon-repository	Fro Bot	Stale red on HEAD; the most recent scheduled run (09-13 18:15) succeeded.
marcusrbrown/cortexkit_anthropic-auth	Fro Bot	No Fro Bot workflow resolvable — consistent with the disabled_inactivity state recorded in the wiki.
marcusrbrown/extend-vscode	Pre-Release Validation (vulnerabilities)

Next step, highest value: bump marcusrbrown/marcusrbrown.com's agent pin past v0.107.0. Its pin last moved 08-31 and automerge appears to have stopped there — Renovate PRs #544 (09-02) and #545 (09-09, [SECURITY]) are both still open, where earlier pin bumps (#540, #542) merged same-day.

PRs — 114 open across 30 repos (verified complete; the first pass at --limit 100 truncated at exactly 100, which is itself the measurement bug recorded in the wiki this run). 85 aging >7d, 63 stale >14d. Excluding the 7 pre-2025 zombie PRs in unlisted repos, the oldest active-fleet idle is 89d.

Issues — 189 open. 82 stale >30d. 16 created in the last day, of which 11 are daily-report issues across the fleet and 5 are this repo's learning-proposal batch. 4 bug-labeled issues, all 4 unassigned: marcusrbrown.com#465 (67d), systematic#740 (42d), marcusrbrown.com#517 (35d), ha-addon-repository#569 (13d). Next step: #569 is the only one with a cross-repo blast radius — it is the same Update Repo Settings 500 now red on bfra-me/github-action's main. Assign that one first.

Top three hotspots (ranked by qualifying findings in this snapshot — stale PRs >14d idle + stale issues >30d idle + abandoned security PRs + red default branch):

1. marcusrbrown/gpt — 34 (15 stale PRs, 17 stale issues, 2 abandoned security PRs). Next step: the a11y-contrast autoheal cluster the wiki has tracked across three surveys is still accreting; close or consolidate it before it grows again.
2. marcusrbrown/vbs — 28 (8 stale PRs, 15 stale issues, 5 abandoned security PRs). Next step: five security PRs idle 36–65 days is the fleet's densest unremediated advisory cluster.
3. marcusrbrown/tokentoilet — 18 (7 stale PRs, 5 stale issues, 6 abandoned security PRs). Next step: highest security-PR count of any repo; batch-review as one pass.

Cross-Project Intelligence

Coverage is partial. metadata/repos.yaml holds 34 tracked entries. 30 public, 3 private, 1 with no private field. Survey state: 28 success, 3 failure, 3 never surveyed. The 3 never-surveyed are the 3 private entries — correctly excluded by the public-only invariant, not a gap. The 3 failures are real and unscanned this cycle: marcusrbrown/containers (09-12), marcusrbrown/dev-like (09-12), bfra-me/renovate-action (09-02). One entry is lost-access, three are pending. Oldest successful survey is 144 days; median 8 days. Scannable coverage: 28 of 34 (82%).

One directly adoptable pattern, and this run produced three confirmations of what its absence costs.

marcusrbrown/infra ships release-alert.yaml: a workflow_run consumer on workflows: [Release], types: [completed], gated on conclusion == 'failure', holding permissions: issues: write and nothing else. It upserts a marker-keyed issue (<!-- release-publish-failure:v1 -->) carrying run URL, head SHA, and conclusion — idempotent, so a 12-run outage yields one issue rather than twelve. It also ships an owner-gated workflow_dispatch synthetic self-test that fires the same code path under a distinct label and marker, so the alarm can be proven live without waiting for an incident.

It is installed on exactly one workflow, in exactly one repository.

What that gap cost, all three confirmed this pass, all 100%-failure scheduled daemons with no failure surface — none of them a PR-gating check, so no branch protection surfaced them:

Repo	Workflow	Failures	Noticed
fro-bot/.github	Manage Issues	12 consecutive, 09-01 → 09-12	12 days late
fro-bot/.github	Merge Data Branch	1, weekly cron, next retry 09-20	same day, by cadence luck
marcusrbrown/marcusrbrown.com	Fro Bot	15 consecutive, 09-07 → 09-14	nothing, until this pass

Adoption shape for this repo: one workflow_run alert listening on the whole scheduled control-plane set (Merge Data Branch, Manage Issues, Update Metadata, Reconcile Repos, Wiki Lint, Poll Invitations, Dispatch Renovate) — workflow_run.workflows takes a list, so this is one file, not seven. Ship the synthetic dispatch path in the same change; an alarm whose first execution is also its first test is not an alarm. Persisted to knowledge/wiki/topics/github-actions-ci.md this run.

Second observation, reported not recommended: the fleet's agent pins span v0.107.0 → v0.111.0 against a latest release of v0.112.0 (2026-09-13). The spread itself is normal Renovate lag. What is not normal is that the repo on the oldest pin is the one failing 100% of scheduled runs, which makes pin currency a liveness variable rather than a hygiene one.

Progressive Improvement

Version drift. Current-version truth from the npm registry latest dist-tag, queried 2026-09-14. Major drift was included in this comparison and is called out per row.

Package	Declared	Registry latest	Read
typescript	6.0.3	7.0.2	One major behind
vitest	4.1.11	5.0.0	One major behind
@vitest/coverage-v8	4.1.4	5.0.0	One major behind, and still 7 patches behind its own vitest core
pnpm (packageManager)	11.25.0	12.4.1	One major behind; #3882 offers 11.26.0 in-major
eslint	10.10.0	10.10.0	Current
prettier	3.9.1	3.9.6	5 patches, inside the minor — within tolerance
@stryker-mutator/core	10.0.0	10.0.0	Current
@types/node	24.13.2	26.5.1	Not drift. mise.toml pins Node 24.21.0; @types/node 24.x is correct alignment. Bumping it to 26 would be the defect.

The @vitest/coverage-v8 misalignment is the only one that is a bug rather than a policy lag. It opened when the vitest security bump (#3873) advanced core without the provider. Smallest safe fix: one line in package.json — "@vitest/coverage-v8": "4.1.11" — then pnpm bootstrap and pnpm coverage. Unchanged from yesterday; still unactioned because a non-security version bump is Renovate's to make.

CI jobs. No missing or degraded jobs in this repository. The Main gate runs Lint, Check Types, Test, Test Scripts Load, Check Workflows, Check Wiki Authority, Check Wiki Write Core Dist, and Check Mutation Guards, all green.

Convention drift from copilot-instructions.md. None found. pnpm-only holds, the shared setup action is used everywhere it should be, no any/@ts-ignore introduced, and the mutation-guard contract is satisfied.

Stale annotations. One TODO-shaped string repo-wide, at scripts/check-private-leak.test.ts:219, inside a test fixture asserting the leak scanner's behavior. Not an annotation. Clean.

learning-proposal backlog — 5 open, all ~4 hours old (#3887, #3888, #3889, #3890, #3891, all created 2026-09-14T00:23Z). Reporting this honestly rather than mechanically: the ≥2-open rule trips, and the ≥14-days rule does not. The empirical record contradicts a stall — the previous batch (#3849–#3853, created 09-07) closed on 09-08, and commit d37f545 added four docs/solutions/ entries the same day. docs/solutions/ now holds 59 documents with additions on 09-05, 09-06, 09-07, 08-31, and 08-25. Read: the pipeline is healthy and the ≥2 threshold is firing on a batch that has not yet had a business day to clear. Re-check tomorrow; if these five are still open on 2026-09-16, that is a real stall. Noted separately that the Improvement Metrics report (#3674) reading healthy is not evidence either way, per the standing caveat.

Needs Human Attention

1. data → main promotion is blocked and the next automatic retry is 2026-09-20.

.github/workflows/merge-data.yaml's 🔒 Block private wiki pages step failed the 09-13 promotion: check-wiki-private-presence: BLOCKED — unattributable wiki repo pages detected. The gate is correct — this is the privacy boundary refusing to promote.

• 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, grandfathering only spares a page byte-identical to main, so a page whose repo went private or lost access and was then edited on data fails closed. metadata/repos.yaml currently carries one lost-access entry and three pending, which is where to look first.
• Window: the 09-06 promotion succeeded and the 09-13 one did not.
• Blast radius: cron: '0 22 * * 0' — weekly. Every wiki ingest, metadata write, and reconcile commit accumulates on data unpromoted until then. That includes the wiki edits this run just staged.
• Smallest safe fix: run scripts/check-wiki-private-presence.ts locally against a data checkout — it has a verbose operator mode printing full page identities, unlike the CI path which is deliberately counts-free. Reconcile the offending entries on data (restore public attribution in the page's frontmatter sources, or remove the orphan entry), then gh workflow run merge-data.yaml rather than waiting for Sunday.
• Do not retry blindly: 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; it addresses a June-era repos.yaml. Treat it as evidence the failure mode recurs.
• Verify with: a manual gh workflow run merge-data.yaml reaching the promotion-diff step and exiting 0.

2. #3512 Gateway rollout claims have drifted from live state on three of four checkable facts.

Compared the issue body against GitHub Project 1, marcusrbrown/infra's pin file, and the live health endpoint. Reporting both values as required; no tracker comment posted and no Project field edited — the Gateway Rollout Tracker workflow owns those writes.

Claim in #3512	Live value	Source
"the deployed gateway is pinned to v0.83.0" (apps/gateway/upstream.json, pin bump 7b9bffd7b, 2026-07-04)	v0.93.1	marcusrbrown/infra:apps/gateway/upstream.json
"Agent releases have since advanced to v0.85.0"	v0.112.0 (2026-09-13)	fro-bot/agent latest release
fro-bot/dashboard#179 listed Open in the dependency matrix	CLOSED since 2026-07-11	fro-bot/dashboard#179
Project 1 Status for #3512	Todo (Readiness tracking); every other one of the 21 items is Done	Project 1 ProjectV2 field values
"operator contract v1.6.0"	Holds. v0.93.1 and v0.112.0 both declare OPERATOR_CONTRACT_VERSION = '1.6.0'; dashboard.fro.bot/operator/health returns {"ok":true,"contractVersion":"1.6.0"}	packages/gateway/src/operator-contract/version.ts at both tags

A fifth, structural mismatch: the body calls the Project matrix "the structured source of truth," but Project 1 holds 21 items and none of them are agent#1033, #1109, #1111, the six push PRs, or dashboard#108/#122/#179 — every item the body's own "Still open / not yet complete" section turns on. The two artifacts have diverged into separate ledgers. Smallest safe fix: decide which one is authoritative and say so in the body; if it is the Project, add the missing items and flip #3512's Status off Todo. Verify by re-running the comparison above and getting agreement on all five rows.

3. marcusrbrown/marcusrbrown.com has produced no successful scheduled agent run in 7 days.

Every scheduled Fro Bot run since 2026-09-07 has failed — 15 of 15 — at OpenCode server bootstrap failed: Timeout waiting for server to start after 5000ms (latest). The pin is fro-bot/agent@26fdb0b5 # v0.107.0, last moved 2026-08-31; repos on v0.109.0 and v0.111.0 are unaffected. Smallest safe fix: bump that pin in .github/workflows/fro-bot.yaml to a current agent SHA. Constraint: this is another repository, so it needs a PR there, not a change here. Do not raise the bootstrap timeout as a workaround — the timeout is a symptom and the working pins prove the fix exists upstream. Verify with: one scheduled or dispatched Fro Bot run concluding success in that repo. Related: Renovate PRs #544 and #545 have been open there since 09-02 and 09-09 while earlier pin bumps merged same-day, so the merge path itself may be what broke first.

4. Fleet-wide security-PR abandonment is now the dominant posture risk.

20 Fro-Bot-authored security PRs idle 34–89 days across bfra-me/github-app, bfra-me/github-action, marcusrbrown/vbs, marcusrbrown/tokentoilet, marcusrbrown/gpt, and marcusrbrown/containers (enumerated under Security). No autoheal pass can close this — every one is a human merge decision in a repo this control plane does not gate. Constraint for whoever picks this up: several within a repo edit the same pnpm.overrides hunk, so rebasing them sequentially costs O(N) per merge. Consolidate per repo into one PR against current main and choose override floors against the advisory set rather than the minimum that clears today's alert.

5. Repository enumeration cannot be proven complete.

gh api user/orgs returns empty, so the token lacks read:org and organization membership is inferred from affiliation rather than enumerated. Cross-checking user/repos (38 results) against gh search surfaced 11 repositories with live open PRs or issues that the listing never returned. Every per-repo check in the Oversight section ran against the 34 active listed repos only. Smallest safe fix: grant read:org to the token used by this workflow, or switch enumeration to gh search repos --owner ... and reconcile the two. Verify with: gh api user/orgs returning a non-empty list, and the listing/search delta dropping to zero.

6. Durable knowledge from this run was persisted; one item was not.

Three sections were written to knowledge/wiki/topics/github-actions-ci.md and logged in knowledge/log.md this run (the liveness-alarm pattern, the flat-run-list measurement bug, and the correlated-failure discriminator). They are staged in the working tree and will only reach main through the data → main promotion that item 1 is blocking. Not persisted: the #3512/Project-1 divergence, because a coordination artifact splitting into two ledgers is a finding about one issue's hygiene, not a reusable pattern — if it recurs on a second tracker it becomes wiki-worthy.

🤖 Generated by Fro Bot · run 34805298521

[fro-bot]

Remediation Pass — 2026-09-15 (UTC)

Categories 1–4 only. Oversight and the daily report run separately.

No branch cut, no commit, no PR. Nothing in categories 1–4 met the minimal-and-reversible bar. The one thing that did break is a timing guard whose only available "fix" is the threshold it exists to defend, so it stays broken and gets written down instead.

Run Summary

Category	Status	Notes
Errored PRs	✅	1 open PR (#3882), 16/16 non-skipped check runs green and 2 legacy commit statuses green. BLOCKED on human review, not CI.
Security	⚠️	Alert #59 unchanged — medium, dev-scope, transitive. Below the auto-heal bar; Renovate owns it. No version changes made.
Control-Plane Integrity	✅	Zero floating action tags, strip-only TS clean, permissions declared on all 29 workflows. Guards intact — one is actively holding a line (below).
Code Quality	⚠️	bootstrap → check-types → lint green. test flaked 1 run in 4: the ReDoS linear-scaling guard, ratio 3.1456 against a ceiling of 3.

---

Errored PRs

One open PR, and it is green on both sources.

PR	Head	Author	Check runs	Legacy statuses	Merge state
#3882	4ad27f2	app/fro-bot	16 success, 4 skipped	renovate/stability-days ✅, Security: Private Leak Scan ✅	BLOCKED

BLOCKED here is branch protection doing its job: main requires 1 approving code-owner review with require_last_push_approval. Not a CI failure, and not mine to clear. The Fro Bot required context reads SKIPPED, which GitHub scores as satisfied — no deadlock.

Yesterday's three other open PRs (#3877, #3884, #3886) have all merged. Nothing failing on main in the last 60 runs across every workflow except the two below.

Off the PR surface:

• Manage Issues — green on its last two scheduled runs. fix(ci): unbreak the Manage Issues lock job #3880's fix holds; that series is closed out.
• Merge Data Branch (34790889509) — still blocked, unchanged since 09-13. Detail under Needs Human Attention; it is the same finding as item 1 in the 09-14 report, not a new one.

Security

• Alert chore(deps): update bfra-me/renovate-config action to v1.13.0 #59 (@humanfs/node, medium, dev-scope, transitive under eslint via @bfra.me/eslint-config, patched in 0.16.8). Still the only open Dependabot alert on this repo. Medium sits below the critical/high remediation threshold and this is routine Renovate territory. Untouched — no dependency versions changed this run.
• Code-scanning surface is unchanged and still not independent signal: VulnerabilitiesID (high) restates chore(deps): update bfra-me/renovate-config action to v1.13.0 #59, BranchProtectionID (high) wants required approvals raised to 2 on main — a branch-protection change, explicitly out of bounds. FuzzingID / CIIBestPracticesID are posture, not defects.
• Advisory data for this repo was readable. No "alerts unavailable" caveat applies here.

Control-Plane Integrity

Re-verified against .github/workflows/*.yaml and .github/actions/setup/action.yaml by explicit file list, not a glob:

• SHA pinning — every non-local uses: carries a 40-hex commit SHA with a # vX.Y.Z comment. Zero floating tags, zero SHA-without-comment. Current-version truth for each pin comes from the pinned upstream's own release tags; no drift remediation was required, so no major bumps were included or deferred.
• Strip-only TypeScript — no enum, namespace, parameter properties, or import x = anywhere in scripts/*.ts. The single grep hit in scripts/repos-metadata.ts:476 is a comment warning against the pattern, which is the correct artifact to find.
• Least privilege — all 29 workflows declare top-level permissions. Four use permissions: {} with job-scoped grants (private-leak-sentinel, update-repo-settings, publish-wiki, unpublish-wiki); scorecard.yaml uses read-all per OpenSSF's documented requirement. No write-all, no top-level write scope anywhere.
• Guard integrity — nothing weakened, and one guard is currently earning its keep. check-wiki-private-presence is what's holding the data → main promotion shut. That is the privacy boundary working, not a bug, and it is the reason this pass wrote nothing to knowledge/** or metadata/**.

Code Quality

pnpm bootstrap → check-types → lint all green on main. Working tree clean afterward — no generated-artifact drift from build-wiki-write-core.

pnpm test is where this run diverges from yesterday's clean read:

FAIL packages/wiki-write-core/src/regex-redos-regressions.test.ts
  > linear-time input parsing > scales malformed wiki log header parsing linearly
  AssertionError: expected 3.145593594169543 to be less than 3

Four full-suite runs on this runner: 1 failed, 3 passed (3683 passed / 3 todo each). The file in isolation passed 23/23. The failure landed on the first run — immediately after lint and check-types, with their CPU still draining — which is precisely the contention shape the test's own comments predict.

A linear operation should ratio at ~2. 3.1456 isn't a regression in mergeWikiLogs; it's the estimator's small term getting deflated under a loaded 4-core box. The guard measured the runner, not the code.

I did not touch it. LINEAR_RATIO_CEILING is the assertion — raising it is the textbook version of making a check pass by lowering a threshold, which this repo's hard boundaries forbid. The alternatives (more samples, pulling the file out of Vitest's file parallelism) are methodology changes, and this file holds methodology changes to a measured-evidence bar it documents at length in its own comments. One observation is not that bar. Written up below instead.

---

Needs Human Attention

1. The data → main promotion is still shut, and the backlog is 38 commits.

Same root cause as the 09-14 report's item 1 — recorded again because the number moved and the clock is running.

• State: origin/data is 38 commits ahead of origin/main, newest dated 2026-09-14. .github/workflows/merge-data.yaml's 🔒 Block private wiki pages step exits 1 with Leak count: 1, one page classified unattributable-page.
• Why one page blocks everything: scripts/check-wiki-private-presence.ts is all-or-nothing by design — collectLeaks returns a flat list and runCli exits non-zero if it is non-empty. There is no partial promotion. One page holds 38 commits of wiki ingest, metadata writes, and reconcile state hostage.
• Mechanism: per scripts/check-wiki-private-presence.ts:233-241, a page whose stem is absent from the public slug map survives only if it is byte-identical to the copy on main. A page for a repo that went private or lost access, and was then edited on data, fails closed. Start at the lost-access and pending entries in metadata/repos.yaml.
• Smallest safe fix: run node scripts/check-wiki-private-presence.ts --operator-report locally against a data checkout with GRANDFATHER_WIKI_REPOS_DIR pointed at main's knowledge/wiki/repos/. That mode prints the real filename and reason; it hard-refuses to run when GITHUB_ACTIONS or CI=true is set, which is exactly why no automated pass can surface the identity for you. The script's formatOperatorReport spells out the four remediation branches at lines 444-448 — note branch 2: the redaction must land as a fro-bot[bot] write to data via a dispatched fro-bot.yaml, never a human-authored PR, or the wiki-authority guard rejects it.
• Why this pass didn't fix it: the remediation necessarily edits knowledge/wiki/repos/** or metadata/repos.yaml. This job is forbidden from both, and Check Wiki Authority would reject such a PR against main regardless.
• Do not: cherry-pick copilot/fix-data-orphan-private-repos (8ea9588, 2026-06-01). It is hundreds of commits stale and targets a June-era repos.yaml. Its continued existence is evidence this failure mode recurs — PR fix(metadata): drop orphan private repo entries blocking data merge #3394 fixed this same class once already.
• Verify with: gh workflow run merge-data.yaml, then confirm the run clears 🔒 Block private wiki pages and reaches the promotion-diff step.
• Deadline: cron: '0 22 * * 0'. Next unattended retry is 2026-09-20. Everything committed to data until then accumulates behind this.

2. regex-redos-regressions.test.ts has a contention-sensitive guard that will eventually redden a healthy CI run.

• File: packages/wiki-write-core/src/regex-redos-regressions.test.ts, test scales malformed wiki log header parsing linearly (line 289), asserting through expectLinearScaling (line 104) against LINEAR_RATIO_CEILING = 3 (line 101).
• Observed: ratio 3.1456 on one of four full-suite runs on a GitHub-hosted runner; the same file in isolation passed 23/23. The failing run followed lint and check-types back-to-back, so the estimator's small term was measured under residual load. Expected ratio for linear work is ~2; the margin to the ceiling is ~1.5x, and contention ate it.
• Root cause: measureScalingRatio (line 70) calibrates a repetition count, then times n and 2n adjacent in time and takes the median of 3 ratios. Median-of-3 rejects a transient spike on one probe; it inherits the bias when load is sustained across the whole sample window. Full-suite Vitest file parallelism on a 4-core runner produces sustained load, not spikes.
• Do NOT fix by raising LINEAR_RATIO_CEILING. That constant is the assertion. The same constant is shared by the meta-test at line 175 that proves the estimator can discriminate quadratic from linear work; raising it erodes both the production guard and the proof that the guard functions. The comment at lines 110-115 already records that two earlier guards were deleted for the inverse failure — unable to catch their own regression while still flaking CI. Do not add a third variant of that mistake in the other direction.
• Viable directions, in preference order: (a) take this one file out of Vitest's file-parallelism pool so the timing guards measure an unloaded core — the assertion is untouched and the noise source is removed; (b) raise the sample count at line 297 above 3, accepting the runtime cost against the 30s suite timeout at line 130. Option (a) is structurally better because it removes the noise rather than averaging over more of it.
• Evidence bar before changing anything: this file documents measured distributions across contention levels for every methodology decision it makes (see the comment block at lines 36-54). One observed failure does not clear that bar. Reproduce with repeated full-suite runs under imposed load, interleaving the arms — the file's own comment at lines 51-53 warns that a blocked design confounds the comparison with CPU frequency drift.
• Verify with: ≥20 full-suite pnpm test runs under imposed CPU oversubscription with zero failures of this test, plus confirmation the meta-test at line 143 still separates its controls.

3. Durable knowledge from this run was not persisted, by design.

This job delivers via branch-pr and cannot write knowledge/**. Two findings are wiki-worthy and need a working-dir run to land:

• The one-page/38-commit blast radius of check-wiki-private-presence's all-or-nothing exit, paired with the fact that the same class was already fixed once in fix(metadata): drop orphan private repo entries blocking data merge #3394 — that is a recidivism data point for the Improvement Metrics loop (Improvement Metrics #3674), not just a bug.
• The failure mode of CPU-timing guards under CI file parallelism, and the specific trap that the obvious fix (raise the ceiling) destroys the guard. Generalizes beyond this repo; belongs on the github-actions-ci topic page.

🤖 Generated by Fro Bot · run 34928079600

[fro-bot]

Superseded by the 2026-09-15 report: #3893