docs: refresh the demo recording, and fix a tape that recorded a false pass - #530

Reworked after review. The previous approach predicted the " (#N)" suffix a
squash merge appends and measured the title against it — machinery to make
a check pass that should not have been running.

The simpler answer is not to run it. A push to main carries work that
already passed on the pull request, and re-checks it against a subject the
author never wrote and cannot shorten. Dropping the push trigger removes
the failure mode instead of predicting it, and the title is checked once,
where it can still be edited.

commit-check-action does that natively with pr-title, so the noxfile goes
back to what it was and this repository now checks itself with the thing
users actually run.

The workflow tests assert both properties that made #530 escape: the
trigger set is pull_request only, and it carries no paths filter — #530
touched only assets/ and matched nothing, so no check ran at all.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn

#530 passed review with a 75-character title and failed commit-check on
main at 82, against a limit of 80 — the squash merge appended " (#530)"
and pushed the subject over. Nothing had run on the pull request itself:
main.yml's paths filter skipped the check because #530 touched only
assets/, and the nox session checked HEAD, never the title a squash merge
would actually commit.

So: a dedicated workflow running commit-check-action on pull requests
only, and the push-to-main check removed instead of taught to cope.

Pull requests only, deliberately. A push to main carries work that
already passed on its pull request, re-checked against a subject the
author never wrote and cannot shorten. Dropping that removes the failure
mode instead of predicting it. No paths filter — a subject, a branch name
or an author address is wrong regardless of which files changed. The
`edited` trigger re-checks when a title changes, because the title is
what a squash merge commits; pr-title on the action checks it directly.

The action rather than the nox session is also this repository checking
itself with the thing users actually run.

Known: CC202 fails on pull-request checkouts until the merge-base fix in
commit-check ships and the action picks it up — the released engine
cannot resolve a target that exists only as origin/main. That fix is a
separate pull request; this one stays CI-only.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn

#530 passed review with a 75-character title and failed commit-check on
main at 82, against a limit of 80 — the squash merge appended " (#530)"
and pushed the subject over. Nothing had run on the pull request itself:
main.yml's paths filter skipped the check because #530 touched only
assets/, and the nox session checked HEAD, never the title a squash merge
would actually commit.

So: a dedicated workflow running commit-check-action on pull requests
only, and the push-to-main check removed instead of taught to cope.

Pull requests only, deliberately. A push to main carries work that
already passed on its pull request, re-checked against a subject the
author never wrote and cannot shorten. Dropping that removes the failure
mode instead of predicting it. No paths filter — a subject, a branch name
or an author address is wrong regardless of which files changed. The
`edited` trigger re-checks when a title changes, because the title is
what a squash merge commits; pr-title on the action checks it directly.

The action rather than the nox session is also this repository checking
itself with the thing users actually run.

Known: CC202 fails on pull-request checkouts until the merge-base fix in
commit-check ships and the action picks it up — the released engine
cannot resolve a target that exists only as origin/main. That fix is a
separate pull request; this one stays CI-only.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn

The README's output blocks predate rule IDs, so they showed neither the
CCxxx identifiers nor the Docs links that every failure now prints. Same
staleness #530 fixed in the demo GIF; the docs site is already current,
only the README had been left behind.

Measured by running each documented command against this checkout rather
than reading the code:

  Type message check failed ==> ...   ->  CC001 message check failed ==> ...
  Type branch check failed  ==> ...   ->  CC201 branch check failed  ==> ...

plus a trailing `Docs: https://commit-check.com/rules/#ccNNN` line on both,
and two commit types the list had never picked up (perf, build).

Four more blocks were stale in the same way, so they are refreshed too:

- --no-banner carried a line that no longer exists anywhere in the source:
  "It doesn't match regex: ^(build|chore|ci|...)". grep over *.py finds it
  only in a test comment.
- --compact prints the rule id: [FAIL] CC001 message: ...
- Both --format json examples were missing the rule_id and docs_url fields,
  showed value as "" where it is now populated on pass, and named a
  subject_imperative check that the default run does not emit — it reports
  subject_max_length (CC004) and subject_min_length (CC005), and lists
  passing checks alongside the failing one.
- The Python API return-value schema was missing rule_id and docs_url. The
  API code examples themselves were correct; each was re-run to confirm.

Every block was then re-captured and compared byte for byte against the
committed text (JSON via json.loads, text with ANSI colours and trailing
padding normalised), so these are transcripts, not transcriptions.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn

…535)

The README's output blocks predate rule IDs, so they showed neither the
CCxxx identifiers nor the Docs links that every failure now prints. Same
staleness #530 fixed in the demo GIF; the docs site was already current,
only the README had been left behind.

Measured by running each documented command against the checkout:

  Type message check failed ==> ...  ->  CC001 message check failed ==> ...
  Type branch check failed  ==> ...  ->  CC201 branch check failed  ==> ...

plus a trailing Docs: https://commit-check.com/rules/#ccNNN line on both,
and two commit types the list had never picked up (perf, build).

Four more blocks were stale the same way: --no-banner carried an
"It doesn't match regex:" line that no longer exists in the source,
--compact now prints the rule id, both --format json examples were missing
rule_id and docs_url and named a subject_imperative check the default run
does not emit (it reports subject_max_length and subject_min_length), and
the Python API return-value schema was missing rule_id and docs_url.

Every block was re-captured and compared byte for byte against the
committed text, so these are transcripts rather than transcriptions.

#530 passed review with a 75-character title and failed commit-check on
main at 82, against a limit of 80 — the squash merge appended " (#530)"
and pushed the subject over. Nothing had run on the pull request itself:
main.yml's paths filter skipped the check because #530 touched only
assets/, and the nox session checked HEAD, never the title a squash merge
would actually commit.

So: a dedicated workflow running commit-check-action on pull requests
only, and the push-to-main check removed instead of taught to cope.

Pull requests only, deliberately. A push to main carries work that
already passed on its pull request, re-checked against a subject the
author never wrote and cannot shorten. Dropping that removes the failure
mode instead of predicting it. No paths filter — a subject, a branch name
or an author address is wrong regardless of which files changed. The
`edited` trigger re-checks when a title changes, because the title is
what a squash merge commits; pr-title on the action checks it directly.

The action rather than the nox session is also this repository checking
itself with the thing users actually run.

Known: CC202 fails on pull-request checkouts until the merge-base fix in
commit-check ships and the action picks it up — the released engine
cannot resolve a target that exists only as origin/main. That fix is a
separate pull request; this one stays CI-only.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn