# rd-verify

> Resolve this repo's real gate, run each command once to a log, and read the summary line instead of trusting the exit code.

`rd-verify` works out what green means in this repo, runs it once, and reads
the output rather than the exit code. Its report is a table with a quoted
summary line per gate, so "tests pass" is a quotation and not a claim.

> Find and run this repo's real verification gate, then read each command's
> summary line instead of trusting its exit code, and report one row per gate
> with the evidence.

## When to use it

Before a child moves to in review, before a pull request, and any time you are
about to tell someone the tree is green. `rd-build` calls it per child and
`rd-pr` calls it before opening. Not mid-edit: run the one test file that
covers what you are changing, and save this for checkpoints.

## What it asks you

Nothing, usually. It resolves the gate itself and tells you which source
answered, because "read from CLAUDE.md" and "inferred from package.json" are
different levels of confidence and you deserve to know which one you got. It
asks only when nothing resolves at all.

## What it writes

A log file per gate under `.radial/`, and a table in chat. It writes nothing to
Radial: it reports, and `rd-build` records.

## How it resolves the gate

<steps>

<step title="The gate-commands hook">

If a wrapper fills it, those are the commands. Nothing is inferred alongside
them: a team that has written its gate down does not want you guessing next to
it.

</step>

<step title="CLAUDE.md or AGENTS.md">

The verification section, in the order it names things.

</step>

<step title="The package manifest">

`package.json` scripts named `lint`, `typecheck`, `test`, `check`, `validate`,
`verify`; else a `Makefile`; else `pyproject.toml`, `go.mod`, `Cargo.toml`.

</step>

</steps>

## Why the summary line, not the exit code

Exit 0 is not proof the tier ran. A test runner that matched zero files exits
0. A type checker pointed at the wrong project exits 0. A script that skipped
its real work because a flag was unset exits 0. So each gate is green only when
there is a line that says what happened (`561 passed, 0 failed`, `Found 0
errors.`), and a gate with no summary line found is a red row, not a green one.

## Extension points

<hook-table skill="rd-verify">
</hook-table>

## A worked wrapper

```markdown
---
name: monorepo-verify
description: The real gate for this monorepo, and the bar we hold before calling it green.
extends: rd-verify
---

Read rd-verify first, then apply the sections below at their hooks.

## gate-commands

1. `pnpm lint`
2. `pnpm type-check`
3. `pnpm test -- --reporter=dot`
4. `pnpm --filter @acme/api test`

## extra-checks

- `pnpm coverage`: the gate is red below 80% lines; quote the measured number.

## green-bar

- The working tree must be clean. Uncommitted changes mean the gate tested
  something nobody else can see.
- The e2e tier must have run, or the report says green-with-no-e2e explicitly.
```

## What it never does

It never claims green from an exit code alone, and never re-runs a suite to
reshape its output: it greps the log it already has. It never substitutes a
smaller command for a gate it could not run; that gate is reported not run,
with the reason. And it never edits a test to make a gate pass.