为任意 GitHub 项目生成生产级 Dockerfile…

当需要把应用容器化、生成或修复 Dockerfile、编写 .dockerignore、解决 Docker 构建问题时使用。

适用场景

解决思路

1. 接受本地路径或 GitHub URL 作为输入，可选接收来自 cloud-native-readiness 的就绪报告；只分析和写入指定的打包产物（Dockerfile、.dockerignore、可选的 compose/entrypoint/文档和部署侧构建证据），默认保留已有文件和项目原有取值，替换已有文件需先记录明确的请求决策再改动。
2. 按四阶段流程执行：Deep Analysis（深度分析）→ Generate（生成）→ Build & Fix（构建与修复）→ Runtime Validation（运行时验证）；每个请求输出 request-scoped 的 success、stopped 或 error 状态。
3. Phase 1 深度分析：读取并执行 modules/analyze.md，产出结构化项目元数据，包括语言/框架/包管理器、构建命令/运行命令/端口、外部依赖（DB/Redis/S3）、系统库需求、迁移系统检测（ORM、迁移数量、执行方式）、构建复杂度分析（重操作、内存风险）以及复杂度等级（L1/L2/L3）。
4. Phase 2 生成：读取并执行 modules/generate.md，基于 Phase 1 的分析结果产出 Dockerfile（含迁移处理和构建优化）、.dockerignore（感知 workspace）、docker-compose.yml（如需外部服务）、.env.docker.local（仅可选占位键，绝不写真实密钥值）、docker-entrypoint.sh（含迁移执行）、DOCKER.md（完整部署指南）以及环境变量文档。
5. Phase 3 构建验证（闭环）：读取并执行 modules/build-fix.md，运行 docker buildx build --platform linux/amd64 --load；成功则进入 Phase 4，失败则解析错误、匹配错误模式、修复 Dockerfile 后重试；最大迭代次数按复杂度等级：L1 为 1 次、L2 为 3 次、L3 为 5 次。
6. Phase 4 运行时验证：执行 docker-compose up -d 并确认容器无崩溃；若检测到迁移，用 psql -c "\dt" 查询数据库确认表已创建、迁移数量与预期一致（如 76/76）、无 "relation does not exist" 错误；测试 HTTP 端点，200/302/401 可接受，500 为失败；检查日志中的错误并验证健康检查端点；只有全部通过才可声明成功。
7. 支持 workspace/monorepo：识别 pnpm workspace、Turborepo、npm workspaces。
8. 自动检测自定义构建 CLI（turbo、nx、lerna、rush 或项目专用）并使用正确语法。
9. 检测并处理需要 git commit hash（GITHUB_SHA）的项目，例如设置 ENV GITHUB_SHA=docker-build 绕过 git 依赖。
10. 自动检测并添加构建时环境变量占位符（用于 Next.js SSG）。
11. 使用 40+ 已知错误模式数据库自动匹配并修复构建错误。
12. 生成智能 .dockerignore，避免排除 workspace 必需文件和 CLI 配置依赖（如用 e2e/* 而非 e2e，再配合 !e2e/package.json）。
13. 支持自定义入口点（自定义 server 启动器）。
14. 自动检测 ORM 与迁移，处理 standalone 模式（standalone + ORM 时单独安装 ORM 依赖并复制到最终镜像）。
15. 构建优化：跳过重量级 CI 任务（lint/type-check）以防 OOM，必要时将 NODE_OPTIONS 提升到 8192MB。
16. 自动检测 Rust/NAPI-RS 原生模块并支持多架构构建。
17. 检测后端期望的静态资源路径并映射前端产物（如把前端输出复制到后端期望路径）。
18. 自动检测外部服务依赖：PostgreSQL、Redis、MinIO、ManticoreSearch。
19. 零人工交互：自动生成所有配置文件（包括密钥占位）。
20. 处理常见问题：迁移未执行（standalone + ORM 单独装依赖、在 entrypoint 中加运行时迁移、启动后用 psql -c "\dt" 验证）；构建 OOM（跳过 CI 任务、提高 NODE_OPTIONS）；workspace 文件找不到（修正 .dockerignore）；lockfile=false 项目（用 pnpm install 而非 pnpm install --frozen-lockfile）；构建时环境变量缺失（在 build 阶段加 ARG/ENV 占位）；Node 二进制路径（RUN ln -sf /usr/local/bin/node /bin/node）；standalone 模式找不到 ORM（在 /deps 单独安装并复制）；monorepo 自定义 CLI 构建命令错误（使用检测到的 CLI 语法）；CLI 配置文件被 .dockerignore 排除（从排除项中移除 .prettierrc、.prettierignore 等）；静态资源运行时找不到（在 Dockerfile 中复制到后端期望路径）。
21. 构建后执行完整验证脚本：docker-compose up -d 后 sleep 30，docker-compose ps 确认全部 UP 且 HEALTHY，按需用 psql 列出表并统计迁移数量，用 curl -s -o /dev/null -w "%{http_code}" 测试 HTTP 状态码，docker-compose logs app | grep -i "error" 检查日志，docker images 检查镜像大小，最后 docker-compose down 清理。
22. 验证辅助脚本用 node --check，并运行基线用例 dockerfile-positive-build-runtime 和 dockerfile-violating-build-only，验证实际容器行为、迁移、HTTP、日志、文件范围和脱敏。
23. 输出打包结果契约：包含 source、owned_files、build（dockerfile_valid、image_identity 脱敏后的 tag 或 digest、result_artifact: docker-build/build-result.json）、runtime（migration、database_or_state_proof、http_health、log_analysis、result_artifact: docker-build/validation-result.json）、verification（redaction、helper_checks）、terminal_state、safe_next_action；结果中绝不包含密码、token、环境变量值、数据库 URL 或完整连接串。
24. 向 sealos-deploy 交接时发送完整类型化 handoff：target、inputArtifact（已验证的 Dockerfile 及带来源溯源的构建/运行结果）、allowedAction（在选定部署范围内构建或复用镜像）、failureReturn（失败的打包、迁移、HTTP、健康或运行时日志阶段）、responseOwner: dockerfile-skill。
25. 成功标准：构建阶段无错误退出、镜像大小合理（多数应用 < 2GB）、遵循生产最佳实践（多阶段、非 root、固定版本）、包含全部必要支持文件、处理所有 workspace/monorepo 需求；运行时阶段容器成功启动、迁移成功执行、数据库表已创建、应用返回有效 HTTP 码、日志无运行时错误；构建通过但运行时失败、迁移检测到但表缺失、应用返回 500、日志出现数据库 relation 错误时不得声明成功。

适用边界 · 注意事项

• 不要把 docker build 成功当作运行时验收；缺少迁移/表、HTTP、健康或日志证据时不能声明成功。
• 不要在报告或结果中泄露密钥、环境变量值、数据库 URL 或完整连接串。
• 不要在没有明确请求决策记录的情况下替换已有文件或安装系统级依赖。