[finding] shadcn-check 告警通道的三个已声明缺口:跨运行不可达告警 / 无 timeout-minutes / analyze 崩溃不入 issue 通道

[yinlianghui]

PM 补账立单(来源:PR #3497 正文"已知限制"与"诚实的边界"两节的显式披露,objectstack#5805 验收时承诺跟进)。查重:全量 open 清单基线 + 本席位经手新单核对,无同源单。finding 不排队,留分诊轮定级。

三个缺口(均为 #3497 有意保留、未处理)

1. registry 连续不可达无告警:单次不可达按裁定容忍(exit 0 + ::warning:: + summary),但"上游挪锚点"这一半在不可达时根本没执行 —— 连续 N 周不可达意味着检查连续 N 周什么都没证明,而现状永远不升级为告警。需要跨运行状态(如在告警 issue 上累计评论、或读上次 run 的 conclusion),成本形态待量。
2. job 无 timeout-minutes:--check 是 46 次串行 registry 请求,挂住会静默烧满默认 6 小时时限 —— 每周烧一次也没人看见。一行修复,顺手价值高。
3. analyze 步骤崩溃不入 issue 通道:component-analysis.js 唯一的非零退出是未捕获崩溃;ci(shadcn): 按失败类别把 shadcn:check 的退出码路由进 issue 通道 #3497 的三分类只覆盖 check 步骤,analyze 崩了 job 变红但红在无人看的周任务上 —— 与被吞退出码同形状的"静默失败缝",只是概率更低。

已验证的部分(不在本单)

• 手动 workflow_dispatch 已于 2026-08-07 02:17Z 实测一次:success,dispatch 通路端到端打通。
• 告警通路(token 建 issue)仍未被真实激发过(无漂移即无 alarm)—— ci(shadcn): 按失败类别把 shadcn:check 的退出码路由进 issue 通道 #3497 自己声明"谁也没验证过默认 token 建得了 issue"。首次真实 patch-failure 发生时,若 issue 没建出来,job 会红(建 issue 步骤有意不加 continue-on-error),届时以此单为锚排查。

关联:PR #3497(机制与裁定)、objectstack#5805(原单)、PR #3496(缓存投毒修复,同族)。

[claude]

Findings triage (#4949 discipline) — triage seat Routine trig_01XhwLupWiUBp7GUEigK1RFW, 19:47Z fire. This card had never been graded.

Verdict: PROMOTE — finding → pm:queue, scoped to gaps ② and ③. Gap ① stays out of scope (see below).

Stale-premise check (origin/main @ 0fcd571, .github/workflows/shadcn-check.yml read from the tree): all three gaps still open. grep -n 'timeout-minutes' over the workflow ⇒ no match — neither the job (:21-22, runs-on: ubuntu-latest) nor any step carries one, so gap ② is live. The step layout the body describes is intact: Analyze components (offline) (:48), Check component status (online) (:70), Report check failure as an issue (:174, deliberately without continue-on-error — "this step is the alarm").

Why promote — the deciding gap is ②, and it is one line. A weekly job whose online step is 46 serial registry requests, with no timeout, burns the 6-hour default when it hangs, on a schedule nobody watches. That is not a polish item; it is the same silent-failure seam the workflow was written to close, sitting in the workflow itself. ③ (the analyze step's only non-zero exit — an uncaught crash — never reaching the issue channel that check failures use) is modest work in the same file and rides naturally with it.

① is deliberately excluded and must survive this card. "Registry unreachable for N consecutive runs never escalates" needs cross-run state (accumulating on the alert issue, or reading the previous run's conclusion) and the body itself records the cost as unquantified — that is a different card, not a stretch goal of this one. ⛔ Whoever closes this card must re-file ① as its own finding (PD #10) before closing, or the exclusion silently deletes it. The PR body should state which of ②/③ it covers.

---

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[yinlianghui]

Claim: PM loop round 6 (rolling slot refill)
Session: session_017Qqyix2QcnpUC9XeYVDzx3 · Branch: claude/issue-3586-shadcn-check-alert-gaps · Worktree: objectui-issue-3586
File surface: the shadcn-check workflow file + component-analysis.js (or wherever #3497 put the check/alert steps) + the workflow's guard test if one pins it. Serial constraints: disjoint from #7100/#4154/#4160/#4148 in flight.
Container & model: S, mode:subagent, model: opus

Direction, per gap: (2) the timeout-minutes one-liner — just do it, sized generously above the measured 46-request serial worst case. (3) route an analyze-step crash into the SAME issue channel #3497 built for check failures (extend the existing classification, don't invent a second channel; the "red on an unwatched weekly job" is the exact silent-failure shape being closed). (1) investigate-then-implement: measure the cost shape of cross-run state (reading the previous run's conclusion via the Actions API in-workflow vs accumulating comments on the alarm issue) and implement the CHEAPER honest form — consecutive-unreachable-runs ≥ N escalates into the issue channel; N and the mechanism are yours to pick with the reasoning recorded. The card's "已验证的部分" section is context, not scope — do not try to synthetically fire the token-creates-issue path; #3497 deliberately left that to the first real event.

---

Generated by Claude Code

[yinlianghui]

ACCEPT (objectui seat PM, session session_017Qqyix2QcnpUC9XeYVDzx3, review of record) — PR #4174, all three declared gaps closed.

The investigate-then-implement on gap 1 is the model answer: five candidate mechanisms costed with substantive disqualifications (previous-run conclusion structurally blind because #3497's tolerance exits success; alarm-issue comments forbidden by design since a tolerated run HAS no issue; actions/cache's 7-day eviction sitting exactly on the 7-day cron would silently reset the streak forever) — and the chosen marker-step mechanism got the reverse-verification case that matters most for it, the silent rename that breaks nothing visible. Gap 2's timeout is sized from measured history (~37ms/request, 49s worst run, 20min ≈ 1.5× compound-degraded worst case), not a guess. Gap 3's tee fix (the old redirect threw away the stderr the alarm needs) shows the failure path was actually walked. Extracting the classification into a tested script when the input count grew past hand-verifiable is the #3497 lineage continued properly, and the paired reverse tests prove the two states separate rather than keying off one switch. The #4031 duplicate handled by attach-not-scatter with measurements that advance that card.

The weekly registry watchdog now has a bounded clock, a classified crash channel, and an outage streak alarm. Flipping ready + auto-merge.

---

Generated by Claude Code