What success looks like
You onboarded a repository. Now what should you actually see, when, and which command shows it to you? Four checkpoints, each with the command that proves it and the failure that looks identical from the outside.
Redline's hardest failure mode is not breaking. It is running, looking green, and doing nothing — a gate nobody required, a reviewer that stopped finding things, a rule everyone ignores. Every checkpoint below is paired with the way it fails quietly, because that is the one you have to go and look for.
Checkpoint 1 — the repository can describe itself
When: the moment the onboarding pull request merges. Who: you, in the repository.
$ npx redlinegate@latest status
This contacts no host and needs no credential — it reads the checkout. Success is that it names your profile, the rung the gate sits at, and the standards version the artifacts were rendered from, and that pendingAdmin is empty. Anything listed there is a capability that needed repository-admin rights you did not have, and it is waiting on a person, not on time. --json gives the same thing to a script.
The quiet failure: a non-empty pendingAdmin that nobody reads. The repository looks onboarded, the files are all there, and the merge policy was never applied — clearing it is admin work, not a matter of time.
Checkpoint 2 — the gate reports, under the name something requires
When: the first pull request after onboarding.
$ npx redlinegate@latest verify
status reads your checkout; verify reads the host. It takes what the host currently has required and compares it to what actually reported on the latest pull request. The name is redline-gate / gate — a reusable workflow reports as <caller job id> / <called job id>, and both ids are pinned in scripts/validate.mjs so CI fails if either is renamed.
The quiet failure: a required check whose name nothing ever reports — every pull request waits forever on a status that does not exist (what to do about it). On the default advisory install nothing is required yet, so verify can only surface the reported name for you to eyeball; on a --blocking install it is a real assertion and fails.
Checkpoint 3 — findings arrive, and carry ids you can act on
When: the first pull request that touches code a stack covers.
Success is a review comment in the output contract — a severity, a rule id in brackets, one line on what breaks and one on the fix. The id is the part that matters: it is what makes the finding measurable, and it is what turns the comment back into an editable rule.
$ npx redlinegate@latest explain core/query-string-concatenation
That prints the rule, who decided it, the file and line in standards/ where it is defined, and every profile that receives it. If you disagree with a finding, that line number is where the disagreement gets settled.
The quiet failure: findings with no id, or an id redline explain --list does not know. Those were invented by the model, and every aggregate keyed on them is fiction — they are counted as untagged rather than silently accepted. A steady stream of core/uncatalogued is different: that is the signal a real rule is missing, and it is working as designed.
Checkpoint 4 — the estate answers whether any of it is being used
When: after a few weeks of merged pull requests. Who: the platform team, not a repository owner — the commands behind this one act on an organisation and are meaningless in a product repo (Who runs what).
The hero number is findings acted on, and beside it the dashboard carries the rule tuning queue — the standard's own to-do list, and the thing to work through before anyone writes a new rule. Telemetry & validation has the tiles, what each one reads like when it is healthy, and the weekly canary that proves the reviewer is still catching things.
The quiet failure: a dashboard that looks calm because nothing reached it. A figure Redline could not compute says why instead of defaulting to zero — a measurement plane that fills gaps with zeros reports a stalled collector as a quiet week.
The end state — earning the right to block
Success is not a blocking gate on day one. A repository climbs the enforcement ladder on recorded evidence — seed recall, false positives and acted-on rate, the same figures checkpoint 4 reads — and the thresholds are deliberately hard because a reviewer that flags correct code cannot be given a veto. Promotion is refused without the evidence and names the figure that is short; demotion never needs any.
Be honest about where this stands. No seed scores have been recorded yet — the pilot produces the first ones, and nothing widens past one repository per stack until they are in CHANGELOG.md. Until a recall number exists, every repository is legitimately at observe or warn, and a blocking rung is not something to reach for.
The short version
| Question | Command | Where |
|---|---|---|
| What is installed here? | redline status | your repo, no credential |
| Does the host agree? | redline verify | your repo |
| What does this finding mean? | redline explain <id> | anywhere |
| Would this diff pass? | redline review | your repo, before you push |
| Who is onboarded? | redline registry | source repo, nightly |
| Is review being acted on? | redline metrics dashboard | metrics repo |
| Does it still catch defects? | redline metrics score-seeds | against a pilot PR |
| What did it cost? | redline metrics roi | metrics repo |