4. Push and stay current
What the same rules do once the change leaves your machine, and how a new version of the rules reaches your repository without you running anything.
Push and open a pull request
In a real repository, commit and push as usual. The playground has no remote, so there the commit is as far as it goes.
git commit -m "feat: load users from JSON"
git push -u origin feat/load-userOpen the pull request and fill in the template onboarding added, including its ## Launch readiness checklist. The gate then runs these jobs:
- Deterministic policy: the same checker rules as
reviewin step 1, with no model. Its findings are in the job's log. Had you pushed the file from step 1, this job would have failed on its two BLOCKERs. - PR checklist and ADR: whether the checklist is complete, and whether a change of more than 300 lines links a decision record.
- Secret scan and dependency review: the security floor.
Their results are combined into one required check, redline-gate / gate. A newly onboarded repository is at the observe rung: a failing policy, checklist or ADR job is reported as a warning and the check stays green. The secret scan and dependency review are the exception. They block at every rung, observe included. See Enforcement for how a repository is promoted to blocking. The model review from step 2 does not run in the gate; it is advice to you, before you push.
To prove the gate passes, blocks and refuses a bad exemption on your repository, run the Verification drill once on a throwaway branch.
When the standards change
The rules are versioned. When the organisation publishes a new version, your repository is behind until it takes it, and status says so:
$ npx redlinegate@latest status … standards 0.2.0 — behind 0.2.1, a sync will raise it
You do not run anything to catch up. The team that owns Redline runs redline sync, which opens a pull request on every repository that is behind, re-rendering AGENTS.md, CLAUDE.md and the rest with the new rules. Review that pull request like any other and merge it.
Do not run redline sync from your own repository. It is the estate-wide command: it runs from a checkout of the Redline source repository and opens pull requests on every registered repository.
To check that your repository still matches what .redline.json says is installed (the gate workflow, the rendered files, the host settings), run npx redlinegate@latest verify. Unlike the commands above it asks the host, so it needs a credential (on GitHub, gh auth login or GH_TOKEN), and it does not work in the playground. See What success looks like for what a healthy result looks like.
What you just did
- Wrote code that broke four rules, and saw
reviewname each one by severity and rule id, with no model. - Had your assistant review the same change, against the same rules, in the same format.
- Asked
explainwhat a rule means and who decided it, then fixed the code properly and watched the review come back clean. - Saw which of those rules the gate enforces on a pull request, and how a new version of the rules reaches your repository.
To remove the playground:
$ cd .. && rm -rf redline-demo
Where to go next
- Adopting Redline: from day one to blocking merges.
- Local review: every way to run the review before you push.
- Troubleshooting: when something here did not match what you saw.