Back to Details

sealos-deploy

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Sealos Deploy

Sealos 部署

Identity and Discovery

身份标识与发现

  • Owner: 
    sealos-deploy
    (
    /sealos-deploy
    and deploy, update, publish, or cloud-runtime requests).
  • Class: 
    composite-orchestration
    across readiness, Dockerfile, template, build, deployment, and Runtime Truth.
  • Canaries: 
    DEP-KUBECONFIG-SCOPE
    , 
    DEP-CONFIRM-MUTATION
    , 
    DEP-REDACT
    , and 
    DEP-RUNTIME-TRUTH
    .
  • Contract: Read 
    references/deploy-contract.md
     after the canaries pass. It defines the typed phase handoffs, owned 
    .sealos
    artifacts, terminal states, and the read-only Canvas boundary.
  • 所有者： 
    sealos-deploy
    （对应
    /sealos-deploy
    以及部署、更新、发布或云运行时请求）。
  • 类别： 跨就绪检查、Dockerfile、模板、构建、部署及Runtime Truth的
    composite-orchestration
    （复合编排）。
  • 金丝雀标识： 
    DEP-KUBECONFIG-SCOPE
    、
    DEP-CONFIRM-MUTATION
    、
    DEP-REDACT
    和
    DEP-RUNTIME-TRUTH
    。
  • 契约： 金丝雀标识验证通过后，阅读
    references/deploy-contract.md
    。它定义了类型化阶段交接、专属
    .sealos
    工件、终端状态以及只读Canvas边界。

Scope and Boundaries

范围与边界

Accept a local path or GitHub URL and scope all work to the selected namespace/app. Preserve the current DEPLOY/UPDATE phase order, 
.sealos
artifact inventory, one log file, dependency handoffs, and cleanup footprint. All Kubernetes commands use 
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify
; unsupported workloads stop before scoring/build.
接受本地路径或GitHub URL，并将所有工作限定在选定的命名空间/应用范围内。保留当前DEPLOY/UPDATE阶段顺序、
.sealos
工件清单、单个日志文件、依赖项交接及清理足迹。所有Kubernetes命令均使用
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify
；不支持的工作负载会在评分/构建前终止。

Risk and Confirmation

风险与确认

Keep auth/workspace, kubeconfig scope, system-tool installation, public exposure, credential changes, deletion, rollback, and cleanup confirmation visible before module detail. Redact passwords, tokens, cookies, env values, kubeconfig, Secret data, and full connection strings. A quality gate and actual Runtime Truth evidence are acceptance conditions.
For every gated mutation, report the exact operation, impact, confirmation, and post-action evidence. Keep sanitized logs, state, diagnostics, and footprint evidence free of secret data.
在展示模块详情前，需明确显示认证/工作区、kubeconfig范围、系统工具安装、公共暴露、凭证变更、删除、回滚及清理的确认信息。对密码、令牌、Cookie、环境变量值、kubeconfig、Secret数据及完整连接字符串进行脱敏处理。质量门控和实际Runtime Truth证据是验收条件。
对于每个门控式变更，需报告确切操作、影响、确认信息及操作后证据。确保脱敏后的日志、状态、诊断信息及足迹证据不含敏感数据。

Lifecycle Workflow

生命周期工作流

For each request, run preflight/auth/workspace, detect mode, enforce eligibility, assess/detect/build or reuse, generate/validate the template, deploy or update, run Runtime Truth, and record state/cleanup evidence. Emit request-scoped 
success
, 
stopped
, or 
error
; the existing phase modules below remain authoritative for detailed behavior.
针对每个请求，依次运行预检/认证/工作区检查、检测模式、强制合规性评估、评估/检测/构建或复用、生成/验证模板、部署或更新、运行Runtime Truth，并记录状态/清理证据。输出请求范围的
success
、
stopped
或
error
；以下现有阶段模块仍为详细行为的权威依据。

Progressive Disclosure

渐进式披露

Load 
modules/
and helper scripts one phase at a time after the corresponding canaries pass. Preserve typed readiness → Dockerfile → Docker-to-Sealos handoffs, 
.sealos/analysis.json
, 
.sealos/build/build-result.json
, 
.sealos/template/index.yaml
, 
.sealos/state.json
, and delivery evidence; do not hide phase order behind a generic deploy shortcut.
在对应金丝雀标识验证通过后，分阶段加载
modules/
及辅助脚本。保留类型化的就绪→Dockerfile→Docker到Sealos的交接、
.sealos/analysis.json
、
.sealos/build/build-result.json
、
.sealos/template/index.yaml
、
.sealos/state.json
及交付证据；不要用通用部署快捷方式隐藏阶段顺序。

Output, Stop, and Error States

