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
Zero open PRs in this repo. Check runs and legacy commit statuses both enumerated; nothing to repair.
Security
⚠️
5 open Dependabot alerts (4 high fast-uri, 1 medium @humanfs/node), all dev-scope transitive. One-line override fix identified, not delivered — see Needs Human Attention.
Control-Plane Integrity
✅
All third-party action refs SHA-pinned with version comments; scripts/*.ts strip-only clean; least-privilege permissions intact; no guard weakened.
Code Quality
✅
pnpm bootstrap, check-types, lint, test all pass — 71 files / 2846 tests, 0 failures.
Coverage partial: 27/34 tracked repos surveyed successfully, 4 failed, 3 never surveyed. Two adoptable findings reported.
Progressive Improvement
⚠️
TypeScript and Vitest each a major behind; Manage Issues has two independent silent faults. Zero open learning-proposal issues.
Delivery constraint on this run. The scheduled pass ran in working-dir mode, and this job has no PR-creation step — its only delivery path is wiki-ingest.ts, which commits knowledge/** to data. Any edit to pnpm-workspace.yaml or a workflow would have been discarded silently. No code fix was applied. No PR was opened. No branch was pushed. Every remediation below is reported, not delivered, and each carries the exact change to apply.
Version truth: npm registry for tool versions, the Renovate Dependency Dashboard (#2828) for action pins, upstream release/source for dessant/lock-threads. Major drift is included and labeled.
Errored PRs
None. Zero open pull requests on fro-bot/.github, so there is nothing with failing CI to repair. Both check runs and legacy commit statuses were enumerated; neither source reported a failure with no PR to attach it to.
Security
Five open Dependabot alerts, all development scope, all transitive through pnpm-lock.yaml:
All four fast-uri alerts collapse to one resolution. pnpm-workspace.yaml already carries fast-uri: '>=4.1.2' as a prior remediation override, and the lockfile resolved to exactly 4.1.2 — the vulnerable floor. Path: ajv@8.20.0 → ajv-formats → eslint-plugin-json-schema-validator → @bfra.me/eslint-config (devDependency). The @humanfs/node medium is left to Renovate per dependency ownership.
Worth naming: the Renovate Dependency Dashboard currently reads "Renovate has not found any CVEs on osv.dev" while Dependabot holds five open alerts against the same lockfile. Two advisory sources, two verdicts. Do not read the Renovate line as an all-clear.
This is a textbook instance of the wiki's own a >= override floor is a snapshot, not a guarantee rule — the constraint held, the resolution never moved.
Control-Plane Integrity
All four sub-checks verified clean.
SHA pinning — every third-party uses: across .github/workflows/*.yaml and .github/actions/**/action.yaml is a full commit SHA with a # vX.Y.Z comment. Zero floating tags. The only grep hit lacking a version comment was statuses: write in check-private-leak.yaml:53 — a permissions key, not a ref.
Strip-only TypeScript — no enum, namespace, parameter properties, or TS import aliases in scripts/*.ts. pnpm check-types clean under Node 24 native TS.
Least privilege — every workflow declares a top-level permissions:, and every one defaults to contents: read with narrow job-level escalation only where required (security-events: write in CodeQL, statuses: write in the private-leak sentinel, issues/pull-requests: write in the lock and label jobs). No over-broad grant found.
One note on the bfra-me/.github reusable-workflow refs: renovate.yaml and update-repo-settings.yaml are both at 2f2e9da… / v4.24.0. This repo does not reproduce the eight-survey-deep pin-divergence anomaly recorded on bfra-me/works, where a sibling reusable workflow froze at v4.16.0 while the others tracked upstream.
Code Quality
Full validation run, all green:
Command
Result
pnpm bootstrap
✅
pnpm check-types
✅
pnpm lint
✅ (check-md-links + eslint)
pnpm test
✅ 71 files, 2846 passed, 3 todo
No mechanical lint or format fixes were available to apply. Wiki lint reports one deterministic finding, already tracked at #3798 (broken esphome link in knowledge/wiki/topics/home-assistant.md) — not newly introduced, and not regressed by this run's wiki edits.
Oversight
Report-only. 38 repositories enumerated with at least read access; 4 archived, 34 scanned. Three private repositories are tracked in control-plane metadata and are excluded from this report entirely, by count only.
Aging / stale PRs — 90 created >7d ago, 66 untouched >14d, zero drafts. Oldest: renovate-config#1383 (176d), gpt#2165 (159d), gpt#2320 (137d). Six of the ten oldest are fix(security) remediation PRs sitting 79–80 days — advisory patches rotting into merge conflicts while the vulnerability stays live. Next step: triage github-action#1463/#1466 and github-app#840/#842 as duplicated pairs — one decision clears six PRs.
Stale issues (>30d) — 75 total. Nine of the top ten are abandoned multi-phase epics in vbs and extend-vscode. Next step: bulk-close or collapse to one tracking issue each.
Unassigned bugs — 7. The two urgent ones are infra#1258 (deps stranded on main, never redeployed) and infra#1234 (dashboard deploy stuck since 08-30). Next step: assign both — that is an active outage class, not backlog.
New issues (last 2d) — 17, of which 10 are generated daily-report boilerplate. Next step: that ratio is the argument for the retention sweep which is currently broken (see Progressive Improvement).
Top 3 hotspots (deduplicated qualifying findings, public repos only):
marcusrbrown/gpt — 32 (15 aging PRs, 17 stale issues). Anchor: PR#2165, HeroUI v2→v3, 159d. One stalled migration fanned out into ~9 issues and a PR. Decide it in or out; nothing else here moves first.
marcusrbrown/sparkle — 18 (15 aging PRs, 2 stale issues, 1 unassigned bug). Anchor: PR#1914, autoheal lint auto-fixes, 24d. Six aging PRs are chore(lint): apply auto-fixes from autohealing run — the autohealer opens faster than anyone merges. Auto-merge lint-only diffs or throttle the job.
The structural read across the sweep: 90 aging PRs against 34 active repos, zero drafts, a large share bot-authored. The automation generates work faster than the merge path consumes it, and security patches are queued behind lint churn. That is a queue with no drain.
Cross-Project Intelligence
Report-only. Coverage is partial. Of 34 entries in metadata/repos.yaml: 27 surveyed successfully, 4 failed, 3 never surveyed. One entry (marcusrbrown/copiloting) is >30d stale and also trips wiki lint's stale-claim and missing-cross-reference advisories. Unscanned entries are not named where they are private.
Two adoptable findings, both from bfra-me/works via the wiki:
Marker-authenticated report discovery.bfra-me/works trusts a prior report only when author.login is exactly fro-botand the body carries <!-- fro-bot:autoheal-report:v1 -->; a matching title alone is explicitly untrusted. This repo has adopted only the cosmetic half of that remedy. Dated titles: yes. Author check and body marker: no — this daily pass is instructed to close prior reports by title prefix, which is weaker still than the exact-title case the wiki originally described, on a public repo, with an App token holding issues: write. Directly adoptable and the highest-value item in this section. Persisted to the wiki as a dated correction.
A uses:-ref drift lint.bfra-me/works carried a sibling reusable workflow frozen at v4.16.0 for eight surveys while its two siblings rode to v4.24.0 — same owner, same datasource, invisible to review. A repo-level check comparing all refs against a shared upstream would have caught it immediately. This repo is currently clean on that axis, which makes now the cheap time to add the check.
Progressive Improvement
Report-only.
Tool-version drift (source: npm registry; majors included): typescript 6.0.3 → 7.0.2 (major behind), vitest 4.1.4 → 5.0.0 (major behind; Renovate branch renovate/major-vitest-monorepo is queued awaiting status checks). eslint 10.9.0 → 10.9.1 and prettier 3.9.1 → 3.9.6 are patch-only, within tolerance. All are Renovate's to land.
Degraded CI job — Manage Issues has two independent, silent faults, neither of which blocks anything because the workflow is not a required check:
The retention sweep at .github/workflows/manage-issues.yaml:38 selects on test("Daily (Org Oversight|Autohealing) Report"). The current title is Daily Fro Bot Report — …, which does not match. The 3-day report-retention policy has been matching zero issues since the rename, while exiting 0. That is why 10 of the 17 new org-wide issues in the last two days are report boilerplate.
learning-proposal backlog — zero open, so the compounding pipeline is not stalled by the stated rule (none older than 14 days, fewer than two open). Recorded from a direct label query rather than inferred from Improvement Metrics #3674's healthy reading, which cannot evidence this either way.
Stale TODO/FIXME — none in scripts/*.ts or docs/*.md outside a test fixture.
Body matrix row: fro-bot/.github#3512 = Open, gateway-side gates satisfied
Project 1 item: Status=Todo, Readiness=tracking
The consequence is not cosmetic. The body lists "Operator push deploy + enablement (v0.85.0) — not yet deployed (the deployed pin is v0.83.0)" as a blocking item; the pin is now v0.93.1, which is past v0.85.0, so that blocker is very likely already resolved and nobody updated the tracker. The tracker is 10 minor versions behind on the deploy pin and 22 behind on the release head, and its Project item never left Todo while the work it describes shipped.
Needs Human Attention
Written so any LLM agent can pick these up cold.
1. Manage Issues → Lock job fails on every scheduled run
File:.github/workflows/manage-issues.yaml:105 (token passed at line 113)
Evidence:run 33722522110 — ##[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 input with Joi.string().trim().max(100) in src/schema.js. GitHub's auto-provisioned GITHUB_TOKEN, passed as ${{ github.token }}, has grown past 100 characters. Upstream relaxed the bound to .max(1000) in v6.0.1 (2026-05-21). Verified by diffing src/schema.js at the pinned SHA against v6.0.2.
Smallest safe fix: bump the pin dessant/lock-threads@7266a7ce5c1df01b1c6db85bf8cd86c737dadbe7 # v6.0.0 → the v6.0.2 SHA with a matching # v6.0.2 comment. One line.
Constraint / do not retry: this run did not apply it. Renovate already has this exact update queued on Dependency Dashboard Dependency Dashboard #2828 (v6.0.0 → v6.0.2) and owns routine version bumps; do not open a competing PR. Do not "fix" this by swapping in a shorter token or deleting the input — the token is correct and the validator is stale. Do not vendor the action to patch the schema.
Verify: after the pin lands, gh run list --workflow manage-issues.yaml --limit 1 shows the Lock job concluding success.
2. Report-retention sweep matches nothing after the report rename
File:.github/workflows/manage-issues.yaml:38
Root cause: the selector is test("Daily (Org Oversight|Autohealing) Report"). Reports are now titled Daily Fro Bot Report — YYYY-MM-DD (UTC). The regex has matched zero issues since the rename and the step exits 0, so the failure is invisible.
Smallest safe fix: extend the alternation to test("Daily (Org Oversight|Autohealing|Fro Bot) Report"). Keep the older names — they still identify historical reports that need collecting.
Constraint: the surrounding while read loop already tolerates empty input; no other change needed. Do not widen the pattern beyond these three names — this job closes issues with an App token, and a loose selector on a public repo becomes a denial-of-service on the issue tracker.
Verify:gh issue list --state open --json title --jq '[.[]|select(.title|test("Daily (Org Oversight|Autohealing|Fro Bot) Report"))]|length' is non-zero before the fix ships, and the next scheduled run reports a non-zero close count.
3. fast-uri override floor sits at the vulnerable version
File:pnpm-workspace.yaml:14
Root cause:fast-uri: '>=4.1.2' was written as a prior security remediation; 4.1.2 is now the vulnerable floor for four high-severity advisories. The lockfile resolved to exactly 4.1.2.
Smallest safe fix:fast-uri: '>=4.1.2' → fast-uri: '>=4.1.3', then pnpm install --lockfile-only to move the single resolution. Latest published is 4.1.4; 4.1.3 is the minimum patched version, so the floor covers both.
Constraint: dev-scope transitive only — no runtime exposure. Ship it alone; do not batch with the @humanfs/node medium or any other bump, and do not run a full pnpm update. Note this override shape will re-rot: consider whether a >= floor is the right instrument at all, given it silently permits the exact version it was written to exclude.
Verify:pnpm why fast-uri resolves to ≥4.1.3 and the four Dependabot alerts auto-close.
4. Gateway tracker #3512 is 25 days stale and its Project item never left Todo
Root cause: documented in the section above with both claimed and live values. No automated writer reconciles the issue body against apps/gateway/upstream.json or the agent release feed.
Smallest safe fix: update the three version claims in the Track cross-repo Gateway operator control-surface rollout #3512 body and move the Project 1 item off Status=Todo. Re-evaluate whether the "Operator push deploy + enablement" blocker is still real now the pin is v0.93.1.
Constraint: the dedicated Gateway Rollout Tracker workflow owns tracker writes. Do not post tracker comments or edit Project fields from the daily-report path.
5. Oversight enumeration is degraded — token lacks read:org
Root cause:gh api user/orgs --paginate returns empty rather than erroring. Org membership could not be listed directly; the sweep compensated by deriving org owners from the repo list and querying orgs/bfra-me/repos explicitly, which surfaced no additional repos. Coverage is believed complete for this run but is not guaranteed — an org whose repos are all invisible to the user-repos listing would be silently absent. An empty success is indistinguishable from a denied read here, which is the whole problem.
Smallest safe fix: grant the sweep token read:org.
Verify:gh api user/orgs --jq 'length' returns non-zero.
6. Cross-project survey coverage is partial
Root cause: 4 of 34 tracked repos have last_survey_status: failure and 3 have never been surveyed. Failure reasons are not recorded in metadata/repos.yaml beyond the status field, so diagnosing requires reading run logs.
Smallest safe fix: re-dispatch via gh workflow run survey-repo.yaml -f node_id=<node_id> using the node_id values on the data branch, and capture a failure reason field alongside last_survey_status.
Constraint: three tracked repos are private. Never name them or their contents on a public surface; the public-only wiki invariant blocks them at survey, ingest, and the data → main promotion gate — keep it that way.
7. The control-plane repo has no wiki page of its own
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. Three sections in knowledge/wiki/topics/github-actions-ci.md now reference it by plain name because a [[fro-bot--github]] wikilink would dangle.
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 three plain-text references to wikilinks.
Constraint: writes to knowledge/** go through the established wiki scripts to the data branch — never edited directly on main.
Knowledge persisted
Three findings from this run were durable enough to keep, and are committed to knowledge/wiki/topics/github-actions-ci.md plus knowledge/log.md — the only delivery path this run actually had:
A dated correction to A Title-Matched Rolling Issue Is a Public Write Surface, confirming the finding is unmitigated on this repo: dated titles were adopted, the author check and body marker were not. The date was the ergonomic improvement; the author check was the control.
New: A Rename Silently Orphans Its Title-Matching Consumers — a name used as an interface is an interface, and a filter that matches nothing looks exactly like a filter with nothing to match.
New: A Pinned Action Freezes Validation Against a Credential Format That Keeps Moving — third member of the "the pin is fine, the meaning moved" family. SHA pinning worked exactly as designed, and that is precisely why the lock job broke.
Both Manage Issues faults are silent, unguarded, and were found by reading run history rather than from any alert. The control plane has been watching thirty-four repositories with a broken clock on its own wrist.
Daily Fro Bot Report — 2026-09-04 (UTC)
Run Summary
fast-uri, 1 medium@humanfs/node), all dev-scope transitive. One-line override fix identified, not delivered — see Needs Human Attention.scripts/*.tsstrip-only clean; least-privilege permissions intact; no guard weakened.pnpm bootstrap,check-types,lint,testall pass — 71 files / 2846 tests, 0 failures.read:org), compensated.Manage Issueshas two independent silent faults. Zero openlearning-proposalissues.Delivery constraint on this run. The scheduled pass ran in
working-dirmode, and this job has no PR-creation step — its only delivery path iswiki-ingest.ts, which commitsknowledge/**todata. Any edit topnpm-workspace.yamlor a workflow would have been discarded silently. No code fix was applied. No PR was opened. No branch was pushed. Every remediation below is reported, not delivered, and each carries the exact change to apply.Version truth: npm registry for tool versions, the Renovate Dependency Dashboard (#2828) for action pins, upstream release/source for
dessant/lock-threads. Major drift is included and labeled.Errored PRs
None. Zero open pull requests on
fro-bot/.github, so there is nothing with failing CI to repair. Both check runs and legacy commit statuses were enumerated; neither source reported a failure with no PR to attach it to.Security
Five open Dependabot alerts, all
developmentscope, all transitive throughpnpm-lock.yaml:fast-uri>=4.0.1 <4.1.3fast-uri>=4.0.0 <4.1.3fast-uri>=4.0.0 <4.1.3fast-uri>=4.0.0 <4.1.3@humanfs/node<0.16.8All four
fast-urialerts collapse to one resolution.pnpm-workspace.yamlalready carriesfast-uri: '>=4.1.2'as a prior remediation override, and the lockfile resolved to exactly4.1.2— the vulnerable floor. Path:ajv@8.20.0 → ajv-formats → eslint-plugin-json-schema-validator → @bfra.me/eslint-config(devDependency). The@humanfs/nodemedium is left to Renovate per dependency ownership.Worth naming: the Renovate Dependency Dashboard currently reads "Renovate has not found any CVEs on osv.dev" while Dependabot holds five open alerts against the same lockfile. Two advisory sources, two verdicts. Do not read the Renovate line as an all-clear.
This is a textbook instance of the wiki's own a
>=override floor is a snapshot, not a guarantee rule — the constraint held, the resolution never moved.Control-Plane Integrity
All four sub-checks verified clean.
uses:across.github/workflows/*.yamland.github/actions/**/action.yamlis a full commit SHA with a# vX.Y.Zcomment. Zero floating tags. The only grep hit lacking a version comment wasstatuses: writeincheck-private-leak.yaml:53— a permissions key, not a ref.enum,namespace, parameter properties, or TS import aliases inscripts/*.ts.pnpm check-typesclean under Node 24 native TS.permissions:, and every one defaults tocontents: readwith narrow job-level escalation only where required (security-events: writein CodeQL,statuses: writein the private-leak sentinel,issues/pull-requests: writein the lock and label jobs). No over-broad grant found.One note on the
bfra-me/.githubreusable-workflow refs:renovate.yamlandupdate-repo-settings.yamlare both at2f2e9da…/ v4.24.0. This repo does not reproduce the eight-survey-deep pin-divergence anomaly recorded onbfra-me/works, where a sibling reusable workflow froze at v4.16.0 while the others tracked upstream.Code Quality
Full validation run, all green:
pnpm bootstrappnpm check-typespnpm lintcheck-md-links+ eslint)pnpm testNo mechanical lint or format fixes were available to apply. Wiki lint reports one deterministic finding, already tracked at #3798 (broken
esphomelink inknowledge/wiki/topics/home-assistant.md) — not newly introduced, and not regressed by this run's wiki edits.Oversight
Report-only. 38 repositories enumerated with at least read access; 4 archived, 34 scanned. Three private repositories are tracked in control-plane metadata and are excluded from this report entirely, by count only.
fix(security)remediation PRs sitting 79–80 days — advisory patches rotting into merge conflicts while the vulnerability stays live. Next step: triage github-action#1463/#1466 and github-app#840/#842 as duplicated pairs — one decision clears six PRs.vbsandextend-vscode. Next step: bulk-close or collapse to one tracking issue each.Top 3 hotspots (deduplicated qualifying findings, public repos only):
wsDoS, 55d untouched. Merge or close the four stalled security PRs; they are the only findings here with real exposure.chore(lint): apply auto-fixes from autohealing run— the autohealer opens faster than anyone merges. Auto-merge lint-only diffs or throttle the job.The structural read across the sweep: 90 aging PRs against 34 active repos, zero drafts, a large share bot-authored. The automation generates work faster than the merge path consumes it, and security patches are queued behind lint churn. That is a queue with no drain.
Cross-Project Intelligence
Report-only. Coverage is partial. Of 34 entries in
metadata/repos.yaml: 27 surveyed successfully, 4 failed, 3 never surveyed. One entry (marcusrbrown/copiloting) is >30d stale and also trips wiki lint'sstale-claimandmissing-cross-referenceadvisories. Unscanned entries are not named where they are private.Two adoptable findings, both from
bfra-me/worksvia the wiki:bfra-me/workstrusts a prior report only whenauthor.loginis exactlyfro-botand the body carries<!-- fro-bot:autoheal-report:v1 -->; a matching title alone is explicitly untrusted. This repo has adopted only the cosmetic half of that remedy. Dated titles: yes. Author check and body marker: no — this daily pass is instructed to close prior reports by title prefix, which is weaker still than the exact-title case the wiki originally described, on a public repo, with an App token holdingissues: write. Directly adoptable and the highest-value item in this section. Persisted to the wiki as a dated correction.uses:-ref drift lint.bfra-me/workscarried a sibling reusable workflow frozen at v4.16.0 for eight surveys while its two siblings rode to v4.24.0 — same owner, same datasource, invisible to review. A repo-level check comparing all refs against a shared upstream would have caught it immediately. This repo is currently clean on that axis, which makes now the cheap time to add the check.Progressive Improvement
Report-only.
typescript6.0.3 → 7.0.2 (major behind),vitest4.1.4 → 5.0.0 (major behind; Renovate branchrenovate/major-vitest-monorepois queued awaiting status checks).eslint10.9.0 → 10.9.1 andprettier3.9.1 → 3.9.6 are patch-only, within tolerance. All are Renovate's to land.Manage Issueshas two independent, silent faults, neither of which blocks anything because the workflow is not a required check:Lockjob fails on every run (see Needs Human Attention feat: set default settings #1)..github/workflows/manage-issues.yaml:38selects ontest("Daily (Org Oversight|Autohealing) Report"). The current title isDaily Fro Bot Report — …, which does not match. The 3-day report-retention policy has been matching zero issues since the rename, while exiting0. That is why 10 of the 17 new org-wide issues in the last two days are report boilerplate.learning-proposalbacklog — zero open, so the compounding pipeline is not stalled by the stated rule (none older than 14 days, fewer than two open). Recorded from a direct label query rather than inferred from Improvement Metrics #3674'shealthyreading, which cannot evidence this either way.scripts/*.tsordocs/*.mdoutside a test fixture.Gateway Rollout Tracker (#3512) — awareness only
Review-only; no tracker comment posted and no Project field edited. Three mismatches, each with both values:
fro-bot/agentv0.83.0marcusrbrown/infraapps/gateway/upstream.jsonpins v0.93.1fro-bot/.github#3512= Open, gateway-side gates satisfiedStatus=Todo,Readiness=trackingThe consequence is not cosmetic. The body lists "Operator push deploy + enablement (v0.85.0) — not yet deployed (the deployed pin is v0.83.0)" as a blocking item; the pin is now v0.93.1, which is past v0.85.0, so that blocker is very likely already resolved and nobody updated the tracker. The tracker is 10 minor versions behind on the deploy pin and 22 behind on the release head, and its Project item never left
Todowhile the work it describes shipped.Needs Human Attention
Written so any LLM agent can pick these up cold.
1.
Manage Issues→Lockjob fails on every scheduled run.github/workflows/manage-issues.yaml:105(token passed at line 113)##[error]"github-token" length must be less than or equal to 100 characters longdessant/lock-threadsv6.0.0 validates its token input withJoi.string().trim().max(100)insrc/schema.js. GitHub's auto-provisionedGITHUB_TOKEN, passed as${{ github.token }}, has grown past 100 characters. Upstream relaxed the bound to.max(1000)in v6.0.1 (2026-05-21). Verified by diffingsrc/schema.jsat the pinned SHA againstv6.0.2.dessant/lock-threads@7266a7ce5c1df01b1c6db85bf8cd86c737dadbe7 # v6.0.0→ the v6.0.2 SHA with a matching# v6.0.2comment. One line.v6.0.0 → v6.0.2) and owns routine version bumps; do not open a competing PR. Do not "fix" this by swapping in a shorter token or deleting the input — the token is correct and the validator is stale. Do not vendor the action to patch the schema.gh run list --workflow manage-issues.yaml --limit 1shows theLockjob concludingsuccess.2. Report-retention sweep matches nothing after the report rename
.github/workflows/manage-issues.yaml:38test("Daily (Org Oversight|Autohealing) Report"). Reports are now titledDaily Fro Bot Report — YYYY-MM-DD (UTC). The regex has matched zero issues since the rename and the step exits0, so the failure is invisible.test("Daily (Org Oversight|Autohealing|Fro Bot) Report"). Keep the older names — they still identify historical reports that need collecting.while readloop already tolerates empty input; no other change needed. Do not widen the pattern beyond these three names — this job closes issues with an App token, and a loose selector on a public repo becomes a denial-of-service on the issue tracker.gh issue list --state open --json title --jq '[.[]|select(.title|test("Daily (Org Oversight|Autohealing|Fro Bot) Report"))]|length'is non-zero before the fix ships, and the next scheduled run reports a non-zero close count.3.
fast-urioverride floor sits at the vulnerable versionpnpm-workspace.yaml:14fast-uri: '>=4.1.2'was written as a prior security remediation; 4.1.2 is now the vulnerable floor for four high-severity advisories. The lockfile resolved to exactly 4.1.2.fast-uri: '>=4.1.2'→fast-uri: '>=4.1.3', thenpnpm install --lockfile-onlyto move the single resolution. Latest published is 4.1.4; 4.1.3 is the minimum patched version, so the floor covers both.@humanfs/nodemedium or any other bump, and do not run a fullpnpm update. Note this override shape will re-rot: consider whether a>=floor is the right instrument at all, given it silently permits the exact version it was written to exclude.pnpm why fast-uriresolves to ≥4.1.3 and the four Dependabot alerts auto-close.4. Gateway tracker #3512 is 25 days stale and its Project item never left
Todoapps/gateway/upstream.jsonor the agent release feed.Status=Todo. Re-evaluate whether the "Operator push deploy + enablement" blocker is still real now the pin is v0.93.1.5. Oversight enumeration is degraded — token lacks
read:orggh api user/orgs --paginatereturns empty rather than erroring. Org membership could not be listed directly; the sweep compensated by deriving org owners from the repo list and queryingorgs/bfra-me/reposexplicitly, which surfaced no additional repos. Coverage is believed complete for this run but is not guaranteed — an org whose repos are all invisible to the user-repos listing would be silently absent. An empty success is indistinguishable from a denied read here, which is the whole problem.read:org.gh api user/orgs --jq 'length'returns non-zero.6. Cross-project survey coverage is partial
last_survey_status: failureand 3 have never been surveyed. Failure reasons are not recorded inmetadata/repos.yamlbeyond the status field, so diagnosing requires reading run logs.gh workflow run survey-repo.yaml -f node_id=<node_id>using thenode_idvalues on thedatabranch, and capture a failure reason field alongsidelast_survey_status.data → mainpromotion gate — keep it that way.7. The control-plane repo has no wiki page of its own
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. Three sections inknowledge/wiki/topics/github-actions-ci.mdnow reference it by plain name because a[[fro-bot--github]]wikilink would dangle.knowledge/wiki/repos/fro-bot--github.mdperknowledge/schema.md, add it toknowledge/index.md, then promote the three plain-text references to wikilinks.knowledge/**go through the established wiki scripts to thedatabranch — never edited directly onmain.Knowledge persisted
Three findings from this run were durable enough to keep, and are committed to
knowledge/wiki/topics/github-actions-ci.mdplusknowledge/log.md— the only delivery path this run actually had:Both
Manage Issuesfaults are silent, unguarded, and were found by reading run history rather than from any alert. The control plane has been watching thirty-four repositories with a broken clock on its own wrist.Run Summary
schedule-898cd73a-33834617552scheduleonrefs/heads/mainworking-dir— no PRs opened, no branches created, no commits pushed by this agentknowledge/wiki/topics/github-actions-ci.md,knowledge/log.mdpnpm bootstrap✅ ·check-types✅ ·lint✅ ·test✅ (2846 passed)