Iron rule: Do not directly change deployment configuration before confirming the runtime environment, environment variables, and rollback path.
Workflow
- Step 1: Identify the deployment target ⚠️ REQUIRED
- 1.1 Clarify the target platform, build command, run command, and artifact form.
- 1.2 Inventory the required environment variables, secrets, and external services.
- Step 2: Align with the current configuration ⚠️ REQUIRED
- 2.1 Read package.json, relevant configuration files, and existing workflows.
- 2.2 Identify single points of failure and platform assumptions in the current process.
- Step 3: Implement changes
- 3.1 When modifying containers, builds, deployments, or CI processes, keep responsibilities clearly layered.
- 3.2 Explicitly handle caching, concurrency, artifacts, and failure exit codes.
- 3.3 Do not write secrets into the repository or logs.
- Step 4: Verify and roll back
- 4.1 Run a local build or minimal verification command whenever possible.
- 4.2 Output the required environment variables, risk points, and rollback method.
Focus points
- Whether the build command matches the actual script.
- Whether environment variables are clearly defined and defaults are safe.
- Whether there is obvious waste or instability in images, caching, and dependency installation.
- Whether CI can provide sufficient logs and clear status on failure.
Project-specific tips
- Dockerfile and docker-compose.yml should be considered together; do not change only one side of the configuration.
- If the project uses a .env template or a runtime configuration entry such as runtimeConfig, prefer following the existing pattern.
- Deployment configurations for Vercel, Cloudflare, and GitHub Actions must stay consistent with the real scripts in package.json.
- When pursuing a minimal image, also balance debugging usability and build stability.
Anti-patterns
- Changing a workflow without checking the real scripts in package.json.
- Writing secrets, tokens, or production addresses into configuration files for speed.
- Fixing only the current platform without explaining the impact on other deployment targets.
Pre-delivery checklist
- The target platform, build process, and environment variables have been aligned.
- No hardcoded secrets or dangerous default values have been introduced.
- Minimal verification steps and rollback tips have been provided.
- Configuration changes and script commands remain consistent.