输出、终止与错误状态

  • success
    : actual returned App URL/live identity, route and port match, setup/login proof, recent logs/events, workload convergence, database/object evidence, full footprint, and saved deploy state.
  • stopped
    : unsupported eligibility, missing auth/tool, unresolved configuration, or unconfirmed public/destructive/cleanup boundary with the safe next action.
  • error
    : failed preflight, build/template/deploy/runtime/rollback/cleanup step and recovery action with sensitive values redacted.
  • success
    ：实际返回的应用URL/实时身份、路由与端口匹配、设置/登录证明、近期日志/事件、工作负载收敛、数据库/对象存储证据、完整资源占用情况及已保存的部署状态。
  • stopped
    ：不符合合规性、缺少认证/工具、配置未解决或未确认公共/破坏性/清理边界，并提供安全的下一步操作建议。
  • error
    ：预检失败、构建/模板/部署/运行时/回滚/清理步骤失败，并提供脱敏后的恢复操作建议。

Handoffs

交接机制

Readiness, Dockerfile, and Docker-to-Sealos inputs use typed 
target
, 
inputArtifact
, 
allowedAction
, 
failureReturn
, and 
responseOwner
fields. A verified deploy can hand 
target: sealos-canvas
, 
inputArtifact: sanitized .sealos/state.json and Runtime Truth
, 
allowedAction: read-only topology inspection
, 
failureReturn: runtime/state diagnostic
, and 
responseOwner: sealos-deploy
.
就绪检查、Dockerfile及Docker到Sealos的输入使用类型化的
target
、
inputArtifact
、
allowedAction
、
failureReturn
和
responseOwner
字段。已验证的部署可传递
target: sealos-canvas
、
inputArtifact: 脱敏后的.sealos/state.json和Runtime Truth
、
allowedAction: 只读拓扑检查
、
failureReturn: 运行时/状态诊断
及
responseOwner: sealos-deploy
。

Verification

验证机制

Use the existing eligibility, artifact, quality-gate, footprint, live-smoke, rollout, Runtime Truth, and cleanup checks. Baseline cases 
deploy-positive-runtime-truth
and 
deploy-violating-missing-runtime-proof
must preserve actual App URL/live identity, auth/cleanup confirmation, log scans, and redaction.
使用现有的合规性、工件、质量门控、资源占用、实时冒烟测试、发布、Runtime Truth及清理检查。基准案例
deploy-positive-runtime-truth
和
deploy-violating-missing-runtime-proof
必须保留实际应用URL/实时身份、认证/清理确认、日志扫描及脱敏处理。

Compatibility

兼容性

Sealos auth/workspace are required for deploys. Docker, buildx, and gh CLI are required only when the selected path needs local build/push. git is required when cloning from a GitHub URL or when git metadata is needed. Node.js 18+ remains an optional accelerator. Phase 5 requires Python 3.8+ with PyYAML; root Compose conversion also requires kompose and may require crane when image tags are floating.
部署需要Sealos认证/工作区。仅当选定路径需要本地构建/推送时，才需要Docker、buildx和gh CLI。当从GitHub URL克隆或需要git元数据时，需要git。Node.js 18+为可选加速工具。阶段5需要Python 3.8+及PyYAML；根Compose转换还需要kompose，当镜像标签为浮动标签时可能还需要crane。

Brain Managed Mode

Brain托管模式

The skill has two deliberately separate execution modes:
  • Local mode is the existing interactive workflow. It is selected when 
    SEALAI_DEPLOY_MODE
    is absent or has any value other than 
    managed
    ; its auth, prompts, Template API flow, and output remain unchanged.
  • Managed mode is selected only when 
    SEALAI_DEPLOY_MODE=managed
    . The Devbox Codex is the deployment executor: it analyzes, builds, applies, observes, diagnoses, repairs, and verifies with the injected kubeconfig. Brain is the task control plane and form owner; it is not a second Kubernetes executor.
Managed mode is non-interactive. Do not start OAuth, install tools, ask for confirmation in the turn, or replace a missing callback with a file, webhook, curl request, or a Brain-side apply. Before doing any work, confirm that the Codex tool registry contains both exact MCP tools 
template_ready
and 
deployment_completed
. If either tool is unavailable, stop with a managed-mode fatal error; never claim a deployment result.
Brain supplies these task-scoped values through the environment:
text
SEALAI_DEPLOY_MODE=managed
SEALAI_DEPLOY_TASK_ID=<task id>
SEALAI_PROJECT_ID=<Brain project id>
SEALAI_NAMESPACE=<target namespace>
SEALAI_INPUTS_PATH=/run/sealai/deployment/inputs.json
SEALAI_TURN_DEADLINE_AT=<absolute deadline>
Use the injected kubeconfig/context for every Kubernetes command. Do not perform login or switch workspace. Keep the input file and kubeconfig out of prompts, logs, Timeline text, and generated artifacts; read the input file only when the managed flow says to do so.
The actual Sealos Instance name is owned by the Template/Skill path. Brain does not pre-allocate it and the managed adapter does not add Brain identity labels or 
extraLabels
.
Deploy compatible cloud workloads to Sealos Cloud, stopping unsupported targets before build or deployment.
该技能有两个明确分离的执行模式：
  • Local mode（本地模式）：现有交互式工作流。当
    SEALAI_DEPLOY_MODE
    不存在或值为
    managed
    以外的任何内容时选择；其认证、提示、Template API流程及输出保持不变。
  • Managed mode（托管模式）：仅当
    SEALAI_DEPLOY_MODE=managed
    时选择。Devbox Codex为部署执行器：它通过注入的kubeconfig进行分析、构建、应用、观察、诊断、修复及验证。Brain为任务控制平面及表单所有者；它不是第二个Kubernetes执行器。
