fix(*): add extra blank line before the first entry in list

docs/appendices/group-policies.md

@@ -22,6 +22,7 @@ Examples: `phase-transition-solver`, `gw-spectrum-calculator-py`.
 
 ### R3 — Required Files
 Every repository must contain at the time of first collaborator access:
+
 - `README.md` (using the group template)
 - `.gitignore` (appropriate for the primary language)
 - `LICENSE` (MIT unless the PI specifies otherwise)
@@ -157,6 +158,7 @@ user-facing behaviour.
 
 Policies are updated via Pull Request to this handbook.
 Proposed policy changes must:
+
 1. Be discussed in a group meeting or in an Issue before opening a PR.
 2. Be approved by the PI.
 3. Be communicated to all active group members after merging.

docs/appendices/research-software-principles.md

@@ -30,6 +30,7 @@ paper that describes it. It deserves the same level of care, documentation,
 and peer review.
 
 Consequences:
+
 - Code review is peer review, not gatekeeping.
 - A function without a citation to its source equation is incomplete.
 - "It works on my machine" is not scientific validation.
@@ -65,6 +66,7 @@ Version control is not for programmers — it is for anyone who produces
 files that change over time and whose history matters.
 
 In this group, version control applies to:
+
 - Simulation code
 - Analysis scripts
 - Figure-generation scripts
@@ -73,6 +75,7 @@ In this group, version control applies to:
 - This handbook
 
 **Not** managed by the group's repositories:
+
 - Raw experimental data (managed separately)
 - Large simulation outputs (referenced by path, not stored in Git)
 - Binary assets and generated figures (regenerated from code)
@@ -85,6 +88,7 @@ Consistency across the group matters more than any individual's preferred workfl
 
 The canonical workflow in this handbook is not the only valid approach to Git.
 There are many legitimate alternatives. We use one because:
+
 - Onboarding is faster when everyone does the same thing
 - Code review is easier when history has a predictable structure
 - Debugging is faster when `git log` is clean and squashed
@@ -101,6 +105,7 @@ The minimum testing bar for research code is not code coverage percentage —
 it is: *can you trust the results enough to put them in a paper?*
 
 Practically, this means:
+
 - Every numerical result that appears in a figure must have a test
 - Every equation implementation must be validated against a known special case
 - Every bug fix must be accompanied by a regression test
@@ -116,6 +121,7 @@ future self. Documenting your work is an act of respect for your collaborators
 and the scientific community.
 
 Minimum documentation standards:
+
 - Every function explains what it does and what its parameters mean
 - Every non-trivial algorithm cites its source
 - Every repository has a README that a newcomer can follow
@@ -161,6 +167,7 @@ into a published figure.
 ## 10. The Handbook Is a Living Document
 
 This handbook describes current best practices. It will need to change as:
+
 - The group grows
 - New tools become available
 - Current practices are found to be ineffective

docs/maintainer/01-repo-creation.md

@@ -75,6 +75,7 @@ A well-labelled repository is discoverable and professional.
      ```
      physics  cosmology  phase-transition  python  research-code
      ```
+
 3. Click **Save changes**.
 
 ---
