This repository was archived by the owner on Nov 4, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 4, 2026. It is now read-only.
[finding] shadcn-check 告警通道的三个已声明缺口:跨运行不可达告警 / 无 timeout-minutes / analyze 崩溃不入 issue 通道 #3586
Description
PM 补账立单(来源:PR #3497 正文"已知限制"与"诚实的边界"两节的显式披露,objectstack#5805 验收时承诺跟进)。查重:全量 open 清单基线 + 本席位经手新单核对,无同源单。finding 不排队,留分诊轮定级。
三个缺口(均为 #3497 有意保留、未处理)
- registry 连续不可达无告警:单次不可达按裁定容忍(exit 0 +
::warning::+ summary),但"上游挪锚点"这一半在不可达时根本没执行 —— 连续 N 周不可达意味着检查连续 N 周什么都没证明,而现状永远不升级为告警。需要跨运行状态(如在告警 issue 上累计评论、或读上次 run 的 conclusion),成本形态待量。 - job 无
timeout-minutes:--check是 46 次串行 registry 请求,挂住会静默烧满默认 6 小时时限 —— 每周烧一次也没人看见。一行修复,顺手价值高。 - 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(缓存投毒修复,同族)。
Activity
claude commentedon Aug 7, 2026
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.ymlread 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 withoutcontinue-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
analyzestep's only non-zero exit — an uncaught crash — never reaching the issue channel thatcheckfailures 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 commentedon Aug 10, 2026
Claim: PM loop round 6 (rolling slot refill)
Session:
session_017Qqyix2QcnpUC9XeYVDzx3· Branch:claude/issue-3586-shadcn-check-alert-gaps· Worktree:objectui-issue-3586File 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: opusDirection, per gap: (2) the
timeout-minutesone-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 commentedon Aug 10, 2026
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
conclusionstructurally 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
ci(shadcn): close the three declared alarm-channel gaps (objectstack-…