docs: join broken sentences (one sentence per line)

Join lines where a single sentence was broken across multiple lines.
Per Plone style, each sentence should be exactly one line for clean
diffs. Also fix code blocks in write-custom-templates.md that were
incorrectly joined, and restore admonition formatting.

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

Author: jensens

docs/sources/explanation/architecture.md

@@ -14,9 +14,7 @@ myst:
 ## Overview
 
 plone.meta is a code generation tool.
-It reads per-repository configuration
-from {file}`.meta.toml`, renders Jinja2 templates, validates the output, and
-manages git operations.
+It reads per-repository configuration from {file}`.meta.toml`, renders Jinja2 templates, validates the output, and manages git operations.
 
 ## Components
 
@@ -26,17 +24,13 @@ The core of plone.meta is a set of Jinja2 templates stored in
 {file}`src/plone/meta/default/`.
 Each template corresponds to a configuration file in the target repository.
 
-Templates use `%(variable)s` style placeholders (Python string formatting
-syntax within the Jinja2 context) for inserting configuration values.
-The template engine has `trim_blocks` and `lstrip_blocks` enabled for clean
-output, and `keep_trailing_newline` preserves proper file endings.
+Templates use `%(variable)s` style placeholders (Python string formatting syntax within the Jinja2 context) for inserting configuration values.
+The template engine has `trim_blocks` and `lstrip_blocks` enabled for clean output, and `keep_trailing_newline` preserves proper file endings.
 
 #### Modular tox templates
 
-The {file}`tox.ini.j2` template uses a modular architecture with Jinja2
-`{% include %}` directives.
-Rather than a single monolithic template, the tox configuration is composed
-from focused sub-templates:
+The {file}`tox.ini.j2` template uses a modular architecture with Jinja2 `{% include %}` directives.
+Rather than a single monolithic template, the tox configuration is composed from focused sub-templates:
 
 - {file}`tox-init.j2` -- tox initialization and configuration header
 - {file}`tox-base.j2` -- base test environment definition
@@ -49,8 +43,7 @@ This modular structure makes the templates easier to maintain and extend.
 
 ### PackageConfiguration class
 
-The {file}`config_package.py` module contains the `PackageConfiguration` class,
-which orchestrates the entire process:
+The {file}`config_package.py` module contains the `PackageConfiguration` class, which orchestrates the entire process:
 
 1. **Read** {file}`.meta.toml` from the target repository
 2. **Detect** whether the repository is GitHub or GitLab hosted
@@ -82,15 +75,11 @@ If validation fails, you are prompted to proceed or abort.
 2. Commits all changes with a descriptive message
 3. Optionally pushes to the remote
 
-Branch names follow the pattern `config-with-<type>-template-<commit-hash>`,
-where the commit hash refers to the plone.meta repository, making it clear
-which version of the templates was used.
+Branch names follow the pattern `config-with-<type>-template-<commit-hash>`, where the commit hash refers to the plone.meta repository, making it clear which version of the templates was used.
 
 ## GitHub Actions workflow architecture
 
-Rather than generating complete CI workflows inline, plone.meta generates
-a thin {file}`meta.yml` that uses GitHub's `workflow_call` to reference reusable
-workflows stored in the plone/meta repository itself.
+Rather than generating complete CI workflows inline, plone.meta generates a thin {file}`meta.yml` that uses GitHub's `workflow_call` to reference reusable workflows stored in the plone/meta repository itself.
 This means:
 
 - Workflow logic is maintained in one place
@@ -101,10 +90,8 @@ This means:
 ## Test matrix
 
 A key architectural feature of plone.meta 2.x is the test matrix.
-Rather than testing against a single Python version, plone.meta generates
-test environments for all combinations of Plone versions and Python versions.
-The default matrix covers Plone 6.0, 6.1, and 6.2 across Python 3.10
-through 3.14.
+Rather than testing against a single Python version, plone.meta generates test environments for all combinations of Plone versions and Python versions.
+The default matrix covers Plone 6.0, 6.1, and 6.2 across Python 3.10 through 3.14.
 
 The test matrix is reflected in multiple generated outputs:
 
@@ -114,8 +101,7 @@ The test matrix is reflected in multiple generated outputs:
   matrix combinations in CI
 - **GitLab CI**: Matrix jobs are generated in {file}`.gitlab-ci.yml`
 
-Each combination uses its own constraints file, allowing different Plone
-versions to pin different dependency versions.
+Each combination uses its own constraints file, allowing different Plone versions to pin different dependency versions.
 
 ## Data flow
 

docs/sources/explanation/configuration-philosophy.md

