Reformat Markdown with mdtablefix (mdformat-all)

AGENTS.md

@@ -22,9 +22,9 @@
   examples demonstrating usage and outcome. Test documentation should omit
   examples that only restate the test logic.
 - **Keep file size manageable.** No single code file should be longer than 400
-  lines. Long switch statements or dispatch tables should be broken up by feature
-  and constituents colocated with targets. Large blocks of test data should be
-  moved to external data files.
+  lines. Long switch statements or dispatch tables should be broken up by
+  feature and constituents colocated with targets. Large blocks of test data
+  should be moved to external data files.
 - **Name things precisely.** Use clear, descriptive variable and function names.
   For booleans, prefer names with `is`, `has`, or `should`.
 - **Structure logically.** Each file should encapsulate a coherent module. Group
@@ -64,7 +64,8 @@
   commit, ensure all of the following are met:
   - New functionality or behaviour changes are fully validated by relevant unit
     and behavioural tests.
-  - Bug fixes include a failing test before the fix and a passing test afterward.
+  - Bug fixes include a failing test before the fix and a passing test
+    afterward.
   - Code passes lint checks.
   - Formatting is correct and validated.
 - **For Python files:**
@@ -78,7 +79,8 @@
   - **Mermaid diagrams:** Passes validation using nixie (`make nixie`).
 - **Committing:**
   - Only changes that meet all quality gates should be committed.
-  - Write clear, descriptive commit messages that summarise the change, following:
+  - Write clear, descriptive commit messages that summarise the change,
+    following:
     - **Imperative mood** in the subject line (for example, "Fix bug", "Add feature").
     - **Subject line length:** around 50 characters or fewer.
     - **Body:** Separate subject from body with a blank line. Explain *what* and
@@ -100,7 +102,8 @@
     to calculating or deriving one value.
   - **Primitive obsession / data clumps:** groups of simple variables that are
     frequently passed together, which may indicate a missing abstraction.
-  - **Excessive parameters:** functions or methods requiring too many parameters.
+  - **Excessive parameters:** functions or methods requiring too many
+    parameters.
   - **Feature envy:** methods that focus more on other data than their own.
   - **Shotgun surgery:** one change that forces many files to be edited.
 - **Abstraction / port / helper policy:** before adding a new abstraction, port,
@@ -110,7 +113,8 @@
   - Document the new abstraction's intended scope and re-use policy.
   - Record the decision in architecture, design, or developers-guide docs using
     `docs/contents.md` as the index.
-- **Post-commit review:** after functional changes or bug fixes that meet quality
+- **Post-commit review:** after functional changes or bug fixes that meet
+  quality
   gates, review changed code and adjacent areas using these heuristics.
 - **Separate atomic refactors:** if refactoring is required, implement it in a
   separate atomic commit after the functional change and ensure it passes all
@@ -123,11 +127,13 @@
 - Snapshot tests (using `syrupy`) should be provided where multivariant output
   format consistency is relevant to the requirements.
 - Add end-to-end tests where a change affects externally observable workflows,
-  integration contracts, persistence, command-line behaviour, network boundaries,
-  user interface flows, or other system-level behaviour.
-- Use property tests with `hypothesis` or `CrossHair` when a change introduces an
+  integration contracts, persistence, command-line behaviour, network
+  boundaries, user interface flows, or other system-level behaviour.
+- Use property tests with `hypothesis` or `CrossHair` when a change introduces
+  an
   invariant over a range of inputs, states, orderings, or transitions.
-- Run relevant unit, behavioural, property, and end-to-end suites before and after
+- Run relevant unit, behavioural, property, and end-to-end suites before and
+  after
   each change.
 
 ## Markdown guidance
@@ -144,14 +150,14 @@
 
 ## Project documentation
 
-Record design decisions in the design document. Where a decision is substantive,
-record it in an ADR document following the documentation style guide, then
-reference that ADR from the design document.
+Record design decisions in the design document. Where a decision is
+substantive, record it in an ADR document following the documentation style
+guide, then reference that ADR from the design document.
 
 Update `docs/users-guide.md` for any change to application behaviour or user
 interface that users should know about. Document internally facing interfaces
-or practices in the relevant component architecture document. Document internally
-facing conventions or practices in `docs/developers-guide.md`.
+or practices in the relevant component architecture document. Document
+internally facing conventions or practices in `docs/developers-guide.md`.
 
 ## Python development guidelines
 

README.md

@@ -29,10 +29,10 @@ The Bun toolchain remains in use for runtime scripts and formatting tasks.
 
 ## Infrastructure
 
