[objectstack-fleet]

Requested by Elon · project thread

Fixes #27726

Clause-②: no
Metadata-protocol: none

维护者速读

• 改了什么：看板快照脚本在计数对不上时，先逐号核对再下结论；并把下次读取的起点往回留 15 分钟。
• 为什么改：巡检从 10-26 起每次都红。实测是 1 张转仓卡和 2 张「GitHub 列表返回旧数据」漏掉的关单，存档永远以为它们还开着。
• 风险与回滚：只动 scripts/pm/board-snapshot.mjs，不发布任何包。被销毁（404）的卡照样报红，没有放宽。回滚就是 revert 这一个提交。
• 先看：scripts/pm/board-snapshot.mjs 里的 reconcileOpenSet（核对逻辑），然后是 settledCursor 和 numberReadVerdict。
• 两分钟验证：node scripts/pm/board-snapshot.mjs --self-test，预期最后一行是 OK … 191 cases pass across 14 batteries。
• 需要你做的：无，席位落地。

What changes

scripts/pm/board-snapshot.mjs only.

• The cursor settles. A live walk's stored cursor (the delta's, or the incremental walk's) is now no later than LISTING_SETTLE_MS (15 min) before the instant its last listing page was read (settledCursor). The next run re-reads that trailing window. since is inclusive, so this is an over-read that writes identical bytes unless a row really changed. On a quiet board the cursor is already older and does not move.

• A disagreeing census is reconciled before it is reported (reconcileOpenSet). When the first count check reads SHORTFALL or SURPLUS, the open listing (openSetPath, creation order) is compared with the archive's open records (reconcileCandidates; gone-ledger numbers excluded, capped at RECONCILE_MAX_NUMBERS). Each number the two disagree on is read on its own, with redirects not followed (numberReadVerdict):

  • 200: archived again.
  • A 301 to an issue in another repository: written onto the archived record as transferred_to. The record stays, and the census counts it apart (counts.issues_transferred).
  • 404 or 410: left exactly as archived. It is still a SURPLUS, still exit 2, and the summary names it with its --restore.

  The board's arithmetic is then read again and the census retaken. The reported verdict is that second reading. The first one is kept in run.reconcile and printed on the reconcile line.

• The read helper gains a reply mode for the per-number read, and stays the file's only fetch. The header gains § "A listing that lags, and a card that moved", and the SURPLUS wording now says that a transfer is recorded rather than ledgered.

Why — measured

Every scheduled snapshot since 2026-10-26T15:11Z reported SURPLUS 1 to 3, read from the 22 manifests on board-archive (ok through 10-26T08:38Z, then 1, 2, 3). I diffed the archive tip (run 40947805554, 20:21Z: archived 323, gone 62, board 258) against the API. Exactly three open issues were archived that the board does not hold:

number	what the API says	why the archive kept it open
#25896	301 → objectstack-ai/hotcrm#2307	the listing never returns a transferred number
#26084	closed 2026-10-27T02:32:52Z	the 02:33Z run's listing served its pre-close row (updated 01:52) while serving rows updated 02:33:14 and 02:33:18 fresh. The cursor became 02:33:18, so the close was outside every later window.
#26638	closed 2026-10-28T02:25:16Z, touched 02:26:13	same, in the 02:26Z run, whose cursor was 02:26:16

