You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1 open PR, #3834, fails Check Mutation Guards. Diagnosed as the expected pre-Unit-5 baseline, not a defect. Non-required check. No repair warranted.
Security
⚠️
5 open Dependabot alerts, byte-identical to the 2026-09-04 and 2026-09-05 sets. 4× high fast-uri still resolving to the vulnerable floor. Third consecutive day unremediated.
Control-Plane Integrity
✅
SHA pinning, strip-only TS, least privilege, and guard integrity all verified clean against 498f33d.
Code Quality
✅
bootstrap / check-types / lint / test all green. 74 files, 2994 passed, 3 todo.
Oversight
❔
Dependabot alert reads return 403 on 28 of 34 accessible repos; user/orgs returns empty. Every count below is a floor, not a total.
Cross-Project Intelligence
⚠️
Coverage partial: 31 of 34 tracked entries scannable, 3 never surveyed, 2 public survey failures. Two adoptable patterns identified.
Progressive Improvement
⚠️
No unexplained tool drift — every gap is a governed hold, and the TypeScript hold's lift condition was re-verified today. One durable fragility found in required-check wiring.
Errored PRs
One open PR in this repo: #3834, fix(ci): guard mutate entries with a barrel-excluding source-reach check, authored by marcusrbrown (repository owner, trusted). Head 8c0492a, branch fix/mutation-guards-source-reach-check — in-repo and writable.
Both failure sources enumerated, since they are separate records:
Root cause — and why it is not a defect. The job ran to completion in 5m43s across 9 modules and 2558 mutants: 1402 killed, 787 survived, 362 no-coverage, 7 timeout, 0 errors. It returned verdict mutant-timeout. scripts/check-mutation-guards.ts:426 resolves any Timeout to mutant-timeout, which exitCodeFor maps to 1 — deliberately, so that a slow-but-terminating mutant can never be laundered into Stryker's default score, which counts Timeout as detected. docs/plans/2026-09-04-001-feat-counterexample-proven-guards-plan.md:398 states the contract outright: until Unit 5 lands, this job is expected to report mutants-survived or mutant-timeout on any PR touching the trigger set, and is visible in Main for observation only. Unit 6 gates making it required on a clean baseline.
Confirmed against live branch protection: Check Mutation Guards is not among the 13 required contexts on main. The PR is not blocked. Today's 7 timeouts and per-module counts match the recorded Unit 5 baseline (CI run 34007429970) exactly — no regression.
No repair applied, and none warranted. Turning this green would require either driving the mutation set to clean (Unit 5 — a many-file test-authoring effort well past the scope cap) or widening timeoutMS, which is precisely the guardrail-weakening the run boundaries forbid.
Security
Five open Dependabot alerts, identical for the third consecutive day. All development scope, all transitive through pnpm-lock.yaml:
Re-verified against 498f33d: pnpm-workspace.yaml:14 carries fast-uri: '>=4.1.2' and pnpm-lock.yaml:1649 resolves to exactly 4.1.2. The remediation floor is the vulnerable version. @humanfs/node sits at 0.16.7 (pnpm-lock.yaml:466). Both dev-scope; no runtime exposure. Carried to Needs Human Attention #4 with the one-line fix.
Code scanning: 4 open alerts, all OpenSSF Scorecard findings with no associated file (VulnerabilitiesID high, BranchProtectionID high, FuzzingID medium, CIIBestPracticesID low). Not code defects. Secret scanning: 0.
The advisory-source split persists and is worth restating each day it holds: Dependency Dashboard #2828 reads "Renovate has not found any CVEs on osv.dev" against the same lockfile Dependabot holds five alerts on. One of those two instruments is wrong about this tree. Do not read the Renovate line as an all-clear.
Control-Plane Integrity
All four sub-checks verified clean against 498f33d.
(a) SHA pinning — every third-party uses: across .github/workflows/*.yaml and .github/actions/**/action.yaml resolves to a 40-hex SHA. Zero floating tags, zero pins missing a # vX.Y.Z comment. The comment is load-bearing: a SHA pin without one drops out of Renovate's detected dependencies, making a missing comment a silent update outage rather than a style nit.
(b) Strip-only TypeScript — no enum, namespace, parameter properties, or import-equals in scripts/*.ts or packages/*/src/*.ts. The single grep hit is the explanatory comment at scripts/repos-metadata.ts:476. Check Types and Test Scripts Load both green on fix(ci): guard mutate entries with a barrel-excluding source-reach check #3834.
(c) Least privilege — 29 workflows, every one declaring a top-level permissions: block. The count fell from 30 for a good reason: mutation-spike.yaml was added 2026-09-04 (71f7fa8) and removed 2026-09-05 (d8e64c7) when the guard graduated into main.yaml — a temporary spike workflow retired rather than left to rot. The only contents: write grants are App-token minting scopes at status-truth.yaml:378 and wiki-lint.yaml:192, the two jobs that write the data branch. scorecard.yaml:19 uses read-all, the upstream-recommended shape. No write-all anywhere.
(d) Guard integrity — wiki-authority guard, privacy gates, and branch protection untouched. main retains enforce_admins: true and 13 required contexts. Nothing relaxed.
Code Quality
Full validation at 498f33d, all green:
Command
Result
pnpm bootstrap
✅
pnpm check-types
✅ (includes build-wiki-write-core.ts)
pnpm lint
✅ (check:md-links + eslint)
pnpm test
✅ 74 files, 2994 passed, 3 todo, 12.23s
Test count rose from 2846 to 2994 (+148) since 2026-09-05, tracking the mutation-guard suite landing across 5718ff4, d8e64c7, and 498f33d. No mechanical lint or format fixes were available to apply. Nothing to heal.
Oversight
Enumeration. 38 repositories returned with at least read access; 34 active, 4 archived. gh api user/orgs returns empty rather than erroring, so org-scoped enumeration is unverifiable — coverage is believed complete via user/repos?affiliation=owner,collaborator,organization_member, but an empty success is indistinguishable from a denied read. Carried as Needs Human Attention #5.
Security alerts — the reason this category is ❔. Dependabot alert reads succeed on 6 repos (all fro-bot/*) and return 403 Resource not accessible by personal access token on the other 28 (marcusrbrown/*, bfra-me/*). Of the 6 readable, only this repo carries open high/critical alerts. Fleet security posture is 82% unobserved. Every number below is a floor.
PR queue — the dominant signal. 105 open PRs across the 34 active repos:
Measure
Count
Open PRs
105
Aging >7d (by creation)
84
Stale >14d (by last activity)
66
Fro-Bot-authored
65
Sixty-two percent of the fleet's open PRs are ones Fro Bot opened. The oldest is bfra-me/renovate-config#1383 at 178 days; marcusrbrown/gpt#2165 at 161 days. Tracked at #3652, and not improving. Roughly a dozen of the stale ones are Fro-Bot security remediations — fast-uri, postcss, brace-expansion, nanoid, js-yaml — sitting unmerged in sparkle, vbs, and tokentoilet for 40+ days. The bot is remediating advisories into a queue nobody drains, which is functionally indistinguishable from not remediating them.Next step: batch-review the open Fro-Bot fix(security): PRs first; they are single-line override edits and merge or close cleanly.
Issues. 185 open across 34 repos. 17 created in the last 24h, of which 11 are daily reports rather than work. 75 stale >30d. 10 bug-labeled issues, all 10 unassigned, including marcusrbrown/infra#1278 and #1277 opened today for stranded deploys. Next step: assign the 5 newest; the 5 older than 15 days need a triage decision, not an assignee.
Failing default branches — 5 of 34. Check runs and legacy statuses both inspected; all failures originated in check runs.
Two of those five are Fro Bot failing on itself. The marcusrbrown.com failure this morning is the instructive one — it ended:
"Agent failed with recoverable LLM error" error="Agent error: name=APIError; status=400"
##[warning] Cannot post error comment: missing target context
##[error] Agent execution failed with a recoverable LLM error, and no delivery surface was available to report it.
A scheduled run has no issue or PR to comment on, so when the agent fails on a schedule trigger the failure is reportable only to the Actions log. The daemon can fail quietly on exactly the trigger nobody watches. Filed as Needs Human Attention #9. Separately, bfra-me/github-action's Update Repo Settings failure shares a root cause with the open bug bfra-me/ha-addon-repository#569 ("Update Repo Settings job fails with 500") — one upstream fault, two repos, only one of which has an issue.
Top three hotspots (ranked by qualifying findings in this snapshot: stale PRs >14d + stale issues >30d + failing default branch + unassigned bugs):
marcusrbrown/gpt — 32. 15 stale PRs (every open PR in the repo is stale) and 17 stale issues. Includes #2586 and #2587, Fro-Bot security pins open 79 days. Next step: this repo needs a queue-drain session, not more automation.
marcusrbrown/vbs — 23. 8 stale PRs, 15 stale issues. Five stale PRs are Fro-Bot security remediations with zero review activity since creation. Next step: merge or close #672, #688, #697, #701, #717 as one batch.
marcusrbrown/sparkle — 16. 13 stale PRs, 2 stale issues, 1 unassigned bug (#1940, flaky turbo build task, 15d). Six stale PRs are chore(lint): apply auto-fixes from autohealing run — the autohealer has been re-proposing the same fixes into an undrained queue since 2026-07-02. Next step: merge the oldest lint-fix PR and close the five that supersede each other.
No issues, PRs, or labels were modified in this category.
Cross-Project Intelligence
metadata/repos.yaml carries 34 tracked entries — every one treated as in scope, not a sample.
Coverage is partial. 31 public entries scanned. 3 entries are private and have never been surveyed; per the public-only wiki invariant they are neither named nor described here, and that is correct behavior rather than a gap to close. 2 public entries carry last_survey_status: failure: marcusrbrown/renovate-config (2026-08-26) and bfra-me/renovate-action (2026-09-02). That is an improvement on yesterday's 4 — marcusrbrown/systematic and fro-bot/agent both recovered. marcusrbrown/copiloting remains onboarding_status: lost-access, last surveyed 136 days ago.
Automation-coverage gaps across public tracked entries: 7 have no Fro Bot workflow (marcusrbrown/ha-config, marcusrbrown/.github, marcusrbrown/esphome.life, marcusrbrown/extend-vscode, marcusrbrown/Presentations, fro-bot/fro-bot.github.io, fro-bot/systematic); 3 have no Renovate (fro-bot/fro-bot.github.io, fro-bot/systematic, marcusrbrown/cortexkit_anthropic-auth).
Two adoptable findings. No changes made.
An aggregator job collapses 13 required contexts into 1.marcusrbrown/marcusrbrown.com's ci.yaml fans parallel jobs into a single quality-gate aggregator, and branch protection requires only that. This repo instead enumerates 13 individual contexts while main.yaml declares 8 jobs and the rest arrive from four other workflows. Today they match exactly — verified against fix(ci): guard mutate entries with a barrel-excluding source-reach check #3834 — but the match is maintained by hand. Every job rename requires a synchronized branch-protection edit made through a surface this repo does not version-control, which is the failure mode already recorded in docs/solutions/workflow-issues/quoted-required-status-check-context-2026-06-09.md. Check Mutation Guards becoming required at Unit 6 is the next scheduled chance to get it wrong.
An out-of-band probe catches what a self-reporting daemon cannot.marcusrbrown/infra runs cliproxy-auth-monitor.yaml, a 15-minute health probe with a synthetic self-test, deliberately outside the pipeline it watches. This repo has no equivalent: the daily pass is the only thing that reports on the daily pass. Today's marcusrbrown.com failure — an agent that could not report its own failure because a scheduled run has no comment target — is precisely the class of fault an out-of-band probe exists to catch. The probe does not need to be clever. It needs to be elsewhere.
Progressive Improvement
Tool-version drift — none unexplained. Current versions read from the npm registry latest dist-tag on 2026-09-06, cross-checked against Dependency Dashboard #2828, regenerated 03:10 UTC today. Major drift included.
Tool
Pinned
Latest
Verdict
eslint
10.9.0
10.10.0
Governed. 10.10.0 published 2026-09-04, still inside the preset's minimumReleaseAge window.
Governed. renovate/major-vitest-monorepo is queued under Pending Status Checks.
@stryker-mutator/core
10.0.0
10.0.0
Current.
The TypeScript hold deserves the detail. .github/renovate.json5 pins allowedVersions: '<6.1.0' because typescript-eslint reads ts.Extension.Cjs, which TypeScript 7's native rewrite removed, crashing type-aware linting outright (typescript-eslint#12518). The comment names its own lift condition: "Lift this once @typescript-eslint/parser publishes a peer range that permits 7.x." Checked against the registry today — @typescript-eslint/parser@8.69.0 still declares typescript: >=4.8.4 <6.1.0. The hold remains correct and the ceiling still mirrors the peer range exactly. This is what docs/solutions/best-practices/dependency-holds-need-lift-conditions-2026-08-31.md was written for, and it worked: a two-major-version gap resolved to "verified current" in one registry read instead of a judgment call.
CI job coverage.main.yaml declares 8 jobs; 13 contexts are required on main; all 13 were produced on #3834. No missing or degraded jobs. Check Mutation Guards is intentionally excluded from required checks pending Unit 6.
Convention drift. None found against .github/copilot-instructions.md. The pnpm-only contract is intact (packageManager: pnpm@11.25.0, no competing lockfiles), and the shared ./.github/actions/setup is used by every dependency-consuming workflow.
Stale annotations. Zero. The only TODO in tracked source is a deliberate string literal inside a test fixture at scripts/check-private-leak.test.ts:196.
learning-proposal pipeline — healthy, and checked properly rather than by reading the metrics report. 0 open proposals. The last batch of 5 (#3801–#3805) closed COMPLETED on 2026-08-31, and commit ff74ca0 added exactly 5 matching files to docs/solutions/ the same day. Proposals are converting to authored learnings 1:1 — the only evidence that counts, since #3674 reading healthy would look identical if none of them had. 52 learnings total.
One finding, carried to Needs Human Attention #10: the required-check enumeration described in Cross-Project Intelligence finding 1.
Review only. No tracker comments posted, no Project fields edited; the dedicated Gateway Rollout Tracker workflow owns those writes.
#3512 was last updated 2026-08-10 — 27 days ago. Project 1 (Gateway operator control-surface rollout) reports updatedAt: 2026-08-10T05:40:21Z, the same timestamp. Meanwhile the Gateway Rollout Tracker workflow has run and concluded success every day since. Four mismatches, both values given:
The 12 orphans: fro-bot/agent#1033, #1109, #1111, #1152, #1157, #1160, #1162, #1163, #1165; fro-bot/dashboard#108, #122, #179. The Project's newest agent item is #944.
The mechanism matters more than the numbers. The tracker settles on a snapshot hash over Project item states and issue states — all genuinely unchanged — so it reports success daily and writes nothing. But the evidence that went stale is the deployed pin and the release line, neither of which is in the snapshot. The tracker is not failing to detect drift; it is not looking at the axis the drift is on. Same shape as the two Manage Issues faults recorded on 2026-09-05: an instrument reporting success because it is structurally incapable of observing its own subject. Yesterday registered #3512 as 26 days stale with the item stuck in Todo; today it is 27 days stale, the item is still in Todo, and the release gap widened by 16 minors.
Needs Human Attention
Written so any LLM agent can pick these up cold. Items 1–8 carry forward from 2026-09-05, with deltas noted inline. Items 9–10 are new.
1. The daily pass is instructed to auto-heal but has no delivery path for code changes — unchanged; still the root cause of everything below it staying open
Root cause: the scheduled fro-bot job runs in working-dir mode, and the only commit-capable step is Ingest wiki insight changes (line 680), whose change detector at line 664 is git diff --no-ext-diff -- knowledge/index.md knowledge/log.md knowledge/wiki. Edits to any other path are discarded at runner teardown. Re-confirmed today by reading the workflow directly: categories 1–4 of the prompt all require branch pushes or PRs, none of which this job can perform.
Smallest safe fix: deliberately not attempted. Either (a) add a PR-creation step gated on a non-knowledge/** diff, or (b) narrow the prompt so it stops promising delivery it cannot perform. Option (a) grants a scheduled agent a write path to code on a public repo — a trust-boundary change that should be reviewed as one, not slipped in as a workflow tweak.
Constraint / do not retry: do not fix this from inside the daily pass; the edit would be discarded by the very mechanism it is trying to change. Do not add a broad git add -A step — the runner's tree also holds the wiki snapshot restored from data (today: 21 files, +4355/−580 lines) and metadata/repos.yaml state, all of which would be swept into a code commit under a misleading message.
Verify: make a one-character edit outside knowledge/** in a dispatch run and confirm it reaches a commit or PR.
2. Report-retention sweep matches nothing after the report rename — unchanged; re-verified today
File:.github/workflows/manage-issues.yaml:38
Root cause: the selector is still test("Daily (Org Oversight|Autohealing) Report"). Reports are titled Daily Fro Bot Report — YYYY-MM-DD (UTC), which does not match. Zero closes since the rename; the step exits 0, so the failure is invisible.
New evidence for urgency: 41 open Daily …Report issues now accumulate across 23 repos fleet-wide. Oldest: fro-bot/agent#252 (193d), marcusrbrown/marcusrbrown.com#260 (182d), marcusrbrown/systematic#153 (181d). marcusrbrown/infra alone holds 10.
Smallest safe fix: extend the alternation to test("Daily (Org Oversight|Autohealing|Fro Bot) Report"). Keep the older names — they still identify historical reports in sibling repos.
Better fix: select on the <!-- fro-bot:daily-report:v1 --> body marker plus author.login == "fro-bot". The fleet-wide count above is the argument for doing this once, centrally.
Constraint: do not widen beyond those three names. This job closes issues with an App token on public repos; a loose selector becomes a denial-of-service on the issue tracker.
Verify: the next scheduled run reports a non-zero close count.
3. Manage Issues → Lock job fails on every scheduled run — unchanged; now 4 consecutive failures
File:.github/workflows/manage-issues.yaml:105
Evidence:failure on runs 33949073076 (2026-09-05, new since the last report), 33844029067, 33722522110, 33597979057 — ##[error]"github-token" length must be less than or equal to 100 characters long.
Root cause:dessant/lock-threads v6.0.0 validates its token with Joi.string().trim().max(100). GitHub's auto-provisioned GITHUB_TOKEN has grown past 100 characters. Upstream relaxed the bound to .max(1000) in v6.0.1.
Smallest safe fix: bump the pin dessant/lock-threads@7266a7ce5c1df01b1c6db85bf8cd86c737dadbe7 # v6.0.0 → the v6.0.2 SHA with a matching comment. One line.
Constraint / do not retry: Renovate has this queued on #2828 and owns routine bumps — do not open a competing PR. Do not shorten or remove the token; the token is correct and the validator is stale. Do not vendor the action to patch its schema.
Verify:gh run list --workflow manage-issues.yaml --limit 1 shows Lock concluding success.
4. fast-uri override floor sits at the vulnerable version — unchanged; third day
File:pnpm-workspace.yaml:14
Root cause:fast-uri: '>=4.1.2' was itself a prior security remediation. 4.1.2 is now the vulnerable floor for four high advisories, and pnpm-lock.yaml:1649 resolves to exactly 4.1.2, so no routine install will ever move it.
Smallest safe fix:'>=4.1.2' → '>=4.1.3', then pnpm install --lockfile-only. 4.1.3 is the minimum patched version; latest published is 4.1.4.
Constraint: dev-scope transitive only. Ship it alone — do not batch with the @humanfs/node medium, do not run a full pnpm update. The instrument itself deserves reconsideration: a >= floor silently permits the exact version it was written to exclude, and this is the second time it has rotted.
Verify:pnpm why fast-uri resolves ≥4.1.3 and the four alerts auto-close.
Root cause:gh api user/orgs returns empty rather than erroring. An empty success is indistinguishable from a denied read, so an org whose repos are invisible to the user/repos listing would be silently absent from every count in this report.
Smallest safe fix: grant the sweep token read:org.
Verify:gh api user/orgs --jq 'length' returns non-zero.
6. Fleet security-alert visibility is 82% blind — upgraded from yesterday's coverage note; now quantified
Root cause:GET /repos/{owner}/{repo}/dependabot/alerts returns 403 Resource not accessible by personal access token on 28 of 34 accessible repos — every marcusrbrown/* and bfra-me/* entry. Only fro-bot/* repos are readable.
Why it matters: the Oversight security line can never be worse than ✅ for 82% of the fleet regardless of actual state. A green org-wide security reading is currently unfalsifiable.
Smallest safe fix: grant the sweep token security_events: read (or the equivalent fine-grained Dependabot alerts: read) on the marcusrbrown and bfra-me installations.
Constraint / do not retry: do not substitute a heuristic. Do not infer alerts from lockfile parsing or from open Renovate PRs — a guessed alert count is worse than a declared ❔.
Verify:gh api repos/marcusrbrown/gpt/dependabot/alerts --jq 'length' returns a number rather than a 403.
7. Cross-project survey coverage is partial with no recorded failure reason — improved: 4 failures → 2
Root cause: 2 public tracked entries carry last_survey_status: failure (marcusrbrown/renovate-config 2026-08-26, bfra-me/renovate-action 2026-09-02); 3 private entries have never been surveyed. metadata/repos.yaml records only status, so diagnosis requires per-repo log archaeology. marcusrbrown/systematic and fro-bot/agent recovered since yesterday and nobody knows why — the same gap running in the other direction.
Smallest safe fix: re-dispatch via gh workflow run survey-repo.yaml -f node_id=<node_id> using the node_id from the data branch, and add a failure-reason field alongside last_survey_status so the next pass can triage without log archaeology.
Constraint: three tracked repos are private. Never name them or their contents on a public surface. Writes to metadata/** go through the established scripts to the data branch, never edited on main.
8. The control-plane repo still has no wiki page of its own — unchanged
Root cause:knowledge/wiki/repos/ has pages for fro-bot--agent, --dashboard, --space-bus, --systematic, and --fro-bot-github-io, but none for fro-bot/.github. The surveyor is the one repo it never surveys, which is why every finding about this repo lands in a topic page instead of its own.
Smallest safe fix: survey this repo into knowledge/wiki/repos/fro-bot--github.md per knowledge/schema.md, add it to knowledge/index.md, then promote the plain-text references in knowledge/wiki/topics/github-actions-ci.md to wikilinks.
Constraint: writes to knowledge/** go through the established wiki scripts to the data branch — never edited directly on main (Check Wiki Authority enforces this).
9. A scheduled agent run that fails has no delivery surface to report the failure — new
Repo:fro-bot/agent (the action), observed failing in marcusrbrown/marcusrbrown.com
Evidence:run 34009395265, job 101422431653, 2026-09-06T03:37:19Z. Sequence: Agent failed with recoverable LLM error … status=400 → ##[warning] Cannot post error comment: missing target context → ##[error] Agent execution failed with a recoverable LLM error, and no delivery surface was available to report it.
Root cause: the error-reporting path resolves a comment target from the triggering issue or PR. A schedule trigger has neither, so the agent correctly declines to guess a target and the failure reaches only the Actions log. The APIError 400 itself is likely transient; the reporting gap is not.
Smallest safe fix: give the scheduled path a fallback delivery surface. Least-surprising option: on schedule/workflow_dispatch, fall back to $GITHUB_STEP_SUMMARY, which this workflow already writes to elsewhere, needs no permission, and is always available. A dedicated agent-run-failure issue deduplicated by marker is more visible but requires issues: write on a path that currently has none.
Constraint / do not retry: do not make the agent guess a comment target on scheduled runs — commenting on an unrelated recently-updated issue is worse than silence. Do not suppress the ##[error] to make the job green; the job failing is correct, only the reporting is missing.
Verify: force a scheduled-path failure in a dispatch run and confirm the reason appears in the job summary, not only in raw logs.
10. Required-check contexts are enumerated by hand and drift silently — new
Files:.github/workflows/main.yaml (8 jobs) plus contexts from codeql-analysis.yaml, dependency-review.yaml, renovate.yaml, check-private-leak.yaml; branch protection on main, which is not version-controlled in this repo
Root cause: branch protection requires 13 individually named contexts. Renaming or adding a job requires a synchronized edit through the settings API. Today they match exactly — verified against fix(ci): guard mutate entries with a barrel-excluding source-reach check #3834 — but the invariant is maintained by hand, and the prior incident is already recorded in docs/solutions/workflow-issues/quoted-required-status-check-context-2026-06-09.md.
Why now:Check Mutation Guards is scheduled to become required at plan Unit 6 (docs/plans/2026-09-04-001-feat-counterexample-proven-guards-plan.md:398). That is the next opportunity for the enumeration to fall out of sync.
Smallest safe fix: add an aggregator job to main.yaml that needs: every quality job and fails if any dependency did not succeed, then reduce branch protection to that single context plus the checks originating in other workflows. Pattern in use at marcusrbrown/marcusrbrown.com (ci.yaml → quality-gate).
Constraint / do not retry: do not reduce the required-check list before the aggregator exists and has been observed failing correctly — an aggregator that passes when a dependency is skipped is strictly worse than the current enumeration. Use if: always() with explicit needs.*.result assertions, not implicit needs success. Do not modify branch protection from the daily pass; run boundaries forbid it.
Verify: with the aggregator in place, remove a job from its needs list and confirm the aggregator fails.
Knowledge Persisted
None this run — deliberately. The Ingest wiki insight changes step fires on any diff under knowledge/index.md, knowledge/log.md, or knowledge/wiki/, and commits the entire diff under a single message. The runner's tree currently holds an uningested survey changeset restored from data (21 files, +4355/−580). Appending today's findings would commit that unrelated body of work under a daily-report summary and misattribute its provenance. The findings are recorded here instead; the durable ones — the tracker's blind axis, and the 82% alert blindness — belong in the wiki from a run whose tree is clean. This is a consequence of Needs Human Attention #1, not a judgment that the signal was weak.
Daily Fro Bot Report — 2026-09-06 (UTC)
Run Summary
Check Mutation Guards. Diagnosed as the expected pre-Unit-5 baseline, not a defect. Non-required check. No repair warranted.fast-uristill resolving to the vulnerable floor. Third consecutive day unremediated.498f33d.bootstrap/check-types/lint/testall green. 74 files, 2994 passed, 3 todo.403on 28 of 34 accessible repos;user/orgsreturns empty. Every count below is a floor, not a total.Errored PRs
One open PR in this repo: #3834,
fix(ci): guard mutate entries with a barrel-excluding source-reach check, authored bymarcusrbrown(repository owner, trusted). Head8c0492a, branchfix/mutation-guards-source-reach-check— in-repo and writable.Both failure sources enumerated, since they are separate records:
/commits/8c0492a/check-runs) — 15 total: 13success, 1skipped, 1failure—Check Mutation Guards(job 101421946215)./commits/8c0492a/status) —state: success, 1 context (Security: Private Leak Scan). Zero failures.Root cause — and why it is not a defect. The job ran to completion in 5m43s across 9 modules and 2558 mutants: 1402 killed, 787 survived, 362 no-coverage, 7 timeout, 0 errors. It returned verdict
mutant-timeout.scripts/check-mutation-guards.ts:426resolves anyTimeouttomutant-timeout, whichexitCodeFormaps to1— deliberately, so that a slow-but-terminating mutant can never be laundered into Stryker's default score, which countsTimeoutas detected.docs/plans/2026-09-04-001-feat-counterexample-proven-guards-plan.md:398states the contract outright: until Unit 5 lands, this job is expected to reportmutants-survivedormutant-timeouton any PR touching the trigger set, and is visible inMainfor observation only. Unit 6 gates making it required on acleanbaseline.Confirmed against live branch protection:
Check Mutation Guardsis not among the 13 required contexts onmain. The PR is not blocked. Today's 7 timeouts and per-module counts match the recorded Unit 5 baseline (CI run 34007429970) exactly — no regression.No repair applied, and none warranted. Turning this green would require either driving the mutation set to
clean(Unit 5 — a many-file test-authoring effort well past the scope cap) or wideningtimeoutMS, which is precisely the guardrail-weakening the run boundaries forbid.Security
Five open Dependabot alerts, identical for the third consecutive day. All
developmentscope, all transitive throughpnpm-lock.yaml:fast-urifast-urifast-urifast-uri@humanfs/nodeRe-verified against
498f33d:pnpm-workspace.yaml:14carriesfast-uri: '>=4.1.2'andpnpm-lock.yaml:1649resolves to exactly4.1.2. The remediation floor is the vulnerable version.@humanfs/nodesits at0.16.7(pnpm-lock.yaml:466). Both dev-scope; no runtime exposure. Carried to Needs Human Attention #4 with the one-line fix.Code scanning: 4 open alerts, all OpenSSF Scorecard findings with no associated file (
VulnerabilitiesIDhigh,BranchProtectionIDhigh,FuzzingIDmedium,CIIBestPracticesIDlow). Not code defects. Secret scanning: 0.The advisory-source split persists and is worth restating each day it holds: Dependency Dashboard #2828 reads "Renovate has not found any CVEs on osv.dev" against the same lockfile Dependabot holds five alerts on. One of those two instruments is wrong about this tree. Do not read the Renovate line as an all-clear.
Control-Plane Integrity
All four sub-checks verified clean against
498f33d.uses:across.github/workflows/*.yamland.github/actions/**/action.yamlresolves to a 40-hex SHA. Zero floating tags, zero pins missing a# vX.Y.Zcomment. The comment is load-bearing: a SHA pin without one drops out of Renovate's detected dependencies, making a missing comment a silent update outage rather than a style nit.enum,namespace, parameter properties, or import-equals inscripts/*.tsorpackages/*/src/*.ts. The single grep hit is the explanatory comment atscripts/repos-metadata.ts:476.Check TypesandTest Scripts Loadboth green on fix(ci): guard mutate entries with a barrel-excluding source-reach check #3834.permissions:block. The count fell from 30 for a good reason:mutation-spike.yamlwas added 2026-09-04 (71f7fa8) and removed 2026-09-05 (d8e64c7) when the guard graduated intomain.yaml— a temporary spike workflow retired rather than left to rot. The onlycontents: writegrants are App-token minting scopes atstatus-truth.yaml:378andwiki-lint.yaml:192, the two jobs that write thedatabranch.scorecard.yaml:19usesread-all, the upstream-recommended shape. Nowrite-allanywhere.mainretainsenforce_admins: trueand 13 required contexts. Nothing relaxed.Code Quality
Full validation at
498f33d, all green:pnpm bootstrappnpm check-typesbuild-wiki-write-core.ts)pnpm lintcheck:md-links+eslint)pnpm testTest count rose from 2846 to 2994 (+148) since 2026-09-05, tracking the mutation-guard suite landing across
5718ff4,d8e64c7, and498f33d. No mechanical lint or format fixes were available to apply. Nothing to heal.Oversight
Enumeration. 38 repositories returned with at least read access; 34 active, 4 archived.
gh api user/orgsreturns empty rather than erroring, so org-scoped enumeration is unverifiable — coverage is believed complete viauser/repos?affiliation=owner,collaborator,organization_member, but an empty success is indistinguishable from a denied read. Carried as Needs Human Attention #5.Security alerts — the reason this category is ❔. Dependabot alert reads succeed on 6 repos (all
fro-bot/*) and return403 Resource not accessible by personal access tokenon the other 28 (marcusrbrown/*,bfra-me/*). Of the 6 readable, only this repo carries open high/critical alerts. Fleet security posture is 82% unobserved. Every number below is a floor.PR queue — the dominant signal. 105 open PRs across the 34 active repos:
Sixty-two percent of the fleet's open PRs are ones Fro Bot opened. The oldest is bfra-me/renovate-config#1383 at 178 days; marcusrbrown/gpt#2165 at 161 days. Tracked at #3652, and not improving. Roughly a dozen of the stale ones are Fro-Bot security remediations —
fast-uri,postcss,brace-expansion,nanoid,js-yaml— sitting unmerged insparkle,vbs, andtokentoiletfor 40+ days. The bot is remediating advisories into a queue nobody drains, which is functionally indistinguishable from not remediating them. Next step: batch-review the open Fro-Botfix(security):PRs first; they are single-line override edits and merge or close cleanly.Issues. 185 open across 34 repos. 17 created in the last 24h, of which 11 are daily reports rather than work. 75 stale >30d. 10 bug-labeled issues, all 10 unassigned, including marcusrbrown/infra#1278 and #1277 opened today for stranded deploys. Next step: assign the 5 newest; the 5 older than 15 days need a triage decision, not an assignee.
Failing default branches — 5 of 34. Check runs and legacy statuses both inspected; all failures originated in check runs.
Fro BotFro BotPre-Release Validation (vulnerabilities)Renovate / Renovate×3Update Repo SettingsTwo of those five are Fro Bot failing on itself. The
marcusrbrown.comfailure this morning is the instructive one — it ended:A scheduled run has no issue or PR to comment on, so when the agent fails on a
scheduletrigger the failure is reportable only to the Actions log. The daemon can fail quietly on exactly the trigger nobody watches. Filed as Needs Human Attention #9. Separately,bfra-me/github-action'sUpdate Repo Settingsfailure shares a root cause with the open bug bfra-me/ha-addon-repository#569 ("Update Repo Settings job fails with 500") — one upstream fault, two repos, only one of which has an issue.Top three hotspots (ranked by qualifying findings in this snapshot: stale PRs >14d + stale issues >30d + failing default branch + unassigned bugs):
chore(lint): apply auto-fixes from autohealing run— the autohealer has been re-proposing the same fixes into an undrained queue since 2026-07-02. Next step: merge the oldest lint-fix PR and close the five that supersede each other.No issues, PRs, or labels were modified in this category.
Cross-Project Intelligence
metadata/repos.yamlcarries 34 tracked entries — every one treated as in scope, not a sample.Coverage is partial. 31 public entries scanned. 3 entries are private and have never been surveyed; per the public-only wiki invariant they are neither named nor described here, and that is correct behavior rather than a gap to close. 2 public entries carry
last_survey_status: failure:marcusrbrown/renovate-config(2026-08-26) andbfra-me/renovate-action(2026-09-02). That is an improvement on yesterday's 4 —marcusrbrown/systematicandfro-bot/agentboth recovered.marcusrbrown/copilotingremainsonboarding_status: lost-access, last surveyed 136 days ago.Automation-coverage gaps across public tracked entries: 7 have no Fro Bot workflow (
marcusrbrown/ha-config,marcusrbrown/.github,marcusrbrown/esphome.life,marcusrbrown/extend-vscode,marcusrbrown/Presentations,fro-bot/fro-bot.github.io,fro-bot/systematic); 3 have no Renovate (fro-bot/fro-bot.github.io,fro-bot/systematic,marcusrbrown/cortexkit_anthropic-auth).Two adoptable findings. No changes made.
marcusrbrown/marcusrbrown.com'sci.yamlfans parallel jobs into a singlequality-gateaggregator, and branch protection requires only that. This repo instead enumerates 13 individual contexts whilemain.yamldeclares 8 jobs and the rest arrive from four other workflows. Today they match exactly — verified against fix(ci): guard mutate entries with a barrel-excluding source-reach check #3834 — but the match is maintained by hand. Every job rename requires a synchronized branch-protection edit made through a surface this repo does not version-control, which is the failure mode already recorded indocs/solutions/workflow-issues/quoted-required-status-check-context-2026-06-09.md.Check Mutation Guardsbecoming required at Unit 6 is the next scheduled chance to get it wrong.marcusrbrown/infrarunscliproxy-auth-monitor.yaml, a 15-minute health probe with a synthetic self-test, deliberately outside the pipeline it watches. This repo has no equivalent: the daily pass is the only thing that reports on the daily pass. Today'smarcusrbrown.comfailure — an agent that could not report its own failure because a scheduled run has no comment target — is precisely the class of fault an out-of-band probe exists to catch. The probe does not need to be clever. It needs to be elsewhere.Progressive Improvement
Tool-version drift — none unexplained. Current versions read from the npm registry
latestdist-tag on 2026-09-06, cross-checked against Dependency Dashboard #2828, regenerated 03:10 UTC today. Major drift included.eslintminimumReleaseAgewindow.prettier.github/renovate.json5disables patch updates exceptpython/typescript.typescriptvitestrenovate/major-vitest-monorepois queued under Pending Status Checks.@stryker-mutator/coreThe TypeScript hold deserves the detail.
.github/renovate.json5pinsallowedVersions: '<6.1.0'because typescript-eslint readsts.Extension.Cjs, which TypeScript 7's native rewrite removed, crashing type-aware linting outright (typescript-eslint#12518). The comment names its own lift condition: "Lift this once @typescript-eslint/parser publishes a peer range that permits 7.x." Checked against the registry today —@typescript-eslint/parser@8.69.0still declarestypescript: >=4.8.4 <6.1.0. The hold remains correct and the ceiling still mirrors the peer range exactly. This is whatdocs/solutions/best-practices/dependency-holds-need-lift-conditions-2026-08-31.mdwas written for, and it worked: a two-major-version gap resolved to "verified current" in one registry read instead of a judgment call.CI job coverage.
main.yamldeclares 8 jobs; 13 contexts are required onmain; all 13 were produced on #3834. No missing or degraded jobs.Check Mutation Guardsis intentionally excluded from required checks pending Unit 6.Convention drift. None found against
.github/copilot-instructions.md. The pnpm-only contract is intact (packageManager: pnpm@11.25.0, no competing lockfiles), and the shared./.github/actions/setupis used by every dependency-consuming workflow.Stale annotations. Zero. The only
TODOin tracked source is a deliberate string literal inside a test fixture atscripts/check-private-leak.test.ts:196.learning-proposalpipeline — healthy, and checked properly rather than by reading the metrics report. 0 open proposals. The last batch of 5 (#3801–#3805) closedCOMPLETEDon 2026-08-31, and commitff74ca0added exactly 5 matching files todocs/solutions/the same day. Proposals are converting to authored learnings 1:1 — the only evidence that counts, since #3674 readinghealthywould look identical if none of them had. 52 learnings total.One finding, carried to Needs Human Attention #10: the required-check enumeration described in Cross-Project Intelligence finding 1.
Gateway Rollout Tracker (#3512) — awareness only
Review only. No tracker comments posted, no Project fields edited; the dedicated Gateway Rollout Tracker workflow owns those writes.
#3512 was last updated 2026-08-10 — 27 days ago. Project 1 (
Gateway operator control-surface rollout) reportsupdatedAt: 2026-08-10T05:40:21Z, the same timestamp. Meanwhile the Gateway Rollout Tracker workflow has run and concludedsuccessevery day since. Four mismatches, both values given:v0.83.0v0.93.1marcusrbrown/infra→apps/gateway/upstream.jsonv0.85.0"v0.109.2(2026-09-06T03:24:53Z)fro-bot/agentreleasesStatus = TodoThe 12 orphans:
fro-bot/agent#1033,#1109,#1111,#1152,#1157,#1160,#1162,#1163,#1165;fro-bot/dashboard#108,#122,#179. The Project's newest agent item is#944.The mechanism matters more than the numbers. The tracker settles on a snapshot hash over Project item states and issue states — all genuinely unchanged — so it reports
successdaily and writes nothing. But the evidence that went stale is the deployed pin and the release line, neither of which is in the snapshot. The tracker is not failing to detect drift; it is not looking at the axis the drift is on. Same shape as the twoManage Issuesfaults recorded on 2026-09-05: an instrument reporting success because it is structurally incapable of observing its own subject. Yesterday registered #3512 as 26 days stale with the item stuck inTodo; today it is 27 days stale, the item is still inTodo, and the release gap widened by 16 minors.Needs Human Attention
Written so any LLM agent can pick these up cold. Items 1–8 carry forward from 2026-09-05, with deltas noted inline. Items 9–10 are new.
1. The daily pass is instructed to auto-heal but has no delivery path for code changes — unchanged; still the root cause of everything below it staying open
.github/workflows/fro-bot.yaml, lines 660–706fro-botjob runs inworking-dirmode, and the only commit-capable step isIngest wiki insight changes(line 680), whose change detector at line 664 isgit diff --no-ext-diff -- knowledge/index.md knowledge/log.md knowledge/wiki. Edits to any other path are discarded at runner teardown. Re-confirmed today by reading the workflow directly: categories 1–4 of the prompt all require branch pushes or PRs, none of which this job can perform.knowledge/**diff, or (b) narrow the prompt so it stops promising delivery it cannot perform. Option (a) grants a scheduled agent a write path to code on a public repo — a trust-boundary change that should be reviewed as one, not slipped in as a workflow tweak.git add -Astep — the runner's tree also holds the wiki snapshot restored fromdata(today: 21 files, +4355/−580 lines) andmetadata/repos.yamlstate, all of which would be swept into a code commit under a misleading message.knowledge/**in a dispatch run and confirm it reaches a commit or PR.2. Report-retention sweep matches nothing after the report rename — unchanged; re-verified today
.github/workflows/manage-issues.yaml:38test("Daily (Org Oversight|Autohealing) Report"). Reports are titledDaily Fro Bot Report — YYYY-MM-DD (UTC), which does not match. Zero closes since the rename; the step exits0, so the failure is invisible.Daily …Reportissues now accumulate across 23 repos fleet-wide. Oldest:fro-bot/agent#252(193d),marcusrbrown/marcusrbrown.com#260(182d),marcusrbrown/systematic#153(181d).marcusrbrown/infraalone holds 10.test("Daily (Org Oversight|Autohealing|Fro Bot) Report"). Keep the older names — they still identify historical reports in sibling repos.<!-- fro-bot:daily-report:v1 -->body marker plusauthor.login == "fro-bot". The fleet-wide count above is the argument for doing this once, centrally.3.
Manage Issues→Lockjob fails on every scheduled run — unchanged; now 4 consecutive failures.github/workflows/manage-issues.yaml:105failureon runs 33949073076 (2026-09-05, new since the last report), 33844029067, 33722522110, 33597979057 —##[error]"github-token" length must be less than or equal to 100 characters long.dessant/lock-threadsv6.0.0 validates its token withJoi.string().trim().max(100). GitHub's auto-provisionedGITHUB_TOKENhas grown past 100 characters. Upstream relaxed the bound to.max(1000)in v6.0.1.dessant/lock-threads@7266a7ce5c1df01b1c6db85bf8cd86c737dadbe7 # v6.0.0→ the v6.0.2 SHA with a matching comment. One line.gh run list --workflow manage-issues.yaml --limit 1showsLockconcludingsuccess.4.
fast-urioverride floor sits at the vulnerable version — unchanged; third daypnpm-workspace.yaml:14fast-uri: '>=4.1.2'was itself a prior security remediation. 4.1.2 is now the vulnerable floor for four high advisories, andpnpm-lock.yaml:1649resolves to exactly 4.1.2, so no routine install will ever move it.'>=4.1.2'→'>=4.1.3', thenpnpm install --lockfile-only. 4.1.3 is the minimum patched version; latest published is 4.1.4.@humanfs/nodemedium, do not run a fullpnpm update. The instrument itself deserves reconsideration: a>=floor silently permits the exact version it was written to exclude, and this is the second time it has rotted.pnpm why fast-uriresolves ≥4.1.3 and the four alerts auto-close.5. Oversight enumeration is degraded — token lacks
read:org— unchangedgh api user/orgsreturns empty rather than erroring. An empty success is indistinguishable from a denied read, so an org whose repos are invisible to theuser/reposlisting would be silently absent from every count in this report.read:org.gh api user/orgs --jq 'length'returns non-zero.6. Fleet security-alert visibility is 82% blind — upgraded from yesterday's coverage note; now quantified
GET /repos/{owner}/{repo}/dependabot/alertsreturns403 Resource not accessible by personal access tokenon 28 of 34 accessible repos — everymarcusrbrown/*andbfra-me/*entry. Onlyfro-bot/*repos are readable.security_events: read(or the equivalent fine-grained Dependabot alerts: read) on themarcusrbrownandbfra-meinstallations.❔.gh api repos/marcusrbrown/gpt/dependabot/alerts --jq 'length'returns a number rather than a 403.7. Cross-project survey coverage is partial with no recorded failure reason — improved: 4 failures → 2
last_survey_status: failure(marcusrbrown/renovate-config2026-08-26,bfra-me/renovate-action2026-09-02); 3 private entries have never been surveyed.metadata/repos.yamlrecords only status, so diagnosis requires per-repo log archaeology.marcusrbrown/systematicandfro-bot/agentrecovered since yesterday and nobody knows why — the same gap running in the other direction.gh workflow run survey-repo.yaml -f node_id=<node_id>using thenode_idfrom thedatabranch, and add a failure-reason field alongsidelast_survey_statusso the next pass can triage without log archaeology.metadata/**go through the established scripts to thedatabranch, never edited onmain.8. The control-plane repo still has no wiki page of its own — unchanged
knowledge/wiki/repos/has pages forfro-bot--agent,--dashboard,--space-bus,--systematic, and--fro-bot-github-io, but none forfro-bot/.github. The surveyor is the one repo it never surveys, which is why every finding about this repo lands in a topic page instead of its own.knowledge/wiki/repos/fro-bot--github.mdperknowledge/schema.md, add it toknowledge/index.md, then promote the plain-text references inknowledge/wiki/topics/github-actions-ci.mdto wikilinks.knowledge/**go through the established wiki scripts to thedatabranch — never edited directly onmain(Check Wiki Authorityenforces this).9. A scheduled agent run that fails has no delivery surface to report the failure — new
fro-bot/agent(the action), observed failing inmarcusrbrown/marcusrbrown.comAgent failed with recoverable LLM error … status=400→##[warning] Cannot post error comment: missing target context→##[error] Agent execution failed with a recoverable LLM error, and no delivery surface was available to report it.scheduletrigger has neither, so the agent correctly declines to guess a target and the failure reaches only the Actions log. TheAPIError 400itself is likely transient; the reporting gap is not.schedule/workflow_dispatch, fall back to$GITHUB_STEP_SUMMARY, which this workflow already writes to elsewhere, needs no permission, and is always available. A dedicatedagent-run-failureissue deduplicated by marker is more visible but requiresissues: writeon a path that currently has none.##[error]to make the job green; the job failing is correct, only the reporting is missing.10. Required-check contexts are enumerated by hand and drift silently — new
.github/workflows/main.yaml(8 jobs) plus contexts fromcodeql-analysis.yaml,dependency-review.yaml,renovate.yaml,check-private-leak.yaml; branch protection onmain, which is not version-controlled in this repodocs/solutions/workflow-issues/quoted-required-status-check-context-2026-06-09.md.Check Mutation Guardsis scheduled to become required at plan Unit 6 (docs/plans/2026-09-04-001-feat-counterexample-proven-guards-plan.md:398). That is the next opportunity for the enumeration to fall out of sync.main.yamlthatneeds:every quality job and fails if any dependency did not succeed, then reduce branch protection to that single context plus the checks originating in other workflows. Pattern in use atmarcusrbrown/marcusrbrown.com(ci.yaml→quality-gate).if: always()with explicitneeds.*.resultassertions, not implicitneedssuccess. Do not modify branch protection from the daily pass; run boundaries forbid it.needslist and confirm the aggregator fails.Knowledge Persisted
None this run — deliberately. The
Ingest wiki insight changesstep fires on any diff underknowledge/index.md,knowledge/log.md, orknowledge/wiki/, and commits the entire diff under a single message. The runner's tree currently holds an uningested survey changeset restored fromdata(21 files, +4355/−580). Appending today's findings would commit that unrelated body of work under a daily-report summary and misattribute its provenance. The findings are recorded here instead; the durable ones — the tracker's blind axis, and the 82% alert blindness — belong in the wiki from a run whose tree is clean. This is a consequence of Needs Human Attention #1, not a judgment that the signal was weak.Run Summary
schedule-898cd73a-34010068592scheduleonrefs/heads/main@498f33dworking-dir— no PRs opened, no branches created, no commits pushed, no history rewritten by this agentpnpm bootstrap✅ ·check-types✅ ·lint✅ ·test✅ (2994 passed, 3 todo)