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>

7 files changed, 24 insertions, 22 deletions

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` |