在容器化或部署前评估仓库是否适合云原生改造（含 0-12…

当你需要判断一个仓库能否容器化/上 Kubernetes、是否已有 Docker 产物、以及下一步该不该生成 Dockerfile 时使用。

适用场景

解决思路

1. 接受本地路径或 GitHub URL 作为输入，检查仓库证据；只做只读评估，不写入项目文件，也不对不受支持的目标打分。
2. 在首次打分前先加载 knowledge/deployment-eligibility.md，执行资格判定；若工作负载不受支持或无法判定，则在产物检测、打分、生成 Dockerfile 或部署之前停止（fail-closed）。
3. 按三阶段工作流执行：Phase 1 Assess（先拒绝不受支持的工作负载类型，再对合格目标打分）→ Phase 2 Detect（检查是否已存在 Docker 产物）→ Phase 3 Route（已有产物则直接返回结果，否则调用 dockerfile-skill 容器化）。
4. 在对应阶段到达时，按一层深度加载 modules/assess.md、modules/detect.md、modules/route.md；资格停止后不要加载 Dockerfile 细节或触发交接。
5. Phase 1 对合格目标按 6 个维度各打 0-2 分：Statelessness（是否本地存状态，如内存会话、本地文件写入）、Config Externalization（配置是硬编码还是由环境变量/配置文件驱动）、Horizontal Scalability（多实例并行是否冲突）、Startup/Shutdown（启动是否快、是否优雅处理 SIGTERM）、Observability（健康检查、结构化日志、指标）、Service Boundaries（是聚焦服务还是紧耦合单体）。
6. 按总分给出评级：10-12 优秀、完全云原生就绪；7-9 良好、小幅调整即可；4-6 一般、容器化前需部分重构；0-3 差、需大量返工，当前不建议容器化。
7. Phase 2 检测已有产物：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），并输出产物清单及质量评估。
8. Phase 3 按决策矩阵路由（仅对 eligible 目标）：分数 ≥7 且产物完整 → 报告现有配置，结束；≥7 且产物部分 → 报告缺口并建议改进，结束；≥7 且无产物 → 调用 dockerfile-skill 生成；4-6 任意 → 报告问题与修复步骤，可选继续调用 dockerfile-skill；0-3 任意 → 报告阻塞项，禁止调用 dockerfile-skill。
9. 最终输出必须使用规定的 Readiness Report 格式：Summary（项目、资格与工作负载类型、分数/12 与评级、结论）、Assessment Details（✅ 优势 / ⚠️ 关注点 / ❌ 阻塞项）、Dimension Scores 六维评分表、Existing Docker Artifacts、Recommendation。
10. 资格停止时只报告工作负载类型、原因码、证据与下一步动作，不要编造就绪度分数。
11. 报告中保持源码路径、环境变量值和任何凭据脱敏；payload 绝不包含密码、token、kubeconfig 内容、环境变量值或完整连接字符串。
12. 请求以 success、stopped 或 error 结束，每种结果都携带所选来源、工作负载类型、脱敏状态与所达到的最强证据；success 还需包含评分维度、产物清单、关注点、建议、验证证据与类型化交接。
13. 当合格且路由需要打包时，向 dockerfile-skill 发送类型化交接：inputArtifact 为含来源、语言/框架/包管理器、依赖/配置、工作负载、分数、维度、关注点与产物清单的就绪度报告；allowedAction 为在接收方自有文件范围内生成 Docker 打包；failureReturn 为就绪度发现与失败的路由条件；responseOwner 为 cloud-native-readiness。
14. 交接时附上摘要：检测到的语言/框架/包管理器、外部服务依赖、配置外化状态、特殊关注点（有状态组件、长启动等）；就绪度报告发现用于指导 Dockerfile 生成，检测到的外部服务直接映射为 docker-compose.yml 服务，关注点转为 Dockerfile 注释 / DOCKER.md 注意事项，配置外化发现驱动 ENV/ARG 设置。
15. 用 workload-eligibility.mjs、score-model.mjs、当前就绪度评估证据以及基线轨迹 readiness-positive-eligible 和 readiness-violating-ineligible 做验证；先验证资格再打分/构建，保留报告字段，并对形似凭据的值脱敏。

适用边界 · 注意事项

• 工作负载不受支持或资格无法判定（needs_review）时——必须在产物检测、打分、Dockerfile 生成或部署前停止。
• 就绪度分数为 0-3 时——只报告阻塞项，不要调用 dockerfile-skill。
• 仅做独立就绪度评估时——报告保留在请求结果中，不要创建 .sealos/analysis.json，也不要写入项目文件。