@feigi/fleet-ctl 3.81.3 → 3.81.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@feigi/fleet-ctl",
-  "version": "3.81.3",
+  "version": "3.81.5",
   "description": "Agent fleet: run-team controller, merge bot, PR reviewer, and the ticket pipeline they share",
   "license": "Apache-2.0",
   "repository": {

package/scripts/reap.sh

@@ -371,10 +371,10 @@ keep() {
 # at, by two DIFFERENT rules for two DIFFERENT groups. Three call sites below
 # read `status --porcelain` (`-uall`, or `-unormal --ignored`) and are safe
 # because git quotes PATHS; a fourth, added after this comment was first
-# written, reads `for-each-ref --format='%(refname)
-# %(upstream:track)'` and is safe for an unrelated reason — a REFNAME,
-# unlike a path, can never contain the byte at all. Nothing in the body
-# checks either invariant.
+# written, reads `for-each-ref` with a format that prints only refnames and
+# fixed words, and is safe for an unrelated reason — a REFNAME, unlike a
+# path, can never contain the byte at all, and a fixed word is text git
+# itself prints. Nothing in the body checks either invariant.
 #
 # The path-reading three: both halves of git's answer put a control byte in
 # a path beyond reach of the split, by two DIFFERENT rules — measured on git
@@ -394,13 +394,19 @@ keep() {
 #   0x02 there either.
 #
 # The ref-reading fourth: no PATH-quoting rule is doing the work, because no
-# quoting is needed — git refuses to CREATE the ref at all. Measured, git
-# 2.50.1 (Apple Git-155): `git branch "$(printf 'a\002b')"` fails outright —
-# `fatal: 'a?b' is not a valid branch name` — and so does `git update-ref
-# refs/heads/"$(printf 'a\002b')" HEAD` — `refusing to update ref with bad
-# name`. `%(refname)` and `%(upstream:track)` can only ever answer with
-# bytes that already survived `check-ref-format` on the way in, so a raw
-# 0x02 can never reach either field to begin with. A fifth call site joins
+# quoting is needed — every field its format prints is either a validated
+# refname or a fixed word git prints. git refuses to CREATE a ref whose name
+# holds the byte at all. Measured, git 2.50.1 (Apple Git-155): `git branch
+# "$(printf 'a\002b')"` fails outright — `fatal: 'a?b' is not a valid branch
+# name` — and so does `git update-ref refs/heads/"$(printf 'a\002b')" HEAD`
+# — `refusing to update ref with bad name`. `%(refname)` can only ever
+# answer with bytes that already survived `check-ref-format` on the way in.
+# The other two fields are fixed words: the `%(if)%(upstream)` test prints
+# `upstream` or `no-upstream` out of the format itself, and
+# `%(upstream:track)` prints git's own tracking words — `[gone]`, `[ahead N]`
+# and their siblings. `%(upstream)`'s own text is never printed: it is built
+# from the branch.<b>.merge value, which git does not validate, and a raw
+# 0x02 written there reaches it (measured, git 2.50.1). A fifth call site joins
 # this ref group: `rev-parse --verify refs/heads/<b>`, where
 # `<b>` is a name the `for-each-ref` call site produced. Its stdout is an
 # object id in hex, and what it can put on stderr is git's own fixed prose
@@ -416,10 +422,10 @@ keep() {
 # -uall -z` carries the raw 0x02 straight through, `-z` being the
 # machine-readable form that drops the quoting, and so does any command
 # emitting CONTENT rather than paths or refnames (`log --format=%s`, `show
-# <rev>:<path>`, both measured). The ref group has no equivalent flag —
-# `for-each-ref` cannot be asked to emit an unvalidated refname — so this
-# warning is really aimed at the path group and at any THIRD kind of call
-# site a future caller might add.
+# <rev>:<path>`, both measured). The ref group stays out of reach only while
+# its format prints no atom built from config, such as `%(upstream)` — so
+# this warning is aimed at the path group, at that format, and at any THIRD
+# kind of call site a future caller might add.
 #
 # Left unguarded anyway, deliberately: every call site is shaped
 # `if ! git_probe …; then keep …`, so a garbled $gp_rc can never come back 0
@@ -980,13 +986,14 @@ EOF
 #
 # The [gone] test reads $3 and the no-upstream test reads $2: a space is not
 # legal in a branch name (measured — git refuses `has space` as invalid), so
-# the name is always the whole of $1, and $2 is `upstream=` followed by
-# %(upstream)'s ref — exactly `upstream=` when the branch has none. The
-# tracking forms that DO carry a space, `[ahead 1]` and its siblings, split so
-# that $3 holds `[ahead` — not `[gone]` either way. That layout holds only
-# while the upstream ref carries no whitespace: %(upstream) is built from the
-# branch.<b>.merge value, which git does not validate, and a space there moves
-# the track out of $3 (measured, git 2.50.1).
+# the name is always the whole of $1. $2 is a fixed word the format itself
+# prints — `upstream` when the branch has one, `no-upstream` when it has
+# none — so an unset upstream still fills $2 rather than leaving the
+# whitespace split to drop an empty field. $3 is %(upstream:track). The
+# tracking forms that DO carry a space, `[ahead 1]` and its siblings, split
+# so that $3 holds `[ahead` — not `[gone]` either way. No field prints
+# %(upstream)'s own text, which git builds from the unvalidated
+# branch.<b>.merge value.
 # A command substitution inside a `for ... in` word list discards its own
 # exit status entirely, in every shell measured here (bash, dash, macOS
 # /bin/sh): `for x in $(false); do …; done` completes at the loop's own end,
@@ -1011,10 +1018,7 @@ EOF
 # the same reason — dying here would also abort the second sweep and the
 # final `worktree prune`, neither of which this enumeration failing has
 # anything to do with, over a failure that only defers reaping to a later pass.
-# `upstream=` makes an unset %(upstream) a field of its own. Without it the
-# whitespace split drops the empty field, and `$2` reads the track instead, so
-# `$2=="upstream="` is exactly the no-upstream case and `$3` the [gone] test.
-if ! git_probe for-each-ref --format='%(refname) upstream=%(upstream) %(upstream:track)' refs/heads; then
+if ! git_probe for-each-ref --format='%(refname) %(if)%(upstream)%(then)upstream%(else)no-upstream%(end) %(upstream:track)' refs/heads; then
   keep "" "could not enumerate [gone] branches — none reaped, and none reported reapable either$(gp_why)"
   gone_branches=""
   no_upstream=""
@@ -1032,7 +1036,7 @@ else
     keep "" "could not enumerate [gone] branches — none reaped, and none reported reapable either"
     gone_branches=""
   fi
-  if ! no_upstream=$(printf '%s\n' "$gp_out" | awk '$2=="upstream="{sub(/^refs\/heads\//,"",$1); print $1}'); then
+  if ! no_upstream=$(printf '%s\n' "$gp_out" | awk '$2=="no-upstream"{sub(/^refs\/heads\//,"",$1); print $1}'); then
     keep "" "could not enumerate branches with no upstream — none reported kept"
     no_upstream=""
   fi

package/skills/run-team/references/ci-watcher.md

@@ -47,14 +47,25 @@ bill a second one that `rate_limit` does not report; the boundary is per route,
 so `actions/runs/<id>/jobs` is on the reported counter. Every response says
 `X-Ratelimit-Resource: core`, so only the reset epoch and the used sequence tell
 the two apart, and the unreported bucket's remaining count is readable only from
-the `X-Ratelimit-Remaining` header of a call that bills it. **A second pass gate
-therefore probes it too**: one `gh api -i` read of
+the `X-Ratelimit-Remaining` header of a call that bills it. GitHub's REST
+rate-limit documentation does not describe this bucket (it says `core` covers
+"all non-search-related resources in the REST API"), so the gate rests on
+measurement (2026-10-13 and 2026-10-19), not on documentation. **A second pass
+gate therefore probes it too**: one `gh api -i` read of
 `actions/workflows?per_page=1` per tick, 1 unit of that bucket (measured
 2026-10-13: its remaining count fell by 1 per call while `rate_limit` stood
 still, and its reset epoch differed from `rate_limit`'s). A `ci-state` call
 spends 4 units of it on the common path — one `gh run list` and one `gh run view`
 cost 2 each (measured the same day) — so it is held to the same `200 + 4 × count`
-reserve. It has its own global latch (`hidden_out`) and its DEGRADED and
+reserve. 4 is the most one call spends on this bucket for a repo with at most 100
+workflows: 0 with no CI, 2 with no run on the PR's head, 4 otherwise. The
+dropped-required-jobs path adds only reported-bucket calls, and the workflow-name
+lookup pages 100 workflows per page, so a repo with more pays more per call. The
+bucket is account-wide, not per repository: probes on three unrelated
+repositories drew one countdown and one reset epoch (measured 2026-10-19), so
+another run on the same token, or any `gh run` use, spends it, and its
+DEGRADED line can fire with few open PRs on this repository. It has its own
+global latch (`hidden_out`) and its DEGRADED and
 RECOVERED lines name it, so a pause on this bucket is not misread as the
 reported budget running low. An unreadable header is an outage here exactly as a
 non-numeric `rate_limit` read is. The probe runs only when the reported-bucket