refactor progress

CONTRIBUTING.md

@@ -1,12 +1,12 @@
-# Contributing to fluxerapp/fluxer
+# Contributing to Fluxer
 
-Thanks for contributing. This document explains how we work so your changes can land smoothly, and so nobody wastes time on work we cannot merge.
+Thanks for contributing. This document explains how we work so your changes can land smoothly and nobody wastes time on work we can't merge.
 
 ## Quick rules (please read)
 
 ### 1) All PRs must target `canary`
 
-`canary` is our trunk branch. Open all pull requests against `canary`. PRs targeting other branches will be closed or you will be asked to retarget.
+`canary` is our trunk branch. Open all pull requests against `canary`. PRs targeting other branches will be closed or retargeted.
 
 ### 2) All PRs must include a short description
 
@@ -16,24 +16,32 @@ Every PR must include a short description covering:
 - why it changed
 - anything reviewers should pay attention to
 
-A few bullets is perfect.
+A few bullets is fine.
 
-### 3) Coordinate before starting larger work
+### 3) Open an issue before submitting a PR
 
-If you are planning anything beyond a small, obvious fix (new feature, meaningful refactor, new dependency, new API surface, behavior changes), coordinate with the maintainers first.
+We strongly prefer that every PR addresses an existing issue. If one doesn't exist yet, open one describing the problem or improvement and your proposed approach. This gives maintainers a chance to weigh in on direction before you invest time, and avoids the mutual displeasure of:
 
-This avoids the mutual displeasure of:
+- you doing significant work, and
+- us having to reject or postpone the change because it doesn't align with current goals, or because we aren't ready to maintain what it introduces
 
-- you investing significant time, and
-- us having to reject or postpone the change because it does not align with current goals, or because we are not ready to maintain what it introduces
+For small, obvious fixes (typos, broken links, trivial one-liners) you can skip the issue and go straight to a PR.
 
-Ways to coordinate:
+Ways to coordinate on larger work:
 
 - open an issue describing the problem and your proposed approach
 - open a draft PR early to confirm direction
 - discuss with a maintainer in any channel you already share
 
-If you are unsure whether something counts as "larger work", ask first.
+If you're unsure whether something needs an issue first, it probably does.
+
+### 4) Understand the code you submit
+
+You must have sufficient understanding of every change in your PR to explain it and defend it during review. You don't need to write an essay, but you should be able to give a short summary of what the patch does and why it's correct.
+
+**LLM-assisted contributions.** You're welcome to use LLMs as a tool for automating mechanical work. We don't ask you to disclose this, since we assume you're acting in good faith: you're the one who signs off on the patch you submit in your own name, and you have the technical understanding to verify that it's accurate.
+
+That said, don't use LLMs on areas of the codebase you don't understand well enough to verify the output. If part of your change touches code you aren't confident reviewing yourself, say so in the issue you opened beforehand and defer that work to someone else. The maintainers will be happy to help.
 
 ## Workflow
 
@@ -48,10 +56,10 @@ We strongly prefer small, focused PRs that are easy to review.
 
 ### Commit style and history
 
-We squash-merge PRs, and the PR title becomes the single commit message on `canary`. For that reason:
+We squash-merge PRs, so the PR title becomes the single commit message on `canary`. For that reason:
 
 - PR titles must follow Conventional Commits.
-- Individual commits inside the PR do not need to follow Conventional Commits.
+- Individual commits inside the PR don't need to follow Conventional Commits.
 
 If you like to commit in small increments, feel free. If you prefer a tidier PR history, force-pushes are welcome (for example, to squash or reorder commits before review). Just avoid rewriting history in a way that makes it hard for reviewers to follow along.
 
@@ -87,17 +95,14 @@ We care about confidence more than ceremony. Add tests when they provide real va
 
 ### Backend changes
 
-For backend changes, we suggest adding an integration or unit test.
+For backend changes, add a unit test.
 
-- If a unit test would require heavy mocking to be meaningful, either:
-  - restructure the code so it can be tested without excessive mocking, or
-  - prefer an integration test if restructuring is not practical
-
-- If you are unsure which route is best, discuss it with a maintainer before investing time.
+- If a unit test would require heavy mocking to be meaningful, restructure the code so it can be tested cleanly through its interfaces.
+- If you're unsure how to approach this, discuss it with a maintainer before investing time.
 
 ### Frontend changes
 
-We generally do not encourage new unit tests for frontend code unless:
+We don't generally encourage new unit tests for frontend code unless:
 
 - the area already has unit tests, or
 - the change is complex or sensitive, and a unit test clearly reduces risk
@@ -106,9 +111,9 @@ In most cases, clear PR notes and practical verification are more valuable.
 
 ## Formatting and linting
 
-Do not block on formatting or linting before opening a PR. CI enforces required checks and will tell you what needs fixing before merge.
+Don't block on formatting or linting before opening a PR. CI enforces required checks and will tell you what needs fixing before merge.
 
-Open the PR when it is ready for review, then iterate based on CI and feedback.
+Open the PR when it's ready for review, then iterate based on CI and feedback.
 
 ## CLA (required)
 
@@ -117,7 +122,7 @@ We require a Contributor License Agreement (CLA) for this repository.
 Why:
 
 - The project is available under AGPLv3.
-- We also offer a commercial license for organizations that cannot (or do not want to) comply with AGPL obligations.
+- We also offer a commercial license for organisations that can't (or don't want to) comply with AGPL obligations.
 - To keep both options possible, we need permission to include contributions in both distributions.
 
 What it means for you:
@@ -125,12 +130,12 @@ What it means for you:
 - You keep ownership of your contribution.
 - You can keep using your contribution in your own work.
 - You grant us the rights needed to distribute your contribution as part of the project, including under a commercial license.
-- We may refactor or remove code over time and are not required to include every contribution. However, any distributed version that includes your contribution remains properly licensed under the project license(s) that applied when you contributed.
+- We may refactor or remove code over time and aren't required to include every contribution. However, any distributed version that includes your contribution remains properly licensed under the project licence(s) that applied when you contributed.
 
 How to sign:
 
 - On your first PR, a bot will comment with a CLA link.
-- Click it, sign with your GitHub account, and you are done.
+- Click it, sign with your GitHub account, and you're done.
 
 ## PR checklist
 
@@ -139,8 +144,9 @@ Before requesting review:
 - [ ] PR targets `canary`
 - [ ] PR title follows Conventional Commits (mostly lowercase)
 - [ ] PR includes a short description of what/why
+- [ ] You understand every change in the PR and can explain it during review
 - [ ] Tests added or updated where it makes sense (especially backend changes)
-- [ ] CI is green (or you are actively addressing failures)
+- [ ] CI is green (or you're actively addressing failures)
 - [ ] CLA signed (the bot will guide you)
 
 Optional but helpful:
@@ -150,13 +156,13 @@ Optional but helpful:
 
 ## Code of Conduct
 
-This project follows a Code of Conduct. By participating, you are expected to uphold it:
+This project follows a Code of Conduct. By participating, you're expected to uphold it:
 
 - See [`CODE_OF_CONDUCT.md`](./CODE_OF_CONDUCT.md)
 
 ## Security
 
-Please do not report security issues via public GitHub issues.
+Please don't report security issues via public GitHub issues.
 
 Use our security policy and reporting instructions here: