Rewrite AGENTS.md in short plain sentences (#327)

Every rule keeps its meaning and emphasis. Sentences are split so each
holds one idea, with the main rule before its exception and every
command, file name and identifier in backticks.

Three statements were false against the repo or the standing rulings
on record and are corrected:

- the format check is `make fmt-check`, not `make check-fmt`
- a feature branch reaches `next` through a PR that passes review, is
  merged only when the feature is completely finished and the code is
  up to standards, and is deleted after the merge; only the user
  merges `next` into `main`
- the naming example uses the code's term: `al` is bad,
  `SourceHostAllowlist` is good

The `Last Updated` line takes today's date.

Model: fable-5-1

AGENTS.md

@@ -30,47 +30,47 @@ These rules MUST be followed at all times. This is very important.
 
 - When fixing a bug, write a failing test for the bug FIRST. Add appropriate
   logging to the test, to make sure the test is written correctly. Commit that.
-  Then fix the bug until the test passes, without modifying the test further.
+  Then work on the fix until the test passes, without changing the test further.
   Then commit the fix.
 
 - When adding a new feature, do the same: write a test first (test-driven
   development, TDD). The test does not need to be very complex. Commit the test,
   then commit the feature.
 
-- When adding a new feature, use a feature branch. A feature branch lands on
+- When adding a new feature, use a feature branch. The feature branch reaches
-  `next` through a reviewed PR. The branch is merged, and then deleted, only
+  `next` through a PR that passes review. It is merged only when the feature is
-  when the feature is completely finished and the code passes `make check`. Only
+  completely finished and the code is up to standards. The code is up to
-  the owner merges `next` into `main`.
+  standards when it passes `make check`. The branch is deleted after the merge.
+  Only the user merges `next` into `main`.
 
 - Write `godoc` comments for all exported types and functions as you go along.
 
 - ALWAYS be consistent in naming. If you name something one way in one place,
   use the EXACT SAME name in every other place.
 
-- Be descriptive and specific in naming. `wl` is bad; `SourceHostAllowlist` is
+- Be descriptive and specific in naming. `al` is bad; `SourceHostAllowlist` is
   good. `ConnsPerHost` is bad; `MaxConnectionsPerHost` is good.
 
 - This is not prototype or teaching code. It is designed for production. Any
   security issue (such as denial of service) or other web vulnerability is a P1
-  bug, the highest priority. It must be added at the top of `TODO.md`.
+  bug. It must be added at the top of `TODO.md`.
 
 - Do not stub an implementation unless you are specifically instructed to. This
   is production code, and we need working implementations.
 
 - NEVER silently fall back to a different setting when a user's parameter
-  explicitly specifies a value. Return an error instead. For example, if a user
+  explicitly specifies a value. For example, if a user requests `format=webp`
-  requests `format=webp` and WebP encoding is not supported, return an error. Do
+  and WebP encoding is not supported, return an error. Do NOT silently output
-  NOT silently output PNG instead. If a user specifies `fit=invalid` and that
+  PNG instead. If a user specifies `fit=invalid` and that fit mode does not
-  fit mode does not exist, return an error. Do NOT silently default to `cover`.
+  exist, return an error. Do NOT silently default to `cover`. A silent fallback
-  A silent fallback violates the principle of least surprise and masks bugs.
+  violates the principle of least surprise and masks bugs. Defaults are
-  Defaults are acceptable only for OMITTED parameters, never for INVALID
+  acceptable only for OMITTED parameters, never for INVALID explicit values.
-  explicit values.
 
 - Avoid vendoring dependencies unless specifically instructed to. NEVER commit
   the `vendor/` directory. NEVER commit compiled binaries. If such a directory
   or file exists and `.gitignore` does not list it, add it to `.gitignore`.
   Commit that `.gitignore` change. Keep the entire git repository, history
-  included, under 20 MiB. Commit a larger file only when you specifically must.
+  included, under 20 MiB. Go over 20 MiB only when you specifically must commit
-  Media files used as test fixtures are one such case. Only OUR source code and
+  a large file, such as a media file used as a test fixture. Only OUR source
-  its immediately supporting files, such as test examples, go into the
+  code and its immediately supporting files, such as test examples, go into the
   repository and its history.