@@ -92,6 +93,7 @@ ls -la
 ```
 
 Confirm:
+
 - `.gitignore` is present and appropriate for the language
 - `README.md` is present
 - `LICENSE` is present

docs/maintainer/03-branch-protection.md

@@ -28,6 +28,7 @@ Configure the rule for the branch name pattern: `main`
 ✓ **Enable:** "Require a pull request before merging"
 
 Sub-options:
+
 - **"Require approvals":** ✓ Enable — set to **1** (minimum; increase when group grows)
 - **"Dismiss stale pull request approvals when new commits are pushed":** ✓ Enable
 
@@ -43,6 +44,7 @@ Sub-options:
 ✓ **Enable:** "Require status checks to pass before merging"
 
 Sub-options:
+
 - **"Require branches to be up to date before merging":** ✓ Enable
 
   *Why:* Prevents a PR from merging if `main` has advanced since the PR branch

docs/maintainer/04-collaborators.md

@@ -54,6 +54,7 @@ graph TD
 5. GitHub sends an invitation email. The collaborator must accept within 7 days.
 
 Verify acceptance:
+
 - Settings → Collaborators → look for "Pending" status
 - Follow up if pending for more than 2 business days
 
@@ -100,6 +101,7 @@ Access for individual repository:
 **Repository → Insights → (not available) — use organisation audit log**
 
 Use the audit log to:
+
 - Verify that a student accepted their invitation
 - Confirm who made a settings change
 - Investigate unexpected repository actions

docs/maintainer/05-labels.md

@@ -100,17 +100,20 @@ gh label create "status: stale" --color "cccccc" --description "No activity for
 ## Applying Labels Consistently
 
 **Labels on Issues:**
+
 - Apply `type:` label when creating the issue
 - Apply `priority:` label if urgency is known
 - Apply `status:` as work progresses
 
 **Labels on Pull Requests:**
+
 - Apply `type:` label to every PR (students should do this when opening the PR)
 - Apply `priority: high` for urgent fixes
 - Apply `status: needs-review` when the PR is ready for review
 - Remove `status: needs-review` and add `status: stale` if the PR goes cold
 
 **Periodic triage (recommended: weekly):**
+
 - Review open issues and PRs without labels
 - Apply `status: stale` to anything with no activity for 30+ days
 - Prompt authors or close stale items

docs/maintainer/06-milestones.md

@@ -12,6 +12,7 @@ They are the primary tool for deadline-driven planning in the group.
 ## What Is a Milestone?
 
 A milestone has:
+
 - A **title** (the goal)
 - An optional **description** (what done looks like)
 - A **due date**
@@ -63,9 +64,11 @@ A milestone without a due date is just a label with extra steps.
 ## Assigning Issues and PRs to Milestones
 
 When opening or editing an Issue or PR:
+
 - Right sidebar → **Milestone** → select the appropriate milestone
 
 For batch assignment:
+
 - **Issues** → check multiple issues → **Milestone** dropdown
 
 **Policy:** Every issue and PR that must be completed before a deadline
@@ -81,6 +84,7 @@ Navigate to **Issues → Milestones** to see all milestones and their completion
 The progress bar shows `X of Y issues/PRs closed`.
 
 Use this in group meetings to communicate:
+
 - How much remains before the deadline
 - Which items are blocking progress
 - Whether the deadline is realistic

docs/maintainer/07-project-board.md

@@ -52,10 +52,12 @@ Add these fields to track status alongside the default title/assignee:
 ## Linking Issues and PRs to the Board
 
 When creating an issue or PR:
+
 - Right sidebar → **Projects** → select the board
 - Set the **Status** field to the appropriate column
 
 When work progresses, update the status:
+
 - Created issue → **Backlog**
 - Work started, branch created → **In Progress**
 - PR opened → **In Review**

docs/maintainer/08-review-workflow.md

@@ -30,6 +30,7 @@ someone with Maintain or Admin permission.
 The group policy: **respond to a PR within 2 working days** of it being assigned.
 
 "Respond" means:
+
 - Approve and merge, or
 - Leave at least one substantive comment and request changes, or
 - Leave a comment explaining a delay ("I'll review this by [date]")
@@ -124,6 +125,7 @@ The maintainer merges the PR:
 
 1. Confirm the branch is up to date with `main` (GitHub shows a warning if not).
    If not: ask the author to rebase, or click "Update branch" (merge) as a last resort.
+
 2. Confirm all conversations are resolved.
 3. Confirm CI passes (once CI is active).
 4. Click **"Squash and merge"**.
@@ -133,6 +135,7 @@ The maintainer merges the PR:
 
    Optional: one-line context if the title is not fully self-explanatory.
    ```
+
 6. Click **"Confirm squash and merge"**.
 7. The remote branch is deleted automatically.
 
@@ -143,6 +146,7 @@ The maintainer merges the PR:
 A PR is stale if the author has not responded to review feedback within 7 days.
 
 Steps:
+
 1. Leave a comment: *"Pinging @author — any update on this? Happy to help if you're stuck."*
 2. Wait 3 more days.
 3. If still no response: label `status: stale`.

docs/maintainer/09-merge-strategy.md

