cloud-native-readiness

云原生就绪度评估技能

身份与发现

• 所有者： cloud-native-readiness（/cloud-native-readiness，以及就绪度、容器化、部署可行性或工作负载资格相关请求）。
• 类别： read-only-observation；仅在资格和路由证据通过后，才向 dockerfile-skill 进行类型化交接。
• 金丝雀： CNR-ELIGIBILITY-STOP 和 CNR-ROUTE-HANDOFF。

范围与边界

接受本地路径或 GitHub URL，并检查仓库证据。此条目评估资格、就绪度和现有产物；不会写入项目文件，也不会为缺乏支持的目标评分。单独的就绪度请求会将报告保留在请求结果中，不会创建 .sealos/analysis.json；组合式部署编排可以根据自身契约持久化经过净化的交接快照。Dockerfile 交接会将就绪度报告作为输入产物，并将打包变更留给接收方负责。

风险与确认

评分前加载 knowledge/deployment-eligibility.md。对于不受支持或尚未确定的工作负载，在检测产物、评分、生成 Dockerfile 或部署之前停止。报告中的源路径、环境值和任何凭据都必须经过脱敏；保留当前默认拒绝的资格边界。

生命周期工作流

对于每个请求，选择仓库、检查资格、评估符合条件的目标、检测 Docker 产物，并且仅在决策矩阵允许时进行路由。请求以 success、stopped 或 error 结束；每个结果都包含所选源、工作负载类型、脱敏状态和已取得的最强证据。现有的三阶段 Assess → Detect → Route 工作流仍作为下文中的领域扩展。

渐进式披露

进入相应阶段时，逐层加载 modules/assess.md、modules/detect.md 和 modules/route.md。首次评分前加载部署资格知识。资格检查停止后，不要加载 Dockerfile 细节，也不要执行交接。

输出、停止与错误状态

• success：包含所选源、符合资格的工作负载类型、评分维度、产物清单、关注事项、建议、验证证据以及任何类型化交接。
• stopped：包含所选源、工作负载类型、资格或确认原因代码、观察到的证据、脱敏结果和安全的后续操作；不声称存在任何下游产物。
• error：包含所选源、失败阶段或辅助程序或产物、经过净化的诊断信息、脱敏结果和恢复操作。

交接

符合资格且路由要求打包时，对于仅评估请求，发送以下完整的类型化交接。接收技能会重新检查自身范围和金丝雀。

target: dockerfile-skill
inputArtifact: readiness report with source, project language/framework/package manager, dependencies/configuration, workload, score, dimensions, concerns, and artifact inventory
allowedAction: generate Docker packaging within the receiving skill's owned file scope
failureReturn: readiness findings and the failed route condition
responseOwner: cloud-native-readiness

验证

使用 workload-eligibility.mjs、score-model.mjs、当前就绪度评估证据，以及基线跟踪 readiness-positive-eligible 和 readiness-violating-ineligible。在评分或构建前验证资格，保留报告字段，并对疑似凭据格式的值进行脱敏。

就绪度报告契约

将此负载限定在当前请求范围内，并使用相对于仓库的路径。下游交接可以复用该负载，无需重复发现。

source:
  kind: local-path | github-url
  display: redacted repository identifier
project:
  language: detected language
  framework: detected framework or null
  package_manager: detected package manager or null
  dependencies: redacted external dependency types and versions
  configuration: redacted configuration and environment-key observations
workload:
  type: server | static-web | worker | scheduled-job | reviewed-remote-desktop | unresolved
  eligibility: eligible | ineligible | needs_review
assessment:
  score: 0-12 or null when stopped
  dimensions: six named scores when eligible
  concerns: redacted findings
artifacts:
  status: complete | partial | none
  inventory: repository-relative paths and quality observations
recommendation: report-only | package | remediate | stop
verification:
  helper: eligibility and/or scoring helper invoked
  evidence: observed result and redaction status
handoff: typed tuple or none
terminal_state: success | stopped | error
safe_next_action: request-scoped next action

负载绝不包含密码、令牌、kubeconfig 内容、环境值或完整连接字符串。

概述

此技能通过三阶段工作流评估仓库是否已准备好部署为云原生微服务：

1. 评估 - 拒绝不受支持的工作负载类型，然后为符合资格的目标评分
2. 检测 - 检查 Docker 产物是否已存在（Dockerfile、docker-compose、容器镜像）
3. 路由 - 如果产物已存在，则直接返回结果；如果不存在，则调用 dockerfile-skill 进行容器化

工作流

cloud-native-readiness
  │
  ├─ Phase 1: Cloud-Native Assessment
  │    ├─ Eligibility fails or needs review → Report evidence, END
  │    └─ Eligible → Calculate readiness score
  │
  ├─ Phase 2: Existing Artifacts Detection
  │    ├─ Found Dockerfile/docker-compose/image → Report existing setup, END
  │    └─ Not found → Continue
  │
  └─ Phase 3: Route to dockerfile-skill
       └─ Invoke /dockerfile to generate Docker configuration

