用途：sg-ship 是 ShipGuard 的编排层。用户用日常语言提出“检查我刚改的内容”“这个分支能交付吗”“PR 前做端到端验证”等请求时，它推断意图、给出一个具体范围与检查计划，必要时只问一个合并问题，然后开启一次统一评审。用户无需了解斜杠命令、技能名、参数或结果文件名。
主要能力：按“静态发现→语义检查→动态模拟→视觉确认→人工决策”的顺序串联既有技能：sg-code-audit、sg-logic-audit、sg-process-check、sg-visual-run、sg-visual-review。它本身是薄编排器，通过内部桥接调用这些技能，不新增分析逻辑。范围只解析一次并贯穿各环节，确保所有环节检查同一改动。逻辑审计为固定环节：范围内出现工作流、状态机、重试、事务、授权路径或非平凡算法时，会做有界候选检测并执行语义追踪。
使用方式：默认范围为已提交改动与上游分支 merge-base 的差异，base = git merge-base HEAD @{upstream}（无上游时回退到默认分支）；--diff=<ref> 覆盖基准，--all 表示全仓库范围。范围 = git diff {base}...HEAD（三点）。解析出的 ref 以 --diff={ref} 传给每个环节，从而抑制子技能自身的范围提问。审计默认以 --report-only 运行，只有用户明确要求修复时才传 --fix，且修复后需重新解析范围。视觉环节在适用且需要时可用 node visual-tests/shipguard.mjs serve 启动应用，结束后用 node visual-tests/shipguard.mjs stop 停止（仅当由该 CLI 启动）。各阶段结果写入 visual-tests/_results/，run.json 记录每个环节状态（ran/skipped/not-applicable/error/needs-agent），非 ran 状态必须带原因。
适用场景：PR 或交付前的端到端验证、分支就绪性检查、重试/事务/授权等语义契约核查、改动前后行为对比、受影响路由的浏览器确认。
限制：审计环节 token 消耗较大（标准约 2M），语义追踪在适用时增加跨文件开销，建议保持范围狭窄并提前说明大计划。sg-ship 自身不修复、不决策，只做编排并把结果汇总到单一面板。无 UI、无 agent-browser 或用户排除视觉检查时跳过视觉环节并记录原因；某环节出错时报告并继续其余环节。未提供的信息（如具体收费、平台支持）暂未提供。