cpflow 5.3.0 → 6.0.0

data/CHANGELOG.md

@@ -12,6 +12,43 @@ In addition to the standard keepachangelog.com categories, this project uses a l
 
 ## [Unreleased]
 
+## [6.0.0] - 2026-10-08
+
+### Breaking Changes
+
+- BREAKING CHANGE: Raised the minimum supported Ruby version from 3.0 to 3.2. Users on Ruby 3.0 or 3.1 must upgrade Ruby before installing the next major cpflow release. CI now tests each supported Ruby minor from 3.2 through 3.4. [PR 464](https://github.com/shakacode/control-plane-flow/pull/464) by [Justin Gordon](https://github.com/justin808).
+
+### Added
+
+- **Production promotion runs show a staging comparison against the last recorded production release before production approval, with up to 100 commit subjects and explicit notices for missing provenance or diverged history.** After approval, promotion stops if staging changed or live production differs from the preview’s release baseline. [PR 500](https://github.com/shakacode/control-plane-flow/pull/500) by [Justin Gordon](https://github.com/justin808).
+- **Review apps can opt in to generated disposable credentials.** Each PR app gets its own tagged secret dictionary and policy; setup fills only missing keys after checking both resource markers and policy scope, and app deletion removes the resources after checking their bindings and target, including after partial deletion or opt-in removal. Cleanup probes the deterministic per-app resource names for every dynamically matched review app so removed opt-ins can still be reconciled; a provider read failure, unexpected grant, or unmarked name collision now fails the delete step for inspection instead of silently succeeding. [PR 483](https://github.com/shakacode/control-plane-flow/pull/483) by [Justin Gordon](https://github.com/justin808).
+- **Staging and review-app Docker builds accept optional credentials through BuildKit secret mounts.** Set `DOCKER_BUILD_SECRETS` for staging and `REVIEW_APP_DOCKER_BUILD_SECRETS` for review apps; review builds never receive the staging secret. Credential values stay out of build arguments, and temporary files are removed after success or failure. Deployment callers can append build arguments through the `docker_build_extra_args` workflow input. [PR 503](https://github.com/shakacode/control-plane-flow/pull/503) and [PR 505](https://github.com/shakacode/control-plane-flow/pull/505) by [Alexey Romanov](https://github.com/alexeyr-ci6).
+
+### Changed
+
+- **Bumped the pinned GitHub Actions in the generated production-promotion workflow and this repository's reusable workflows to `actions/checkout` 7.0.1, `actions/github-script` 9.0.0, and `docker/setup-buildx-action` 4.3.0.** Downstream repositories pick up the template change with `cpflow update-github-actions`. [PR 460](https://github.com/shakacode/control-plane-flow/pull/460) by [Justin Gordon](https://github.com/justin808). Fixes [issue 459](https://github.com/shakacode/control-plane-flow/issues/459).
+- **Changed generated GitHub Actions to check in cpflow's composite actions under `.github/actions/cpflow-*` and refresh them with `cpflow update-github-actions`.** Reusable workflows now load those local actions from the caller repository's trusted event revision, while the separately pinned checkout at `.cpflow` supplies the cpflow runtime source. Downstream repositories must commit generated workflows and local actions together when upgrading. [PR 451](https://github.com/shakacode/control-plane-flow/pull/451) by [Justin Gordon](https://github.com/justin808). Part of [issue 375](https://github.com/shakacode/control-plane-flow/issues/375).
+- **Made `update-github-actions` preserve downstream workflows by default and require explicit `--workflows` selection to add or replace them.** Ambiguous staging configuration and differing legacy validators fail before writes. Downstream checks can use the preserved `bin/test-cpflow-github-flow-custom` extension. SHA pins require a reviewed `--version` label, and the migration guide documents generated action allowlists. [PR 476](https://github.com/shakacode/control-plane-flow/pull/476) by [Justin Gordon](https://github.com/justin808). Fixes [issue 473](https://github.com/shakacode/control-plane-flow/issues/473).
+- **Trimmed the RubyGems post-install message to a three-line generated-workflow reminder with a link to the full update and validation instructions.** [PR 447](https://github.com/shakacode/control-plane-flow/pull/447) by [Justin Gordon](https://github.com/justin808). Fixes [issue 377](https://github.com/shakacode/control-plane-flow/issues/377).
+
+### Fixed
+
+- **Fixed the generated `bin/pin-cpflow-github-ref` helper so `-h` and `--help` print usage and exit successfully before inspecting repository state.** [PR 474](https://github.com/shakacode/control-plane-flow/pull/474) by [Justin Gordon](https://github.com/justin808). Fixes [issue 473](https://github.com/shakacode/control-plane-flow/issues/473).
+- **Kept no-argument releases pinned to the latest changelog version during retries, and blocked implicit prerelease-to-stable promotion.** If an interrupted release already bumped the gem version or created its tag, rerunning `bundle exec rake release` no longer falls through to a stable release that is absent from the changelog. [PR 472](https://github.com/shakacode/control-plane-flow/pull/472) by [Justin Gordon](https://github.com/justin808).
+- **Loaded the caller's generated `.github/actions/cpflow-*` through `actions/checkout`'s trusted default in the reusable review-app deploy, delete, and stale-cleanup workflows.** Dropping the explicit `ref:` still resolves to the revision GitHub already recorded for the triggering event (`GITHUB_SHA`, the base-branch tip under `pull_request_target`), and a default checkout is never inspected by the fork-PR checkout guard added in `actions/checkout` 7.0.0. The previous explicit `github.event.pull_request.base.sha` pin in the delete workflow could trip that guard, and fail teardown, when a fork PR was closed by a manual fast-forward that left the recorded base SHA equal to the PR head. Review-app teardown consequently runs the base-tip copy of the generated actions rather than the pull request's recorded pre-merge base, which matters only if the merge itself changed those actions. Downstream repositories pick up the change when `cpflow update-github-actions` bumps the reusable-workflow ref. [PR 467](https://github.com/shakacode/control-plane-flow/pull/467) by [Justin Gordon](https://github.com/justin808). Fixes [issue 463](https://github.com/shakacode/control-plane-flow/issues/463).
+- **Gave `pull_request_target` an explicit branch in the reusable review-app deploy source validator.** The reusable workflow's event allowlist admits `pull_request_target`, but the deploy source validator handled only `pull_request` and `issue_comment`. It now treats `pull_request_target` exactly like `pull_request`, skipping fork pull requests with the documented deploy-skipped summary, as defence-in-depth for callers that rewire the deploy trigger. The shipped caller templates never send that event, so no existing deployment behavior changes and same-repository pull requests are unaffected. [PR 467](https://github.com/shakacode/control-plane-flow/pull/467) by [Justin Gordon](https://github.com/justin808). Fixes [issue 462](https://github.com/shakacode/control-plane-flow/issues/462).
+- **Prevented shell interpretation of dynamic Control Plane CLI and Docker arguments.** Resource names, image references, container names, locations, and other dynamic values now remain literal argv elements; output suppression and stderr capture use process redirection options without rebuilding a shell command. Fixes [issue 452](https://github.com/shakacode/control-plane-flow/issues/452). [PR 458](https://github.com/shakacode/control-plane-flow/pull/458) by [Justin Gordon](https://github.com/justin808).
+- **Fixed scheduled slow-suite regressions in stale-app workload suspension, invalid upstream-token handling, transient workload image deployment, and delayed one-off job output.** `cleanup-stale-apps --mode=stop` now skips configured workloads absent from a stale app, upstream authorization failures cleanly remove their temporary profile and stderr capture, workload image updates retry for a bounded window before failing, and non-interactive `cpflow run` commands drain logs for a bounded post-terminal window so delayed ingestion does not drop completed job output. Slow-suite command logs and failure artifacts now redact token options and explicitly supplied sensitive values. [PR 413](https://github.com/shakacode/control-plane-flow/pull/413) by [Justin Gordon](https://github.com/justin808). Addresses [issue 409](https://github.com/shakacode/control-plane-flow/issues/409).
+- **Queued every pending shared-org Slow and Specific RSpec run instead of letting GitHub replace an older waiter.** Fast runs keep their per-PR or per-ref queue, while the domain-mutating suites use GitHub's bounded `queue: max` behavior in one repository-wide concurrency group. [PR 457](https://github.com/shakacode/control-plane-flow/pull/457) by [Justin Gordon](https://github.com/justin808). Fixes [issue 403](https://github.com/shakacode/control-plane-flow/issues/403).
+- **Bounded `cpflow run` status reconciliation after a non-interactive command finishes.** When Control Plane keeps reporting a cron job as active or pending after the command completion marker, `cpflow run` now waits up to a configurable 20-minute grace period and then exits nonzero with the job, replica, and last observed status instead of polling forever. Addresses the bounded-reconciliation portion of [HiChee issue 10375](https://github.com/shakacode/hichee/issues/10375). [PR 453](https://github.com/shakacode/control-plane-flow/pull/453) by [Justin Gordon](https://github.com/justin808).
+- **Deleting a disposable review app removes PostgreSQL helper secrets and their access policy when newly generated templates marked them as app-owned.** Cleanup validates secret types, exact policy targets, and app-only grants, supports partial deletion without the GVC, and preserves unmarked legacy helpers. [PR 502](https://github.com/shakacode/control-plane-flow/pull/502) by [Justin Gordon](https://github.com/justin808).
+- **Production promotion now reports the healthy production endpoint as its GitHub deployment URL, so GitHub shows a "View deployment" link for it.** Existing generated workflows that declare `environment: production` as a plain string still pass `bin/test-cpflow-github-flow`; regenerate to get the link. [PR 495](https://github.com/shakacode/control-plane-flow/pull/495) by [Justin Gordon](https://github.com/justin808).
+- **Hardened generated Rails deployment scaffolding and production promotion.** New scaffolds omit repository secrets, Rails credential keys, and local databases from Docker contexts, remove temporary native build tools, avoid retaining asset-precompile secrets, persist every detected production SQLite database without hiding image migrations, and support digest-pinned staging images during promotion. Production promotion now requires a full staging commit SHA, targets the GitHub release at that commit, and only attempts rollback after deployment starts. [PR 488](https://github.com/shakacode/control-plane-flow/pull/488) by [Justin Gordon](https://github.com/justin808).
+
+### Security
+
+- **Hardened generated Docker builds that use SSH private dependencies.** Private keys now enter `ssh-agent` through standard input instead of being persisted between composite-action steps, invocation-local cleanup runs even when execution stops before the build, and pre-existing `known_hosts` state is preserved across success and failure. [PR 477](https://github.com/shakacode/control-plane-flow/pull/477) and [PR 478](https://github.com/shakacode/control-plane-flow/pull/478) by [Justin Gordon](https://github.com/justin808). Fixes [issue 473](https://github.com/shakacode/control-plane-flow/issues/473).
+
 ## [5.3.0] - 2026-09-02
 
 ### Added
@@ -474,7 +511,8 @@ Deprecated `cpl` gem. New gem is `cpflow`.
 
 First release.
 
-[Unreleased]: https://github.com/shakacode/control-plane-flow/compare/v5.3.0...main
+[Unreleased]: https://github.com/shakacode/control-plane-flow/compare/v6.0.0...HEAD
+[6.0.0]: https://github.com/shakacode/control-plane-flow/compare/v5.3.0...v6.0.0
 [5.3.0]: https://github.com/shakacode/control-plane-flow/compare/v5.2.0...v5.3.0
 [5.2.0]: https://github.com/shakacode/control-plane-flow/compare/v5.1.1...v5.2.0
 [5.1.1]: https://github.com/shakacode/control-plane-flow/compare/v5.1.0...v5.1.1

data/CONTRIBUTING.md

@@ -35,6 +35,43 @@ gem install overcommit
 overcommit --install
 ```
 
+## GitHub Actions Dependencies
+
+Every repository-based external `uses:` entry under `.github/workflows/` or `.github/actions/` must use an immutable,
+lowercase 40-character commit SHA followed by the exact release tag in a same-line comment. Do not use moving
+major-version tags or branch names. New action repositories also require explicit review before they are added to
+`trusted_actions` in `.agents/trusted-actions.yml`. Docker actions must use an exact `sha256:` image digest; manually
+review the registry, image, and digest because Docker references are outside the repository allowlist.
+Generated downstream calls to Control Plane Flow's cross-repository reusable workflows are the deliberate exception:
+they use an exact `vX.Y.Z` release tag so the workflow source stays aligned with the released `cpflow` gem.
+
+Dependabot checks GitHub Actions dependencies weekly. For each proposed update, verify that the release tag resolves to
+the proposed commit, review the upstream release and diff, and keep the version comment synchronized with the pin.
+Dependabot-authored runs receive no repository secrets, so `RSpec (Fast)` fails at `Setup Control Plane tools`. The
+credential-free `Ruby 3.3 compatibility` and `Ruby 3.4 compatibility` jobs do run
+`spec/github_actions_dependency_policy_spec.rb`, so a bump that leaves the generated templates or the
+`EXPECTED_CPFLOW_CHECKOUT_ACTION` constant behind still fails there, even on a Dependabot-authored pull request that
+cannot run the credentialed suite. A Dependabot bump is therefore never merged directly: a maintainer opens a pull
+request that supersedes it and lands the same pin. That maintainer pull request must update the pin in all four places,
+or CI fails:
+
+- `.github/workflows/**` and `.github/actions/**` — the workflows that actually run in this repository.
+- `lib/github_flow_templates/.github/workflows/**` — the workflows generated into downstream repositories.
+- `lib/github_flow_templates/bin/test-cpflow-github-flow` — the `EXPECTED_CPFLOW_CHECKOUT_ACTION` constant.
+- `spec/command/generate_github_actions_spec.rb` and `spec/github_workflows_spec.rb` — the assertions that hard-code
+  the expected SHA.
+
+`spec/github_actions_dependency_policy_spec.rb` guards the first three. It fails when a template occurrence's commit
+SHA or version comment drifts from the repository pin for the same action, when a template `uses:` entry is left on a
+mutable ref such as `@v7` or `@main`, or when a template pins an external action that the repository workflows do not
+use. Only script constants such as `EXPECTED_CPFLOW_CHECKOUT_ACTION` and `docker://` image references may omit the
+version comment, because neither is a workflow step with somewhere to hang a same-line release tag. Calls to cpflow's
+own reusable workflows under `.github/workflows/` are the one exception to the commit-pin rule, and only for the
+`@__CPFLOW_GITHUB_ACTIONS_REF__` generator placeholder or an exact release tag. `@main` and `@v5` fail, and so does any
+other `shakacode/control-plane-flow` reference, such as `shakacode/control-plane-flow/some-action@v6.0.0` or the bare
+repository, which must be commit-pinned like any external action. The literal `vX.Y.Z` is accepted only in the verifier
+script's `EXPECTED_PROMOTE_WORKFLOW_REF_FORMAT` constant, never in a workflow step.
+
 ## Docs Site Dispatch
 
 The `trigger-docs-site.yml` workflow notifies `shakacode/controlplaneflow-com` when docs-related files change on `main`.
@@ -113,9 +150,9 @@ cpflow test
 
 ## Developing the GitHub flow generator
 
-`cpflow generate-github-actions` copies templates from `lib/github_flow_templates/` into a target repo's `.github/` directory. To work on this feature:
+`cpflow generate-github-actions` copies workflow templates in `lib/github_flow_templates/` and canonical composite actions in `.github/actions/cpflow-*` into a target repo's `.github/` directory. To work on this feature:
 
-- **Edit the templates in place.** The generator does no string-mangling beyond a small set of substitutions handled in `lib/command/generate_github_actions.rb`; what you put in `lib/github_flow_templates/.github/` is (almost) exactly what ships into a generated repo. Make changes there, not in a generated copy.
+- **Edit each canonical source in place.** The generator does no string-mangling beyond a small set of substitutions handled in `lib/command/generate_github_actions.rb`; what you put in `lib/github_flow_templates/.github/` is (almost) exactly what ships into a generated repo. Edit composite actions in the root `.github/actions/cpflow-*` directories. Make changes in those canonical sources, not in a generated copy.
 - **Surface area to keep consistent.** A change to a PR command (e.g. `+review-app-deploy`) usually touches three places: the trigger workflow (`lib/github_flow_templates/.github/workflows/cpflow-deploy-review-app.yml`), the PR-open quick reference (`cpflow-review-app-help.yml`), and the long-form help (`lib/github_flow_templates/.github/cpflow-help.md`). The AI flow prompt (`lib/command/ai_github_flow_prompt.rb`) also names commands and should be kept in sync.
 - **Run the generator spec on every change:**
 

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    cpflow (5.3.0)
+    cpflow (6.0.0)
       dotenv (~> 3.1)
       jwt (~> 3.1)
       psych (~> 5.2)

data/README.md

@@ -29,7 +29,7 @@ _If you need a free demo account for Control Plane (no CC required), you can con
 To bootstrap a new project, run three commands from the repo root:
 
 1. **`cpflow github-flow-readiness`** — gate for common rollout blockers (missing Rails runtime scaffold, legacy Ruby or Bundler toolchains, unpublished exact-pinned gems or npm packages, missing production Dockerfiles). Exits non-zero on any blocker.
-2. **`cpflow generate`** — creates `.controlplane/` scaffolding. Infers the app prefix from the repo directory, the base Ruby version from `.ruby-version`/`.tool-versions`/`Gemfile`, the JS package manager from `package.json`, repo-defined frontend precompile hooks (Shakapacker `precompile_hook`, React on Rails auto bundle generation), and switches to persistent `db` + `storage` volume templates when `config/database.yml` shows SQLite in production.
+2. **`cpflow generate`** — creates `.controlplane/` scaffolding and a safe root `.dockerignore` when one is missing. It infers the app prefix from the repo directory, the base Ruby version from `.ruby-version`/`.tool-versions`/`Gemfile`, the JS package manager from `package.json`, repo-defined frontend precompile hooks (Shakapacker `precompile_hook`, React on Rails auto bundle generation), and switches to persistent SQLite data + Active Storage volume templates when `config/database.yml` shows SQLite in production.
 3. **`cpflow generate-github-actions`** — adds the reusable GitHub Actions pipeline for review apps, staging deploys, and manual production promotion.
 
 The generated scaffold is a starting point. After generation, adapt `.controlplane/` for app-specific workloads (Sidekiq, Node renderer), wire any private-dependency Docker build settings (SSH key, optional known-host overrides), and verify that the production Docker build succeeds.
@@ -307,6 +307,11 @@ aliases:
     # If not specified, defaults to 21600 (6 hours).
     runner_job_timeout: 1000
 
+    # Sets how long `cpflow run` waits for Control Plane to reconcile a cron job status
+    # after the non-interactive command prints its completion marker.
+    # If not specified, defaults to 1200 (20 minutes).
+    runner_job_status_reconciliation_timeout: 1200
+
     # Apps with a deployed image, or an image-less GVC, created before this amount of days
     # will be listed for deletion when running the command `cpflow cleanup-stale-apps`.
     stale_app_image_deployed_days: 5
@@ -393,7 +398,7 @@ cpflow generate-github-actions
 bin/test-cpflow-github-flow
 ```
 
-`cpflow github-flow-readiness` exits non-zero when it finds blockers such as unpublished exact-pinned packages or a missing production Dockerfile, so use it as the gate before generation. Then review the generated `.controlplane/controlplane.yml` entries, adjust any app-specific workloads, and configure the GitHub repository variables and secrets described in [CI automation](./docs/ci-automation.md), including the optional Docker build settings for private GitHub dependencies and custom SSH known hosts. `cpflow generate-github-actions` also writes `bin/test-cpflow-github-flow` for local validation and `bin/pin-cpflow-github-ref` for temporarily pinning downstream wrappers to an upstream commit SHA during pre-release testing. `cpflow generate` already switches to persistent `db` and `storage` volumes when `config/database.yml` shows SQLite in production and preserves detected frontend precompile hooks, but you should still confirm that the generated Dockerfile picked a Ruby base image compatible with the app's declared Ruby requirement and that the emitted workload set matches the real app. If you want an AI agent to do this end to end, give it the [AI rollout prompt](./docs/ai-github-flow-prompt.md) rather than a vague "set up CI" request.
+`cpflow github-flow-readiness` exits non-zero when it finds blockers such as unpublished exact-pinned packages or a missing production Dockerfile, so use it as the gate before generation. Then review the generated `.controlplane/controlplane.yml` entries, adjust any app-specific workloads, and configure the GitHub repository variables and secrets described in [CI automation](./docs/ci-automation.md), including the optional Docker build settings for private GitHub dependencies and custom SSH known hosts. `cpflow generate-github-actions` checks in the local `.github/actions/cpflow-*` implementations alongside the workflows, and also writes `bin/test-cpflow-github-flow` for local validation and `bin/pin-cpflow-github-ref` for temporarily pinning downstream wrappers to an upstream commit SHA during pre-release testing. `cpflow generate` already switches to persistent `/app/data` and `/app/storage` volumes when `config/database.yml` shows SQLite in production, redirects every detected production SQLite database into persistent storage, keeps migrations visible under `/app/db`, and preserves detected frontend precompile hooks. You should still confirm that the generated Dockerfile picked a Ruby base image compatible with the app's declared Ruby requirement and that the emitted workload set matches the real app. If you want an AI agent to do this end to end, give it the [AI rollout prompt](./docs/ai-github-flow-prompt.md) rather than a vague "set up CI" request.
 
 For a live example, see the [react-webpack-rails-tutorial](https://github.com/shakacode/react-webpack-rails-tutorial/blob/master/.controlplane/readme.md) repository.
 
@@ -540,6 +545,9 @@ If you want to run PostgreSQL on Control Plane instead of keeping a Heroku add-o
 persistent storage and optional scheduled backups. Additionally, we provide a default `postgres` template in this
 repository optimized for Control Plane and suitable for development purposes.
 
+For disposable review apps, see [PostgreSQL for review apps](./docs/postgres-review-apps.md)
+for helper ownership, automatic cleanup, and recovery after interrupted deletion.
+
 ## In-memory Databases
 
 E.g., Redis, Memcached.

data/cpflow.gemspec

@@ -14,23 +14,11 @@ Gem::Specification.new do |spec|
   spec.license     = "MIT"
   spec.post_install_message = <<~MESSAGE
     cpflow #{Cpflow::VERSION} installed.
-
-    If this repository already uses generated cpflow GitHub Actions, update the
-    checked-in wrappers so GitHub loads the matching control-plane-flow release tag:
-
-      cpflow update-github-actions
-      bin/test-cpflow-github-flow
-
-    If you run cpflow through Bundler:
-
-      bundle exec cpflow update-github-actions
-      bin/test-cpflow-github-flow bundle exec cpflow
-
-    New repository? Run `cpflow generate-github-actions` first to create the
-    wrappers (and the `bin/test-cpflow-github-flow` script referenced above).
+    Generated GitHub Actions users: run `cpflow update-github-actions` after upgrading.
+    Docs: https://github.com/shakacode/control-plane-flow/blob/main/docs/ci-automation.md#updating-generated-github-actions-after-gem-updates
   MESSAGE
 
-  spec.required_ruby_version = ">= 3.0.0"
+  spec.required_ruby_version = ">= 3.2"
 
   spec.add_dependency "dotenv",   "~> 3.1"
   spec.add_dependency "jwt",      "~> 3.1"

data/docs/ai-github-flow-prompt.md

@@ -10,9 +10,9 @@ first.
 ```text
 Set up Control Plane GitHub Flow for this repo. First make sure the `cpflow` CLI is available: use the repo's existing `bundle exec cpflow` if present, otherwise install the published `cpflow` Ruby gem with `gem install cpflow`; if neither is possible, stop and report that blocker. Use the same `cpflow` invocation for the rest of the rollout. Start with `cpflow github-flow-readiness` and stop on any reported blockers. The repo must be deployable from a clean clone: published package versions, complete runtime scaffold, and a production Dockerfile that can build the app. If any package version is unpublished, inaccessible from CI, or requires credentials that are not already modeled in the repo or GitHub settings, stop and report the blocker instead of generating workflow files. If the repo is a legacy sample pinned to an obsolete Ruby or Bundler toolchain, if it does not even have a production Dockerfile yet, or if it is a monorepo without an already-decided single app boundary for this flow, stop and report that as a prerequisite instead of forcing the rollout.
 
-If `.controlplane/` is missing, run `cpflow generate`. Treat the generated app names as the repo-name default and rename them only if the project needs a different prefix. Then run `cpflow generate-github-actions` (or `cpflow generate-github-actions --staging-branch BRANCH` when staging should deploy from a branch other than `main`/`master`), keep review apps opt-in via `+review-app-deploy`, make sure any `STAGING_APP_BRANCH` repository variable is also present in the generated staging workflow's `on.push.branches` filter, and list the GitHub secrets and variables that must be configured. Do not hand-edit duplicated upstream refs into the generated wrappers: the only downstream Control Plane Flow pin should be the reusable workflow `uses: ...@vX.Y.Z` value generated from the installed `cpflow` gem version, and upstream workflows load their matching shared actions automatically. When bumping the `cpflow` gem in a downstream repo, run `cpflow update-github-actions` (or `bundle exec cpflow update-github-actions`) and validate with `bin/test-cpflow-github-flow` in the same PR so the checked-in wrappers move to the matching release tag. Keep the normal generated review-app setup simple: review apps require only `CPLN_TOKEN_STAGING` when the generated review app config can be inferred. For public demos, starter staging apps, and long-lived review apps, keep the app workload `type: standard` with one warm replica, set its autoscaling metric to `disabled`, and enable `capacityAI: true` so Control Plane can right-size CPU and memory allocation at that fixed replica count. Shared Postgres and other stateful workloads are the usual exceptions and should stay manually sized; Capacity AI is for supported stateless app/service workloads. If true idle scale-to-zero is explicitly required, create a separate `serverless` workload before first deploy or plan a delete/recreate migration because Control Plane will not change an existing `standard` workload to `serverless` in place. For shared review-app resources such as one staging database, use `shared_secret_grants` and `{{SHARED_SECRET_DATABASE}}` placeholders instead of hardcoding the base app secret name; this keeps review-app policy binding and cleanup automatic while avoiding per-PR database cost. Document the one-time Control Plane bootstrap command for persistent staging and production apps with `cpflow setup-app --skip-post-creation-hook`; for existing apps or later template updates, document `cpflow apply-template` and the need for the app identity to have `reveal` on the app secret policy. Do not imply the staging deploy or promotion workflows create those persistent GVCs. For production promotion, document a protected `production` GitHub Environment with required reviewers, prevent self-review, and `CPLN_TOKEN_PRODUCTION` stored as an environment secret, not as a repository or organization secret.
+If `.controlplane/` is missing, run `cpflow generate`. Treat the generated app names as the repo-name default and rename them only if the project needs a different prefix. Then run `cpflow generate-github-actions` (or `cpflow generate-github-actions --staging-branch BRANCH` when staging should deploy from a branch other than `main`/`master`), keep review apps opt-in via `+review-app-deploy`, make sure any `STAGING_APP_BRANCH` repository variable is also present in the generated staging workflow's `on.push.branches` filter, and list the GitHub secrets and variables that must be configured. Do not hand-edit duplicated upstream refs into the generated wrappers. Keep every generated Control Plane Flow source pin synchronized at the same `vX.Y.Z`: each reusable-workflow `uses: ...@vX.Y.Z` ref, the production promotion `.cpflow` checkout ref, and its `control_plane_flow_ref` setup input. By default, `cpflow generate-github-actions` derives these values from the installed `cpflow` gem version; temporary explicit ref overrides are for unreleased testing and must keep all three values synchronized. Keep the generated `.github/actions/cpflow-*` files from that same gem unchanged; upstream reusable workflows invoke those checked-in local actions and separately check out the matching runtime source at `.cpflow`. When bumping the `cpflow` gem in a downstream repo, `cpflow update-github-actions` refreshes local actions and helpers while preserving all top-level workflows, including their refs and triggers. Use `cpflow update-github-actions --workflows FILE...` to explicitly select wrappers for replacement, then review the diff and reapply downstream customizations. A differing existing validator blocks all writes: preserve its downstream checks in executable `bin/test-cpflow-github-flow-custom`, then remove or rename the old generated validator before retrying. The generated validator invokes that preserved extension and propagates its failures. Follow `docs/ci-automation.md` for the migration procedure, keep source pins compatible with the updated actions, and run `bin/test-cpflow-github-flow` in the same PR (or `bin/test-cpflow-github-flow bundle exec cpflow` when using Bundler). Keep the normal generated review-app setup simple: review apps require only `CPLN_TOKEN_STAGING` when the generated review app config can be inferred. For public demos, starter staging apps, and long-lived review apps, keep the app workload `type: standard` with one warm replica, set its autoscaling metric to `disabled`, and enable `capacityAI: true` so Control Plane can right-size CPU and memory allocation at that fixed replica count. Shared Postgres and other stateful workloads are the usual exceptions and should stay manually sized; Capacity AI is for supported stateless app/service workloads. If true idle scale-to-zero is explicitly required, create a separate `serverless` workload before first deploy or plan a delete/recreate migration because Control Plane will not change an existing `standard` workload to `serverless` in place. For shared review-app resources such as one staging database, use `shared_secret_grants` and `{{SHARED_SECRET_DATABASE}}` placeholders instead of hardcoding the base app secret name; this keeps review-app policy binding and cleanup automatic while avoiding per-PR database cost. Document the one-time Control Plane bootstrap command for persistent staging and production apps with `cpflow setup-app --skip-post-creation-hook`; for existing apps or later template updates, document `cpflow apply-template` and the need for the app identity to have `reveal` on the app secret policy. Do not imply the staging deploy or promotion workflows create those persistent GVCs. For production promotion, document a protected `production` GitHub Environment with required reviewers, prevent self-review, and `CPLN_TOKEN_PRODUCTION` stored as an environment secret, not as a repository or organization secret.
 
-Keep Node available in the final image if asset compilation or SSR depends on ExecJS, Yarn, `pnpm`, or npm after the main install layer. Make sure the generated Dockerfile uses a Ruby base image compatible with the app's declared Ruby requirement. Preserve repo-defined frontend build hooks: if `config/shakapacker.yml` defines a `precompile_hook`, or React on Rails enables `config.auto_load_bundle = true`, confirm the generated Dockerfile runs that codegen step before `rails assets:precompile`. If `config/database.yml` shows SQLite in production, confirm that the generated scaffold uses persistent `db` and `storage` volumes plus a release script that runs `rails db:prepare`; otherwise keep the default Postgres workload. If the public workload is not named `rails`, set `PRIMARY_WORKLOAD` or adjust the generated workflows. Inspect the Dockerfile and package sources for private GitHub dependencies or `RUN --mount=type=ssh`; if present, wire `DOCKER_BUILD_SSH_KEY`, optionally set `DOCKER_BUILD_SSH_KNOWN_HOSTS` for non-GitHub SSH hosts, and keep `DOCKER_BUILD_EXTRA_ARGS` to newline-delimited single tokens such as `--build-arg=FOO=bar`.
+Keep Node available in the final image if asset compilation or SSR depends on ExecJS, Yarn, `pnpm`, or npm after the main install layer. Make sure the generated Dockerfile uses a Ruby base image compatible with the app's declared Ruby requirement. Preserve repo-defined frontend build hooks: if `config/shakapacker.yml` defines a `precompile_hook`, or React on Rails enables `config.auto_load_bundle = true`, confirm the generated Dockerfile runs that codegen step before `rails assets:precompile`. If `config/database.yml` shows SQLite in production, confirm that the generated scaffold redirects every production database file into persistent `/app/data` (or keeps it under persistent `/app/storage`) without mounting over the image's `/app/db` migrations, stores Active Storage under `/app/storage`, and runs `rails db:prepare`; otherwise keep the default Postgres workload. If the public workload is not named `rails`, set `PRIMARY_WORKLOAD` or adjust the generated workflows. Inspect the Dockerfile and package sources for private GitHub dependencies or `RUN --mount=type=ssh`; if present, wire `DOCKER_BUILD_SSH_KEY`, optionally set `DOCKER_BUILD_SSH_KNOWN_HOSTS` for non-GitHub SSH hosts, and keep `DOCKER_BUILD_EXTRA_ARGS` to newline-delimited single tokens such as `--build-arg=FOO=bar`.
 
 Run the real local validations you can: Docker build if feasible, repo tests or smoke checks, YAML validation, and any CI-equivalent build steps. Push the branch and check the GitHub Actions results. Only stop early for a real external blocker or a product decision that changes scope.
 ```
@@ -46,7 +46,7 @@ Stop and report the blocker instead of generating `cpflow-*` workflow files when
 The rollout is done when all of the following are true:
 
 - `.controlplane/` exists and matches the actual app shape
-- `.github/cpflow-help.md` and `.github/workflows/cpflow-*` wrappers are in place
+- `.github/cpflow-help.md`, `.github/workflows/cpflow-*`, and `.github/actions/cpflow-*` are in place
 - review apps are opt-in, staging auto-deploys from one branch, and production promotion is manual
 - required GitHub secrets and variables are documented for the repo
 - the production image build path is validated for the real app