gstack /canary 深度解析基于 browse 守护进程与基线对比的部署后可视化金丝雀监控【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack/canary是 gstackGarrys Stack技能库中的Post-Deploy Visual Monitor部署后可视化金丝雀监控技能。它以发布可靠性工程师Release Reliability Engineer的视角在每次发布后的关键 10 分钟窗口内驱动 browse 无头浏览器守护进程对线上应用反复进行页面加载、截图、控制台错误与性能采样并与部署前捕获的基线对比把已经发布与已验证可用之间的空档补上。阅读本文后你将掌握/canary的参数语义、基线建立流程、告警分级与瞬态容错规则、健康报告的产物结构以及它在源码与测试中的底层实现依据。该技能的权威定义位于 canary/SKILL.md由 canary/SKILL.md.tmpl 通过bun run gen:skill-docs见 package.json 的gen:skill-docs脚本自动生成。技能核心围绕 browse 守护进程展开browse 的完整命令语义记录在 browse/SKILL.md 与 browse/sections/command-list.md 中。/canary解决的问题CI 通过不等于线上可用技能开头给出了一个典型的失败叙事一个部署在 CI 中全绿却在生产环境崩坏原因可能是缺失的环境变量、CDN 缓存了过期静态资源、或是数据库迁移在真实数据量下比预期慢得多。这类问题的共性在于它们在 CI 环境里根本不会被观察到只有真实流量、真实环境变量、真实 CDN 链路才会触发。/canary的定位就是shipped 到 verified 之间的安全网把发现问题的时间窗口压缩到前 10 分钟而不是 10 小时。它在 docs/skills.md 的技能目录中被描述为SRE角色Post-deploy monitoring loop. Watches for console errors, performance regressions, and page failures using the browse daemon.并在技能正文中将其明确为post-deploy monitoring mode。与技能调度相关的两个环境要素也值得说明技能以斜杠命令方式唤起用户在输入/canary url时即触发本技能frontmatter 中声明了模型需要拥有 Bash、Read、Write、Glob、AskUserQuestion 工具版本为 1.0.0premable 层级为 2。frontmatter 里的triggers如monitor after deploy、canary check、watch for errors post-deploy让技能在用户以自然语言而非斜杠命令提出监控部署金丝雀检查等请求时也能被正确路由。底层引擎browse 守护进程与技能用到的命令/canary本身不实现浏览器能力它全部委托给 browse 守护进程。browse 是 gstack 的常驻无头 Chromium第一次调用自动启动约 3 秒此后单条命令约 100ms且 cookie、标签页、登录会话等状态在多次调用间保持详见 browse/SKILL.md。在每次调用任何 browse 命令之前技能执行 SETUP 检查来解析可执行文件路径$B优先使用仓库内的$_ROOT/.claude/skills/gstack/browse/dist/browse否则回退到$HOME/.claude/skills/gstack/browse/dist/browse两者都不可执行则输出NEEDS_SETUP此时需要先向用户确认执行一次性构建约 10 秒再运行cd SKILL_DIR ./setup。若系统缺少bun脚本会用固定版本 1.3.10 并校验 SHA-256 校验和后安装。/canary监控循环中反复出现的$B命令及其在命令体系中的实现位置如下命令用途依据goto url导航到页面超时或报错意味着页面加载失败导航类命令见 browse/sections/command-list.mdsnapshot -i -a -o png输出可访问性树-i仅交互元素并同时生成带标注框的截图-a -osnapshot 标志语义见 browse/sections/command-list.mdconsole --errors仅过滤输出 console 的错误与警告是新控制台错误告警的数据源在 browse/src/commands.ts 中注册perf输出页面加载耗时是性能回归告警的数据源同上links输出全部链接为 text → href用于页面自动发现同上text输出清洗后的页面文本作为内容快照同上browse的许多读取类输出text、links、console 等会被包裹在BEGIN/END UNTRUSTED EXTERNAL CONTENT标记中以防御提示注入。snapshot的-Ddiff、-ccompact、-s sel作用域、-Ccursor-interactive等标志可以自由组合-o仅在同时使用-a时生效例如$B snapshot -i -a -C -o /tmp/annotated.png。命令形态与参数/canary支持四种参数形态覆盖发布前建档、发布后持续监控、单次体检三种场景/canary url对某 URL 做发布后10 分钟默认时长的持续监控/canary url --duration 5m自定义监控时长允许范围为1 分钟到 30 分钟/canary url --baseline捕获基线截图必须在部署之前运行/canary url --pages /,/dashboard,/settings显式指定要监控的页面清单覆盖默认的自动发现/canary url --quick单次通过式健康检查不进入持续监控循环。未指定--pages时页面列表从应用导航自动发现见 Phase 3。默认监控时长为 10 分钟每次采样间隔为 60 秒。整个技能遵守Read-only原则只观察与报告除非用户明确要求介入修复否则不修改代码。七阶段工作流Phase 1Setup建立产物目录技能启动后先在项目内建立报告目录结构eval $(~/.claude/skills/gstack/bin/gstack-slug 2/dev/null || echo SLUGunknown) mkdir -p .gstack/canary-reports mkdir -p .gstack/canary-reports/baselines mkdir -p .gstack/canary-reports/screenshotsgstack-slug用于生成当前项目的稳定 slug失败时回退为unknown。之后解析用户参数默认时长 10 分钟默认页面由应用导航自动发现。在动手监控之前还需要完成 Step 0 的平台与基准分支探测通过git remote get-url origin判断托管平台含github.com为 GitHub、含gitlab为 GitLab或通过gh auth status/glab auth status兜底进而用gh pr view或 Git 原生命令git symbolic-ref、git rev-parse --verify origin/main等确定 PR 目标分支或仓库默认分支作为后续所有比较与日志记录的上下文。Phase 2基线捕获--baseline模式基线是金丝雀的灵魂。若传入--baseline则在部署前对每个页面来自--pages或首页采集四类证据$B goto page-url $B snapshot -i -a -o .gstack/canary-reports/baselines/page-name.png $B console --errors $B perf $B text每个页面需收集截图路径、console 错误数、来自perf的页面加载时间、文本内容快照。随后写入基线清单.gstack/canary-reports/baseline.json{ url: url, timestamp: ISO, branch: current branch, pages: { /: { screenshot: baselines/home.png, console_errors: 0, load_time_ms: 450 } } }完成基线后技能立即STOP并明确告知用户Baseline captured. Deploy your changes, then run/canary urlto monitor.把部署动作交还给用户保证基线永远代表发布前的已知良好状态。Phase 3页面自动发现未显式给出--pages时通过以下命令发现导航入口$B goto url $B links $B snapshot -i从links输出中提取前 5 个站内导航链接首页总是被包含。随后通过 AskUserQuestion 呈现页面清单推荐选择 A主导航目标用户也可以追加更多页面B或只监控首页做快速检查C。从 browse/sections/command-list.md 的实现看links输出为 text → href 形态天然适合提取导航目标。Phase 4部署前快照无基线时的回退参照若不存在baseline.json技能会在部署前先做一次快速参考快照作为后续回归检测的参照系$B goto page-url $B snapshot -i -a -o .gstack/canary-reports/screenshots/pre-page-name.png $B console --errors $B perf需要说明的是此回退只是参照点强度弱于真正的基线。技能因此特意鼓励在部署前使用--baseline没有基线时金丝雀退化为健康检查health check。Phase 5持续监控循环在指定时长内每 60 秒对每个页面执行一次检查$B goto page-url $B snapshot -i -a -o .gstack/canary-reports/screenshots/page-name-check-number.png $B console --errors $B perf每次检查后与基线或部署前快照对比按四档告警分级页面加载失败goto返回错误或超时触发 CRITICAL新控制台错误出现基线中不存在的错误触发 HIGH性能回归加载时间超过基线的 2 倍触发 MEDIUM坏链出现基线中不存在的新 404触发 LOW。循环内置两条经验法则防止误报与报警疲劳针对变化告警而非绝对值Alert on changes, not absolutes基线里就有 3 个 console 错误的页面只要仍然只有 3 个就算正常多出 1 个新错误才触发告警。性能阈值同样是相对的2 倍于基线是回归1.5 倍可能只是正常波动。不要狼来了Dont cry wolf只有连续 2 次及以上检查都持续出现的模式才构成告警单次网络抖动不告警。一旦出现 CRITICAL 或 HIGH立即通过 AskUserQuestion 通知用户告警卡要求包含时间、页面、类型、具体发现、截图证据路径以及基线与当前值CANARY ALERT ════════════ Time: [timestamp, e.g., check #3 at 180s] Page: [page URL] Type: [CRITICAL / HIGH / MEDIUM] Finding: [what changed — be specific] Evidence: [screenshot path] Baseline: [baseline value] Current: [current value]用户据此在四个动作中决策立即调查并停止监控A、继续监控等待下一次采样以确认是否为瞬态B、立刻回滚部署C、判为误报继续监控D。Phase 6健康报告监控结束或用户提前终止后产出总结报告CANARY REPORT — [url] ═════════════════════ Duration: [X minutes] Pages: [N pages monitored] Checks: [N total checks performed] Status: [HEALTHY / DEGRADED / BROKEN] Per-Page Results: ───────────────────────────────────────────────────── Page Status Errors Avg Load / HEALTHY 0 450ms /dashboard DEGRADED 2 new 1200ms (was 400ms) /settings HEALTHY 0 380ms Alerts Fired: [N] (X critical, Y high, Z medium) Screenshots: .gstack/canary-reports/screenshots/ VERDICT: [DEPLOY IS HEALTHY / DEPLOY HAS ISSUES — details above]报告落盘为.gstack/canary-reports/{date}-canary.md与同名前缀的.json两份。同时把结果写入 review dashboard 的 JSONL 日志eval $(~/.claude/skills/gstack/bin/gstack-slug 2/dev/null) mkdir -p ~/.gstack/projects/$SLUG日志条目为{skill:canary,timestamp:ISO,status:HEALTHY/DEGRADED/BROKEN,url:url,duration_min:N,alerts:N}按项目 slug 分目录持久化在~/.gstack/projects/下便于跨发布追踪趋势。Phase 7基线滚动更新部署健康时技能询问用户是否用本次截图更新基线A) 用当前截图更新基线推荐部署健康新基线反映当前生产状态B) 保留旧基线。选择 A 后最新截图被复制进 baselines 目录并更新baseline.json。这一机制让基线随健康的发布滚动前进避免基线老化到与生产严重脱节。关键规则速查规则含义速度优先调用后 30 秒内开始监控不要过度分析对变化告警与基线对比而非与行业标准对比截图即证据每条告警必须附带截图路径无例外瞬态容忍仅对连续 2 次检查持续出现的模式告警基线是王道无基线的金丝雀只是健康检查阈值为相对值2 倍基线为回归1.5 倍可能是正常波动只读原则只观察和报告不修改代码与发布链路的配合/land-and-deploy之后的最后一道闸/canary在技能体系中的上游是 docs/skills.md 描述的发布链路/ship创建 PR/land-and-deploy负责合并、等 CI、执行部署并验证生产健康/canary则在部署完成后立即接管。docs 中给出的典型会话演进是运行/setup-deploy一次性检测部署平台Fly.io、Render、Vercel、Netlify、Heroku、GitHub Actions 或自定义并写入配置之后/land-and-deploy一条命令从已批准走到已在生产验证部署完成后用/canary继续盯防You: /canary https://myapp.com Claude: Monitoring 8 pages every 2 minutes... Cycle 1: ✓ All pages healthy. p95: 340ms. 0 console errors. Cycle 2: ✓ All pages healthy. p95: 380ms. 0 console errors. Cycle 3: ⚠ /dashboard — new console error: TypeError: Cannot read property map of undefined at dashboard.js:142 Screenshot saved. Alert: 1 new console error after 3 monitoring cycles.该文档同时建议在风险较高的发布后周期性重复运行/canary而不仅是部署完成后的一次性检查。技能工程化侧面模板生成与可校验的产物契约从仓库结构可以观察到两个工程化细节它们解释了为什么/canary的流程可以被反复执行而不漂移其一SKILL.md 由模板生成。canary/SKILL.md 文件头注释明确标注 AUTO-GENERATED from SKILL.md.tmpl do not edit directly 需要重新生成时执行bun run gen:skill-docs即 scripts/gen-skill-docs.ts。对照 canary/SKILL.md.tmpl 可见发布流程主体Arguments、Phase 1-7、Important Rules保存在模板中而 preamble、browse 环境探测{{BROWSE_SETUP}}、基准分支探测{{BASE_BRANCH_DETECT}}等共享段落以占位符形式注入保证所有技能共享同一套运行时规范且互不漂移。其二工作流的产物契约被端到端测试锁定。test/skill-e2e-deploy.test.ts 中定义了Canary skill E2Ecanary-workflow标签测试在一个临时 git 仓库中复制canary技能目录然后以模拟提示驱动模型要求其在没有 browse 守护进程、没有真实 URL的前提下演示对工作流的理解即创建.gstack/canary-reports/目录结构、按 Phase 2 的 schemaurl、timestamp、branch、pages 下的 screenshot / console_errors / load_time_ms写出模拟baseline.json、按 Phase 6 的 Health Report 格式CANARY REPORT 头、duration、pages、status、逐页结果表、verdict写出模拟报告。测试断言目录存在且产物文件数大于 0。这意味着baseline.json与健康报告的字段结构是可被测试校验的契约任何对 Phase 2 / Phase 6 输出格式的改动都需要同步更新测试从而防止技能文档与真实行为脱节。写在最后金丝雀的设计哲学回看整个/canary设计核心并不在于截图或看日志这些单个动作而在于三组取舍对比基线而非绝对标准生产页面本来就可能有历史遗留的 console 错误或偏慢的加载绝对阈值只会产生噪音只有相对基线的变化才与这次部署引入了什么直接相关。用截图锁定证据告警消息不携带抽象描述而是携带可复查的截图路径任何告警都能被人工回溯确认。瞬态与持续的区分网络抖动在发布后 10 分钟窗口内几乎必然出现只有跨越两次采样仍然存在的异常才值得打断用户。如果你的部署流程目前只依赖 CI 绿灯/canary提供了一种低成本补齐生产验证的手段部署前一条--baseline建档发布后一条/canary url盯防即可把发布后前 10 分钟从无人区变成可观测、可告警、可回滚决策的受控窗口。技能完整定义见 canary/SKILL.mdbrowse 命令全量参考见 browse/sections/command-list.md端到端契约测试见 test/skill-e2e-deploy.test.ts。【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考