tsParticles 仓库 Nx Cloud CI 监控全流程monitor-ci 命令与自愈修复机制深度解析【免费下载链接】tsparticlestsParticles - Easily create highly customizable JavaScript particles effects, confetti explosions and fireworks animations and use them as animated backgrounds for your website. Ready to use components available for React.js, Vue.js (2.x and 3.x), Angular, Svelte, jQuery, Preact, Inferno, Solid, Riot and Web Components.项目地址: https://gitcode.com/GitHub_Trending/ts/tsparticles本文以 tsParticles 仓库中 .opencode/commands/monitor-ci.md 命令定义为骨架结合 .opencode/skills/monitor-ci/SKILL.md、ci-poll-decide.mjs、ci-state-update.mjs 等源码深入讲解基于 Nx Cloud 的 CI 监控编排orchestrator设计如何轮询 CI 状态、接入 Nx Cloud 自愈修复self-healing、在本地验证与远程自动修复之间做预算决策并规避与自愈机制竞争的常见反模式。读完你可以完整理解该命令的状态机、决策脚本与状态预算脚本的工作方式并将其模式复用到自己的 Nx 工作区。一、命令定位为什么监控 CI 要绕开原生 CI 工具/monitor-ci是 opencode 命令command同时以同名 skill 存在.opencode/skills/monitor-ci/SKILL.md其核心定位是监控 Nx Cloud CI 流水线执行并处理自愈修复。当用户说 monitor ci、watch ci、track ci、check ci status 等触发词时激活并明确要求优先于原生 CI 提供方工具gh、glab等使用因为只有它能接入 Nx Cloud 的自愈修复能力。命令的编排角色划分非常清晰见文档 Architecture Overview组件职责本命令orchestrator派生子代理、运行确定性脚本、打印状态、执行本地编码工作ci-monitor-subagenthaiku 模型每次调用一个 MCP 工具ci_information或update_self_healing_fix返回结构化结果后立即退出ci-poll-decide.mjs确定性决策脚本根据ci_information结果 状态返回 action 与状态消息ci-state-update.mjs确定性状态脚本管理预算门gate、动作后状态迁移、周期分类该命令在运行时还会自动采集当前 git 上下文git branch --show-current、git rev-parse --short HEAD、git status -sb | head -1用于状态追踪与 commit 对应。二、配置默认值与参数覆盖命令接受用户通过$ARGUMENTS传入的指令解析后与以下默认值合并用户指令优先级高于默认行为设置默认值说明--max-cycles10Agent 发起的 CI Attempt 循环最大次数超限即超时--timeout120最大监控时长分钟--verbositymedium输出级别minimal / medium / verbose--branch自动检测要监控的分支--freshfalse忽略此前会话上下文全新开始--new-cipe-timeout10动作执行后等待新 CI Attempt 出现的分钟数--local-verify-attempts3推送 CI 前本地验证 增强的最大循环次数完整触发语法为[instructions] [--max-cycles N] [--timeout MINUTES] [--verbosity minimal|medium|verbose] [--branch BRANCH] [--fresh] [--auto-fix-workflow] [--new-cipe-timeout MINUTES] [--local-verify-attempts N]。三、前置检查Nx Cloud 连接校验在进入监控主循环前命令强制执行 Step 0 连接检查否则整个技能不可用检查工作区根目录的nx.json中是否存在nxCloudId或nxCloudAccessToken若nx.json缺失或两个属性都不存在 → 直接退出并提示 Nx Cloud not connected...连接成功 → 进入主循环。tsParticles 仓库的 nx.json 中配置了nxCloudId: 62a6df5ddbaff92c46e3b366同时 opencode.json 启用了nx-mcp本地 MCP servernpx nx mcp这为ci_information与update_self_healing_fix两个 MCP 工具提供了运行前提。四、MCP 工具参考三级字段集与调用契约命令通过子代理调用 Nx Cloud MCP 工具获取数据。为控制轮询开销定义了三级字段集用最轻的集合满足当前需求WAIT_FIELDS: cipeUrl,commitSha,cipeStatus LIGHT_FIELDS: cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,autoApplySkipped,autoApplySkipReason,shortLink,confidence,confidenceReasoning,hints,selfHealingSkippedReason,selfHealingSkipMessage HEAVY_FIELDS: taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription两个 MCP 工具的调用契约ci_information接受branch可选默认当前 git 分支、select逗号分隔字段名、pageToken0 起的分页游标用于长字符串分页update_self_healing_fix接受shortLink与动作APPLY/REJECT/RERUN_ENVIRONMENT_STATE。子代理契约定义在 .opencode/agents/ci-monitor-subagent.md 中包含四种命令FETCH_STATUS返回固定字段子集、FETCH_HEAVY汇总 heavy 内容并只返回shortLink、failedTaskIds、suggestedFixDescription、taskFailureSummaries等、UPDATE_FIX执行 APPLY/REJECT/RERUN_ENVIRONMENT_STATE、FETCH_THROTTLE_INFO。子代理被明确要求每次调用只执行一个命令并立即返回不轮询、不循环、不 sleep、不做决策保证主代理orchestrator独占决策权。五、反模式清单为什么不能自己写轮询脚本文档用一张表格明确列出必须规避的行为以及它们造成真实问题的原因反模式危害使用 CI 提供方 CLI 的--watch标志如gh pr checks --watch、glab ci status -w完全绕过 Nx Cloud 自愈修复编写自定义 CI 轮询脚本不可靠、污染上下文、无自愈能力取消 CI workflow/pipeline破坏性操作丢失 CI 进度在主代理上运行 CI 检查浪费主代理上下文 token轮询期间独立分析/修复 CI 失败与自愈机制竞争导致重复修复与状态混乱若本技能激活失败回退路径为使用 CI 提供方 CLI 做一次性只读状态检查单次调用、不带 watch/轮询标志→ 立即携带上下文委托给本技能 → 不再在主代理上继续轮询。六、状态机决策脚本如何把 CI 状态变成动作ci-poll-decide.mjs 是纯函数式的确定性决策引擎核心是classify()决策树自上而下优先级递减与buildOutput()输出映射。它接收ci_information的 JSON 各类状态参数输出单行 JSON{ action, code, message, delay?, noProgressCount, envRerunCount, fields?, newCipeDetected?, verifiableTaskIds? }。决策树优先级源码注释中完整列出WAIT MODE: 1. 新 CI Attempt 检测到 → poll (new_cipe_detected) 2. 等待超时 → done (no_new_cipe) 3. 仍在等待 → wait (waiting_for_cipe) NORMAL MODE: 4. 轮询超时 → done (polling_timeout) 5. 断路器13 次无进展 → done (circuit_breaker) 6. CI 成功 → done (ci_success) 7. CI 被取消 → done (cipe_canceled) 8. CI 超时 → done (cipe_timed_out) 9. CI 失败且无任务记录 → done (cipe_no_tasks) 10. 环境失败 → done (environment_rerun_cap | environment_issue) 11. 自愈被节流 → done (self_healing_throttled) 12. CI 进行中/未开始 → poll (ci_running) 13. 自愈进行中 → poll (sh_running) 14. flaky 任务自动重跑 → poll (flaky_rerun) 15. 修复已自动应用 → poll (fix_auto_applied) 16. 自动应用被跳过 → done (fix_auto_apply_skipped) 17. 自动应用待验证 → poll (verification_pending) 18. 自动应用已验证 → done (fix_auto_applying) 19. 修复验证失败/未执行 → done (fix_needs_review) 20. 修复全部/e2e 已验证 → done (fix_apply_ready) 21. 修复需本地验证 → done (fix_needs_local_verify) 22. 自愈失败 → done (fix_failed) 23. 无可用修复 → done (no_fix) 24. 兜底 → poll (fallback)关键判定逻辑要点任务分类categorizeTasks()将failedTaskIds中未被verifiedTaskIds覆盖的任务分为all_verified、e2e_only、needs_local_verify三类——若未验证任务全部是 e2e任务 ID 中:分隔的第二段包含e2e视为可安全远程应用修复否则给出需要本地验证的任务列表。退避策略backoff()提供 60/90/120/180 秒递增延迟无进展计数越高轮询间隔越长。进度判定hasStateChanged()比较cipeStatus、selfHealingStatus、verificationStatus、failureClassification四项中任一变化即视为进展无进展则noProgressCount 1累计 13 次触发断路器。新 CI Attempt 检测isNewCipe()通过cipeUrl变化或commitSha与期望值匹配来判断。verbosity 输出minimal 仅在状态组合变化时输出verbose 额外附加轮询序号与 CI/自愈/验证三元状态medium 为Poll #N | 消息格式。状态默认行为表简单退出类仅报告并退出状态默认行为ci_success成功退出cipe_canceled退出CI 被取消cipe_timed_out退出CI 超时polling_timeout退出轮询超时circuit_breaker退出连续 13 次轮询无进展environment_rerun_cap退出环境重跑次数耗尽fix_auto_applying自愈正在处理仅记录last_cipe_url进入等待模式无需 MCP 调用或本地 git 操作error等待 60s 后循环需要动作类处理时须读取 .opencode/skills/monitor-ci/references/fix-flows.md 的详细流程状态处理要点fix_auto_apply_skipped修复已验证但自动应用被跳过如防止循环告知用户并提供手动应用选项fix_apply_ready修复已验证全部任务或仅 e2e通过 MCPAPPLYfix_needs_local_verify修复含未验证的非 e2e 任务本地运行后再应用或增强fix_needs_review修复验证失败/未尝试分析后决策fix_failed自愈失败拉取 heavy 数据尝试本地修复先过门检查no_fix无可用修复拉取 heavy 数据尝试本地修复或退出environment_issue通过 MCP 请求环境重跑先过门检查self_healing_throttled拒绝旧修复尝试本地修复no_new_cipeCI Attempt 从未产生自动修复工作流或给出指引退出cipe_no_tasksCI 失败但无任务记录用空 commit 重试一次始终生效的关键规则Git 安全只按文件名暂存特定文件——git add -A或git add .有把用户无关的进行中工作或密钥提交上去的风险环境失败即退OOM、命令找不到、权限拒绝等属于环境问题而非代码缺陷不应消耗本地修复预算门检查Gate Check任何本地修复尝试前必须运行ci-state-update.mjs gate预算耗尽则打印消息并退出。七、主循环从初始化到动作处理的四步编排Step 1初始化追踪状态cycle_count 0 # 仅统计 agent 发起的周期计入 --max-cycles start_time now() no_progress_count 0 local_verify_count 0 env_rerun_count 0 last_cipe_url null expected_commit_sha null agent_triggered false # monitor 采取会触发新 CI Attempt 的动作后置 true poll_count 0 wait_mode false prev_status null prev_cipe_status null prev_sh_status null prev_verification_status null prev_failure_classification nullStep 2轮询循环2a 派生子代理 FETCH_STATUS等待模式下用 WAIT_FIELDS普通模式首次轮询或检测到 newCipe 后用 LIGHT_FIELDS2b 运行决策脚本node skill_dir/scripts/ci-poll-decide.mjs subagent_result_json poll_count verbosity \ [--wait-mode] \ [--prev-cipe-url last_cipe_url] \ [--expected-sha expected_commit_sha] \ [--prev-status prev_status] \ [--timeout timeout_seconds] \ [--new-cipe-timeout new_cipe_timeout_seconds] \ [--env-rerun-count env_rerun_count] \ [--no-progress-count no_progress_count] \ [--prev-cipe-status prev_cipe_status] \ [--prev-sh-status prev_sh_status] \ [--prev-verification-status prev_verification_status] \ [--prev-failure-classification prev_failure_classification]2c 处理脚本输出解析 JSON 并回写no_progress_count、env_rerun_count、各项 prev 状态与poll_countaction poll时打印消息、sleepdelay秒回到 2a若newCipeDetected则清除等待模式action wait同理action done进入 Step 3。Step 3处理可动作状态决策脚本返回done后先执行 cycle-checkStep 4再查表确定默认行为、检查用户指令是否覆盖默认、执行相应动作、必要时更新追踪状态若动作导致循环则回到 Step 2。各状态对应的工具调用脚本源码可查fix_apply_ready→update_self_healing_fix动作APPLYfix_needs_local_verify→ 先以 HEAVY_FIELDS 拉取修复细节再本地验证fix_needs_review→ HEAVY_FIELDS 获取suggestedFixDescription、suggestedFixSummary、taskFailureSummariesfix_failed/no_fix→ HEAVY_FIELDS 获取taskFailureSummaries供本地修复参考environment_issue→update_self_healing_fix动作RERUN_ENVIRONMENT_STATEself_healing_throttled→ HEAVY_FIELDS 获取selfHealingSkipMessage再对每个旧修复执行REJECT。Step 3a新 CI Attempt 检测的状态追踪动作执行后调用 ci-state-update.mjs 的post-action子命令node skill_dir/scripts/ci-state-update.mjs post-action \ --action type \ --cipe-url current_cipe_url \ --commit-sha git_rev_parse_HEAD动作类型共 8 种fix-auto-applying、apply-mcp、apply-local-push、reject-fix-push、local-fix-push、env-rerun、auto-fix-push、empty-commit-push。从源码可见该脚本的关键设计MCP 触发类动作fix-auto-applying、apply-mcp、env-rerun按cipeUrl追踪本地推送类动作按commitSha追踪fix-auto-applying表示是自愈机制而非 monitor 发起的动作故agentTriggered false。脚本返回{ waitMode, pollCount, lastCipeUrl, expectedCommitSha, agentTriggered }。Step 4周期分类与进度追踪node skill_dir/scripts/ci-state-update.mjs cycle-check \ --code code \ [--agent-triggered] \ --cycle-count cycle_count --max-cycles max_cycles \ --env-rerun-count env_rerun_countcycle-check的源码逻辑若上一周期是 agent 触发则cycleCount非环境状态时重置envRerunCount当cycleCount maxCycles - 2时置approachingLimit主代理应询问用户是继续追加 5 或 10 个周期还是停止。若上一周期不是 agent 触发人为推送则记录检测到人为推送。进度追踪的三条规则no_progress_count、断路器与退避重置由 ci-poll-decide.mjs 处理任何状态变化即进展env_rerun_count的非环境状态重置由 cycle-check 处理检测到新 CI Attempt 时重置local_verify_count 0、env_rerun_count 0。八、预算门控gate 子命令如何守住本地修复预算ci-state-update.mjs 的gate子命令是本地动作前唯一的预算闸门支持两种门类型--gate-type local-fix默认上限 3 次--local-verify-attempts已用完则返回allowed: false与 Local fix budget exhausted 消息--gate-type env-rerun上限 2 次超限返回 Environment issue persists after 2 reruns. Manual investigation needed.。任何本地修复尝试与环境重跑在动作前都会先经过该门且计数由 gate 自身递增防止越权消耗预算。九、详细修复流程fix-flows 的六类动作路径.opencode/skills/monitor-ci/references/fix-flows.md 为每个可动作状态给出细粒度流程核心包括fix_needs_local_verify先通过pnpm-lock.yaml→pnpm nx、yarn.lock→yarn nx、否则npx nx探测包管理器并行派生 general 子代理运行可验证任务全部通过则 MCPAPPLY任一失败则进入 Apply Locally Enhance 流程Apply Locally Enhance Flownx-cloud apply-locally shortLink状态置为APPLIED_LOCALLY→ 增强代码 → 本地运行失败任务验证 → 仍失败则先过local-fix门不允许则提交当前状态推送让 CI 做最终裁判→ 通过则提交推送进入等待模式Reject Fix From Scratch Flow先过local-fix门 → MCPREJECT→ 本地从头修复 → 提交推送self_healing_throttled用正则/cipes/{id}解析节流消息中的 CI Attempt URL → 逐个 FETCH_THROTTLE_INFO 拿shortLink后REJECT→ 尝试本地修复 → 兜底用git commit --allow-empty -m ci: rerun after rejecting throttled fixes触发重跑cipe_no_tasks以git commit --allow-empty -m chore: retry ci [monitor-ci]重试一次仍失败则退出。环境 vs 代码失败识别本地任务失败时先判断是代码问题还是环境/工具链问题——命令找不到、OOM/堆分配失败、权限拒绝、网络超时/DNS 失败、系统库缺失、Docker/容器问题、磁盘空间耗尽均为环境失败应立即退出不消耗预算编译错误、测试断言失败、lint 违规、类型错误才进入本地修复流程。提交消息规范git commit -m fix(projects): brief description Failed tasks: taskId1, taskId2 Local verification: passed|enhanced|failed-pushing-to-ci十、错误处理矩阵与用户指令覆盖错误处理Git rebase 冲突报告用户后退出nx-cloud apply-locally失败MCPREJECT修复尝试手工补丁或退出MCP 工具错误重试一次仍失败则报告用户子代理派生失败重试一次仍失败则以错误退出决策脚本错误按error状态处理并递增no_progress_count未检测到新 CI Attempt开启--auto-fix-workflow时尝试 lockfile 更新否则给出指引Lockfile 自动修复失败报告用户指引查看 CI 日志用户指令可覆盖默认行为文档给出典型示例指令效果never auto-apply应用任何修复前都先询问always ask before git push每次推送前询问reject any fix for e2e tasksfailedTaskIds含 e2e 时自动拒绝apply all fixes regardless of verification跳过验证检查直接应用if confidence 70, reject应用前检查 confidence 字段run nx affected -t typecheck before applying增加本地验证步骤auto-fix workflow failures对 CI Attempt 前的失败尝试 lockfile 更新wait 45 min for new CI Attempt覆盖新 CI Attempt 等待超时默认 10 分钟十一、会话上下文与可复用的设计启示命令支持会话级上下文恢复若本会话已运行过/monitor-ci可从先前状态轮询次数、上次 CI Attempt URL 等续跑除非设置--fresh丢弃全部旧状态从 Step 1 重新开始。从整个实现可以提炼出一套可复用的 Agent CI 监控设计模式编排器 一次性子代理 确定性决策脚本三层分离——主代理只做决策与本地编码子代理每次只执行单个 MCP 调用限制上下文消耗决策完全交给无状态的纯函数脚本可测试、可复现预算与状态迁移交给另一个脚本统一管理。这一架构与 tsParticles 仓库中的 Nx 多包工作区nx.json 含nxCloudId插件体系见 opencode.json 的 nx-mcp 配置深度契合也是把 Nx Cloud 自愈能力安全接入 LLM 工作流的直接范本。【免费下载链接】tsparticlestsParticles - Easily create highly customizable JavaScript particles effects, confetti explosions and fireworks animations and use them as animated backgrounds for your website. Ready to use components available for React.js, Vue.js (2.x and 3.x), Angular, Svelte, jQuery, Preact, Inferno, Solid, Riot and Web Components.项目地址: https://gitcode.com/GitHub_Trending/ts/tsparticles创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 tsParticles 仓库 Nx Cloud CI 监控全流程：monitor-ci 命令与自愈修复机制深度解析
tsParticles 仓库 Nx Cloud CI 监控全流程monitor-ci 命令与自愈修复机制深度解析【免费下载链接】tsparticlestsParticles - Easily create highly customizable JavaScript particles effects, confetti explosions and fireworks animations and use them as animated backgrounds for your website. Ready to use components available for React.js, Vue.js (2.x and 3.x), Angular, Svelte, jQuery, Preact, Inferno, Solid, Riot and Web Components.项目地址: https://gitcode.com/GitHub_Trending/ts/tsparticles本文以 tsParticles 仓库中 .opencode/commands/monitor-ci.md 命令定义为骨架结合 .opencode/skills/monitor-ci/SKILL.md、ci-poll-decide.mjs、ci-state-update.mjs 等源码深入讲解基于 Nx Cloud 的 CI 监控编排orchestrator设计如何轮询 CI 状态、接入 Nx Cloud 自愈修复self-healing、在本地验证与远程自动修复之间做预算决策并规避与自愈机制竞争的常见反模式。读完你可以完整理解该命令的状态机、决策脚本与状态预算脚本的工作方式并将其模式复用到自己的 Nx 工作区。一、命令定位为什么监控 CI 要绕开原生 CI 工具/monitor-ci是 opencode 命令command同时以同名 skill 存在.opencode/skills/monitor-ci/SKILL.md其核心定位是监控 Nx Cloud CI 流水线执行并处理自愈修复。当用户说 monitor ci、watch ci、track ci、check ci status 等触发词时激活并明确要求优先于原生 CI 提供方工具gh、glab等使用因为只有它能接入 Nx Cloud 的自愈修复能力。命令的编排角色划分非常清晰见文档 Architecture Overview组件职责本命令orchestrator派生子代理、运行确定性脚本、打印状态、执行本地编码工作ci-monitor-subagenthaiku 模型每次调用一个 MCP 工具ci_information或update_self_healing_fix返回结构化结果后立即退出ci-poll-decide.mjs确定性决策脚本根据ci_information结果 状态返回 action 与状态消息ci-state-update.mjs确定性状态脚本管理预算门gate、动作后状态迁移、周期分类该命令在运行时还会自动采集当前 git 上下文git branch --show-current、git rev-parse --short HEAD、git status -sb | head -1用于状态追踪与 commit 对应。二、配置默认值与参数覆盖命令接受用户通过$ARGUMENTS传入的指令解析后与以下默认值合并用户指令优先级高于默认行为设置默认值说明--max-cycles10Agent 发起的 CI Attempt 循环最大次数超限即超时--timeout120最大监控时长分钟--verbositymedium输出级别minimal / medium / verbose--branch自动检测要监控的分支--freshfalse忽略此前会话上下文全新开始--new-cipe-timeout10动作执行后等待新 CI Attempt 出现的分钟数--local-verify-attempts3推送 CI 前本地验证 增强的最大循环次数完整触发语法为[instructions] [--max-cycles N] [--timeout MINUTES] [--verbosity minimal|medium|verbose] [--branch BRANCH] [--fresh] [--auto-fix-workflow] [--new-cipe-timeout MINUTES] [--local-verify-attempts N]。三、前置检查Nx Cloud 连接校验在进入监控主循环前命令强制执行 Step 0 连接检查否则整个技能不可用检查工作区根目录的nx.json中是否存在nxCloudId或nxCloudAccessToken若nx.json缺失或两个属性都不存在 → 直接退出并提示 Nx Cloud not connected...连接成功 → 进入主循环。tsParticles 仓库的 nx.json 中配置了nxCloudId: 62a6df5ddbaff92c46e3b366同时 opencode.json 启用了nx-mcp本地 MCP servernpx nx mcp这为ci_information与update_self_healing_fix两个 MCP 工具提供了运行前提。四、MCP 工具参考三级字段集与调用契约命令通过子代理调用 Nx Cloud MCP 工具获取数据。为控制轮询开销定义了三级字段集用最轻的集合满足当前需求WAIT_FIELDS: cipeUrl,commitSha,cipeStatus LIGHT_FIELDS: cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,autoApplySkipped,autoApplySkipReason,shortLink,confidence,confidenceReasoning,hints,selfHealingSkippedReason,selfHealingSkipMessage HEAVY_FIELDS: taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription两个 MCP 工具的调用契约ci_information接受branch可选默认当前 git 分支、select逗号分隔字段名、pageToken0 起的分页游标用于长字符串分页update_self_healing_fix接受shortLink与动作APPLY/REJECT/RERUN_ENVIRONMENT_STATE。子代理契约定义在 .opencode/agents/ci-monitor-subagent.md 中包含四种命令FETCH_STATUS返回固定字段子集、FETCH_HEAVY汇总 heavy 内容并只返回shortLink、failedTaskIds、suggestedFixDescription、taskFailureSummaries等、UPDATE_FIX执行 APPLY/REJECT/RERUN_ENVIRONMENT_STATE、FETCH_THROTTLE_INFO。子代理被明确要求每次调用只执行一个命令并立即返回不轮询、不循环、不 sleep、不做决策保证主代理orchestrator独占决策权。五、反模式清单为什么不能自己写轮询脚本文档用一张表格明确列出必须规避的行为以及它们造成真实问题的原因反模式危害使用 CI 提供方 CLI 的--watch标志如gh pr checks --watch、glab ci status -w完全绕过 Nx Cloud 自愈修复编写自定义 CI 轮询脚本不可靠、污染上下文、无自愈能力取消 CI workflow/pipeline破坏性操作丢失 CI 进度在主代理上运行 CI 检查浪费主代理上下文 token轮询期间独立分析/修复 CI 失败与自愈机制竞争导致重复修复与状态混乱若本技能激活失败回退路径为使用 CI 提供方 CLI 做一次性只读状态检查单次调用、不带 watch/轮询标志→ 立即携带上下文委托给本技能 → 不再在主代理上继续轮询。六、状态机决策脚本如何把 CI 状态变成动作ci-poll-decide.mjs 是纯函数式的确定性决策引擎核心是classify()决策树自上而下优先级递减与buildOutput()输出映射。它接收ci_information的 JSON 各类状态参数输出单行 JSON{ action, code, message, delay?, noProgressCount, envRerunCount, fields?, newCipeDetected?, verifiableTaskIds? }。决策树优先级源码注释中完整列出WAIT MODE: 1. 新 CI Attempt 检测到 → poll (new_cipe_detected) 2. 等待超时 → done (no_new_cipe) 3. 仍在等待 → wait (waiting_for_cipe) NORMAL MODE: 4. 轮询超时 → done (polling_timeout) 5. 断路器13 次无进展 → done (circuit_breaker) 6. CI 成功 → done (ci_success) 7. CI 被取消 → done (cipe_canceled) 8. CI 超时 → done (cipe_timed_out) 9. CI 失败且无任务记录 → done (cipe_no_tasks) 10. 环境失败 → done (environment_rerun_cap | environment_issue) 11. 自愈被节流 → done (self_healing_throttled) 12. CI 进行中/未开始 → poll (ci_running) 13. 自愈进行中 → poll (sh_running) 14. flaky 任务自动重跑 → poll (flaky_rerun) 15. 修复已自动应用 → poll (fix_auto_applied) 16. 自动应用被跳过 → done (fix_auto_apply_skipped) 17. 自动应用待验证 → poll (verification_pending) 18. 自动应用已验证 → done (fix_auto_applying) 19. 修复验证失败/未执行 → done (fix_needs_review) 20. 修复全部/e2e 已验证 → done (fix_apply_ready) 21. 修复需本地验证 → done (fix_needs_local_verify) 22. 自愈失败 → done (fix_failed) 23. 无可用修复 → done (no_fix) 24. 兜底 → poll (fallback)关键判定逻辑要点任务分类categorizeTasks()将failedTaskIds中未被verifiedTaskIds覆盖的任务分为all_verified、e2e_only、needs_local_verify三类——若未验证任务全部是 e2e任务 ID 中:分隔的第二段包含e2e视为可安全远程应用修复否则给出需要本地验证的任务列表。退避策略backoff()提供 60/90/120/180 秒递增延迟无进展计数越高轮询间隔越长。进度判定hasStateChanged()比较cipeStatus、selfHealingStatus、verificationStatus、failureClassification四项中任一变化即视为进展无进展则noProgressCount 1累计 13 次触发断路器。新 CI Attempt 检测isNewCipe()通过cipeUrl变化或commitSha与期望值匹配来判断。verbosity 输出minimal 仅在状态组合变化时输出verbose 额外附加轮询序号与 CI/自愈/验证三元状态medium 为Poll #N | 消息格式。状态默认行为表简单退出类仅报告并退出状态默认行为ci_success成功退出cipe_canceled退出CI 被取消cipe_timed_out退出CI 超时polling_timeout退出轮询超时circuit_breaker退出连续 13 次轮询无进展environment_rerun_cap退出环境重跑次数耗尽fix_auto_applying自愈正在处理仅记录last_cipe_url进入等待模式无需 MCP 调用或本地 git 操作error等待 60s 后循环需要动作类处理时须读取 .opencode/skills/monitor-ci/references/fix-flows.md 的详细流程状态处理要点fix_auto_apply_skipped修复已验证但自动应用被跳过如防止循环告知用户并提供手动应用选项fix_apply_ready修复已验证全部任务或仅 e2e通过 MCPAPPLYfix_needs_local_verify修复含未验证的非 e2e 任务本地运行后再应用或增强fix_needs_review修复验证失败/未尝试分析后决策fix_failed自愈失败拉取 heavy 数据尝试本地修复先过门检查no_fix无可用修复拉取 heavy 数据尝试本地修复或退出environment_issue通过 MCP 请求环境重跑先过门检查self_healing_throttled拒绝旧修复尝试本地修复no_new_cipeCI Attempt 从未产生自动修复工作流或给出指引退出cipe_no_tasksCI 失败但无任务记录用空 commit 重试一次始终生效的关键规则Git 安全只按文件名暂存特定文件——git add -A或git add .有把用户无关的进行中工作或密钥提交上去的风险环境失败即退OOM、命令找不到、权限拒绝等属于环境问题而非代码缺陷不应消耗本地修复预算门检查Gate Check任何本地修复尝试前必须运行ci-state-update.mjs gate预算耗尽则打印消息并退出。七、主循环从初始化到动作处理的四步编排Step 1初始化追踪状态cycle_count 0 # 仅统计 agent 发起的周期计入 --max-cycles start_time now() no_progress_count 0 local_verify_count 0 env_rerun_count 0 last_cipe_url null expected_commit_sha null agent_triggered false # monitor 采取会触发新 CI Attempt 的动作后置 true poll_count 0 wait_mode false prev_status null prev_cipe_status null prev_sh_status null prev_verification_status null prev_failure_classification nullStep 2轮询循环2a 派生子代理 FETCH_STATUS等待模式下用 WAIT_FIELDS普通模式首次轮询或检测到 newCipe 后用 LIGHT_FIELDS2b 运行决策脚本node skill_dir/scripts/ci-poll-decide.mjs subagent_result_json poll_count verbosity \ [--wait-mode] \ [--prev-cipe-url last_cipe_url] \ [--expected-sha expected_commit_sha] \ [--prev-status prev_status] \ [--timeout timeout_seconds] \ [--new-cipe-timeout new_cipe_timeout_seconds] \ [--env-rerun-count env_rerun_count] \ [--no-progress-count no_progress_count] \ [--prev-cipe-status prev_cipe_status] \ [--prev-sh-status prev_sh_status] \ [--prev-verification-status prev_verification_status] \ [--prev-failure-classification prev_failure_classification]2c 处理脚本输出解析 JSON 并回写no_progress_count、env_rerun_count、各项 prev 状态与poll_countaction poll时打印消息、sleepdelay秒回到 2a若newCipeDetected则清除等待模式action wait同理action done进入 Step 3。Step 3处理可动作状态决策脚本返回done后先执行 cycle-checkStep 4再查表确定默认行为、检查用户指令是否覆盖默认、执行相应动作、必要时更新追踪状态若动作导致循环则回到 Step 2。各状态对应的工具调用脚本源码可查fix_apply_ready→update_self_healing_fix动作APPLYfix_needs_local_verify→ 先以 HEAVY_FIELDS 拉取修复细节再本地验证fix_needs_review→ HEAVY_FIELDS 获取suggestedFixDescription、suggestedFixSummary、taskFailureSummariesfix_failed/no_fix→ HEAVY_FIELDS 获取taskFailureSummaries供本地修复参考environment_issue→update_self_healing_fix动作RERUN_ENVIRONMENT_STATEself_healing_throttled→ HEAVY_FIELDS 获取selfHealingSkipMessage再对每个旧修复执行REJECT。Step 3a新 CI Attempt 检测的状态追踪动作执行后调用 ci-state-update.mjs 的post-action子命令node skill_dir/scripts/ci-state-update.mjs post-action \ --action type \ --cipe-url current_cipe_url \ --commit-sha git_rev_parse_HEAD动作类型共 8 种fix-auto-applying、apply-mcp、apply-local-push、reject-fix-push、local-fix-push、env-rerun、auto-fix-push、empty-commit-push。从源码可见该脚本的关键设计MCP 触发类动作fix-auto-applying、apply-mcp、env-rerun按cipeUrl追踪本地推送类动作按commitSha追踪fix-auto-applying表示是自愈机制而非 monitor 发起的动作故agentTriggered false。脚本返回{ waitMode, pollCount, lastCipeUrl, expectedCommitSha, agentTriggered }。Step 4周期分类与进度追踪node skill_dir/scripts/ci-state-update.mjs cycle-check \ --code code \ [--agent-triggered] \ --cycle-count cycle_count --max-cycles max_cycles \ --env-rerun-count env_rerun_countcycle-check的源码逻辑若上一周期是 agent 触发则cycleCount非环境状态时重置envRerunCount当cycleCount maxCycles - 2时置approachingLimit主代理应询问用户是继续追加 5 或 10 个周期还是停止。若上一周期不是 agent 触发人为推送则记录检测到人为推送。进度追踪的三条规则no_progress_count、断路器与退避重置由 ci-poll-decide.mjs 处理任何状态变化即进展env_rerun_count的非环境状态重置由 cycle-check 处理检测到新 CI Attempt 时重置local_verify_count 0、env_rerun_count 0。八、预算门控gate 子命令如何守住本地修复预算ci-state-update.mjs 的gate子命令是本地动作前唯一的预算闸门支持两种门类型--gate-type local-fix默认上限 3 次--local-verify-attempts已用完则返回allowed: false与 Local fix budget exhausted 消息--gate-type env-rerun上限 2 次超限返回 Environment issue persists after 2 reruns. Manual investigation needed.。任何本地修复尝试与环境重跑在动作前都会先经过该门且计数由 gate 自身递增防止越权消耗预算。九、详细修复流程fix-flows 的六类动作路径.opencode/skills/monitor-ci/references/fix-flows.md 为每个可动作状态给出细粒度流程核心包括fix_needs_local_verify先通过pnpm-lock.yaml→pnpm nx、yarn.lock→yarn nx、否则npx nx探测包管理器并行派生 general 子代理运行可验证任务全部通过则 MCPAPPLY任一失败则进入 Apply Locally Enhance 流程Apply Locally Enhance Flownx-cloud apply-locally shortLink状态置为APPLIED_LOCALLY→ 增强代码 → 本地运行失败任务验证 → 仍失败则先过local-fix门不允许则提交当前状态推送让 CI 做最终裁判→ 通过则提交推送进入等待模式Reject Fix From Scratch Flow先过local-fix门 → MCPREJECT→ 本地从头修复 → 提交推送self_healing_throttled用正则/cipes/{id}解析节流消息中的 CI Attempt URL → 逐个 FETCH_THROTTLE_INFO 拿shortLink后REJECT→ 尝试本地修复 → 兜底用git commit --allow-empty -m ci: rerun after rejecting throttled fixes触发重跑cipe_no_tasks以git commit --allow-empty -m chore: retry ci [monitor-ci]重试一次仍失败则退出。环境 vs 代码失败识别本地任务失败时先判断是代码问题还是环境/工具链问题——命令找不到、OOM/堆分配失败、权限拒绝、网络超时/DNS 失败、系统库缺失、Docker/容器问题、磁盘空间耗尽均为环境失败应立即退出不消耗预算编译错误、测试断言失败、lint 违规、类型错误才进入本地修复流程。提交消息规范git commit -m fix(projects): brief description Failed tasks: taskId1, taskId2 Local verification: passed|enhanced|failed-pushing-to-ci十、错误处理矩阵与用户指令覆盖错误处理Git rebase 冲突报告用户后退出nx-cloud apply-locally失败MCPREJECT修复尝试手工补丁或退出MCP 工具错误重试一次仍失败则报告用户子代理派生失败重试一次仍失败则以错误退出决策脚本错误按error状态处理并递增no_progress_count未检测到新 CI Attempt开启--auto-fix-workflow时尝试 lockfile 更新否则给出指引Lockfile 自动修复失败报告用户指引查看 CI 日志用户指令可覆盖默认行为文档给出典型示例指令效果never auto-apply应用任何修复前都先询问always ask before git push每次推送前询问reject any fix for e2e tasksfailedTaskIds含 e2e 时自动拒绝apply all fixes regardless of verification跳过验证检查直接应用if confidence 70, reject应用前检查 confidence 字段run nx affected -t typecheck before applying增加本地验证步骤auto-fix workflow failures对 CI Attempt 前的失败尝试 lockfile 更新wait 45 min for new CI Attempt覆盖新 CI Attempt 等待超时默认 10 分钟十一、会话上下文与可复用的设计启示命令支持会话级上下文恢复若本会话已运行过/monitor-ci可从先前状态轮询次数、上次 CI Attempt URL 等续跑除非设置--fresh丢弃全部旧状态从 Step 1 重新开始。从整个实现可以提炼出一套可复用的 Agent CI 监控设计模式编排器 一次性子代理 确定性决策脚本三层分离——主代理只做决策与本地编码子代理每次只执行单个 MCP 调用限制上下文消耗决策完全交给无状态的纯函数脚本可测试、可复现预算与状态迁移交给另一个脚本统一管理。这一架构与 tsParticles 仓库中的 Nx 多包工作区nx.json 含nxCloudId插件体系见 opencode.json 的 nx-mcp 配置深度契合也是把 Nx Cloud 自愈能力安全接入 LLM 工作流的直接范本。【免费下载链接】tsparticlestsParticles - Easily create highly customizable JavaScript particles effects, confetti explosions and fireworks animations and use them as animated backgrounds for your website. Ready to use components available for React.js, Vue.js (2.x and 3.x), Angular, Svelte, jQuery, Preact, Inferno, Solid, Riot and Web Components.项目地址: https://gitcode.com/GitHub_Trending/ts/tsparticles创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考