So it was not a count race. Both candidates on the card are partly true. It is a persistent drift with two classes: a transferred number, and a row the listing served stale inside the read window, after which the newest-row cursor skipped it for good. The same lag had left four closed PRs archived open (#20052, #20072, #20074, #22635). The issue-only count check could not see those.

Tests

New battery the lagging listing and the moved card (22 cases, floor 13 → 14 batteries) in --self-test. The fake board gains lagging/lagListings (serves a row's pre-update version), moved (301) and destroyed (404):

• Today's red, reproduced: a stale close plus a transfer on a level archive. The first census reads SURPLUS 2, and after reconcile the check reads ok. The transferred record is kept whole with transferred_to. The board is read twice, and the second read comes after the repair. The next run reconciles nothing and never reads the moved number again.
• The settle window alone: a lagged relabel moves no count, so no reconcile runs. It is caught by the next run only because the stored cursor settled.
• ⛔ Not a tolerance: a 404 number stays archived open, the check stays SURPLUS and the run exits 2, naming --restore=301. A gone-ledger number is never read. A blank reconcile listing compares nothing and reads no number.
• Pure helpers: settledCursor, reconcileCandidates, numberReadVerdict (cross-repo 301, same-repo 301, 404/410, 5xx) and openSetPath.

Ablation: with the reconcile disabled, 9 cases go red. With the settle disabled, 2 cases go red. Restored, all 191 pass.

Acceptance notes

• The five archived-open PRs that answer 404 (fix(spec): refuse a blank $between endpoint at the runtime filter door #19374, fix(plugin-security): the unowned permission-set refusal moves a counter #19471, feat(spec): one declaration per version grammar — eight carriers reference three exported constants #19478, fix(spec)!: publish the ObjectSchema.fields constructor/prototype refusal through the bannedKeys arm (#19346) #19538, feat(spec): ISecurityService gains resolveEffectiveObjectPermissions, the effective-object-permission reader (#19539) #19540) are destroyed records outside the issue count check. A reconcile reads them each time it runs (5 requests) and names them as destroyed. Nothing quiets them except the gone ledger, which is unchanged.
• The earlier transfers recorded by hand in gone.json stay there and are excluded from the reconcile, so nothing is counted twice.
• Acceptance proper is the next scheduled Fleet Patrols snapshot run going green. The live reading below predicts it.

Verification

Live run of this head against a scratch copy of board-archive (read-only against GitHub, wrote only the copy)

  archive      25639 record(s): 321 open / 12026 closed issue(s) / 1 transferred, 22 open / 13269 closed pull request(s)
  reconcile    the first census disagreed (SURPLUS of 3: archived 324, board 259), so it was reconciled before the verdict below:
               the open listing carried 276 number(s); 13 disagreed with the archive and were read on their own.
               archived again: #20052 closed, #20072 closed, #20074 closed, #22635 closed, #26084 closed, #26638 closed, #27751 open
               transferred:    #25896 → objectstack-ai/hotcrm#2307
               destroyed:      #19374 (404/410 — --restore=19374), #19471 …, #19478 …, #19538 …, #19540 …
               The board's arithmetic was then read again; the count check below is that second reading.
  count check  ok — 321 open issue(s) archived, board says 259 (open_issues_count 276 minus 17 open pull request(s)).
  freshness    fresh — this run confirmed the archive against the live board.
EXIT=0

A second run straight after: no reconcile, count check ok, 34 numbers in 47 requests (the settle window's re-read), EXIT=0.

dispatch-gates

node scripts/pm/dispatch-gates.mjs --commands derives 38 families. All 38 were run with exit codes captured before any pipe. Nine first exited 3 (yaml/@changesets/cli missing in a fresh worktree) and were re-run after pnpm install --frozen-lockfile, exit 0. --ran reconcile: 38 derived famil(ies) accounted for — 38 run, 0 NOT-MEASURED. Changed lines 501 (+471 / −30), under the 3000 threshold.

Human Minimum

• 1. Schemas start as Zod; packages/spec holds no runtime logic. (not touched)
• 2. Every name I added uses the casing for its kind.
• 3. No formatter ran; pnpm lint passes (eslint on the changed file, exit 0; the full run is CI's).
• 4. One issue, one branch off an up-to-date main, one pull request.
• 5. A change that publishes carries a changeset — scripts/pm/** publishes nothing; skip-changeset.
• 6. packages/spec touched: n/a.
• 7. No hand edits to content/docs/references/, packages/*/CHANGELOG.md or content/docs/releases/.
• 8. Title, body and comments are in English.
• The Before Submitting list in CONTRIBUTING.md is done.

🤖 Generated with Claude Code

https://claude.ai/code/session_016WV4cyJuqtXc5LcmkT6E4D

[objectstack-fleet]

Seat review r1 addressed at head 1150f2c. Each item is pinned in --self-test (now 200 cases, the new battery 31) and ablated:

r1 item	fix	ablation
1 destroyed issue cancelled by a new card	withDestroyedIssues: an unledgered issue whose own read answers 404/410 keeps the run red; verdict destroyed when the counts agree	2 cases red
2 cut-short reconcile vs first board	a cut-short reconcile reports the FIRST census against the FIRST board read; the reconcile runs under BOARD_READ_RESERVE (5) so the second read fits	repaired census vs first board: 1 case red
3 cut-short drops the record	the outcome (re-read / transferred / destroyed) is kept and the summary says CUT SHORT	3 cases red
4 gone subtracted twice	only gone numbers the census counted open are subtracted	1 case red
5 fake fetch ignores redirect	the stub follows redirects unless manual, the destination serves its own card; a 200 naming another number or repo is unreadable	dropping redirect: 'manual': 4 cases red
6 5xx unreachable	reply mode returns 5xx as the number's verdict	the self-test throws (red)
7 (optional, done)	every verdict is reconciled, an agreeing one too	3 cases red

Live, against a fresh copy of board-archive: run 1 first census SURPLUS 3 → reconciled → ok, exit 0. Run 2: first census agreed; 5 destroyed pull requests named, issue verdict ok, exit 0. dispatch-gates --ran: 38 derived, 38 run, 0 NOT-MEASURED.

Note on acceptance: Fixes #27726 closes the card on merge, before the acceptance run. The seat reads the first scheduled Fleet Patrols snapshot after merge.

---

Generated by Claude Code

[objectstack-fleet]

domain:skills#2 · os-elon-musk · session_016WV4d1QkPVVzNz3FJqb2iS

维护者速读

• 改了什么：scripts/pm/board-snapshot.mjs 的看板归档计数核对不再每轮红：游标比最后一次列表读取落后 15 分钟再推进，计数不一致时逐号回读对账后再判；跨仓转移（301）记为 transferred_to，删除（404）照旧判红。
• 为什么改：Fleet Patrols 的快照自 10-26 起每轮 exit 2，原因实测是持续多出 1–3 张：#25896 已转去 hotcrm#2307，ci: Test UI always starts 16 shard runners and Test Core 8, even when the affected set is one package, and an empty shard still pays checkout + install + closure build before learning it has nothing to run #26084、Sessions list: the IPv6 zero address renders raw (0000:0000:…:0000) and a token session with no user agent, IP or time renders as a row of dashes #26638 在列表供旧数据时关闭、被游标跳过。告警常红就等于没有告警。
• 风险与回滚：只改 PM 工具脚本、不发包；没有放宽容差、没有 continue-on-error。revert 即回滚。
• 先看：countCheck / withDestroyedIssues 与对账段；自测 200 例。
• 两分钟验证：node scripts/pm/board-snapshot.mjs --self-test。
• 需要你做的：无（非受管面，席位落地）。合并后席位读第一次定时快照确认转绿。

席位意见：ACCEPT。席位复核三轮（第一轮 6 条、第二轮 1 条，均已改正并带自测钉子与消融），CI 全绿。

席位核对

• 形态: one PR, Fixes #27726, one file scripts/pm/board-snapshot.mjs (+665/−33 net), skip-changeset; not a governed path (dispatch-gates --tier: no path-derived mandate); no contract review owed (no schema, no governed text, no Clause-② arm).
• 前提实测: 11 of 11 scheduled snapshot runs red since 10-27 per the card; the dev measured a persistent SURPLUS 1–3 since 10-26T15:11Z (three stuck numbers, read back by the seat's reviewer: #25896 → hotcrm#2307, ci: Test UI always starts 16 shard runners and Test Core 8, even when the affected set is one package, and an empty shard still pays checkout + install + closure build before learning it has nothing to run #26084 and Sessions list: the IPv6 zero address renders raw (0000:0000:…:0000) and a token session with no user agent, IP or time renders as a row of dashes #26638 closed). Not a race.
• 门禁 check-runs: head b764cf216159073af444c1ea660a1d4773b044a5: 45 check-runs, 29 success, 16 skipped, 0 failed, 0 pending; check-expected-skips --pr 27769: OK, every skip in main's roster (exit 0).
• 接受的偏差: transfers are recognised from GitHub's own cross-repo 301 instead of a hand-written gone.json entry; the reconcile runs on every verdict (≈10–20 requests a run under the 800 cap); BOARD_READ_RESERVE 5 keeps the second board read affordable. Card constraints held: no tolerance, no continue-on-error, fleet-patrols.yml untouched.
• 范围外去向: none.
• 落地条款: non-governed; the seat flips ready and arms auto-merge now under the maintainer's landing grant for this term (seat thread, 2026-10-29 22:04Z). Fixes closes the card at merge; acceptance proper = the first scheduled Fleet Patrols snapshot after merge, read by the seat and recorded on fleet-patrols: board-snapshot fails its count check on every scheduled run since at least 2026-10-27 (11 of 11, exit 2), so the patrol is permanently red #27726.