用法

/cloud-native-readiness              # Assess current directory
/cloud-native-readiness <path>       # Assess specific path
/cloud-native-readiness <github-url> # Clone and assess

快速开始

调用时，先读取并执行 modules/assess.md。只有当评估报告将请求的根目录判定为 eligible 时，才继续读取 modules/detect.md 和 modules/route.md。如果结果为 ineligible、未解决的 needs_review 或错误，则应在进行制品检测或后续路由之前，提供相关证据和安全的后续操作，并结束请求。

阶段 1：云原生就绪度评估

加载并执行：modules/assess.md

在评定就绪度分数之前，应用 knowledge/deployment-eligibility.md。 只有当请求的根目录被分类为 eligible 时，才继续。

评估 6 个维度（每项评分 0-2）：

维度	检查内容
无状态性	应用是否在本地存储状态（内存中的会话、本地文件写入）？
配置外部化	配置是硬编码的，还是由环境变量 / 配置文件驱动？
水平可扩展性	多个实例能否无冲突地运行？
启动/关闭	应用能否快速启动并妥善处理 SIGTERM？
可观测性	是否具备健康检查、结构化日志和指标？
服务边界	它是职责明确的服务，还是紧密耦合的单体？

评分：

• 10-12：优秀 — 已完全满足云原生就绪条件
• 7-9：良好 — 经过少量调整后即可就绪
• 4-6：一般 — 容器化前需要进行一些重构
• 0-3：较差 — 需要大幅返工，目前不建议容器化

输出：包含分数、发现和建议的结构化就绪度报告。

阶段 2：检测现有制品

加载并执行：modules/detect.md

检查以下内容：

• Dockerfile / Dockerfile.*（多阶段、多服务）
• docker-compose.yml / docker-compose.yaml / compose.yml
• .dockerignore
• DOCKER.md 或 Docker 相关文档
• 容器镜像仓库引用（ghcr.io、docker.io、ECR、GCR、ACR）
• Kubernetes 清单（k8s/、kubernetes/、deploy/、helm/、charts/）
• 含 Docker 构建步骤的 CI/CD 流水线（.github/workflows/、.gitlab-ci.yml）

输出：现有 Docker/K8s 制品清单及质量评估。

阶段 3：路由决策

加载并执行：modules/route.md

决策矩阵：

ineligible 或未解决的 needs_review 结果始终会在制品检测或 Dockerfile 生成之前停止。评分矩阵仅适用于 eligible 目标。

就绪度分数	是否存在制品	操作
≥ 7	是，完整	报告现有配置。完成。
≥ 7	是，部分	报告缺项并建议改进。完成。
≥ 7	否	调用 dockerfile-skill 生成。
4-6	任意	报告问题和修复步骤。可选择继续使用 dockerfile-skill。
0-3	任意	报告阻碍因素。不要调用 dockerfile-skill。

就绪度报告格式

最终输出必须采用以下格式：

对于已停止的资格判定结果，应报告其工作负载类型、原因代码、证据和后续操作，不得虚构就绪度分数。

# Cloud-Native Readiness Report

## Summary
- **Project**: {name}
- **Eligibility**: {eligible | ineligible | needs_review} — {workload type}
- **Score**: {score}/12 ({rating})
- **Verdict**: {Ready | Ready with caveats | Needs work | Not recommended}

## Assessment Details

### ✅ Strengths
- {what's already cloud-native friendly}

### ⚠️ Concerns
- {issues that need attention}

### ❌ Blockers (if any)
- {critical issues preventing containerization}

## Dimension Scores

| Dimension | Score | Notes |
|-----------|-------|-------|
| Statelessness | {0-2} | {detail} |
| Config Externalization | {0-2} | {detail} |
| Horizontal Scalability | {0-2} | {detail} |
| Startup/Shutdown | {0-2} | {detail} |
| Observability | {0-2} | {detail} |
| Service Boundaries | {0-2} | {detail} |

## Existing Docker Artifacts
- {inventory or "None found"}

## Recommendation
- {next steps}

支持资源

• 部署资格：knowledge/deployment-eligibility.md — 支持的工作负载类型和失败时关闭的路由策略
• 评估标准：knowledge/criteria.md — 详细的评分规则
• 反模式：knowledge/anti-patterns.md — 常见的云原生反模式
• 示例：examples/ — 就绪度报告示例

与 dockerfile-skill 集成

路由到 dockerfile-skill 时，请传递评估上下文：

1. 就绪情况报告中的发现会影响 Dockerfile 生成决策
2. 检测到的外部服务直接对应 docker-compose.yml 中的服务
3. 识别出的问题会成为 Dockerfile 注释或 DOCKER.md 中的注意事项
4. 评估中关于配置外置的发现会决定 ENV/ARG 设置

交接：调用 dockerfile-skill 时，请附上以下内容的摘要：

• 检测到的语言、框架和包管理器
• 外部服务依赖
• 配置外置状态
• 任何特殊问题（有状态组件、启动时间较长等）