[GreedyC]

Description

Clarify that omitting processing_order retains the legacy pipeline: the whole commit is processed before splitting, and each surviving line is then processed again. This distinction matters when filter_commits or a skipping parser discards the whole message before its body lines can be matched.

Add a complete split-before-parsing configuration for unconventional messages, plus an example demonstrating that ^fix: keeps two matching body lines without accepting bugfix:. Replace the ambiguous "default processing order" wording with an explicit opt-in pipeline description.

The new unit test parses the documented TOML settings and checks the ordered, legacy, and parser-first cases. Runtime behavior and defaults are unchanged.

Also regenerate npm/git-cliff/yarn.lock for the six already-published 2.14.2 platform packages. The stale 2.13.1 entries made CI's immutable installation fail before the NodeJS tarball could be validated.

Motivation and Context

Related to #1093 and the compatibility discussion in #1201/#1532. This documents the existing workaround instead of changing the default behavior. The approach was described in the issue discussion before making the change; maintainer review is still pending.

Prepared with assistance from OpenAI Codex; the changes and validation results were reviewed before submission.

How Has This Been Tested?

On macOS arm64 with Rust 1.97.1:

• cargo test --locked -- --skip repo::test::git_upstream_remote: 150 unit/integration tests and two doctests passed.
• cargo test --locked --all-features -- --skip repo::test::git_upstream_remote: 150 unit/integration tests and two doctests passed.
• cargo test --locked --no-default-features -- --skip repo::test::git_upstream_remote: 122 unit/integration tests and two doctests passed.
• cargo clippy --locked --tests -- -D warnings passed.
• Workspace formatting passed using the official nightly rustfmt 1.11.0 (2026-09-30).
• yarn build in website passed.
• The example was also run through the CLI in a temporary Git repository: the explicit pipeline emitted the two Fixed entries, while the legacy configuration emitted no entries.

An isolated fork preflight passed 6/6 jobs against the exact proposed commit a0b4219fa9150ee69ebc636bb948ef326752a144: full default suites on Linux/macOS; additional all-feature/no-default suites on Linux; the pipeline tests on Windows; nightly formatting/clippy; the Node 20 website build; and repository spelling. Its workflow lives on a separate fork-only branch and is not part of this PR.

The repository's CI also skips repo::test::git_upstream_remote; this is a live remote test, not a regression introduced by this change.

Upstream CI notes

• The initial Check NodeJS tarball failed with Yarn YN0028, also reproduced on untouched base 60e0be97e945f71148172675be82399d382c9677. Follow-up commit fdc96b4 regenerates the six lockfile entries to match the manifest's 2.14.2 dependencies. Locally, immutable installation, package build, and verification of all ten expected tarball files now pass. The future release-lockfile automation remains covered by fix(cd): open a pull request that updates yarn.lock after the npm release #1648.
• Links on the follow-up commit still reports three external errors: HTTP 429 for the Grindhouse product URL in website/blog/git-cliff-2.9.0.md, and connection-refused errors for two Repology URLs in website/docs/installation/index.md. These URLs and both source files are unchanged from the base commit. This PR adds no external URLs.

The six-job fork preflight above covers a0b4219. On follow-up fdc96b4, the same upstream Check NodeJS tarball now passes. Link checks remain enabled.

Screenshots / Logs (if applicable)

Fixed: fix: first line of the commit body
Fixed: fix: second line of the commit body

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (no production-code change)
• Refactor (refactoring production code)
• Other: regression coverage for the documented configuration

Checklist:

• My code follows the code style of this project.
• I have updated the documentation accordingly (if applicable).
• I have formatted the code with rustfmt (nightly).
• I checked the lints with clippy.
• I have added tests to cover my changes.
• All new and existing tests passed, with the same live-remote-test exclusion used by CI.

[welcome]

Thanks for opening this pull request! Please check out our contributing guidelines! ⛰️

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 53.33%. Comparing base (60e0be9) to head (fdc96b4).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1649      +/-   ##
==========================================
+ Coverage   53.21%   53.33%   +0.12%     
==========================================
  Files          28       28              
  Lines        2633     2633              
==========================================
+ Hits         1401     1404       +3     
+ Misses       1232     1229       -3     

Flag	Coverage Δ
unit-tests	53.33% <ø> (+0.12%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[GreedyC]

The failing Links job reports connection refusals for two existing Repology URLs and HTTP 429 for the existing Grindhouse link; none of these URLs is changed by this PR. Could a maintainer rerun the failed job when convenient? I do not have permission to rerun it, and have left the link-check policy unchanged.