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>

1 files changed, 7 insertions, 7 deletions

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.