托管模式为非交互式。不要启动OAuth、安装工具、在当前轮次请求确认，或用文件、Webhook、curl请求或Brain端应用操作替代缺失的回调。在执行任何工作前，确认Codex工具注册表包含两个确切的MCP工具
template_ready
和
deployment_completed
。若任一工具不可用，则终止并返回托管模式致命错误；绝不要声称部署完成。
Brain通过环境变量提供以下任务范围的值：
text
SEALAI_DEPLOY_MODE=managed
SEALAI_DEPLOY_TASK_ID=<task id>
SEALAI_PROJECT_ID=<Brain project id>
SEALAI_NAMESPACE=<target namespace>
SEALAI_INPUTS_PATH=/run/sealai/deployment/inputs.json
SEALAI_TURN_DEADLINE_AT=<absolute deadline>
所有Kubernetes命令均使用注入的kubeconfig/上下文。不要执行登录或切换工作区。不要在提示、日志、时间线文本及生成的工件中暴露输入文件和kubeconfig；仅在托管流程要求时读取输入文件。
实际Sealos实例名称由Template/Skill路径管控。Brain不会预分配实例名称，托管适配器也不会添加Brain身份标签或
extraLabels
。
将兼容的云工作负载部署到Sealos Cloud，在构建或部署前终止不支持的目标。

kubectl Safety Rules (all phases)

kubectl安全规则（所有阶段）

All kubectl commands MUST use the Sealos kubeconfig:
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify
System tool installation requires user confirmation. If 
docker
, 
gh
, or 
kubectl
is missing and the skill can install it for the current platform, ask first and only run the install command after the user explicitly replies 
y
.
kubectl delete
requires user confirmation. Before deleting any resource (deployment, service, ingress, PVC, database, etc.), always ask:
WARNING: About to delete <resource kind>/<resource name>. This data cannot be recovered. Confirm? (y/n)
Only proceed after user confirms. This applies even if the pipeline logic suggests deletion — always ask first.
Template API cleanup must include Instance CRs. Deployments created through 
scripts/deploy-template.mjs
create 
instances.app.sealos.io/<app-name>
in addition to App/workload resources. A cleanup is incomplete until 
instances.app.sealos.io
, 
apps.app.sealos.io
, workloads, Services, Ingresses, PVCs, and Pods are all checked.
Use this check when cleaning Template API test deployments:
bash
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" \
  get instances.app.sealos.io,app,statefulset,deployment,svc,ingress,pvc,pod | grep "$APP"
Delete in this order after confirmation:
bash
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete instances.app.sealos.io "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete app "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete statefulset "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete deployment "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete ingress "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete svc "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" get pvc -o name | grep "$APP" | while read -r PVC; do
  KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete "$PVC" --ignore-not-found --wait=false
done
Anti-example: do not report cleanup complete after only checking 
app,statefulset,svc,ingress,pvc,pod
; that misses 
instances.app.sealos.io/<app-name>
and leaves the Sealos Instance layer dirty.
所有kubectl命令必须使用Sealos kubeconfig：
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify
系统工具安装需要用户确认。若
docker
、
gh
或
kubectl
缺失且技能可针对当前平台进行安装，需先询问用户，仅在用户明确回复
y
后才运行安装命令。
kubectl delete
需要用户确认。 在删除任何资源（部署、服务、Ingress、PVC、数据库等）前，必须询问：
WARNING: About to delete <resource kind>/<resource name>. This data cannot be recovered. Confirm? (y/n)
仅在用户确认后继续执行。即使流水线逻辑建议删除，也必须先询问。
Template API清理必须包含Instance CRs。 通过
scripts/deploy-template.mjs
创建的部署除了应用/工作负载资源外，还会创建
instances.app.sealos.io/<app-name>
。仅当
instances.app.sealos.io
、
apps.app.sealos.io
、工作负载、服务、Ingresses、PVCs及Pods均已检查完毕，清理才算完成。
清理Template API测试部署时使用以下检查命令：
bash
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" \
  get instances.app.sealos.io,app,statefulset,deployment,svc,ingress,pvc,pod | grep "$APP"
