#16707: Claude/review deployment setup wbbcc

## Summary Describe the problem and fix in 2–5 bullets: - Problem: - Why it matters: - What changed: - What did NOT change (scope boundary): ## Change Type (select all) - [ ] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes # - Related # ## User-visible / Behavior Changes List user-visible changes (including defaults/config). If none, write `None`. ## Security Impact (required) - New permissions/capabilities? (`Yes/No`) - Secrets/tokens handling changed? (`Yes/No`) - New/changed network calls? (`Yes/No`) - Command/tool execution surface changed? (`Yes/No`) - Data access scope changed? (`Yes/No`) - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: - Runtime/container: - Model/provider: - Integration/channel (if any): - Relevant config (redacted): ### Steps 1. 2. 3. ### Expected - ### Actual - ## Evidence Attach at least one: - [ ] Failing test/log before + passing after - [ ] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: - Edge cases checked: - What you did **not** verify: ## Compatibility / Migration - Backward compatible? (`Yes/No`) - Config/env changes? (`Yes/No`) - Migration needed? (`Yes/No`) - If yes, exact upgrade steps: ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: - Files/config to restore: - Known bad symptoms reviewers should watch for: ## Risks and Mitigations List only real risks for this PR. Add/remove entries as needed. If none, write `None`. - Risk: - Mitigation: <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR improves the Docker multi-arch manifest creation in `docker-release.yml` but introduces critical deployment breakage in `fly.toml` and adds a problematic scheduled workflow. **Key changes:** - Fixes `docker-release.yml` manifest creation by using digest references instead of tag references and properly isolating arch-specific tags - Adds `scheduled-build.yml` that builds amd64-only images every 6 hours and pushes to `:main` and `:latest` tags - Replaces generic `fly.toml` template with a personal app configuration (`openclaw-terylg`) **Critical issues:** - `fly.toml` now contains a personal deployment config that removes all essential runtime configuration (environment variables, process commands, mounts, correct port). Previous comments have detailed these breakages. - `scheduled-build.yml` overwrites multi-arch manifests with amd64-only images every 6 hours, breaking arm64 support for `:main` and `:latest` tags - PR description is completely empty - all required sections (summary, change type, scope, security impact, verification, etc.) are unfilled <h3>Confidence Score: 1/5</h3> - This PR contains deployment-breaking changes and should not be merged without significant revisions - Score of 1 reflects multiple critical issues: (1) `fly.toml` replacement breaks all Fly.io deployments by removing runtime config, using wrong port, and hardcoding personal app name, (2) scheduled workflow continuously breaks multi-arch Docker support by overwriting manifests with amd64-only images, (3) completely empty PR description violates submission requirements. The `docker-release.yml` changes are correct, but cannot outweigh the deployment breakages. - `fly.toml` and `.github/workflows/scheduled-build.yml` require complete rewrites before this can be merged _{Last reviewed commit: 9944f71} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->