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

[fro-bot]

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

Run Summary

Category	Status	Notes
Errored PRs	✅	Remediation pass found none. The single non-Fro-Bot open PR (#3882) is green on check runs and legacy commit statuses. Evidence: remediation comment.
Security	⚠️	1 open Dependabot alert (@humanfs/node, medium, dev-scope, transitive) — below the auto-heal bar. Fleet: a 71-day-old high-severity remediation PR sits unmerged in marcusrbrown/vbs#672.
Control-Plane Integrity	⚠️	Pinning / strip-only TS / least-privilege / guards all clean. Renovate global-config finding confirmed durable and documented → #3901. data → main blocked 7 days; stranded 57 → 62.
Code Quality	✅	Remediation pass ran the full gate on clean main at 9b9635b: 79 files / 3687 passed, zero autofixable drift. #3901 is green on all 14 required contexts.
Oversight	⚠️	38 repos enumerated, all public, 4 archived. Open PRs 112 → 92, stale >14d 58 → 46 — a real one-day drawdown. Only 3 of 34 default branches genuinely red.
Cross-Project Intelligence	⚠️	34 tracked entries; coverage partial — 2 public survey failures, 3 non-public pending, 1 lost-access. One high-value adoptable finding.
Progressive Improvement	⚠️	5 learning-proposal issues open, all 6 days old, zero authored. Newest docs/solutions/ entry is 12 days old. Two 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 #3900, remediation comment.

• #3882 chore(deps): update pnpm to v11.27.0 — 13 check runs pass, 3 skipped by design; legacy renovate/stability-days + Security: Private Leak Scan green. MERGEABLE, BLOCKED on REVIEW_REQUIRED. Green and waiting 10 days.
• #3901 docs(renovate): correct the global-config comment to state the input is inert — opened by the remediation pass at 04:28 UTC, all 14 required contexts green.

That pass cut one branch and opened one PR. Unlike the prior two days, something landed.

Security

One open Dependabot alert, unchanged for a fifth day: @humanfs/node / GHSA-p498-v437-472g, medium, scope development, transitive via eslint. Medium does not authorize a dependency change; Renovate owns routine bumps. Four open code-scanning alerts, all OpenSSF Scorecard posture results rather than code findings — the BranchProtectionID high wants 2 required reviews against the current 1, and branch protection is out of bounds by construction.

The security finding that matters today is not in this repo. Fleet sweep surfaced marcusrbrown/vbs#672 — "fix(security): remediate high-severity ws DoS advisory (GHSA-96hv-2xvq-fx4p)", authored by fro-bot, open 71 days, last touched 71 days ago. A remediation PR that nobody ever touched is strictly worse than an unremediated advisory, because the advisory at least still shows up on a dashboard while the PR reads as handled. Next step: merge or close it; do not let it keep aging as a false signal of coverage.

Control-Plane Integrity

Clean on every structural axis the remediation pass checked: SHA pinning with version comments across all workflows and composite actions, no enum/namespace/parameter-properties in scripts/*.ts, top-level permissions: on all 29 workflows with no write-all, and live branch protection matching .github/settings.yml exactly (14 contexts, enforce_admins: true).

Resolved into documentation: the global-config input in .github/workflows/renovate.yaml has never disabled autodiscover. Two independent upstream causes, both verified at the current pin (bfra-me/renovate-action@78e446d, 10.42.1) — the action interpolates the JSON textually into a double-quoted shell assignment at action.yaml:220 (despite already binding it as env at line 75), and the reusable workflow derives autodiscover from the repository name and passes it as an explicit input that a parsed global-config would lose to anyway. #3901 corrects the comment and changes nothing executable; parsed YAML is identical before and after.

Still broken — data → main promotion, day 7. 62 commits stranded (57 yesterday, 52 the day before). Merge Data Branch last failed 2026-09-13 at 🔒 Block private wiki pages and is a Sunday-only cron. Today is Sunday; tonight's 22:00 UTC attempt will fail identically unless someone acts on data first. Working-tree inspection of metadata/repos.yaml puts a number on it: of 34 entries, exactly one has no explicit private field. That is the whole tripwire.

Code Quality

Not re-run here. The remediation pass executed the repository's own gate twice on main at 9b9635b and again on the PR branch — pnpm bootstrap, check-types, lint, test (79 files, 3687 passed, 3 todo), plus check:wiki-write-core-dist. git status clean afterward; zero lint or format autofix to commit.

Oversight

38 repositories enumerated via paginated user/repos for the fro-bot account (affiliation=owner,collaborator,organization_member). user/orgs returns empty — fro-bot holds no org memberships, so all reach is direct-collaborator. All 38 are public; 4 archived; nothing failed to enumerate.

The backlog actually moved. Yesterday's snapshot vs today:

Measure	2026-09-19	2026-09-20
Open PRs (fleet)	112	92
Stale PRs >14d (no activity)	58	46
Aging PRs >7d (since creation)	—	68
Open issues	—	190
Stale issues >30d	—	134

A 20-PR drawdown in a day is the largest single-day movement recorded in this report series. Worth a caveat: this is a snapshot difference, not an audited merge count.

Default-branch health: 3 of 34 genuinely red, not 8. The raw check-runs array flagged 8 repos, but that endpoint is an append log — every re-run against a commit adds a record instead of replacing it. Reducing to the latest record per check name gives the true set:

Repo	Failing check
bfra-me/github-action	Update Repo Settings / Update Repository Settings
marcusrbrown/extend-vscode	Pre-Release Validation (vulnerabilities)
marcusrbrown/marcusrbrown.com	Fro Bot

The five that dropped out were Renovate / Renovate records superseded by later green runs on the same head — the known upstream osv-offline tag-rotation transient. This set is identical to the one measured 2026-09-18, which is the useful part: the reduced set held while the raw count fell 15 → 8 with nothing repaired.

The headline: marcusrbrown/marcusrbrown.com's scheduled agent has been dead for 15 days. 326 scheduled runs lifetime (288 success / 38 failure); last success 2026-09-05T15:35:45Z; 29 consecutive failures since, both crons firing on time. Every run dies in ~11 s on APIError; status=400, "type":"configuration", and terminates with:

Agent execution failed with a recoverable LLM error, and no delivery surface was available to report it.

The agent is explicitly reporting that it cannot report. A schedule run has no triggering PR or issue, so the error channel does not exist on precisely the one trigger nobody is watching. The streak now spans agent v0.107.0 → v0.113.2 — eight version bumps rode over it without causing or fixing it, which clears the release line as a suspect. Remaining hypothesis: fro-bot.yaml:621 passes model: ${{ vars.FRO_BOT_MODEL }}, a repository-scoped variable; this control plane uses the identical expression and runs green, so the fault localizes to that repo's value. Unverified — the variables API returns 403 to this token.

Top three hotspots (ranked by qualifying findings: stale issues >30d + PRs aging >7d + PRs stale >14d + genuinely-failing default branch):

1. marcusrbrown/gpt — 53. 23 stale issues, 15 aging PRs, all 15 also stale. Oldest: #2165 "feat(ui): Migrate from HeroUI v2 to v3", 175 days old, 132 days untouched. → Close the abandoned migration PR explicitly rather than letting it define the repo's backlog.
2. marcusrbrown/vbs — 37. 19 stale issues, 10 aging PRs. Contains the 71-day high-severity security PR above. → Triage #672 and #671 first; both are Fro-Bot-authored fixes that went nowhere.
3. marcusrbrown/marcusrbrown.com — 19. 6 stale issues, 6 aging PRs (all 6 also stale), plus the dead daemon. Oldest PR #462 at 74 days. → Fix the daemon first; the PR backlog here is a symptom of the same unattended loop.

Unassigned bug-labelled issues: 6, oldest marcusrbrown/marcusrbrown.com#465 at 73 days. New in last 24h: 17 issues, of which 11 are automated daily reports — the genuine new work is fro-bot/agent#1633, #1631, marcusrbrown/systematic#1014, #1005, and marcusrbrown/.dotfiles#2666.

No issues or PRs were modified or labelled in this category.

Cross-Project Intelligence

Coverage is partial. 34 tracked entries in metadata/repos.yaml; 30 carry private: false and were scannable. Not covered, and why:

Class	Count	Note
Public, survey failure	2	marcusrbrown/containers, marcusrbrown/dev-like
Non-public entries	3	Not named, not scanned — public-only invariant
onboarding_status: lost-access	1	Cannot be surveyed at all
No explicit private field	1	The entry blocking data → main; counted, not named

cross_repo_receipts remains set on zero entries, unchanged since first reported. Oldest public survey is marcusrbrown/gpt at 2026-09-03 (17 days).

Adoptable finding — marcusrbrown/infra has already solved today's biggest problem. Its release-alert.yaml is a workflow_run-triggered liveness alarm with three properties this control plane lacks:

• permissions: issues: write and nothing else — minimum viable blast radius for an alarm.
• Marker-based issue upsert (<!-- release-publish-failure:v1 -->) — one perpetual alert, not a new issue per failure.
• An owner-only synthetic self-test via workflow_dispatch, which fabricates a failure and exercises the whole alarm path without breaking the watched workflow. An alarm you cannot test is an alarm you are merely hoping about.

This repo has three workflow_run consumers (check-private-leak.yaml, private-leak-sentinel.yaml, renovate.yaml), and none of them watch for failure. Two of today's findings are the same shape as what this pattern catches: Merge Data Branch failing unheard between Sunday crons, and marcusrbrown.com's agent dying 29 times into an empty room. Adopting it against Merge Data Branch would have surfaced the stranded-commit problem on day one instead of day seven. Report-only; no change made.

Progressive Improvement

The compounding pipeline is stalled. 5 open learning-proposal issues — #3887, #3888, #3889, #3890, #3891 — all 6 days old, all authored by fro-bot, none authored into docs/solutions/. None has crossed 14 days yet, but the count alone (≥2) is the stall signal, and the newest docs/solutions/ entry is dated 2026-09-08, 12 days ago against 59 total docs.

As instructed, the healthy reading on Improvement Metrics #3674 is not evidence this is fine — that report was last generated 2026-09-14 and counts codified classes, so five unauthored proposals are invisible to it by construction. It stays green because this is stalled.

Tool-version drift, current-version truth from the npm registry (npm view <pkg> version, checked 2026-09-20). Major drift is included below:

Tool	Declared	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
eslint	10.10.0	10.11.0	minor
prettier	3.9.1	3.9.8	patch
@stryker-mutator/core	10.0.0	10.0.0	none ✅

Two majors parked, consistent with yesterday. Renovate owns these; nothing opened. One genuinely new nit: @vitest/coverage-v8 (4.1.4) trails vitest (4.1.11) inside the same major. Vitest expects the coverage provider to track the runner version; the skew is small and currently harmless, but it is the kind of drift that produces a confusing failure at the next major boundary rather than now.

CI jobs: no degradation. All 14 required contexts executed and passed on #3901. TODO/FIXME debt in scripts/*.ts: 0. No convention drift from copilot-instructions.md detected.

Gateway Rollout Tracker (#3512)

Review-awareness only; no tracker comment posted and no Project field edited. Four mismatches between #3512 and Project 1:

#	Claim	Live value
1	Issue body describes the operator surface as functionally complete (contract v1.6.0 live, cancellation shipped, push shipped)	Project 1 status for #3512 = Todo, while 20 of its other 21 items are Done
2	"Agent releases have since advanced to v0.85.0"	Upstream release source (gh release list --repo fro-bot/agent) says latest is v0.113.2 (2026-09-16) — 28 minor versions stale, no major boundary crossed
3	"The GitHub Project matrix is the structured source of truth"	fro-bot/dashboard#108 (CLOSED/COMPLETED 2026-07-10) and the six push PRs #1152–#1165 are cited in the body but are absent from Project 1 — so for those, the body is the only record
4	"comments are the audit log"	Last comment is 2026-06-18, 94 days ago, while the body was edited 2026-09-19. The rollup moved; the audit log did not

Mismatches 3 and 4 are the same defect in two directions: the issue names two structured sources of truth and is currently more current than both. The dedicated Gateway Rollout Tracker workflow owns any write here.

Needs Human Attention

1. data → main promotion, day 7. 62 commits stranded, ~5/day. One entry is the whole blocker.

• Files: metadata/repos.yaml on the data branch (not main), scripts/check-wiki-private-presence.ts.
• Root cause: an orphan wiki page with no metadata/repos.yaml entry on data, whose slug matches no repository the fro-bot token can enumerate. Measured today: of 34 entries, exactly 1 lacks an explicit private field. That is the entire tripwire surface.
• Existing lead: branch copilot/fix-data-orphan-private-repos exists on origin, head 8ea9588 "fix(data): remove orphan private repo entries blocking data merge", no open PR, 315 ahead / 77 behind. Evaluate before writing anything new; 77 behind means rebase onto current data, not merge as-is.
• Smallest safe fix: resolve that one entry's private field to an explicit true/false on data. Auditing all 34 for the same omission drains the 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 fails identically and yields no new diagnostic signal.
• Verify: local --operator-report run showing zero leaks → successful Merge Data Branch → git rev-list --count origin/main..origin/data returns 0.
• Reachable only from a working-dir run or a human on data.

2. marcusrbrown/marcusrbrown.com scheduled agent, dead 15 days, 29 consecutive failures.

• File: .github/workflows/fro-bot.yaml in that repo, line 621 (model: ${{ vars.FRO_BOT_MODEL }}).
• Root cause, confirmed: every scheduled run fails in ~11 s with APIError; status=400, "type":"configuration", surviving a 3-cycle grace period. Last success 2026-09-05T15:35:45Z.
• Root cause, hypothesized and unverified: the repository-scoped Actions variable FRO_BOT_MODEL is unset or names a retired model. fro-bot/.github uses the byte-identical expression and runs green daily, which localizes the fault to that repo's value rather than the expression or the agent. The variables API returned 403 to this survey's token — this could not be confirmed and must not be reported as fact.
• Smallest safe fix: run the workflow via workflow_dispatch with a step that echoes the resolved model id, compare against a currently-served model, and correct the variable. One variable edit, no code change.
• Do not: bump the agent version hoping it clears — eight bumps (v0.107.0 → v0.113.2) have already ridden over this without effect. Do not assume it will self-heal; the 09-16 survey hedged that it might, and four more days disproved it.
• Verify: one scheduled run concluding success, or a dispatch run that gets past the 11-second mark.
• Second-order fix worth doing anyway: a schedule run has no PR or issue to comment on, so this outage was undiscoverable from the agent's own output for 15 days. Port marcusrbrown/infra's release-alert.yaml pattern (see Cross-Project Intelligence) so failures alarm into a marker-upserted issue.

3. marcusrbrown/vbs#672 — a high-severity security remediation PR, unmerged 71 days.

• Link: fix(security): remediate high-severity ws DoS advisory (GHSA-96hv-2xvq-fx4p) marcusrbrown/vbs#672, fix(security): remediate high-severity ws DoS advisory (GHSA-96hv-2xvq-fx4p), authored by fro-bot, created and last updated 71 days ago.
• Why it matters: an open remediation PR reads as coverage. Until it merges, the advisory is live and invisible to anyone who sees the PR and assumes it is handled.
• Action: merge it or close it with a reason. Either is better than a third month of ambiguity. Sibling #671 is in the same state.

4. No failure alarm on any workflow_run consumer in this repo.

• Files: .github/workflows/ — three workflow_run consumers exist (check-private-leak.yaml, private-leak-sentinel.yaml, renovate.yaml), none triggered on failure.
• Root cause: Merge Data Branch is a Sunday-only cron whose fail-closed refusal has no subscriber, so a blocked promotion accrues ~5 stranded commits/day for a week before anyone reads it in a daily report.
• Smallest safe fix: add one workflow modeled on marcusrbrown/infra's release-alert.yaml — workflow_run on Merge Data Branch completed, if conclusion is failure, permissions: issues: write only, marker-based upsert, plus the owner-only workflow_dispatch synthetic self-test so the alarm itself is verifiable.
• Do not: grant it more than issues: write, and do not let it open a new issue per failure — the marker upsert is the point.
• Verify: dispatch the synthetic path and confirm exactly one marker-bearing issue appears, then re-dispatch and confirm it updates rather than duplicating.

5. Gateway tracker #3512 has drifted from both of its declared sources of truth. See the table above for all four mismatches with both values. Smallest safe fix: set the Project 1 status for #3512 off Todo, add the missing dashboard#108 and agent#1152–#1165 items to the matrix, and correct the v0.85.0 version claim to the live v0.113.2. Tracker writes belong to the Gateway Rollout Tracker workflow, not this report path.

6. Durable knowledge — persisted this run. Unlike the last two branch-pr passes, this one runs in working-dir mode and wrote to the wiki:

• knowledge/wiki/topics/github-actions-ci.md — extended A Check-Run List Is an Append Log, Not a State Snapshot with a second independent sweep. The raw failure count fell 15 → 8 across two days with nothing repaired, while the latest-per-name reduced set held at exactly the same 3 repos. The generalization recorded: validate a fleet-health metric by re-running it and diffing the set, not the count — membership churn without remediation means the metric is measuring its own sampling window.
• knowledge/wiki/repos/marcusrbrown--marcusrbrown-com.md — daemon health updated to day 15 with full run-history figures, retiring the prior "may heal on unchanged HEAD" hedge, and recording the model-selector hypothesis as explicitly unverified with the reason (403).
• knowledge/log.md — manual-edit entry with sources.

🤖 Generated by Fro Bot · run 35488760839

[fro-bot]

Remediation pass — 2026-09-21 (categories 1–4)

Zero fixes applied. Zero PRs opened. Not for lack of looking: every reactive category came back clean, and the one thing that is genuinely broken is out of this run's reach by rule, not by difficulty. Detail below, then the delta against yesterday's day-7 reading.

1. Errored PRs — clean

Three open PRs, all green on both check sources (check-runs and legacy commit statuses, inspected separately):

PR	Head	Check runs	Legacy statuses	Mergeable
#3904 bfra-me/.github → v4.31.0	renovate/bfra-me-.github-4.x	15 pass, 3 skipped by design	Security: Private Leak Scan ✅	MERGEABLE
#3901 docs(renovate): global-config comment	frobot/renovate-global-config-comment-2026-09-20	13 pass, 4 skipped	Security: Private Leak Scan ✅	MERGEABLE
#3882 pnpm → v11.27.0	renovate/pnpm-11.x	15 pass, 3 skipped	renovate/stability-days ✅, Security: Private Leak Scan ✅	MERGEABLE

#3882 is now green and waiting 11 days, blocked only on REVIEW_REQUIRED. Nothing to repair — a human has to press the button.

2. Security — no critical/high

Dependabot is reachable by this token and returns exactly one open alert: @humanfs/node, medium, transitive via pnpm-lock.yaml (symlink-following recursive copy). Medium is Renovate's lane, not a remediation PR's. No direct dependency or Action carries an open advisory.

Code scanning returns four Scorecard-sourced alerts (VulnerabilitiesID high, BranchProtectionID high, FuzzingID, CIIBestPracticesID) with no file association. BranchProtectionID is worth naming as a probable false read — live protection on main is enforce_admins: true, force-push off, deletions off, 14 required contexts, code-owner review required, require_last_push_approval: true. That is not an unprotected branch. Scorecard most likely scores the intentionally-unprotected data branch, which is load-bearing by design.

3. Control-plane integrity — clean, and verified harder than usual

a. SHA pinning. All 20 third-party uses: references across 29 workflows and the composite actions are pinned to full commit SHAs, every one carrying a # vX.Y.Z comment. I did not stop at "looks pinned" — I resolved all 17 distinct repo@tag pairs against the GitHub refs API (dereferencing annotated tags) and compared to the pinned SHA. 17/17 match. A pin whose comment has drifted off its SHA is the failure mode that actually bites, because it survives every regex audit ever written; there is none here.

b. Strip-only TypeScript. No enum, no namespace, no parameter properties, no TS path aliases in scripts/*.ts. The only hit for the parameter-property pattern is a comment in scripts/repos-metadata.ts:476 explaining why the construct is avoided — the codebase documenting its own constraint.

c. Least privilege. All 29 workflows declare a top-level permissions: block. Zero write-all. The single blanket declaration is scorecard.yaml's read-all, which is the correct direction.

d. Guards. Wiki-authority guard, privacy gates, and branch protection all intact and untouched. pnpm check:mutation-guards passes at 100% mutation score across all 11 guarded modules (2577 mutants, zero survivors) — the guards are not merely present, they are provably load-bearing.

4. Code quality — clean

pnpm bootstrap → check-types → lint → test all exit 0. 79 test files, 3687 tests passing, 3 todo. check:wiki-write-core-dist reports dist up to date. No mechanical lint or format fix available to make; running pnpm fix would produce an empty diff.

---

Needs Human Attention

1. data → main promotion: second consecutive Sunday failure. 67 commits stranded.

This is item 1 of the 2026-09-20 report, and it has gotten worse exactly as that report predicted. Recording the delta rather than reopening the analysis:

	2026-09-20 report	Today
Stranded commits	62	67
Consecutive Sunday failures	1 (09-13)	2 (09-13, 09-20)
Days since last successful promotion	7	15

Last green Merge Data Branch was run 34066893138 on 2026-09-06. Run 35545734311 (2026-09-20 23:48 UTC) failed at 🔒 Block private wiki pages with the identical redacted output: check-wiki-private-presence: BLOCKED — unattributable wiki repo pages detected. Yesterday's forecast — "tonight's 22:00 UTC attempt will fail identically unless someone acts on data first" — landed. Next scheduled attempt is 2026-09-27; absent action it is failure number three at roughly 100 stranded commits.

Why this run could not fix it, stated precisely, because "the bot skipped it again" deserves a reason:

• The fix lives in metadata/repos.yaml on the data branch. This pass is explicitly barred from committing to metadata/** or opening a PR touching it — Check Wiki Authority rejects such a PR against main regardless, so attempting it produces a red PR, not a fix.
• The diagnostic that names the offending page, scripts/check-wiki-private-presence.ts --operator-report, hard-refuses to run when GITHUB_ACTIONS or CI=true is set. I confirmed this by reading the source rather than by trying it. That refusal is correct design — the operator report emits owner--repo filenames that are themselves the private identities the gate exists to protect — but it means no CI-resident agent can ever enumerate the blockers. This one requires a human at a local shell with operator credentials. There is no clever way around it and nobody should build one.

For whoever picks this up cold:

• Files: metadata/repos.yaml on data (not main); scripts/check-wiki-private-presence.ts for the gate logic.
• Root cause: one or more wiki repo pages under knowledge/wiki/repos/ whose slug attributes to no public repo entry in data's metadata/repos.yaml. Yesterday's working-tree measurement isolated it to exactly one entry of 34 lacking an explicit private field.
• Smallest safe fix: resolve that entry's private field to an explicit true/false on data. Audit the other 33 for the same omission while you are in there — draining the class beats defusing the instance, especially for a tripwire that only fires weekly.
• Existing lead, re-verified today: branch copilot/fix-data-orphan-private-repos, head 8ea9588 "fix(data): remove orphan private repo entries blocking data merge", still no open PR. Its diff is 24 deletions in metadata/repos.yaml removing 2 entries. It is stale — it forked from eaf767c while data now sits at 3b81d32, and metadata/repos.yaml has diverged by 195 insertions / 66 deletions since. Rebase onto current data and re-derive; do not merge as-is, and do not assume the 2 entries it deletes are still the right 2.
• Do not: weaken or bypass the gate, add a slug allowlist, wire --operator-report into any workflow, or re-dispatch Merge Data Branch hoping it clears. It fails identically and yields no new signal — two Sundays of evidence say so.
• Verify: local --operator-report shows zero leaks → Merge Data Branch goes green → git rev-list --count origin/main..origin/data returns 0.

2. Dead branch: frobot/readme-pnpm-version-2026-08-17

One commit, 3e35723 "docs: correct pnpm version in README prerequisites", no PR, 35 days old. Its entire diff changes README's pnpm pin from 11.9.0 to 11.19.0 — but main's README has since been rewritten to the version-agnostic "pnpm 11 (exact version pinned in package.json under packageManager)", which is both correct and immune to this class of drift. The branch is obsolete; merging it would regress the README to a hardcoded version that is itself already stale (packageManager reads pnpm@11.25.0). Deleting branches is outside this run's boundaries, so: flagged for manual deletion, no action taken.

3. Durable knowledge surfaced but not persisted

This pass runs branch-pr and has no wiki-write step, so the following is reported rather than written. Whoever next runs in working-dir mode should consider it for knowledge/wiki/topics/github-actions-ci.md:

A fail-closed privacy gate whose only diagnostic refuses to run in CI is uninvestigable by any CI-resident agent — permanently, by construction. Both halves are individually correct: the gate must fail closed, and the diagnostic must refuse CI because its output is the private data. Composed, they produce a failure whose remediation cost is not "hard" but "structurally unavailable to automation," so it does not decay gracefully — it accrues at ~5 stranded commits/day behind a weekly cron with no failure subscriber. The generalizable rule: when a gate's only diagnostic is operator-local, the gate needs a push notification on failure, because the pull path is closed to every automated reader by design.

That is the concrete argument for the workflow_run failure alarm proposed as item 4 of yesterday's report, upgraded from nice-to-have to the actual structural mitigation — such an alarm is the only channel through which this class of failure can reach a human before the next Sunday.

I did not build that alarm this run: adding a new workflow is a new capability, not a minimal reversible repair of something broken, and this pass is barred from touching .github/workflows/ absent a genuine bug in the file itself.

---

The control plane's chrome is clean — pins verified to the byte, guards at full mutation coverage, every gate holding. The one thing that is broken is a gate doing its job perfectly while no one is in the room to hear it. Two Sundays now. The daemon is faithful; the channel is dark.

🤖 Generated by Fro Bot · run 35560232912

[fro-bot]

Superseded by the 2026-09-21 report: #3910