Use the two names consistentlydocs/guidelines-layout

Progmasoft C/C++ Styles names the repository, where a text speaks of
all of it: the README introduction, the license texts, CONTRIBUTING and
the changelog. Progmasoft Core C++ Coding Guidelines names its C++
guide, and its own documents call it "the guidelines", in the plural
like its name, instead of "the guide" or "this guide"; the verbs follow.
Dated changelog entries keep their wording. Paragraphs that grew past
120 columns are rewrapped; every link and anchor still resolves.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

12 files changed, 68 insertions, 61 deletions

diff --git a/ADOPTING.md b/ADOPTING.md
index 38d4cc6..5c1112e 100644
--- a/ADOPTING.md
+++ b/ADOPTING.md
@@ -1,12 +1,12 @@
 <!-- SPDX-FileCopyrightText: 2026 Progmasoft <support@progmasoft.com> -->
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 
-# Adopting the guide
+# Adopting Progmasoft Core C++ Coding Guidelines
 
 A project adopts Progmasoft Core C++ Coding Guidelines by pointing to them, copying their two tool profiles and
 writing down, once, where it deviates.
 
-## 1. Point to the guide
+## 1. Point to the guidelines
 
 Add a short section to the project's contributing guide:
 
@@ -18,11 +18,12 @@ C++ code follows [Progmasoft Core C++ Coding Guidelines](https://github.com/Prog
 Deviations of this project are listed below.
 ```
 
-Do not copy the rules into the project. A copy drifts from the guide, and two documents that disagree are worse than
-one.
+Do not copy the rules into the project. A copy drifts from the guidelines, and two documents that disagree are worse
+than one.
 
-State the language version in the same section, C++20 or C++17; [the guide says how to choose](Progmasoft_Core_Cpp_Coding_Guidelines/Common/LANGUAGE.md), and
-the project follows the page of its version ([C++20](Progmasoft_Core_Cpp_Coding_Guidelines/Cpp20/LANGUAGE.md),
+State the language version in the same section, C++20 or C++17; [the guidelines say how to
+choose](Progmasoft_Core_Cpp_Coding_Guidelines/Common/LANGUAGE.md), and the project follows the page of its version
+([C++20](Progmasoft_Core_Cpp_Coding_Guidelines/Cpp20/LANGUAGE.md),
 [C++17](Progmasoft_Core_Cpp_Coding_Guidelines/Cpp17/LANGUAGE.md)).
 
 ## 2. Copy the profiles
@@ -34,7 +35,8 @@ the project follows the page of its version ([C++20](Progmasoft_Core_Cpp_Coding_
 | compiler flags | [Tooling: flags](Progmasoft_Core_Cpp_Coding_Guidelines/Common/TOOLING.md#flags), in the build files of the project |
 
 The profiles are in the public domain (see [LICENSE.md](LICENSE.md)), so they can be copied under the project's own
-license. Note the guide revision they come from in a comment at the top of each file, so a later update can be compared.
+license. Note the revision of the guidelines they come from in a comment at the top of each file, so a later update can
+be compared.
 
 ## 3. Record the deviations
 
@@ -50,16 +52,16 @@ use exceptions because its host does. List them in the contributing guide, each
   (Errors, 7.1).
 ```
 
-Within the project, its documented rule wins over the guide. An undocumented difference is not a deviation; it is code
-that has not caught up yet.
+Within the project, its documented rule wins over the guidelines. An undocumented difference is not a deviation; it is
+code that has not caught up yet.
 
 ## 4. Converge gradually
 
-Existing code is not rewritten in one sweep. A file follows the guide where it is changed. A purely mechanical change,
-such as applying `clang-format` to a directory or renaming a member convention, is its own pull request, never mixed
-with a change in behavior, so that review and `git blame` stay useful.
+Existing code is not rewritten in one sweep. A file follows the guidelines where it is changed. A purely mechanical
+change, such as applying `clang-format` to a directory or renaming a member convention, is its own pull request, never
+mixed with a change in behavior, so that review and `git blame` stay useful.
 
-## Projects that follow the guide
+## Projects that follow the guidelines
 
 | Project | Deviations recorded in |
 | --- | --- |
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 82bc430..4b896d3 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -3,20 +3,21 @@
 
 # Changelog
 
-A revision of the guide is named by its date. A change that requires existing code to change says so.
+A revision of Progmasoft C/C++ Styles is named by its date. A change that requires existing code to change says so.
 
 ## Unreleased
 
-The guide is named Progmasoft Core C++ Coding Guidelines; it was Progmasoft C++ Style.
+The repository is named Progmasoft C/C++ Styles, and its C++ guide Progmasoft Core C++ Coding Guidelines; both
+were Progmasoft C++ Style.
 
-The guide moved to `Progmasoft_Core_Cpp_Coding_Guidelines/`. `Common/` holds the thirteen chapters, which apply to both versions;
-`Cpp20/` and `Cpp17/` hold what applies to one version: the rules that use C++20 features, and their C++17 form with
-the checks a C++17 library needs. `index.json` lists every document with its chapter and versions. No rule changed;
-links to `Guide/` move to `Progmasoft_Core_Cpp_Coding_Guidelines/Common/`.
+The guidelines moved to `Progmasoft_Core_Cpp_Coding_Guidelines/`. `Common/` holds the thirteen chapters, which apply to
+both versions; `Cpp20/` and `Cpp17/` hold what applies to one version: the rules that use C++20 features, and their
+C++17 form with the checks a C++17 library needs. `index.json` lists every document with its chapter and versions. No
+rule changed; links to `Guide/` move to `Progmasoft_Core_Cpp_Coding_Guidelines/Common/`.
 
-The guide covers C++17 as well as C++20. A project picks one; C++20 stays the default, and C++17 is for libraries meant
-for other people's projects. [The C++17 page](Progmasoft_Core_Cpp_Coding_Guidelines/Cpp17/LANGUAGE.md) lists the C++17 form of each C++20
-feature the guide uses. Existing C++20 projects need no change.
+The guidelines cover C++17 as well as C++20. A project picks one; C++20 stays the default, and C++17 is for libraries
+meant for other people's projects. [The C++17 page](Progmasoft_Core_Cpp_Coding_Guidelines/Cpp17/LANGUAGE.md) lists the
+C++17 form of each C++20 feature the guidelines use. Existing C++20 projects need no change.
 
 ## 2026-10-18
 
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 84acd60..5d836ea 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -3,8 +3,8 @@
 
 # Contributing
 
-Progmasoft C/C++ Styles changes when a rule turns out to be wrong, unclear or missing. Proposals are welcome from anyone,
-whether or not they work on a Progmasoft project.
+Progmasoft C/C++ Styles changes when a rule turns out to be wrong, unclear or missing. Proposals are welcome from
+anyone, whether or not they work on a Progmasoft project.
 
 ## Proposing a change
 
@@ -12,16 +12,16 @@ Open an issue first for anything beyond a correction of wording, a typo or a bro
 
 - **the rule**, as it reads now or as you would write it;
 - **the problem**: code that the current rule makes worse, a bug it fails to prevent, or a case it does not cover;
-- **the cost of the change** for projects that already follow the guide: how much code would have to change, and whether
-  a tool can do it.
+- **the cost of the change** for projects that already follow the guidelines: how much code would have to change, and
+  whether a tool can do it.
 
 A rule earns its place by preventing a real class of mistakes or by removing a choice that would otherwise be argued
 about in every review. "Another style guide does it" is a starting point, not a reason.
 
 ## Writing the change
 
-- Keep the shape of the guide: a rule in bold that says what to do, then the reason, then an example when it helps.
-- Examples follow every rule of the guide, including formatting by the profile and the 80-column limit.
+- Keep the shape of the guidelines: a rule in bold that says what to do, then the reason, then an example when it helps.
+- Examples follow every rule of the guidelines, including formatting by the profile and the 80-column limit.
 - A change to `.clang-format` or `.clang-tidy` says which clang version it was tested with and what it changes in
   formatted code.
 - Write in US English, in the present tense and the active voice.
@@ -30,4 +30,4 @@ about in every review. "Another style guide does it" is a starting point, not a
 ## License of contributions
 
 By contributing you agree that your text is licensed under [CC BY 4.0](LICENSE.md) and that your configuration and code
-examples are dedicated to the public domain under [CC0 1.0](LICENSES/CC0-1.0.md), like the rest of the guide.
+examples are dedicated to the public domain under [CC0 1.0](LICENSES/CC0-1.0.md), like the rest of the repository.
diff --git a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/C-INTERFACES.md b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/C-INTERFACES.md
index 2def35e..7c6ebbc 100644
--- a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/C-INTERFACES.md
+++ b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/C-INTERFACES.md
@@ -83,7 +83,7 @@ example_parser_destroy(example_parser *parser);
 
 ## 10.4 The C++ side
 
-Behind the interface, the implementation is ordinary C++ that follows the rest of this guide:
+Behind the interface, the implementation is ordinary C++ that follows the rest of these guidelines:
 
 ```cpp
 extern "C" auto
diff --git a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/ERRORS.md b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/ERRORS.md
index 20c524f..d2350b9 100644
--- a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/ERRORS.md
+++ b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/ERRORS.md
@@ -26,9 +26,9 @@ never lets one cross a C interface or escape a destructor. Third-party code keep
 
 ## 7.2 `Expected<T>` and `Error`
 
-A function that produces a value or fails returns `Expected<T>`; one that only succeeds or fails returns `Error`. The guide
-does not prescribe the library. `llvm::Expected<T>` and `llvm::Error` suit code that already depends on LLVM; a
-backport of `std::expected` (such as `tl::expected`) or a small type of the project's own suit the rest, and C++23's
+A function that produces a value or fails returns `Expected<T>`; one that only succeeds or fails returns `Error`. The
+guidelines does not prescribe the library. `llvm::Expected<T>` and `llvm::Error` suit code that already depends on LLVM;
+a backport of `std::expected` (such as `tl::expected`) or a small type of the project's own suit the rest, and C++23's
 `std::expected` replaces them once a project moves to it. What matters is the discipline below: the failure is in the
 signature, it cannot be ignored, and it carries a message.
 
@@ -89,7 +89,8 @@ An invariant is something the program's own logic guarantees. A broken invariant
 input, and there is no meaningful way to continue.
 
 - **`assert`** checks an invariant that is cheap to state, in debug builds. It never checks input, never has a side
-  effect, and its message is a condition a reader understands: `assert(index < blocks_.size() && "block id out of range")`.
+  effect, and its message is a condition a reader understands: `assert(index < blocks_.size() && "block id out of
+  range")`.
 - **An always-on check** (a project macro that prints and calls `std::abort`, or `llvm::report_fatal_error`) guards
   an invariant whose
   violation would corrupt memory or produce wrong output in a release build, such as a verifier disagreeing with
diff --git a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/FORMATTING.md b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/FORMATTING.md
index 0b383af..cc088bb 100644
--- a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/FORMATTING.md
+++ b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/FORMATTING.md
@@ -5,7 +5,7 @@
 
 Formatting is mechanical, so a tool does it. Every C++ file is formatted by `clang-format` with the profile below, and
 CI fails when a file is not. Nobody formats by hand, and nobody argues about a formatting choice in a review: a change
-to the profile is a change to this guide.
+to the profile is a change to these guidelines.
 
 ## The shape of the code
 
diff --git a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/LANGUAGE.md b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/LANGUAGE.md
index 246bdc6..21b7f34 100644
--- a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/LANGUAGE.md
+++ b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/LANGUAGE.md
@@ -3,7 +3,7 @@
 
 # 5. Language
 
-The guide covers two language versions, and a project picks one:
+The guidelines cover two language versions, and a project picks one:
 
 - **[C++20](../Cpp20/LANGUAGE.md)** is the default, for applications and for libraries used inside one product.
 - **[C++17](../Cpp17/LANGUAGE.md)** is for a library meant for other people's projects, because C++17 is still the
@@ -173,4 +173,4 @@ validates it.
 | `alloca`, `setjmp`/`longjmp` | ordinary allocation and returns |
 | User-defined literals | named functions or constructors, except the standard ones such as `std::chrono` suffixes |
 
-The features C++20 adds that the guide does not use are on the [C++20 page](../Cpp20/LANGUAGE.md#not-used).
+The features C++20 adds that the guidelines do not use are on the [C++20 page](../Cpp20/LANGUAGE.md#not-used).
diff --git a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/PRINCIPLES.md b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/PRINCIPLES.md
index 2dbc64f..ebabc18 100644
--- a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/PRINCIPLES.md
+++ b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/PRINCIPLES.md
@@ -3,8 +3,8 @@
 
 # 1. Principles
 
-Every rule in this guide serves one of the principles below. When the guide says nothing about a case, decide by them,
-in this order.
+Every rule in these guidelines serves one of the principles below. When the guidelines say nothing about a case, decide
+by them, in this order.
 
 ## 1.1 Correct before fast, and both before clever
 
@@ -45,12 +45,12 @@ Formatting, naming of members, include order and a long list of bug patterns are
 `clang-tidy` and the compiler, with warnings as errors. A review then spends its attention on what tools cannot judge:
 design, names, ownership, and whether the change does what it says.
 
-## 1.7 Consistency within a project beats consistency with the guide
+## 1.7 Consistency within a project beats consistency with the guidelines
 
-A project that adopts this guide over existing code converges gradually. A file follows the guide where it is touched;
-a mechanical sweep is its own change, never mixed into a behavior change. Where a project deliberately deviates, it
-writes the deviation down once (see [Adopting the guide](../../ADOPTING.md)), and then the project's rule wins in that
-project.
+A project that adopts these guidelines over existing code converges gradually. A file follows the guidelines where it is
+touched; a mechanical sweep is its own change, never mixed into a behavior change. Where a project deliberately
+deviates, it writes the deviation down once (see [Adopting the guidelines](../../ADOPTING.md)), and then the project's
+rule wins in that project.
 
 ## 1.8 Small, explicit dependencies
 
diff --git a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/TESTING.md b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/TESTING.md
index f35013f..4104d31 100644
--- a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/TESTING.md
+++ b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/TESTING.md
@@ -4,7 +4,7 @@
 # 12. Testing
 
 A change that alters behavior comes with a test that fails without it. A bug fix comes with the test that reproduces the
-bug. Tests are code: they follow this guide, they are reviewed, and a flaky test is a bug.
+bug. Tests are code: they follow these guidelines, they are reviewed, and a flaky test is a bug.
 
 ## 12.1 Unit tests
 
@@ -23,7 +23,7 @@ bug. Tests are code: they follow this guide, they are reviewed, and a flaky test
   recorded seed, so a failure can be reproduced.
 - **Fast**: a unit test runs in milliseconds. A slow scenario is a separate, labeled test target.
 
-The guide does not prescribe a test framework. Catch2, [Catch3](https://github.com/Progmasoft/catch3), GoogleTest,
+The guidelines do not prescribe a test framework. Catch2, [Catch3](https://github.com/Progmasoft/catch3), GoogleTest,
 doctest and others all fit; choose one per project and use it everywhere in that project. The example below uses the
 Catch2-style API:
 
diff --git a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/TOOLING.md b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/TOOLING.md
index b6fe3c2..4e2255a 100644
--- a/Progmasoft_Core_Cpp_Coding_Guidelines/Common/TOOLING.md
+++ b/Progmasoft_Core_Cpp_Coding_Guidelines/Common/TOOLING.md
@@ -3,7 +3,8 @@
 
 # 13. Tooling
 
-The guide relies on tools for everything that can be checked mechanically. A project that adopts it turns them all on,
+The guidelines rely on tools for everything that can be checked mechanically. A project that adopts them turns the
+tools all on,
 with warnings as errors, in CI and in the local build alike.
 
 ## 13.1 Compiler
@@ -128,11 +129,11 @@ CheckOptions:
 | --- | --- |
 | `bugprone-easily-swappable-parameters` | flags most functions with two parameters of one type; [strong types](TYPES-AND-CLASSES.md#67-strong-types) address the real risk |
 | `bugprone-exception-escape` | meaningless when exceptions are disabled |
-| `portability-avoid-pragma-once` | the guide uses `#pragma once` on purpose |
-| `modernize-use-auto` | the guide writes types that carry information ([Language](LANGUAGE.md#52-auto)) |
+| `portability-avoid-pragma-once` | the guidelines use `#pragma once` on purpose |
+| `modernize-use-auto` | the guidelines write types that carry information ([Language](LANGUAGE.md#52-auto)) |
 | `modernize-use-emplace` | `push_back` of a constructed value is clearer and equally fast after a move |
-| `modernize-use-trailing-return-type` | the guide uses trailing return types, but not for `void` functions, which the check would rewrite |
-| `readability-braces-around-statements` | braces are required by the guide; the check's fix-its fight `clang-format` |
+| `modernize-use-trailing-return-type` | the guidelines use trailing return types, but not for `void` functions, which the check would rewrite |
+| `readability-braces-around-statements` | braces are required by the guidelines; the check's fix-its fight `clang-format` |
 | `readability-function-size`, `readability-magic-numbers` | judged in review; the fixed thresholds produce more noise than findings |
 | `readability-qualified-auto` | conflicts with writing `auto` for pointers returned by APIs whose type is obvious |
 | `readability-redundant-member-init` | aggregate members keep an explicit `{}` so aggregate initialization that omits trailing fields stays clean under `-Wmissing-field-initializers` |
diff --git a/Progmasoft_Core_Cpp_Coding_Guidelines/Cpp17/LANGUAGE.md b/Progmasoft_Core_Cpp_Coding_Guidelines/Cpp17/LANGUAGE.md
index 034f639..d7bf6ec 100644
--- a/Progmasoft_Core_Cpp_Coding_Guidelines/Cpp17/LANGUAGE.md
+++ b/Progmasoft_Core_Cpp_Coding_Guidelines/Cpp17/LANGUAGE.md
@@ -43,8 +43,8 @@ Where the [C++20 page](../Cpp20/LANGUAGE.md) uses a C++20 feature, a C++17 proje
 
 Code written for C++17 is promised to later standards too, so its checks have to reach them:
 
-- **CI builds and tests in C++17 and in the newest standard the project supports.** A rule of C++20 can reject C++17 code,
-  such as the rewritten comparison operators.
+- **CI builds and tests in C++17 and in the newest standard the project supports.** A rule of C++20 can reject C++17
+  code, such as the rewritten comparison operators.
 - **CI builds with each compiler the project supports, not only Clang.** Clang accepts designated initializers in C++17
   and warns; MSVC rejects them. Clang's `-Wc++20-extensions` shows most of these before CI does.
 - **Headers compile under the default modes of the compilers.** MSVC is permissive in C++17 unless `/permissive-` is
diff --git a/README.md b/README.md
index 5d3fc90..7b23c9a 100644
--- a/README.md
+++ b/README.md
@@ -34,7 +34,7 @@ The guidelines for C++17 and C++20, in `Progmasoft_Core_Cpp_Coding_Guidelines/`.
 
 | Chapter | Covers |
 | --- | --- |
-| [1. Principles](Progmasoft_Core_Cpp_Coding_Guidelines/Common/PRINCIPLES.md) | what the guide optimizes for, and how to decide a case it does not cover |
+| [1. Principles](Progmasoft_Core_Cpp_Coding_Guidelines/Common/PRINCIPLES.md) | what the guidelines optimize for, and how to decide a case they do not cover |
 | [2. Formatting](Progmasoft_Core_Cpp_Coding_Guidelines/Common/FORMATTING.md) | the `.clang-format` profile, and what formatting leaves to the author |
 | [3. Naming](Progmasoft_Core_Cpp_Coding_Guidelines/Common/NAMING.md) | types, functions, variables, constants, namespaces, files, macros |
 | [4. Files and headers](Progmasoft_Core_Cpp_Coding_Guidelines/Common/FILES-AND-HEADERS.md) | extensions, `#pragma once`, includes, file size, the order inside a file |
@@ -55,17 +55,19 @@ Each version has a page of its own with the rules that use its features:
 | [C++20](Progmasoft_Core_Cpp_Coding_Guidelines/Cpp20/LANGUAGE.md) | the default: concepts, designated initializers, defaulted comparisons, ranges, `std::span`, `std::format` |
 | [C++17](Progmasoft_Core_Cpp_Coding_Guidelines/Cpp17/LANGUAGE.md) | for libraries used by other projects: the C++17 form of each C++20 rule, and the checks for later standards |
 
-The guide is in `Progmasoft_Core_Cpp_Coding_Guidelines/`: `Common/` holds what applies to both versions, `Cpp20/` and `Cpp17/` what
-applies to one. [`index.json`](Progmasoft_Core_Cpp_Coding_Guidelines/index.json) lists every document with its chapter and the versions it
-applies to, for tools that show or check the guide.
+The guidelines are in `Progmasoft_Core_Cpp_Coding_Guidelines/`: `Common/` holds what applies to both versions, `Cpp20/`
+and `Cpp17/` what applies to one. [`index.json`](Progmasoft_Core_Cpp_Coding_Guidelines/index.json) lists every document
+with its chapter and the versions it applies to, for tools that show or check the guidelines.
 
-[Adopting the guide](ADOPTING.md) explains how a project points to this guide, which files it copies and how it
+[Adopting the guidelines](ADOPTING.md) explains how a project points to them, which files it copies and how it
 records a deviation. [Contributing](CONTRIBUTING.md) explains how to propose a change to a rule.
 
 ### The short version
 
-- C++17 or C++20, formatted by the [clang-format profile](Progmasoft_Core_Cpp_Coding_Guidelines/Common/FORMATTING.md#the-profile), checked by the
-  [clang-tidy profile](Progmasoft_Core_Cpp_Coding_Guidelines/Common/TOOLING.md#132-the-clang-tidy-profile) with every warning an error.
+- C++17 or C++20, formatted by the [clang-format
+  profile](Progmasoft_Core_Cpp_Coding_Guidelines/Common/FORMATTING.md#the-profile), checked by the [clang-tidy
+  profile](Progmasoft_Core_Cpp_Coding_Guidelines/Common/TOOLING.md#132-the-clang-tidy-profile) with every warning an
+  error.
 - `PascalCase` for types, functions and namespaces; `camelCase` for variables and parameters; `name_` for private data
   members; `kPascalCase` for constants and enumerators; `UPPER_SNAKE_CASE` for macros.
 - Four spaces, braces on their own line, 80 columns, the return type on its own line.
@@ -74,7 +76,7 @@ records a deviation. [Contributing](CONTRIBUTING.md) explains how to propose a c
 - No `using namespace`. No exceptions in libraries and tools: recoverable failures return `Expected<T>` or `Error`.
 - Ownership is visible in the type: values and `std::unique_ptr` own, references and views borrow.
 - Every public declaration has a `///` comment, in US English.
-- Tests sit next to the code they test; sanitizers and fuzzers run in CI. The guide prescribes no test, fuzzing or
+- Tests sit next to the code they test; sanitizers and fuzzers run in CI. The guidelines prescribe no test, fuzzing or
   benchmark framework, and no error library: it prescribes how they are used.
 
 ## License