@@ -79,6 +79,7 @@ Update installation documentation (#71)
 ```
 
 Rules:
+
 - **Imperative tense** (same as individual commit messages)
 - **PR number in parentheses** at the end — links back to the PR discussion
 - **One line** is sufficient for the subject

docs/maintainer/10-releases.md

@@ -12,6 +12,7 @@ presentations, and stable versions shared with collaborators.
 ## What Is a Release?
 
 A GitHub Release consists of:
+
 - A **Git tag** (the specific commit being released)
 - A **title** (human-readable version name)
 - **Release notes** (what changed)
@@ -44,6 +45,7 @@ All releases use **Semantic Versioning**: `MAJOR.MINOR.PATCH`
 | `PATCH` | Bug fixes, no new features | `1.0.0 → 1.0.1` |
 
 For research code:
+
 - The **first stable, tested version** is `v1.0.0`
 - **New calculations added** → increment MINOR
 - **Bug fixes** → increment PATCH
@@ -109,18 +111,22 @@ changed and why. Organise by category:
 This release corresponds to the code submitted with arXiv:XXXX.XXXXX.
 
 ### New Features
+
 - Added one-loop thermal correction to effective potential (#42)
 - Added gravitational wave spectrum calculator (#51)
 
 ### Bug Fixes
+
 - Fixed interpolation overflow at high temperature (#55)
 - Corrected sign error in bubble nucleation rate (#57)
 
 ### Documentation
+
 - Updated installation instructions for macOS (#61)
 - Added worked example in docs/examples/ (#63)
 
 ### Breaking Changes
+
 - `compute_potential()` now requires `include_thermal` keyword argument.
   Update existing code: `compute_potential(phi, T, include_thermal=False)`
 ```
@@ -131,6 +137,7 @@ This release corresponds to the code submitted with arXiv:XXXX.XXXXX.
 
 For most research code releases, the auto-generated source archive is sufficient.
 Attach additional assets only when:
+
 - Pre-compiled binaries are provided for reproducibility
 - Large input data files are needed to run the code
 - A specific dataset snapshot is being archived with the release

docs/maintainer/12-documentation-policy.md

@@ -17,6 +17,7 @@ This chapter defines the minimum documentation standards for all group repositor
 
 Every function or class that other code calls must have a docstring.
 The docstring must include:
+
 - **Purpose:** what the function does in one sentence
 - **Parameters:** name, type, meaning, and expected range for each parameter
 - **Return value:** type and meaning
@@ -72,6 +73,7 @@ double thermal_correction(double phi, double T, double g2);
 ### 2. Every Non-Obvious Algorithm
 
 Any non-trivial numerical method must include:
+
 - A citation to the source paper or textbook
 - The equation number being implemented
 - Any assumptions or approximations made
@@ -125,6 +127,7 @@ The README is the first thing a new user reads. It must accurately reflect the
 current state of the code.
 
 Review the README when:
+
 - A new feature significantly changes usage
 - Installation instructions change
 - Dependencies are updated
@@ -175,6 +178,7 @@ Documentation is part of the review checklist (Chapter 8).
 A PR that adds a function without a docstring should not be approved.
 
 Specifically check:
+
 - [ ] New public functions have docstrings with parameter and return docs
 - [ ] Non-obvious algorithms reference their source equation/paper
 - [ ] New scripts have header comments with usage

docs/maintainer/13-testing-policy.md

@@ -16,12 +16,14 @@ This chapter defines the minimum testing requirements for all group repositories
 **Not every line needs a test. Every result that gets published does.**
 
 The following must always have tests:
+
 - Numerical solvers (regression tests with known outputs)
 - Any function whose output appears in a paper figure
 - Parser and file-loading functions (edge cases and malformed inputs)
 - Any function that is non-trivial to inspect visually
 
 The following does not need automated tests:
+
 - Plotting and visualisation functions
 - One-time utility scripts
 - Simple file path manipulation
@@ -117,6 +119,7 @@ tests/
 **Test function naming:** `test_<what_is_being_tested>_<condition>()`
 
 Examples:
+
 - `test_thermal_correction_known_value()`
 - `test_thermal_correction_zero_temperature()`
 - `test_potential_minimum_location_at_T0()`

docs/maintainer/14-ci-preparation.md

@@ -13,11 +13,13 @@ This chapter prepares the repository for CI using GitHub Actions.
 ## What Is CI and Why the Group Needs It
 
 Without CI:
+
 - Tests run only when someone remembers
 - "Tests pass" in the PR description is unverifiable
 - A broken `main` requires manual diagnosis
 
 With CI:
+
 - Tests run automatically on every PR
 - A red ✗ on the PR blocks merge (once status checks are required in Chapter 3)
 - `main` is always in a tested state

docs/maintainer/15-backup-strategy.md

@@ -28,6 +28,7 @@ history exist.
 
 The backup is only as good as the most recent push.
 All branches with meaningful work must be pushed to GitHub before:
+
 - Extended absences (vacations, field work, conferences)
 - Leaving the group
 - Handing off a project
@@ -97,6 +98,7 @@ git push --tags origin
 | Every month (active projects) | Recommended |
 
 Store bundles on:
+
 - The group's institutional server (if available)
 - An external hard drive stored at the institute
 - A cloud storage service with access controlled by the PI

docs/maintainer/16-archiving.md

@@ -6,6 +6,7 @@ A repository should be archived when a project is complete: the paper is publish
 the code is stable, and no further active development is planned.
 
 Archiving is distinct from deletion. An archived repository:
+
 - Remains accessible on GitHub
 - Is clearly marked as inactive (read-only)
 - Can be cloned and cited forever
@@ -57,6 +58,7 @@ The release notes should include the paper DOI and a summary of what the code do
 ### 2. Update README
 
 The README should clearly state:
+
 - The paper this code corresponds to (with full citation and DOI)
 - That the repository is archived and not actively maintained
 - Contact information for questions (PI email)

docs/maintainer/18-student-onboarding.md

@@ -74,6 +74,7 @@ with the student. Have them:
 ## The First PR Review: A Teaching Moment
 
 Review the student's first PR yourself, leaving **pedagogical comments**:
+
 - Point out what they did well
 - Explain (not just flag) any issues with commit message, PR description, etc.
 - Approve and merge together so they see the full cycle