确认后按以下顺序删除：
bash
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete instances.app.sealos.io "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete app "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete statefulset "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete deployment "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete ingress "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete svc "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" get pvc -o name | grep "$APP" | while read -r PVC; do
  KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete "$PVC" --ignore-not-found --wait=false
done
反例：仅检查
app,statefulset,svc,ingress,pvc,pod
后不要报告清理完成；这会遗漏
instances.app.sealos.io/<app-name>
，导致Sealos实例层残留脏数据。

Usage

使用方式

/sealos-deploy <github-url>
/sealos-deploy                    # deploy current project
/sealos-deploy <local-path>
/sealos-deploy <github-url>
/sealos-deploy                    # 部署当前项目
/sealos-deploy <local-path>

Quick Start

快速开始

Execute the modules in order:
  1. modules/preflight.md
    — Environment checks & Sealos auth
  2. modules/pipeline.md
    — Full deployment pipeline (Phase 1–6)
  3. modules/runtime-truth.md
    — Post-deploy Runtime Truth Pass (Phase 6.5)
按顺序执行模块：
  1. modules/preflight.md
    — 环境检查 & Sealos认证
  2. modules/pipeline.md
    — 完整部署流水线（阶段1–6）
  3. modules/runtime-truth.md
    — 部署后Runtime Truth验证（阶段6.5）

Logging

日志记录

