redline-verify

Prompt file imported from moelzanaty3/test-redline (.cursor/commands/redline-verify.md). Copyright stays with the author.

Run Redline the way this repository does, from its root:

• package.json lists redlinegate: use the project's own copy, so you run the version the team pinned — pnpm redline verify with a pnpm-lock.yaml, yarn redline verify with a yarn.lock, bun run redline verify with a bun.lock, otherwise npx redlinegate verify.
• It does not, and package.json has a devEngines.packageManager naming pnpm, yarn or bun: npm refuses to run in that project, so use pnpm dlx redlinegate verify, yarn dlx redlinegate verify or bunx redlinegate verify.
• Anything else: npx redlinegate verify.

Never plain npx redline — that resolves to an unrelated package on the public registry; the published package is redlinegate. Below, redline <command> means that command run the same way.

Report the findings table. Add --gate if the engineer wants an explicit pass/fail summary line printed after the table, such as when running this by hand to mirror what CI's gate check sees.

Each line is a check. For any FAIL, explain what it means and what fixes it:

• onboarded — the repository has no .redline.json. Run redline init.
• capabilities — never a FAIL. It names what this repository deselected at onboarding, so the report describes the whole surface. The checks a deselection governs say off by choice in their own detail rather than reporting the capability as missing: that is the difference between "off because we chose to" and "off because it broke".
• merge-policy — no Redline merge policy was found on the host at all, or the live one has been loosened, or the ruleset that carries it is no longer in force. The finding names what changed: the blocking flag, the approval count, dismissing approvals on push, code-owner review, unresolved-thread resolution — or, on Azure, a blocking Status policy with no matching Build Validation policy to queue the gate pipeline, so the status is never published and every pull request sits blocked; re-run redline init with build administrator rights. Settings the host cannot attribute to Redline are listed as "not compared here" rather than held against the repository. A repository that deselected the merge policy is not compared at all — except where Redline itself applied a blocking policy before the deselection: that ruleset is still live, still requires the Redline check, and fails here while nothing in the repository publishes it.
• gate-machinery — the file that runs the gate is missing from this repository, the job that publishes the required check has been renamed, the file is present and correctly named but no pull request will ever trigger it, or the job is unchanged but the merge policy now requires a different check name. Nothing will ever report the gate, so a blocking policy blocks every pull request forever. Re-run redline init to restore the file or reapply the policy. Only rename the job back if the workflow itself was the thing that changed — if the policy is what moved, the job is already correct, and renaming it is the wrong fix. A repository that deselected the gate passes here, and is told whether the workflow an earlier run installed is still sitting there — a deselection never deletes it.
• check-name-reported — a check ran on the pull request but the required name was never among the ones reported. Where the policy blocks, this blocks every pull request in the repository. Fix the caller job id, or the policy. "No gate run observed yet" is not a failure: no Redline gate run has published anything on that pull request's head commit — other CI may well have — and gate-machinery above is what says whether one ever could.
• security-floor — secret scanning, push protection or dependency alerts has been turned off. A capability nothing could observe is named as unconfirmed, never counted as enabled.
• artifacts-current — the rendered standards are stale against the version this repository recorded. A version difference in either direction is reported without failing, because neither is drift: a newer version upstream is adopted by redline init, and an older one means this CLI is behind the repository and wants updating, not re-running.
• pull-request-template — the template the host actually serves is gone, has a broken REDLINE:BEGIN/REDLINE:END pair, or is missing a section the gate checks for, so the gate fails pull requests opened from it. Re-run redline init — but a mangled marker pair has to be repaired by hand first, because init refuses to write to it.
• pending-admin — a repository administrator still has work to do. Only capabilities a read came back with an answer for are listed as work to chase. Entries the host reported as unavailable, and entries no read can answer at all (labels, review ownership, the repo property, the gate, the merge policy), are listed separately as recorded-but-unactionable. Under --gate only the actionable ones fail, so a record only redline init can clear does not block every pull request in the repository.

A capability the host reports as unsupported — for example Azure DevOps Advanced Security when it isn't licensed on this repository — is not the same as denied: it is never listed as work an administrator must do, because there is no administrator action that would change it. A capability the host answers with unknown — a 401/403 this host cannot tell apart from a genuine refusal — is treated the same way for the same reason: an indeterminate read is not an answer, so it is never counted as work to chase either. Both are still named, so nobody mistakes silence for a clean bill.

Do not attempt to fix host settings yourself. Report and stop.