Flutter CI/CD

Build a reproducible pipeline around the repository's existing delivery model. Preserve the current provider, Flutter version source, package manager, flavors, signing flow, and deployment tooling unless migration is explicitly requested.

Preflight

Read pubspec.yaml, lockfiles, SDK/version-manager files, workspace layout, generated-code policy, flavors, tests, native targets, existing pipeline files, repository scripts, release tooling, protected environments, and secret names before writing pipeline changes. Inspect the actual job dependency graph and recent timing/failure output when diagnosing reliability or speed. When repository evidence is unavailable, request or list the exact files and logs required and keep advice at the invariant level; do not present a placeholder workflow as a completed repair. Never print, move, synthesize, or commit signing material or service credentials.

Separate pull-request confidence from release authority. A passing CI job may prove checks and artifact creation; it does not authorize tagging, store upload, production deployment, or credential changes.

Route the work

• For deterministic format, analysis, generation, test, coverage, golden, matrix, and cache gates, read quality gates.
• For signing, secrets, artifacts, symbols, protected environments, staged rollout, and publication boundaries, read delivery and secrets.
• For GitHub Actions, GitLab CI, Codemagic, Bitrise, Xcode Cloud, monorepos, and provider-preserving decisions, read provider and monorepo.

Load only the references needed by the current pipeline.

Boundaries