Every run MUST write a log file at 
~/.sealos/logs/deploy-<YYYYMMDD-HHmmss>.log
.
At the very start of execution, create the log file once:
bash
mkdir -p ~/.sealos/logs
LOG_FILE=~/.sealos/logs/deploy-$(date +%Y%m%d-%H%M%S).log
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Deploy started" > "$LOG_FILE"
Important: create the log file ONLY ONCE at the start. All subsequent writes MUST append (
>>
) to this same 
$LOG_FILE
. Do NOT create a second log file.
At each phase boundary, append a log entry to the same file with Bash 
>>
:
[2026-03-05 14:30:01] === Phase 0: Preflight ===
[2026-03-05 14:30:01] Docker: ✓ 27.5.1
[2026-03-05 14:30:01] Node.js: ✓ 22.12.0
[2026-03-05 14:30:02] Sealos auth: ✓ (region: <REGION from config.json>)
[2026-03-05 14:30:02] Project: /Users/dev/myapp (github: https://github.com/owner/repo)

[2026-03-05 14:30:03] === Phase 1: Assess ===
[2026-03-05 14:30:03] Score: 9/12 (good)
[2026-03-05 14:30:03] Language: python, Framework: fastapi, Port: 8000
[2026-03-05 14:30:03] Decision: CONTINUE

[2026-03-05 14:30:04] === Phase 2: Detect Image ===
[2026-03-05 14:30:05] Docker Hub: owner/repo:latest (arm64 only, no amd64)
[2026-03-05 14:30:05] GHCR: not found
[2026-03-05 14:30:05] Decision: no amd64 image → continue to Phase 3

[2026-03-05 14:30:06] === Phase 3: Dockerfile ===
[2026-03-05 14:30:06] Existing Dockerfile: none
[2026-03-05 14:30:07] Generated: python-fastapi template, port 8000

[2026-03-05 14:30:08] === Phase 4: Build & Push ===
[2026-03-05 14:30:08] Registry: ghcr (auto-detected via gh CLI)
[2026-03-05 14:30:30] Build: ✓ ghcr.io/zhujingyang/repo:20260305-143022
[2026-03-05 14:30:32] GHCR pullability: private package detected — deploy will auto-create image pull Secret from gh CLI
[2026-03-05 14:30:33] IMAGE_REF=ghcr.io/zhujingyang/repo:20260305-143022

[2026-03-05 14:30:34] === Phase 5: Template ===
[2026-03-05 14:30:35] Output: .sealos/template/index.yaml

[2026-03-05 14:30:36] === Phase 6: Deploy ===
[2026-03-05 14:30:36] Deploy URL: https://template.gzg.sealos.run/api/v2alpha/templates/raw
[2026-03-05 14:30:38] Status: 201 — deployed successfully
[2026-03-05 14:30:38] === DONE ===
On error, log the error details before stopping:
[2026-03-05 14:30:10] === ERROR ===
[2026-03-05 14:30:10] Phase: 4 (Build & Push)
[2026-03-05 14:30:10] Error: docker buildx build failed — "npm ERR! Missing script: build"
[2026-03-05 14:30:10] Retry: 1/3
At the very end, tell the user where the log is:
Log saved to: ~/.sealos/logs/deploy-20260305-143001.log
每次运行必须在
~/.sealos/logs/deploy-<YYYYMMDD-HHmmss>.log
路径下写入日志文件。
在执行开始时，仅创建一次日志文件：
bash
mkdir -p ~/.sealos/logs
LOG_FILE=~/.sealos/logs/deploy-$(date +%Y%m%d-%H%M%S).log
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Deploy started" > "$LOG_FILE"
重要提示：仅在开始时创建一次日志文件。后续所有写入必须使用追加模式（
>>
）写入同一个
$LOG_FILE
。不要创建第二个日志文件。
在每个阶段边界，使用Bash的
>>
命令向同一文件追加日志条目：
[2026-03-05 14:30:01] === Phase 0: Preflight ===
[2026-03-05 14:30:01] Docker: ✓ 27.5.1
[2026-03-05 14:30:01] Node.js: ✓ 22.12.0
[2026-03-05 14:30:02] Sealos auth: ✓ (region: <REGION from config.json>)
[2026-03-05 14:30:02] Project: /Users/dev/myapp (github: https://github.com/owner/repo)

[2026-03-05 14:30:03] === Phase 1: Assess ===
[2026-03-05 14:30:03] Score: 9/12 (good)
[2026-03-05 14:30:03] Language: python, Framework: fastapi, Port: 8000
[2026-03-05 14:30:03] Decision: CONTINUE

[2026-03-05 14:30:04] === Phase 2: Detect Image ===
[2026-03-05 14:30:05] Docker Hub: owner/repo:latest (arm64 only, no amd64)
[2026-03-05 14:30:05] GHCR: not found
[2026-03-05 14:30:05] Decision: no amd64 image → continue to Phase 3

[2026-03-05 14:30:06] === Phase 3: Dockerfile ===
[2026-03-05 14:30:06] Existing Dockerfile: none
[2026-03-05 14:30:07] Generated: python-fastapi template, port 8000

[2026-03-05 14:30:08] === Phase 4: Build & Push ===
[2026-03-05 14:30:08] Registry: ghcr (auto-detected via gh CLI)
[2026-03-05 14:30:30] Build: ✓ ghcr.io/zhujingyang/repo:20260305-143022
[2026-03-05 14:30:32] GHCR pullability: private package detected — deploy will auto-create image pull Secret from gh CLI
[2026-03-05 14:30:33] IMAGE_REF=ghcr.io/zhujingyang/repo:20260305-143022

[2026-03-05 14:30:34] === Phase 5: Template ===
[2026-03-05 14:30:35] Output: .sealos/template/index.yaml

[2026-03-05 14:30:36] === Phase 6: Deploy ===
[2026-03-05 14:30:36] Deploy URL: https://template.gzg.sealos.run/api/v2alpha/templates/raw
[2026-03-05 14:30:38] Status: 201 — deployed successfully
[2026-03-05 14:30:38] === DONE ===
出现错误时，在终止前记录错误详情：
[2026-03-05 14:30:10] === ERROR ===
[2026-03-05 14:30:10] Phase: 4 (Build & Push)
[2026-03-05 14:30:10] Error: docker buildx build failed — "npm ERR! Missing script: build"
[2026-03-05 14:30:10] Retry: 1/3
执行结束时，告知用户日志位置：
Log saved to: ~/.sealos/logs/deploy-20260305-143001.log

Scripts

脚本

Located in 
scripts/
within this skill directory (
<SKILL_DIR>/scripts/
):
ScriptUsagePurpose
workload-eligibility.mjs
node workload-eligibility.mjs <repo-dir>
Read-only fail-closed workload classification; decision is stdout-only
score-model.mjs
node score-model.mjs <repo-dir>
Deterministic readiness scoring (0-12)
detect-template.mjs
node detect-template.mjs [--github-url <url>] --work-dir <repo-dir> --skill-dir <SKILL_DIR>
Detect configured GitHub repo → Sealos template fast-path matches
validate-artifacts.mjs
node validate-artifacts.mjs --dir <work-dir>
Validate 
.sealos
JSON artifacts against enforced schemas
detect-image.mjs
node detect-image.mjs <github-url> [work-dir]
or 
node detect-image.mjs <work-dir>
Detect existing Docker/GHCR images
build-push.mjs
node build-push.mjs <work-dir> <repo> [--registry ghcr|dockerhub] [--user <user>]
Build amd64 image & push to the selected registry (Docker Hub path assumes a public image at deploy time; omitting 
--registry
keeps auto-detect behavior)
ensure-image-pull-secret.mjs
node ensure-image-pull-secret.mjs <namespace> <secret-name> <image-ref> [deployment-name]
Create/update app-scoped GHCR pull Secret and optionally patch an existing Deployment to reference it
gh-refresh-scopes.mjs
node gh-refresh-scopes.mjs write:packages
Refresh GHCR package access in the current TTY; 
write:packages
is sufficient for both push and private pull in this workflow
deploy-template.mjs
node deploy-template.mjs <template-path> [--dry-run] [--args-json '{"KEY":"value"}'|--args-file <file>]
Resolve the current region, enforce private sensitive-args files on POSIX, post a local template YAML, and emit an allowlisted result with credential values redacted
managed-adapter.mjs
node managed-adapter.mjs context|prepare-template <path>|sha256 <path>|read-inputs
Validate the Brain managed contract and compute the exact template SHA without injecting Instance identity or labels
sealos-launchpad-network.mjs
node sealos-launchpad-network.mjs --app <app> --app-url <url> [--expected-port <port>] [--region <url>] [--kubeconfig <path>]
Read-only Launchpad public-network discovery check with App URL and Service port matching
sealos-footprint.mjs
node sealos-footprint.mjs --namespace <ns> --app <app>
Read-only inventory of Instance/App/workloads/Jobs/KubeBlocks/PVCs/ObjectStorageBuckets for deploy debug and cleanup planning
sealos-live-smoke.mjs
node sealos-live-smoke.mjs --url <url> [--captcha-path <path>] [--login-method json-token|cookie-json] [--login-path <path>] [--username <user>] [--password <pass>] [--token-path <path>] [--auth-path <path>] [--missing-api-path <path>] [--missing-page-path <path>]
Read-only or credentialed HTTP smoke test for the real Sealos App entry URL, authenticated routes, and API/SPA negative probes
sealos-log-scan.mjs
node sealos-log-scan.mjs --namespace <ns> --app <app> [--since 10m] [--tail 300] [--baseline <report.json|json>] [--min-window-seconds 60]
Read-only JSON scan of Pod/init/main logs plus Warning Event convergence after readiness, login, and documented API or missing-static-asset checks
sealos-auth.mjs
node sealos-auth.mjs check|login|list|switch
Sealos Cloud authentication & workspace switching
All scripts output JSON. Run via Bash and parse the result.
For public web applications, run 
sealos-launchpad-network.mjs
before HTTP smoke. Acceptance requires 
ok: true
, an open public network, the expected Service port, and an App URL host match. The script emits an allowlisted network summary and excludes raw Launchpad application data, environment variables, Secrets, and kubeconfig content.
Runtime Event acceptance uses two scans. Capture the first report after readiness with no baseline, wait at least 60 seconds, then pass that report through 
--baseline
for the final scan. Extend 
--min-window-seconds
to cover one full known reconciliation, probe, or scheduled-work period. An initial Warning Event is an observation; a Warning that advances after the baseline, an unresolved referenced Secret, a Ready transition, a Pod replacement, or a restart delta is an active failure.
For intentional fault injection, retain a pre-injection report as evidence. After recovery reaches Ready, capture a fresh recovery baseline and compare the final scan against that recovery baseline after the full stability window.
位于该技能目录下的
scripts/
路径（
<SKILL_DIR>/scripts/
）：
脚本使用方式用途
workload-eligibility.mjs
node workload-eligibility.mjs <repo-dir>
只读式故障关闭工作负载分类；决策仅输出到标准输出
score-model.mjs
node score-model.mjs <repo-dir>
确定性就绪评分（0-12）
detect-template.mjs
node detect-template.mjs [--github-url <url>] --work-dir <repo-dir> --skill-dir <SKILL_DIR>
检测已配置的GitHub仓库与Sealos模板的快速路径匹配
validate-artifacts.mjs
node validate-artifacts.mjs --dir <work-dir>
根据强制验证的Schema校验
.sealos
JSON工件
detect-image.mjs
node detect-image.mjs <github-url> [work-dir]
或 
node detect-image.mjs <work-dir>
检测现有Docker/GHCR镜像
build-push.mjs
node build-push.mjs <work-dir> <repo> [--registry ghcr|dockerhub] [--user <user>]
构建amd64镜像并推送到选定的注册表（Docker Hub路径假设部署时为公开镜像；省略
--registry
则保持自动检测行为）
ensure-image-pull-secret.mjs
node ensure-image-pull-secret.mjs <namespace> <secret-name> <image-ref> [deployment-name]
创建/更新应用范围的GHCR拉取Secret，并可选地修补现有Deployment以引用该Secret
gh-refresh-scopes.mjs
node gh-refresh-scopes.mjs write:packages
在当前TTY中刷新GHCR包访问权限；
write:packages
权限足以支持本工作流中的推送和私有拉取操作
deploy-template.mjs
node deploy-template.mjs <template-path> [--dry-run] [--args-json '{"KEY":"value"}'|--args-file <file>]
解析当前区域，在POSIX系统上强制使用私有敏感参数文件，提交本地模板YAML，并输出脱敏后的许可结果
managed-adapter.mjs
node managed-adapter.mjs context|prepare-template <path>|sha256 <path>|read-inputs
验证Brain托管契约，并计算模板的精确SHA值，不注入实例身份或标签
sealos-launchpad-network.mjs
node sealos-launchpad-network.mjs --app <app> --app-url <url> [--expected-port <port>] [--region <url>] [--kubeconfig <path>]
只读式Launchpad公共网络发现检查，验证应用URL与服务端口匹配
sealos-footprint.mjs
node sealos-footprint.mjs --namespace <ns> --app <app>
只读式实例/应用/工作负载/Job/KubeBlocks/PVC/对象存储桶清单，用于部署调试和清理规划
sealos-live-smoke.mjs
node sealos-live-smoke.mjs --url <url> [--captcha-path <path>] [--login-method json-token|cookie-json] [--login-path <path>] [--username <user>] [--password <pass>] [--token-path <path>] [--auth-path <path>] [--missing-api-path <path>] [--missing-page-path <path>]
针对真实Sealos应用入口URL、认证路由及API/SPA负探针的只读或带凭证HTTP冒烟测试
sealos-log-scan.mjs
node sealos-log-scan.mjs --namespace <ns> --app <app> [--since 10m] [--tail 300] [--baseline <report.json|json>] [--min-window-seconds 60]
就绪检查、登录及已记录API或缺失静态资源检查后，对Pod/初始化/主容器日志及Warning事件收敛情况进行只读JSON扫描
sealos-auth.mjs
node sealos-auth.mjs check|login|list|switch
Sealos Cloud认证与工作区切换
所有脚本输出JSON格式内容。通过Bash运行并解析结果。
对于公共Web应用，在HTTP冒烟测试前运行
sealos-launchpad-network.mjs
。验收要求
ok: true
、开放的公共网络、预期的服务端口及应用URL主机匹配。脚本输出许可的网络摘要，排除原始Launchpad应用数据、环境变量、Secrets及kubeconfig内容。
运行时事件验收使用两次扫描。就绪检查后捕获第一个无基准的报告，等待至少60秒，然后将该报告通过
--baseline
参数传入进行最终扫描。延长
--min-window-seconds
以覆盖完整的已知协调、探测或定时任务周期。初始Warning事件为观察项；基准后出现的Warning、未解决的引用Secret、Ready状态转换、Pod替换或重启增量为主动故障。
对于故意故障注入，保留注入前的报告作为证据。恢复至Ready状态后，捕获新的恢复基准，并在完整稳定窗口后将最终扫描结果与该恢复基准进行比较。

Internal Skill Dependencies

内部技能依赖

This skill references knowledge files from co-installed internal skills. These are not user-facing — they are loaded on-demand during specific phases.
<SKILL_DIR>
refers to the directory containing this 
SKILL.md
. Sibling skills are at 
<SKILL_DIR>/../
:
<SKILL_DIR>/../
├── sealos-deploy/           ← this skill (user entry point) = <SKILL_DIR>
├── dockerfile-skill/        ← Phase 3: Dockerfile generation knowledge
├── cloud-native-readiness/  ← Phase 0.4 eligibility policy + Phase 1 assessment criteria
└── docker-to-sealos/       ← Phase 5: Sealos template rules
Paths used in pipeline.md follow the pattern:
<SKILL_DIR>/../dockerfile-skill/knowledge/error-patterns.md
<SKILL_DIR>/../dockerfile-skill/templates/<lang>.dockerfile
<SKILL_DIR>/../docker-to-sealos/references/sealos-specs.md
该技能引用协同安装的内部技能的知识文件。这些文件不面向用户 —— 它们会在特定阶段按需加载。
<SKILL_DIR>
指包含本
SKILL.md
的目录。同级技能位于
<SKILL_DIR>/../
：
<SKILL_DIR>/../
├── sealos-deploy/           ← 本技能（用户入口） = <SKILL_DIR>
├── dockerfile-skill/        ← 阶段3：Dockerfile生成知识
├── cloud-native-readiness/  ← 阶段0.4合规性策略 + 阶段1评估标准
└── docker-to-sealos/       ← 阶段5：Sealos模板规则
pipeline.md中使用的路径遵循以下模式：
<SKILL_DIR>/../dockerfile-skill/knowledge/error-patterns.md
<SKILL_DIR>/../dockerfile-skill/templates/<lang>.dockerfile
<SKILL_DIR>/../docker-to-sealos/references/sealos-specs.md

Phase Overview

阶段概述

PhaseActionSkip When
0 — PreflightCapability scan, path-specific warnings, Sealos authInitial blockers resolved
0.4 — EligibilityConfirm the repository root is a supported cloud workloadAny non-eligible result → stop
0.5 — Template Fast PathMatch GitHub repo to a configured Sealos templateNo match, or match cannot materialize template YAML
1 — AssessClone repo (or use current project), analyze deployabilityScore too low → stop
2 — DetectRoute an evidence-confirmed source-ready static tree to the pinned Nginx image build; otherwise find an existing imageExisting image → jump to Phase 5
3 — DockerfileGenerate Dockerfile if missingAlready has one → skip
4 — Build & Push
docker buildx
→ GHCR (auto via gh CLI) or Docker Hub (fallback)		—
5 — TemplateGenerate Sealos application template—
5.5 — ConfigureGuide user through app env vars and inputsNo inputs needed
6 — DeployDeploy template to Sealos Cloud—
6.5 — Runtime Truth PassVerify Launchpad public networking, the actual Sealos runtime, logs, Event convergence, App URL, login path, object-storage flow, and resource footprintUser explicitly requests deploy-only output
阶段操作跳过条件
0 — 预检能力扫描、路径特定警告、Sealos认证初始阻塞问题已解决
0.4 — 合规性确认仓库根目录为受支持的云工作负载任何不合规结果 → 终止
0.5 — 模板快速路径匹配GitHub仓库与已配置的Sealos模板无匹配，或匹配无法生成模板YAML
1 — 评估克隆仓库（或使用当前项目），分析可部署性评分过低 → 终止
2 — 检测将经证据确认的源码就绪静态树路由到固定的Nginx镜像构建；否则查找现有镜像找到现有镜像 → 跳至阶段5
3 — Dockerfile缺失时生成Dockerfile已有Dockerfile → 跳过
4 — 构建与推送
docker buildx
→ GHCR（通过gh CLI自动检测）或Docker Hub（备选）		—
5 — 模板生成Sealos应用模板—
5.5 — 配置引导用户配置应用环境变量及输入参数无需输入参数
6 — 部署将模板部署到Sealos Cloud—
6.5 — Runtime Truth验证验证Launchpad公共网络、实际Sealos运行时、日志、事件收敛、应用URL、登录路径、对象存储流程及资源占用情况用户明确请求仅输出部署结果

Decision Flow

决策流程

Input (GitHub URL / local path)
  │
  ▼
[Phase 0] Preflight ── fail → guide user to fix and STOP
  │ pass
  ▼
[Phase 0.5] Template fast path
  │
  ├── materialized template match ───────┐
  │                                      │
  ▼                                      │
[Phase 1] Assess ── not suitable → STOP with reason
  │ suitable
  ▼
[Phase 2] Detect existing image
  │
  ├── found (amd64) ────────────────────┐
  │                                     │
  ▼                                     │
[Phase 3] Dockerfile (generate/reuse)   │
  │                                     │
  ▼                                     │
[Phase 4] Build & Push to registry      │
  │                                     │
  ◄─────────────────────────────────────┘
  │
  ▼
[Phase 5] Generate Sealos Template
  ◄──────────────────────────────────────┘
  │
  ▼
[Phase 5.5] Configure ── present env vars → ask user for inputs → confirm
  │
  ▼
[Phase 6] Deploy to Sealos Cloud ── 401 → re-auth
│                                  409 → instance exists
▼
[Phase 6.5] Runtime Truth Pass ── network/runtime/log/login issue → debug template or runtime config
│
▼
Done — app deployed ✓
Execution rule: Phase 1 must never start while Phase 0 still has unresolved entry blockers. Docker, 
gh
, builder, and registry failures must be reported early, but only become hard blockers if the run later requires local build/push.
输入（GitHub URL / 本地路径）
  │
  ▼
[阶段0] 预检 ── 失败 → 引导用户修复并终止
  │ 通过
  ▼
[阶段0.5] 模板快速路径
  │
  ├── 匹配到可生成的模板 ───────┐
  │                                      │
  ▼                                      │
[阶段1] 评估 ── 不适用 → 终止并说明原因
  │ 适用
  ▼
[阶段2] 检测现有镜像
  │
  ├── 找到（amd64） ────────────────────┐
  │                                     │
  ▼                                     │
[阶段3] Dockerfile（生成/复用）   │
  │                                     │
  ▼                                     │
[阶段4] 构建并推送到注册表      │
  │                                     │
  ◄─────────────────────────────────────┘
  │
  ▼
[阶段5] 生成Sealos模板
  ◄──────────────────────────────────────┘
  │
  ▼
[阶段5.5] 配置 ── 展示环境变量 → 请求用户输入 → 确认
  │
  ▼
[阶段6] 部署到Sealos Cloud ── 401 → 重新认证
│                                  409 → 实例已存在
▼
[阶段6.5] Runtime Truth验证 ── 网络/运行时/日志/登录问题 → 调试模板或运行时配置
│
▼
完成 — 应用部署成功 ✓
执行规则： 阶段1绝不能在阶段0仍有未解决的入口阻塞问题时启动。Docker、
gh
、构建器及注册表故障需尽早报告，但仅当后续运行需要本地构建/推送时才成为硬阻塞。