CI gate

A GitHub Actions workflow sends changed-file content to FlowRail for verification against universal and enabled project rules. The gate does not trust a local record saying those files were already checked. Supported changed dependency manifests receive dependency checks; lockfile-only and transitive-resolution changes are outside the CI dependency scope.

New self-serve projects start in advisory mode. Checks run and report findings while you calibrate the setup, but advisory findings do not block merging. During the invited pilot, arrange project provisioning and enforcement-mode changes with FlowRail; there is no public settings screen for these steps. There is no automatic switch after a waiting period.

First complete the installation guide in this repository. The installer requires your workstation FLOWRAIL_API_KEY to be exported in the same terminal. That workstation key is separate from the project verification token used by GitHub Actions. Arrange a project id and display-once project verification token with FlowRail before continuing.

From the same terminal in your repository, run the installer with the server-issued project id, then run CI setup:

Replace YOUR_PROJECT_ID with the project's prj_ identifier. Setup validates the token through a hidden prompt or stdin, stores it as the FLOWRAIL_PROJECT_TOKEN repository secret through GitHub CLI, and guides an administrator through requiring the check. Do not put the token in a command argument or an agent conversation.

Run the workflow once so GitHub creates its status check. In branch protection, require pull requests and passing status checks, select the exact FlowRail check shown on the PR, and include administrators. The installed copy-in workflow uses the check name verify. Enforcement requires both project enforce mode and branch protection.

Use a temporary PR with a deliberate test violation. In advisory mode, confirm the check ran and reported it. In enforce mode, confirm a blocking finding makes the required check fail and prevents merge. Close the test PR without merging it.

Individual rules can be blocking or advisory at the CI checkpoint. In enforce mode, blocking findings and incomplete verification prevent a passing gate result. Operational failures such as unavailable service or unusable responses need a retry; they are not evidence of a clean run.

The workflow lives in your repository. An administrator can change it or bypass branch protection, so FlowRail does not make that workflow tamper-proof. Agent credentials should not have administration or bypass rights if you want the required check to constrain their changes.