Skip to content

docs(fleet-triage): design for org-wide PR/issue triage routine - #51

Open
asachs01 wants to merge 2 commits into
mainfrom
docs/fleet-triage-design
Open

docs(fleet-triage): design for org-wide PR/issue triage routine#51
asachs01 wants to merge 2 commits into
mainfrom
docs/fleet-triage-design

Conversation

@asachs01

@asachs01 asachs01 commented Aug 17, 2026

Copy link
Copy Markdown
Member

Design doc only — no workflow or script changes.

Why now

Survey of org automation on 2026-08-17 found two silent absence-of-signal failures running concurrently:

  1. dependabot-janitor has been disabled_manually since 2026-07-21 — 27 days, 241 open Dependabot PRs — and nothing alerted on the gap. It produced zero failed runs because it produced zero runs.
  2. dependabot-backlog.md, which dependabot-janitor.sh writes and whose comments name a downstream weekly digest routine as its consumer, 404s on main. It has never been committed.

Neither is reachable by hardening the merge policy, which is where all prior effort went (#28, #36, #38, #23). So liveness is component 1 of the design, not an afterthought.

What this specs

The gaps dependabot-janitor does not cover: liveness/deadman, issue triage (65 open), non-Dependabot PR triage (~175 open), the code-owner-blocked backlog, release decoupling, and agent-authored fixes.

Explicitly not a second merge policy. Dependabot merging stays dependabot-janitor.sh's job; the routine consumes its output buckets rather than re-classifying. That script encodes two production incidents a fresh implementation would re-learn the expensive way.

Findings that need a decision regardless of this doc

Open questions in the doc

  1. The CI-split precondition (task_1786765529531, per fix(janitor): add cortextos+conduit to dependabot-janitor repo scope #50) — the janitor was turned off deliberately. Nothing should re-enable it until this is answered.
  2. Code-owner policy for resolving the blocked bucket.
  3. Whether a Claude cloud routine can hold a GitHub App installation token — unverified.
  4. Run budget across 100 repos.

View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

Specs the automation gaps dependabot-janitor does not cover: liveness,
issues, non-Dependabot PRs, the code-owner-blocked backlog, release
decoupling, and agent-authored fixes.

Not a second merge policy. Dependabot merging stays dependabot-janitor.sh's
job; the routine consumes its output buckets rather than re-classifying. That
script encodes two production incidents (sentinelone-mcp#31 vacuous-green
all-skipping checks, node-datto-rmm#46 grouped-PR hidden major) that a fresh
implementation would re-learn.

Survey findings against main (2026-08-17) recorded in the CHANGELOG:
- janitor disabled_manually since 2026-07-21; 27 days, 241 open Dependabot
  PRs, nothing alerting on the gap
- dependabot-backlog.md 404s on main, never committed, despite a named
  downstream consumer
- required_status_checks NULL on 20/20 sampled *-mcp repos
- #23 still a live hole (grouped + green CI); #22 obsolete, would downgrade
  actions/checkout v6.0.3 -> v4.3.1
Ran dependabot-janitor.sh with DRY_RUN=true locally (no production state
touched, disabled workflow left disabled). 100 repos scanned: 118 would merge
across 71 repos, 25 majors, 21 red CI, 1 conflict.

Two things the data changed:

- #23 is latent, not firing. 108 of the 118 would-merge PRs (92%) are grouped
  and eligible only via the blanket title shortcut, but parsing every dep out
  of all 108 bodies found 0 cross-major and 0 unparseable bumps. The groups are
  update-type-scoped today. Still worth rebasing as defence in depth; demoted
  from re-enable blocker.

- Release decoupling is promoted to a precondition. 118 merges across 71 repos
  with release.yml still on push:[main] is up to 71 semantic-release -> GHCR ->
  Azure deploys in one unbatched wave.

Also records that the dry run's blocked=0 is an artifact: the script
short-circuits on DRY_RUN before the approve+merge attempt, so that bucket can
never populate. It neither confirms nor refutes the code-owner component.

Rollout reordered accordingly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

1 participant