-Infrastructure automation, GitOps workflows, and ephemeral preview
-environments are maintained in the Nile Valley repository
-(`../../nile-valley`). This repository ships the application code, container
-images, and Helm chart that Nile Valley deploys.
+Infrastructure automation, GitOps workflows, and ephemeral preview environments
+are maintained in the Nile Valley repository (`../../nile-valley`). This
+repository ships the application code, container images, and Helm chart that
+Nile Valley deploys.
 
 ## Formatting, linting, and type checking
 

docs/backend-roadmap.md

@@ -220,8 +220,8 @@ so persistence details stay confined to outbound adapters.
 
 ## 4. Pagination infrastructure
 
-Pagination relies on domain repositories exposing ordered queries via ports;
-see `docs/keyset-pagination-design.md` for the detailed crate design.
+Pagination relies on domain repositories exposing ordered queries via ports; see
+`docs/keyset-pagination-design.md` for the detailed crate design.
 
 ### 4.1. Pagination crate foundation
 
@@ -236,7 +236,8 @@ see `docs/keyset-pagination-design.md` for the detailed crate design.
 
 ### 4.2. Endpoint adoption
 
-- [x] 4.2.1. Replace offset pagination in `GET /api/v1/users` with the new crate,
+- [x] 4.2.1. Replace offset pagination in `GET /api/v1/users` with the new
+      crate,
   including Diesel filters that respect `(created_at, id)` ordering and bb8
   connection pooling.
 - [x] 4.2.2. Update the repository layer to surface pagination-aware errors
@@ -246,9 +247,9 @@ see `docs/keyset-pagination-design.md` for the detailed crate design.
   and page traversal counts for analytics.
 - [ ] 4.2.4. Preserve the shipped admin provenance reporting baseline for
   `GET /api/v1/admin/enrichment/provenance`: keep admin-only access,
-  deterministic `(imported_at, id)` ordering, and legacy `before`
-  compatibility (Request for Comments 3339 (RFC 3339) `RFC3339` or
-  `RFC3339|UUID`) while layering the shared pagination crate on top.
+  deterministic `(imported_at, id)` ordering, and legacy `before` compatibility
+  (Request for Comments 3339 (RFC 3339) `RFC3339` or `RFC3339|UUID`) while
+  layering the shared pagination crate on top.
 - [ ] 4.2.5. Implement dual query compatibility for admin enrichment reporting:
   add the new opaque `cursor` parameter alongside the shipped `before`
   contract, reject requests that provide both, and map invalid cursor or
@@ -259,8 +260,8 @@ see `docs/keyset-pagination-design.md` for the detailed crate design.
   complete.
 - [ ] 4.2.7. Extend repository and endpoint tests to prove lossless traversal
   across `(imported_at, id)` tie boundaries for opaque cursor mode, plus
-  regression coverage that the shipped legacy `before` behaviour remains
-  stable during migration.
+  regression coverage that the shipped legacy `before` behaviour remains stable
+  during migration.
 - [ ] 4.2.8. Execute and document the deprecation plan for legacy `before` /
   `nextBefore` support, including removal criteria and release sequencing once
   consumers have migrated to opaque cursors.

docs/backend-sample-data-design.md

@@ -55,9 +55,7 @@ Proposed API:
 - `SeedRegistry { version: u32, interest_theme_ids: Vec<Uuid>,
   safety_toggle_ids: Vec<Uuid>, seeds: Vec<SeedDefinition> }`
 - `SeedDefinition { name: String, seed: u64, user_count: usize }`
-- `ExampleUserSeed { id: Uuid, display_name: String,
-  interest_theme_ids: Vec<Uuid>, safety_toggle_ids: Vec<Uuid>, unit_system:
-  UnitSystemSeed }`
+- `ExampleUserSeed { id: Uuid, display_name: String, interest_theme_ids: Vec<Uuid>, safety_toggle_ids: Vec<Uuid>, unit_system: UnitSystemSeed }` <!-- markdownlint-disable-line MD013 -->
 - `UnitSystemSeed` enum with `Metric` and `Imperial`.
 - `generate_example_users(registry: &SeedRegistry, seed: &SeedDefinition)
   -> Vec<ExampleUserSeed>`
@@ -152,8 +150,8 @@ the field names. Proposed config fields:
 - `example_data.user_count`: optional override for the seed's default count.
 - `example_data.registry_path`: path to the registry JSON.
 
-Environment overrides (subject to the same naming conventions and mapping
-rules `ortho-config` applies elsewhere):
+Environment overrides (subject to the same naming conventions and mapping rules
+`ortho-config` applies elsewhere):
 
 - `EXAMPLE_DATA_IS_ENABLED`
 - `EXAMPLE_DATA_SEED_NAME`