CI blow up

[0xjei]

Context

The CI configuration has grown into a large, manually coordinated system. The main workflow (.github/workflows/ci.yml) contains 22 jobs and about 1,400 lines. The repository also has separate workflows for the agent harness, license headers, PR size, PR titles, Docker builds, branch cleanup, and releases.

This issue is for a general CI refactoring discussion. It does not prescribe an immediate rewrite.

Current concerns

• Change detection is manually maintained through many path filters and boolean job outputs. Some shared inputs, such as root manifests, lockfiles, build scripts, and configuration files, are not obviously covered by the relevant filters.
• There is no single required CI gate that represents the complete merge decision. Branch protection must depend on many independent job and workflow statuses.
• Tool setup is repeated across jobs for Rust, Node, pnpm, Foundry, solc, Nargo, Barretenberg, and system packages.
• Local pre-push checks and CI checks are split across multiple workflows and are not fully consistent.
• PR title and commit-message rules differ between the local hook, workflow configuration, and contributor documentation.
• Release jobs have broad dependencies and failure handling that should be reviewed. In particular, some publication jobs use continue-on-error, while release creation does not require every publication job to succeed.
• Pull-request Docker workflows and workflow-level package permissions should be reviewed to avoid unnecessary registry writes.
• Action references are pinned to commit SHAs in the main CI workflow but use mutable version tags in several other workflows.

Refactoring goals

• Keep fast feedback for focused pull requests.
• Preserve full coverage for protocol, contract, circuit, proof, integration, template, and release paths.
• Make the change-impact rules explicit and difficult to under-classify.
• Provide one stable required status for branch protection.
• Reduce repeated environment setup and workflow-specific shell logic.
• Make release publication fail closed and prevent partial releases.
• Keep security-sensitive permissions scoped to the jobs that need them.
• Keep expensive cryptographic and end-to-end tests isolated from fast checks.

Candidate direction

• Define a small always-running validation gate for policy, formatting, manifests, and change classification.
• Replace the large manual boolean output list with a central impact matrix or reusable change-classification workflow.
• Add shared handling for root manifests, shared scripts, workflow changes, and build configuration.
• Extract repeated tool installation and cache setup into composite actions or reusable workflows.
• Separate pull-request checks from nightly, scheduled, and release-only verification.
• Add an explicit aggregate job that fails when any required lane fails and is the only required branch-protection status.
• Unify PR title and commit validation around one versioned configuration.
• Review Docker push behavior, action pinning, and permissions across every workflow.
• Define release invariants and require all mandatory artifacts and publication jobs to succeed before creating a release.

Suggested first step

Map every current job to its purpose, trigger, change inputs, dependencies, artifacts, timeout, required status, and expected execution frequency. Use that map to identify missing coverage and duplicated setup before changing workflow structure.