@weotro/dx 0.3.0 → 0.3.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@weotro/dx",
-  "version": "0.3.0",
+  "version": "0.3.3",
   "type": "module",
   "license": "MIT",
   "repository": {

package/skills/dx-adopt/SKILL.md

@@ -47,6 +47,8 @@ setup 顺序为全量契约及输入检查 → 缺失 .local 复制 → 环境
 
 同步 package scripts、CI、容器及部署调用、测试服务启动命令、开发说明和 agent 指令。旧功能清理须有去向与消费者切换证据。升级、审查及参数/环境/构建/进程/布局变化，按 [适配回归检查](references/adoption-regressions.md)相关分支取得隔离与真实运行证据。
 
+涉及多品牌或多环境部署时，读取[部署坐标与私有 profile](references/adoption-regressions.md#部署坐标与私有-profile)及[远端资源与部署状态](references/adoption-regressions.md#远端资源与部署状态)；构建会改写源码目录时，读取[临时生成文件与恢复](references/adoption-regressions.md#临时生成文件与恢复)；并行安排验证前，核对[验证任务的并发边界](references/adoption-regressions.md#验证任务的并发边界)。这些是按项目能力采用的适配规则，不要求新增品牌、部署平台或审批流程。
+
 逐项记录：
 
 - 实际安装源与版本，根和子目录发现正确工程，入口执行权限能随 clone 保留。

package/skills/dx-adopt/references/adoption-regressions.md

@@ -83,8 +83,11 @@ dx 已消费环境标志并处理标准帮助；应用按首个 -- 分开位置
 
 `dx/scripts/` 是公开入口契约；`dx/lib/`（实现与配套测试）和 `dx/config/`（项目策略）是可选的集中布局。移动时核对：
 
+采用集中布局且存在相关能力时，可按职责组织 `dx/lib/brand/`（品牌生成、投影、资源与就绪检查）和 `dx/lib/release/`（发布编排、平台适配器与构建入口），测试与实现同目录；品牌身份与发布拓扑仍由项目各自的配置真源维护。这是组织方式示例，不是 DX 强制目录契约。
+
 - 包装入口、相对 import、基于 import.meta.url 的根定位、测试复制 fixture。
 - Nx targets/inputs、lint glob、容器 COPY、CI、部署配置、文档与 agent 指令。
+- 测试分类 forwarder 及注册覆盖；发现工作区测试时过滤已经移走但尚未暂存删除的旧路径。生成文件头部的生成器路径从生成器修改并重新生成，不手改派生产物。
 - 根与子目录调用、Git 可执行文件模式、至少一个真实命令；搜索旧路径确认没有活动消费者。
 
 setup 使用隔离 Git 主 checkout、linked worktree 和独立 clone 验证：复制发生在应用 setup 前，已有 local 不覆盖、权限保留，独立 clone 不继承另一 clone 的秘密。应用 setup 保持幂等；仅存在 `dx/config/` 不等于有效的 `dx/scripts/setup`。
@@ -104,3 +107,47 @@ setup 使用隔离 Git 主 checkout、linked worktree 和独立 clone 验证：
 部署凭据采用工具支持的非 argv 通道；例如核实所用 Vercel CLI 支持后通过 `VERCEL_TOKEN` 传递，避免 `--token` 暴露在进程参数和命令日志中。用假令牌检查最终 argv 与输出。CI 需要临时 local 凭据文件时，在创建文件前注册清理，再写入并运行命令，覆盖写入或后续步骤失败的路径。
 
 失败按复现证据区分本次回归、既有问题与环境问题；必要时在不覆盖当前工作区的隔离基线复现。相关问题解决并复验后更新已知失败记录。纯技能或文档更新只检查结构、引用与差异，不因此重跑业务全仓测试。
+
+## 部署坐标与私有 profile
+
+多品牌或多环境项目把品牌、应用环境、目标、团队及项目作为一组部署坐标，在入口解析后显式传入实际构建和上传进程。CLI 收到了 `--brand`，不等于下游环境已经包含品牌。明确选择器的优先级：显式部署参数可以覆盖继承值，或在冲突时拒绝；不能静默使用另一品牌。构建缓存也须覆盖实际影响产物的品牌与环境输入。
+
+用隔离替身或非秘密标记观察最终子进程，覆盖未设置选择器、继承另一品牌、嵌套包装及不同环境；验证目标项目与产物品牌一致，不仅断言入口解析结果。平台若将预发项目也作为其 production target 部署，须明确区分应用环境与平台 target，按实际坐标判断是否发错环境。
+
+私有 profile 保存凭据与部署坐标，品牌公开域名、CDN、名称等构建配置从项目品牌真源派生；不要因为它们通过环境变量传递就维护多份真源。需要规范 dotenv 路径的工具由包装器按需临时物化，退出后清理；持久 profile、提交模板和临时文件的职责分开。私有文件保持 Git 忽略及限制权限，日志和异常不输出真实 token 或整份环境。
+
+一个 profile 共用团队 ID 时，切换团队需同步核对该 profile 下所有目标的项目 ID，避免新团队与旧项目混用。先准备并校验完整的新映射，再更新相关键，保留无关配置和权限。缺失 profile 可从对应模板创建，缺失服务凭据明确列出，不默认复制另一品牌的数据库、SSH 或服务身份。
+
+## 远端资源与部署状态
+
+在用户授权的团队创建或调整项目之前，用凭据只读核对账号、目标团队及已有项目。认证成功不代表有目标团队权限；团队 slug 用于查找，回读的 ID 用于配置。查重时同时核对归属与名称，创建后回读确认再写本地映射。根据所用 API/CLI 版本核对参数，不把更新接口的字段假定为创建接口也接受；失败后先确认是否已创建资源，再决定重试。
+
+平台可能另行校验 Git 提交作者的成员权限和代码托管账号关联，例如 Vercel 的 `TEAM_ACCESS_REQUIRED`。遇到阻断时核对提交作者、token 所属账号及团队权限，按平台支持的方式使用真实获授权身份；不要把 token 有效当作作者权限证明，也不通过伪造作者或重写历史绕过限制。
+
+上传完成与生成部署 URL 都不等于发布完成。按部署 ID 查询远端真实状态，绑定预期团队、项目和应用环境；遇到平台的失败终态（如 `BLOCKED`、`ERROR`、`CANCELED`）立即报告安全的原因，不能一直显示 `Building…`。等待设置有限超时，并提供精确部署链接；超时后状态未知时先查询原部署，不自动重复上传或撤销远端资源。
+
+用替身覆盖失败终态、状态长期不变、API 请求失败和归属不匹配。只有远端达到预期成功状态且所需产物核验通过才报告部署成功。交付分别说明资源创建、私有配置写入、完整 profile 校验、实际部署与远端验证；只填好了平台参数但缺其他必需配置时，不能宣称已经可部署。
+
+## 临时生成文件与恢复
+
+先区分长期派生产物与临时构建投影，再决定 Git 跟踪策略。根据 fresh clone、编辑器、构建准备和漂移检查的需要保留或调整跟踪，不为隐藏部署残留直接忽略文件；取消跟踪并不会清除磁盘上残留的另一品牌配置。调整跟踪属于单独的依赖与准备流程变更。
+
+在第一次临时改写之前，为本次会触及的明确文件集合保存原始字节、权限及是否存在。边界覆盖所有会改写它们的准备、构建和部署步骤；外层准备已改写之后才备份，会把投影残留当作原始状态。文件集合从实际生成器确定并随其输出变化维护，不照搬其他项目的固定名单。
+
+在成功、失败及 SIGINT/SIGTERM 路径恢复部署前状态：原来不存在的临时文件移除，原来的本地修改保留；构建产物按项目策略保留。不能以 `git restore .`、全仓 reset 或无差别重新生成代替快照恢复，这些操作可能覆盖无关修改或部署前已有的生成文件编辑。既有残留先验证与已知投影一致，再按当前授权恢复标准生成态。
+
+恢复必须等待本次写入进程及后代停止，不能只等待直接子进程退出。信号处理保留到收尾完成；恢复失败返回非零，并保留原失败原因及可恢复证据，不把失败报告成成功。有并行发布时按共享写入范围串行、加互斥或隔离工作区，避免两个快照交错恢复；无法捕获的强杀不承诺由 finally 恢复，需要时设计持久备份及下次运行的恢复入口。
+
+回归验证从真实 DX 入口进入，用隔离目录和部署替身产生实际文件改写，覆盖：
+
+- 成功、构建或上传失败、最外层 SIGINT/SIGTERM；原退出码或中断状态继续传播。
+- 部署前有本地编辑、原文件缺失、非默认权限与原始字节；无关文件及构建产物不被误恢复。
+- 子进程收到停止信号后仍延迟写入；断言最终恢复发生在最后一个写入者退出之后。
+
+仅匹配脚本中的 try/finally、restore 字符串或模拟返回 0，不足以证明恢复生效。
+
+## 验证任务的并发边界
+
+并行前沿真实依赖链检查读写集合。lint 可能依赖类型检查和契约生成，build 也可能写同一目录；多个看似只读的验证入口还可能自动安装依赖。共享暂存目录、生成代码、品牌投影或 node_modules 的命令应串行，或放入隔离工作区；单个编排器内部的依赖调度不等于多个外部进程之间有锁。
+
+并发后出现重复声明、暂存目录消失、移动文件失败或 bin 链接创建失败时，先确认相关进程已经结束，再通过正常生成或安装入口串行恢复并复验。用证据区分调度冲突与代码回归，不通过修改生成代码、放宽依赖策略或忽略错误来消除症状。共享输入未再变化且相关检查已通过时，不重复扩大验证。

package/skills/git-release/SKILL.md

@@ -11,7 +11,7 @@ description: 仅在显式调用 git-release 时使用：准备或执行版本发
 只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
 仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
 
-用户显式调用本技能执行发布，即明确授权在本次目标仓库创建并推送目标版本的 tag，以及创建并发布对应的 GitHub Release。完成准备和验证后连续执行至发布结果核验，无需再次询问是否推送 tag 或创建 Release。用户明确限定为仅准备、草稿、审计或修改技能时，按该范围执行；本授权不包含覆盖冲突 tag、删除既有 Release 或额外的生产操作。
+用户显式调用本技能执行发布，即明确授权在本次目标仓库创建并推送目标版本的 tag、创建并发布对应的 GitHub Release，以及创建该版本的远程 GitHub 回访审计 Issue。完成准备和验证后连续执行至 Release 与回访 Issue 均读回核验，无需再次询问是否推送 tag、创建 Release 或回访 Issue。用户明确限定为仅准备、草稿、审计、修改技能或不创建 Issue 时，按该范围执行；本授权不包含覆盖冲突 tag、删除既有 Release 或额外的生产操作。
 
 ## 发布准备
 
@@ -45,8 +45,8 @@ gh release create v<VERSION> --title "v<VERSION>" --notes-file <notes-path>
 
 准备审计草稿时按需读取 [发布后回访契约](references/post-release-follow-up.md)。以本次变更映射受影响对象、预期行为、通过标准和脱敏证据；不是部署操作手册。
 
-默认本技能只编写回访审计 Issue，不执行生产验证；用户另有只读取证任务时按该任务范围继续。发布成功不代表部署完成，依赖部署后事实的审计项保持未勾选。
+默认本技能创建远程回访审计 Issue，不执行生产验证；用户另有只读取证任务时按该任务范围继续。发布成功不代表部署完成，依赖部署后事实的审计项保持未勾选。
 
-任务包含创建回访 Issue 时，发布成功后创建并读回，确认实质变更均有对应审计项或不适用说明。创建失败时保留草稿与已发布状态，修复可恢复错误，仅补做未完成的 Issue 操作。
+发布成功后，在同一目标仓库查找该版本已有的回访 Issue（含已关闭项），以版本、Release URL 和目标提交确认对应关系；存在则复用并读回，否则直接创建并读回，确认实质变更均有对应审计项或不适用说明。创建失败或结果不明时先查询远端状态，修复可恢复错误，仅补做未完成的 Issue 操作，避免重复创建。确实无法完成时保留草稿并报告具体阻碍，明确标记回访 Issue 未完成。
 
-最终报告版本、目标提交、Release URL、验证结果和回访 Issue（或本地草稿）链接；区分发布成功、部署状态未知与未完成项。
+完整发布的完成条件包含远程回访 Issue 已创建或复用并读回核验；本地草稿仅是准备或失败恢复材料。最终报告版本、目标提交、Release URL、验证结果和远程回访 Issue URL；区分发布成功、部署状态未知与未完成项。仅准备或草稿任务按用户范围报告本地产物。

package/skills/git-release/references/post-release-follow-up.md

@@ -75,12 +75,12 @@ GitHub Release、tag、CI 或部署工作流成功都不能证明生产已完成
 
 ## 完成边界
 
-完整发布并创建回访 Issue 的完成条件如下；用户仅要求本地草稿时，以草稿覆盖范围和质量为准：
+完整发布的完成条件如下；回访 Issue 按入口技能默认创建到目标 GitHub 仓库。用户明确限制任务范围时按该范围执行，仅要求本地草稿时以草稿覆盖范围和质量为准：
 
 - Release 已读回确认；
 - 本次发布的每项实质变更已映射到审计项或不适用说明；
 - 每个审计项都有审计对象、通过标准、证据要求和时机；
-- Issue 已创建并读回，且没有占位符；
+- 远程 Issue 已创建或复用并读回，且没有占位符；
 - 所有依赖部署后事实的审计项均未勾选；
 - Issue 没有声称已经完成部署或生产验证，也没有写成部署操作步骤。
 

package/skills/project-agent-standards/SKILL.md

@@ -1,21 +1,31 @@
 ---
 name: project-agent-standards
-description: 审核并补齐项目面向 agent 的 GitHub 模板、开发评审规范、DX 工作流与回访 Issue 规则，将 AGENTS.md 整理为按需读取的渐进披露结构。
+description: 审核并补齐项目面向 agent 的 GitHub 模板、开发评审规范、DX 工作流、回访 Issue 规则、.scratch 跟踪与跨端联动约束，将 AGENTS.md 整理为按需读取的渐进披露结构。
 ---
 
 # 项目 Agent 规范整备
 
 对用户指定仓库执行审核并补齐缺项；未指定时使用当前仓库。只读审核请求只报告差异。默认执行本地可回退的模板和文档修改，不包含提交、推送、发布 Issue / PR、安装工具或改造构建系统。现有全局技能保持不变。
 
+以下所有规范、模板和入口均先检查是否已有等效内容，再依据源码、配置、测试和已有决策核对其正确性及项目适用性。已存在、正确且符合项目状况的内容保持原样，不为统一措辞、路径或套用骨架而修改。只有确认缺失、错误、过时或不符合项目状况时才做最小必要修改；依据不足时保留原文并报告待确认事项。
+
 ## 1. 建立项目依据
 
 检查工作区状态，读取目标及祖先的 `AGENTS.md`。按需检查已有规范、贡献指南、GitHub 模板、技术栈清单、任务配置和 CI。优先搜索标题与职责，不能仅凭文件名判定规范缺失。
 
-记录以下六项的现状、路径和缺口：Issue / PR 模板、agent 引用、开发评审规范、DX / Nx 工作流、回访规则、AGENTS.md 渐进披露结构。检查根及模块 agent 入口的内容分工、读取条件和引用链；祖先指令用于确定约束，不修改目标仓库之外的文件。区分已配置的命令、实际运行结果与未来建议；不读取或输出秘密值。
+记录以下十项的现状、路径和缺口：Issue / PR 模板、agent 引用、开发评审规范、DX / Nx 工作流、回访规则、AGENTS.md 渐进披露结构、根 AGENTS.md 的开工前三问、`.scratch/` 的 Git 跟踪状态、跨端联动规则、GitHub Issue / PR 的直接提交流程。检查根及模块 agent 入口的内容分工、读取条件和引用链；祖先指令用于确定约束，不修改目标仓库之外的文件。区分已配置的命令、实际运行结果与未来建议；不读取或输出秘密值。
 
 完成条件：每项均有存在证据或明确的缺失结论，能够识别目标模块与实际工具链。
 
-## 2. 补齐 GitHub 模板
+### 检查 `.scratch/` 的 Git 跟踪
+
+根目录 `.scratch/` 应纳入版本控制，不得被 Git 忽略。分别检查实际跟踪与忽略状态：用 `git ls-files -- .scratch/` 确认已有受跟踪文件；用 `git check-ignore -v --no-index -- .scratch/ .scratch/.gitkeep` 并结合目录内现有文件检查生效规则。即使已有文件被跟踪，也要检查是否仍有忽略规则阻止新增文件进入版本控制；命中 `!` 反向规则表示取消忽略，不能仅凭命令退出码判断。
+
+缺失或空目录补 `.scratch/.gitkeep`，因为 Git 不跟踪空目录。最小调整仓库内的 `.gitignore`，解除对 `.scratch/` 及其内容的忽略；若由父目录或通配规则造成，确保父目录与内容均可被重新包含。全局忽略或 `.git/info/exclude` 的影响优先通过仓库内精确反向规则解决，不修改仓库外配置。保留凭据等敏感文件的专用忽略规则，不批量暂存现有内容。只读审核仅报告缺口。
+
+完成条件：报告目录是否存在、是否被忽略、是否已有受跟踪文件及修复结果。新增文件尚未进入 Git 索引时标明“待纳入跟踪”，不能将“未被忽略”报告为“已跟踪”；只有用户授权暂存时才将核实过的文件加入索引。
+
+## 2. 补齐 GitHub 模板与提交流程
 
 使用随技能携带的完整模板，无需访问原始项目：
 
@@ -24,11 +34,17 @@ description: 审核并补齐项目面向 agent 的 GitHub 模板、开发评审
 | [Issue 模板](assets/github/ISSUE_TEMPLATE/issue.md) | `.github/ISSUE_TEMPLATE/issue.md` |
 | [PR 模板](assets/github/pull_request_template.md) | `.github/pull_request_template.md` |
 
-目标缺失时创建目录并直接复制。目标已有等效内容时保留；空文件或缺少模板必需结构时，以资源覆盖该目标文件。覆盖前保留目标的未提交或未跟踪原文到仓库外的临时备份，并记录路径；已提交的原文可通过 Git 恢复。用户明确要求统一为附带模板时直接覆盖。
+确认没有可复用的等效模板时，创建目录并按项目状况适配资源。目标已有正确且适用的等效内容时保留；空文件可使用资源填充，缺少项目所需结构时只补齐缺项。覆盖前保留目标的未提交或未跟踪原文到仓库外的临时备份，并记录路径；已提交的原文可通过 Git 恢复。用户明确要求统一为附带模板时直接覆盖。
 
 检查根目录、`docs/` 与 `.github/` 是否有竞争的默认 PR 模板；将仍适用的独有约束合入标准模板，再清理被取代的默认副本并更新引用。保留用途不同的 Issue Forms、多模板及配置，不因其存在就删除。已有标准文件中的项目专属验收要求同样需要保留。
 
-完成条件：两个标准位置均有可用模板，默认 PR 模板选择无冲突，独有约束和用户原文可追踪。
+检查 `AGENTS.md` 引用的 Issue / PR 流程、贡献指南及相关命令说明，确保明确采用以下正常提交流程；已有等效规则则复用，缺失时在现有流程文档中补齐，没有载体时创建 `docs/agents/github-workflow.md`，并在根 `AGENTS.md` 添加创建或更新 GitHub Issue / PR 时必须读取的入口：
+
+> 用户要求创建 GitHub Issue / PR 时，完成必要的信息整理与项目要求的验证后，直接提交到 GitHub。Issue 创建为正式 Issue；PR 创建为可评审的普通 PR，不使用 Draft 状态或 `--draft`。不设置“先生成本地草稿、等待草稿确认、再发布”的中间流程，也不以 GitHub Projects 的 draft issue 代替正式 Issue。提交后返回实际链接，继续正常的评审、CI 与合并流程。
+
+将已有“默认草稿”“先草稿再转正式”或“先确认草稿才能发布”的相冲突说明改为此流程，保留正常的内容检查、评审与 CI 要求。用于 CLI 提交正文的临时文件不属于草稿流程；用户只要求撰写或审核正文时，仍按该任务范围处理。本技能整备流程文档本身不创建或发布 Issue / PR。
+
+完成条件：Issue / PR 均有可用模板，已有正确且适用的路径保留，默认 PR 模板选择无冲突，提交流程明确使用正式 Issue 与普通 PR，入口可达且无冲突的草稿要求，独有约束和用户原文可追踪。
 
 ## 3. 补齐面向 agent 的参考文档
 
@@ -52,6 +68,19 @@ DX 文档必须检查实际 DX 配置、Nx 目标与 CLI 能力。已接入则
 
 ## 4. 检查并改造 AGENTS.md 的渐进披露结构
 
+检查根 `AGENTS.md`（沿用仓库已有的文件名大小写）是否包含以下开工前三问。已有完整等效约束且正确、符合项目状况时保持原样；部分缺失时只补缺项，整段缺失时在根入口的工作原则或全局约束处加入以下内容，沿用项目语言。此约束属于全局必需规则，保留在根入口正文中：
+
+> Ask yourself before starting:
+>
+> 1. "Is this a real problem?" - Reject over-engineering.
+> 2. "Is there a simpler way?" - Always seek the simplest solution (KISS).
+
+根据源码目录与工作区配置识别实际存在的 `mobile`、`admin`、`front` 应用，包括 `apps/` 等嵌套位置。存在其中至少两端时，检查根 `AGENTS.md` 是否已有覆盖这些端的联动规则；仅在某一端的模块入口中有规则不足以覆盖其他端发起的修改。缺失时在根入口补齐以下约束，并按实际存在的端适配：
+
+> 修改 mobile、admin、front 任一端时，必须同时评估其他现有端是否需要同步修改，重点核对共享业务规则、接口契约、数据字段及对应用户流程。mobile 与 front 经常承载相同功能，修改其中一端时必须检查另一端的对应实现。需要联动时一并修改并验证受影响端；无需联动时在交付说明中简述依据。
+
+已有等效约束时复用，仅有单端时将跨端检查记为“不适用”，不添加不存在的端或要求无关端机械同步。
+
 渐进披露按任务需要加载说明：根入口保留项目识别、全局必需约束与条件明确的文档入口；模块入口保留该目录适用的规则；详细流程、命令说明、模板字段和专题规范放在被引用文档中。判断依据是内容职责与加载方式，不以行数或是否已有链接判定。只有简短必需规则的入口无需为了拆分而创建文件。
 
 存在下列情况时，在本次整备中直接改造：入口堆放仅特定任务需要的详细流程；所有专题文档被要求无条件全文加载；只有链接而没有读取条件；相同规范在多个入口重复维护。只读审核请求则报告问题和迁移建议。
@@ -77,6 +106,6 @@ DX 文档必须检查实际 DX 配置、Nx 目标与 CLI 能力。已接入则
 
 ## 5. 验证与交付
 
-检查差异、Markdown 链接、模板 frontmatter、占位符和竞争模板。逐项复核第 1 步的六项清单与所有新引用，确认再执行一次不会增加文件或重复条目。对照迁移记录检查规则完整性，并分别用代码修改、Issue / PR 编写和回访任务走查入口，确认能够找到对应规范，且不会要求加载无关专题。
+检查差异、Markdown 链接、模板 frontmatter、占位符和竞争模板。逐项复核第 1 步的十项清单与所有新引用，确认根入口的开工前三问完整、`.scratch/` 的跟踪与忽略状态已分别核实、适用项目的跨端联动规则覆盖实际存在的各端，已有正确且适用的内容未被改写，每处修改均有具体缺口或纠错依据，再执行一次不会增加文件或重复条目。对照迁移记录检查规则完整性，并分别用代码修改、Issue / PR 编写和回访任务走查入口；模拟用户要求创建 GitHub Issue / PR 的任务，确认流程直接提交正式 Issue 或普通 PR，没有草稿确认或 Draft 状态的中间环节；多端项目额外从 mobile 或 front 修改任务走查另一端影响评估，确认能够找到对应规范，且不会要求加载无关专题。
 
 纯文档修改按项目规则做差异与格式验证；验证命令存在可以检查配置或安全的帮助输出，不为文档审核运行发布、迁移或全仓测试。报告每项的保留 / 新建 / 更新状态、文件链接、实际验证和未确认事项，以及渐进披露检查结论与章节迁移去向；未接入 DX / Nx 要明确说明。不要将文档中列出的命令写成已经执行通过。