♻️ Tighten the development/ prose

Same decisions, rationale, rejected alternatives and known issues, said with
less padding: ~5,530 -> ~4,730 words (-15%). Every fact from the first draft is
kept; only the wording, duplicated lead-ins and restated context are cut.

development/README.md

@@ -1,23 +1,18 @@
 # Development documentation
 
-These files explain **why** this project works the way it does: the decisions
-behind it, what was rejected, and the shortcomings and known issues we carry.
-They are written for maintainers and contributors of the project itself.
+Why this project works the way it does: the decisions, what was rejected, and
+the shortcomings and known issues we carry. Written for maintainers and
+contributors.
 
-The actionable rules — how to set up, run, test, and submit — live in
-[CONTRIBUTING.md](../CONTRIBUTING.md). This folder is the "why" behind those
-rules: read the relevant file here before changing an area, and update it when
-a decision changes, rather than leaving an obsolete reason behind. A rule and
-its reason drift apart when they live in one place and are maintained in two;
-keeping the rule in CONTRIBUTING.md and the reason here keeps each single-homed.
-**Each fact is written once**: the actionable rule in CONTRIBUTING.md, the
-reason here. Neither restates the other — when the same fact would be useful in
-both, one links to the other instead of copying it.
+The actionable rules — setup, running, testing, submitting — live in
+[CONTRIBUTING.md](../CONTRIBUTING.md). **Each fact is written once**: the rule
+there, the reason here; neither restates the other, and where a fact is useful
+in both they link. Read the relevant file before changing an area, and when a
+rule changes update its rationale here in the same commit.
 
-User-facing documentation lives in [README.md](../README.md). A `docs/` folder
-is deliberately not used yet: the convention is that `docs/` is the future
-user documentation site, and deploying that site is out of scope. When it
-exists, these files stay here — they are not user documentation.
+User-facing documentation is [README.md](../README.md). `docs/` is deliberately
+unused: that name is reserved for the future user documentation site, and
+deploying it is out of scope. These files are not part of that site.
 
 ## Layout
 
@@ -32,15 +27,13 @@ One file per category:
 | [ci.md](./ci.md)                 | CI pipeline, runner image, coverage serving                             |
 | [publishing.md](./publishing.md) | Release and npm publishing                                              |
 
-A category that outgrows one file becomes a folder with an index, but we start
-with one file per category because each area is small enough to hold in mind at
-once. When a category splits, the links in CONTRIBUTING.md and README.md keep
-pointing at the category, not at a single decision.
+We start with one file per category so each area stays small enough to hold in
+mind; a category that outgrows it becomes a folder with an index, and the links
+in CONTRIBUTING.md and README.md point at the category, not a single decision.
 
 ## Decision blocks
 
-Every non-obvious choice is recorded as a block inside the relevant category
-file, using this shape:
+Record every non-obvious choice as a block in the relevant category file:
 
 ```md
 ## Runner image
@@ -65,25 +58,21 @@ of downloading per job.
     - recover with `docker rmi <image>`
 ```
 
-- The date is the month the decision was made, not the date the file was last
-  edited. It is the anchor a reader uses to tell "this is current" from "this
-  was current once".
-- `Rejected` is what makes the record worth keeping: it stops the project from
-  re-litigating the same alternatives. An empty `Rejected` usually means the
-  alternatives were never written down.
-- `Known issue` is where shortcomings live. If a caveat is not tied to one
-  decision, put it under a `## Known issues` section at the end of the file.
-- A superseded decision is **replaced in place**, not archived in a second
-  file — the file always describes the current world, and git history is the
-  archive.
+- The date is the month the decision was made, not when the file was edited —
+  the anchor for "current" versus "was current once".
+- `Rejected` stops the project re-litigating the same alternatives; an empty one
+  usually means they were never written down.
+- `Known issue` is where shortcomings live. A caveat not tied to one decision
+  goes under a `## Known issues` section at the end of the file.
+- Replace a superseded decision in place rather than archiving it; git history
+  is the archive.
 
 ## Adding to these docs
 
-1. Pick the category file for the area you are changing: `library`, `workflow`,
-   `tooling`, `testing`, `ci`, or `publishing`.
-2. Add or update a decision block. Keep the existing text unless the decision
-   actually changed.
-3. If the change alters an actionable rule, update
-   [CONTRIBUTING.md](../CONTRIBUTING.md) in the same commit and cross-link the
-   two. The reverse also holds: never change a rule in CONTRIBUTING.md without
-   updating its rationale here.
+1. Pick the category: `library`, `workflow`, `tooling`, `testing`, `ci`,
+   `publishing`.
+2. Add or update a decision block; keep existing text unless the decision
+   changed.
+3. If an actionable rule changes, update
+   [CONTRIBUTING.md](../CONTRIBUTING.md) in the same commit and cross-link.
+   Never change a rule there without updating its rationale here.