@@ -20,10 +20,8 @@ plone.meta is designed around two principles:
 
 ## The extra_lines approach
 
-Rather than adding a configuration option for every possible customization,
-almost all generated files support an `extra_lines` key in {file}`.meta.toml`.
-This key accepts raw configuration text that is appended to the generated
-file.
+Rather than adding a configuration option for every possible customization, almost all generated files support an `extra_lines` key in {file}`.meta.toml`.
+This key accepts raw configuration text that is appended to the generated file.
 
 This approach has several advantages:
 
@@ -33,33 +31,24 @@ This approach has several advantages:
 - **Low maintenance:** New configuration options in tools (flake8, tox,
   isort, etc.) do not require changes to plone.meta itself.
 
-The tradeoff is that `extra_lines` content is not validated against the
-template -- it is simply appended.
-But this is intentional: it keeps the tool simple and avoids becoming a
-configuration management framework.
+The tradeoff is that `extra_lines` content is not validated against the template -- it is simply appended.
+But this is intentional: it keeps the tool simple and avoids becoming a configuration management framework.
 
 ## When extra_lines is not enough
 
-For cases where appending text is insufficient -- where the configuration
-needs to *change* the template output rather than extend it -- plone.meta
-provides specific configuration keys. Examples:
+For cases where appending text is insufficient -- where the configuration needs to *change* the template output rather than extend it -- plone.meta provides specific configuration keys. Examples:
 
 - `test_runner` to switch between pytest and zope.testrunner
 - `constraints_file` to override the default pip constraints URL
 - `custom_image` to change the GitLab CI Docker image
 - `jobs` to select which CI jobs are enabled
 
 These options are added conservatively.
-If you need a customization that
-plone.meta does not support, you can
-[request it](https://github.com/plone/meta/issues/new).
+If you need a customization that plone.meta does not support, you can [request it](https://github.com/plone/meta/issues/new).
 
 ## Don't edit generated files
 
-This is the cardinal rule of plone.meta: **never directly edit the files
-that plone.meta manages.**
-Any changes will be overwritten the next time `config-package` runs.
+This is the cardinal rule of plone.meta: **never directly edit the files that plone.meta manages.** Any changes will be overwritten the next time `config-package` runs.
 
 All customization goes through {file}`.meta.toml`.
-This single file captures the complete delta between the defaults and your
-repository's needs, making it easy to review, maintain, and update.
+This single file captures the complete delta between the defaults and your repository's needs, making it easy to review, maintain, and update.

docs/sources/explanation/index.md

@@ -21,24 +21,21 @@ These pages help you understand *why* plone.meta works the way it does.
 :link: why-standardize
 :link-type: doc
 
-The motivation behind plone.meta: what problems it solves, what it replaces,
-and why centralized configuration management matters for the Plone ecosystem.
+The motivation behind plone.meta: what problems it solves, what it replaces, and why centralized configuration management matters for the Plone ecosystem.
 :::
 
 :::{grid-item-card} Architecture
 :link: architecture
 :link-type: doc
 
-How plone.meta works internally: template rendering, file generation,
-validation, and the git workflow.
+How plone.meta works internally: template rendering, file generation, validation, and the git workflow.
 :::
 
 :::{grid-item-card} Configuration Philosophy
 :link: configuration-philosophy
 :link-type: doc
 
-The design principles behind the `extra_lines` approach: sane defaults
-with simple extensibility.
+The design principles behind the `extra_lines` approach: sane defaults with simple extensibility.
 :::
 
 :::{grid-item-card} Scope and Limitations

docs/sources/explanation/scope.md

@@ -13,8 +13,7 @@ myst:
 
 ## What plone.meta covers
 
-plone.meta manages configuration files for **single-package Python
-repositories** in the Plone ecosystem.
+plone.meta manages configuration files for **single-package Python repositories** in the Plone ecosystem.
 This includes:
 
 - Development tool configuration (linting, formatting, editor settings)
@@ -28,38 +27,26 @@ This includes:
 
 ### JavaScript and frontend projects
 
-Volto and other JavaScript-based projects have their own ecosystem with
-different tooling (ESLint, Prettier, Jest, etc.).
+Volto and other JavaScript-based projects have their own ecosystem with different tooling (ESLint, Prettier, Jest, etc.).
 plone.meta is strictly for Python projects.
 
 ### Monorepo projects
 
-Repositories with both backend and frontend code bases -- such as those
-created by [Cookieplone](https://github.com/plone/cookieplone) -- are
-not supported.
+Repositories with both backend and frontend code bases -- such as those created by [Cookieplone](https://github.com/plone/cookieplone) -- are not supported.
 plone.meta expects a single Python package at the top level of the repository.
 
 ### Multi-version support
 
-plone.meta allows testing against multiple Plone versions via the
-`test_matrix` configuration.
-However, it does not support maintaining
-entirely separate dependency sets or build configurations for different
-major Plone versions within a single branch.
+plone.meta allows testing against multiple Plone versions via the `test_matrix` configuration.
+However, it does not support maintaining entirely separate dependency sets or build configurations for different major Plone versions within a single branch.
 
 ### Package scaffolding
 
 plone.meta does not create new packages.
 It configures existing ones.
-For creating new Plone packages, use
-[Cookieplone](https://github.com/plone/cookieplone) or
-[plonecli](https://pypi.org/project/plonecli/).
+For creating new Plone packages, use [Cookieplone](https://github.com/plone/cookieplone) or [plonecli](https://pypi.org/project/plonecli/).
 
 ### Custom CI logic
 
 plone.meta generates standardized CI pipelines.
-If your package needs
-significantly custom CI logic (custom Docker builds, deployment steps,
-integration tests with external services), you can extend via `extra_lines`,
-but at some point it may make more sense to maintain CI configuration
-manually.
+If your package needs significantly custom CI logic (custom Docker builds, deployment steps, integration tests with external services), you can extend via `extra_lines`, but at some point it may make more sense to maintain CI configuration manually.

docs/sources/explanation/why-standardize.md

@@ -13,8 +13,7 @@ myst:
 
 ## The problem
 
-The Plone ecosystem consists of over 100 Python packages, each maintained by
-different people at different times.
+The Plone ecosystem consists of over 100 Python packages, each maintained by different people at different times.
 Without coordination, each repository develops its own approach to:
 
 - Test configuration and runners
@@ -25,15 +24,12 @@ Without coordination, each repository develops its own approach to:
 - Release processes
 
 This leads to fragmentation.
-A developer picking up a new package has to figure out from scratch how to
-run tests, what formatting rules apply, and whether the CI pipeline is current.
-Contributions become harder because the answer to "how do I run the tests?"
-differs for every package.
+A developer picking up a new package has to figure out from scratch how to run tests, what formatting rules apply, and whether the CI pipeline is current.
+Contributions become harder because the answer to "how do I run the tests?" differs for every package.
 
 ## What plone.meta solves
 
-By using plone.meta, every Plone package answers the same set of questions
-in the same way:
+By using plone.meta, every Plone package answers the same set of questions in the same way:
 
 - **Do the tests pass?** `tox -e test`
 - **What's the test coverage?** `tox -e coverage`
@@ -51,12 +47,9 @@ Tooling evolves.
 Linting rules change.
 New Python versions are released.
 CI providers update their APIs.
-Without centralization, updating 100+
-repositories is impractical -- each one needs manual changes, review, and
-testing.
+Without centralization, updating 100+ repositories is impractical -- each one needs manual changes, review, and testing.
 
-With plone.meta, a tooling update happens in one place (the templates),
-and is then rolled out to all packages via `config-package` or `multi-call`.
+With plone.meta, a tooling update happens in one place (the templates), and is then rolled out to all packages via `config-package` or `multi-call`.
 This makes it practical to:
 
 - Adopt new tools (e.g., switching formatters)
@@ -65,8 +58,5 @@ This makes it practical to:
 
 ## Adoption
 
-plone.meta is mandatory for repositories under the
-[GitHub Plone organization](https://github.com/plone).
-It is encouraged for repositories under the
-[collective Plone organization](https://github.com/collective) and for
-private packages.
+plone.meta is mandatory for repositories under the [GitHub Plone organization](https://github.com/plone).
+It is encouraged for repositories under the [collective Plone organization](https://github.com/collective) and for private packages.

docs/sources/how-to/configure-github-actions.md

@@ -11,8 +11,7 @@ myst:
 
 <!-- diataxis: how-to -->
 
-`plone.meta` generates a {file}`.github/workflows/meta.yml` file that references
-reusable workflows from the plone/meta repository.
+`plone.meta` generates a {file}`.github/workflows/meta.yml` file that references reusable workflows from the plone/meta repository.
 
 ## Select CI jobs
 
@@ -30,9 +29,7 @@ jobs = [
 ```
 
 :::{note}
-The `"test"` job is no longer included in the default jobs list. Testing
-is now handled by the separate {file}`test-matrix.yml` workflow, which is
-generated automatically when `use_test_matrix` is enabled (the default).
+The `"test"` job is no longer included in the default jobs list. Testing is now handled by the separate {file}`test-matrix.yml` workflow, which is generated automatically when `use_test_matrix` is enabled (the default).
 :::
 
 Available jobs:
@@ -88,8 +85,7 @@ os_dependencies = "git libxml2 libxslt1-dev"
 
 ## Add lines after OS dependency installation
 
-Use `extra_lines_after_os_dependencies` to insert additional setup steps
-that run after the OS-level dependencies are installed but before tests:
+Use `extra_lines_after_os_dependencies` to insert additional setup steps that run after the OS-level dependencies are installed but before tests:
 
 ```toml
 [github]
@@ -101,9 +97,7 @@ extra_lines_after_os_dependencies = """
 
 ## Test matrix workflow
 
-When `use_test_matrix` is enabled (the default), plone.meta generates a
-separate {file}`test-matrix.yml` workflow that tests all combinations of Plone
-versions and Python versions.
+When `use_test_matrix` is enabled (the default), plone.meta generates a separate {file}`test-matrix.yml` workflow that tests all combinations of Plone versions and Python versions.
 This replaces the old single-version `test` job.
 
 The matrix is configured in the `[tox]` section:
@@ -114,17 +108,14 @@ use_test_matrix = true
 test_matrix = {"6.2" = ["3.14", "3.13", "3.12", "3.11", "3.10"], "6.1" = ["3.13", "3.12", "3.11", "3.10"]}
 ```
 
-Using `"*"` as shorthand includes all currently supported Python versions
-for a given Plone version:
+Using `"*"` as shorthand includes all currently supported Python versions for a given Plone version:
 
 ```toml
 [tox]
 test_matrix = {"6.2" = ["*"]}
 ```
 
-To disable the test matrix and fall back to a single test job, set
-`use_test_matrix = false` in the `[tox]` section and add `"test"` back to
-the `[github] jobs` list.
+To disable the test matrix and fall back to a single test job, set `use_test_matrix = false` in the `[tox]` section and add `"test"` back to the `[github] jobs` list.
 
 ## Add extra workflow jobs
 

docs/sources/how-to/configure-gitlab-ci.md

@@ -11,8 +11,7 @@ myst:
 
 <!-- diataxis: how-to -->
 
-For repositories hosted on GitLab, `plone.meta` generates a {file}`.gitlab-ci.yml`
-file instead of GitHub Actions workflows.
+For repositories hosted on GitLab, `plone.meta` generates a {file}`.gitlab-ci.yml` file instead of GitHub Actions workflows.
 
 ## Select CI jobs
 
@@ -30,16 +29,14 @@ jobs = [
 
 ## Use custom Docker images
 
-Specify Docker images per Python version using the `custom_images`
-dictionary:
+Specify Docker images per Python version using the `custom_images` dictionary:
 
 ```toml
 [gitlab]
 custom_images = {"3.14" = "python:3.14-trixie", "3.13" = "python:3.13-trixie"}
 ```
 
-This allows different Python versions in the CI matrix to use appropriate
-base images (for example, Debian Trixie for Python 3.14 support).
+This allows different Python versions in the CI matrix to use appropriate base images (for example, Debian Trixie for Python 3.14 support).
 
 ## Install OS-level dependencies
 
@@ -53,12 +50,9 @@ os_dependencies = """
 ## Test matrix support
 
 GitLab CI also benefits from the test matrix feature.
-When `use_test_matrix` is enabled (the default), the generated {file}`.gitlab-ci.yml`
-will include test jobs for each combination of Plone version and Python
-version defined in `[tox] test_matrix`.
+When `use_test_matrix` is enabled (the default), the generated {file}`.gitlab-ci.yml` will include test jobs for each combination of Plone version and Python version defined in `[tox] test_matrix`.
 
-See {doc}`/how-to/customize-meta-toml` for details on configuring the
-test matrix.
+See {doc}`/how-to/customize-meta-toml` for details on configuring the test matrix.
 
 ## Add extra configuration
 

docs/sources/how-to/custom-branch.md

@@ -11,8 +11,7 @@ myst:
 
 <!-- diataxis: how-to -->
 
-By default, `config-package` creates a branch named
-`config-with-default-template-<commit-hash>`.
+By default, `config-package` creates a branch named `config-with-default-template-<commit-hash>`.
 You can override this.
 
 ## Use a specific branch name
@@ -32,5 +31,4 @@ To apply changes without creating a new branch:
 venv/bin/config-package --branch current /path/to/package
 ```
 
-This is useful when you have already created a branch manually and want to
-update it with the latest configuration.
+This is useful when you have already created a branch manually and want to update it with the latest configuration.