Name the write queue in the index of the directory that holds it

[iderex]

The issue this belongs to

Closes #479

What changed

The header of src/server/mod.rs gains one paragraph, for write_queue, in the
same shape as the nine beside it: which record it holds, what of that record is
here, and the absence it keeps. It is placed after states and before
federation, where the module's own header says it sits, and it says that
nothing is sent, nothing is acknowledged and no drain runs, for the same reason
transport holds no socket.

Nothing else moves. No behaviour, signature, type, variant or registration.

What failure it prevents

The directory's front page walked ten registered modules and named nine. A
reader who wants to know where a write to a server is held opens this directory,
reads a walk that names nine modules, and concludes the queue is somewhere else
or is not built. That is the direction that reads as covered: the answer is one
entry away, says of itself that it belongs here, and the index was the one place
in the tree not saying so.

It was found by deriving the header's module walk from the registrations below
it rather than by reading the prose.

Evidence

The commit being pushed:

git rev-parse HEAD
a1dc89c53eb7896941d486c55123db5b8e5fea23

What the header named, at the parent. The header is everything above the first
registration, and the count is per registered module rather than typed:

git show a1dc89c^:src/server/mod.rs | sed -n '/^pub mod/q;p' > /tmp/header.txt
for m in $(git show a1dc89c^:src/server/mod.rs | sed -n 's/^pub mod \(.*\);/\1/p'); do
  printf '%s\t%s\n' "$m" "$(grep -c "\[\`$m\`\]" /tmp/header.txt)"
done
address	1
certificate	1
destinations	1
federation	1
library	1
recovery	3
retry	1
states	1
transport	6
write_queue	0

Not in any looser form either, and neither its record nor its issue:

grep -n -iE 'queue|0047|#47' /tmp/header.txt ; echo "exit=$?"
exit=1

The same derivation at this commit:

git show HEAD:src/server/mod.rs | sed -n '/^pub mod/q;p' > /tmp/head.txt
for m in $(git show HEAD:src/server/mod.rs | sed -n 's/^pub mod \(.*\);/\1/p'); do
  printf '%s\t%s\n' "$m" "$(grep -c "\[\`$m\`\]" /tmp/head.txt)"
done
address	1
certificate	1
destinations	1
federation	1
library	1
recovery	4
retry	1
states	1
transport	7
write_queue	1

The module says where it belongs, at the parent:

git show a1dc89c^:src/server/write_queue.rs | sed -n '11,17p'
//! # Why it is here rather than beside the store
//!
//! 0047 opens with the sentence that decides this: the queue is not the offline
//! path, it is THE path, and every write the core makes to a server goes onto it
//! whether the server is answering or not. So it is part of reaching a server,
//! and it sits beside [`super::recovery`], which is what it drains on rather
//! than on a timer of its own.

and what it states as absent, which the new paragraph repeats rather than
softens:

git show a1dc89c^:src/server/write_queue.rs | sed -n '32,36p'
//! WHAT IS NOT HERE IS THE DELIVERY. The library opens no socket, for the
//! reason [`super::transport`] gives about itself, so nothing is sent, nothing
//! is acknowledged and no drain runs. This module holds the queue such a drain
//! would walk. #47's two conditions restart the core and restore a server, and
//! neither is met by anything here.

The rest of the tree already points a reader at it, at the parent:

git grep -l 'server::write_queue' a1dc89c^ -- src/ | grep -v ':src/server/'
a1dc89c^:src/cache/envelope.rs
a1dc89c^:src/lib.rs
a1dc89c^:src/lifecycle/mod.rs
a1dc89c^:src/playback/cadence.rs
a1dc89c^:src/playback/report.rs
a1dc89c^:src/playback/resume.rs
a1dc89c^:src/playback/watched.rs
a1dc89c^:src/session/mid_playback.rs
git grep -n 'write_queue' a1dc89c^ -- .github/coverage/pinned-surface
a1dc89c^:.github/coverage/pinned-surface:91:module  src/server/write_queue.rs  0047's order, coalescing and bound for every write the core makes to a server. A defect here delivers somebody's actions out of the order they took them, keeps a queue that grows with activity rather than with breadth, or drops what a person just did instead of what they did three weeks ago.

The dates. The registration was added by the commit that added the module, and
the header gained two further module paragraphs after that:

git log --format='%h %cI %s' --diff-filter=A a1dc89c^ -- src/server/write_queue.rs
b29ecc9 2026-08-30T22:46:34+02:00 Hold 0047's order, coalescing and bound where a counter and an equality decide them (#250)
git blame -L 81,81 --date=short a1dc89c^ -- src/server/mod.rs | cat
b29ecc9d (Nils Lehnen 2026-08-30 81) pub mod write_queue;
git blame -L 59,59 --date=short a1dc89c^ -- src/server/mod.rs | cat
449f15c8 (Nils Lehnen 2026-08-31 59) //! [`library`] holds 0039's answer shape: the offset and the count a paged read
git blame -L 53,53 --date=short a1dc89c^ -- src/server/mod.rs | cat
965e1a35 (Nils Lehnen 2026-09-02 53) //! [`destinations`] holds that list: the origins the operator configured, the

What the change is:

git diff --stat origin/main...HEAD
 src/server/mod.rs | 10 ++++++++++
 1 file changed, 10 insertions(+)
git diff --name-only origin/main...HEAD
src/server/mod.rs

The two commands the gate runs, at this commit. The build was run first and
exited 0; its own summary line is not pasted, because this board's hygiene check
reads the word in it as a speed claim:

cargo build --locked --all-targets ; echo "exit=$?"
exit=0
cargo test --locked ; echo "exit=$?"
exit=0
cargo test --locked 2>&1 | grep -c '^test result: ok'
10
cargo test --locked 2>&1 | grep -c 'test result: FAILED'
0

Four of this board's own legs, run on this machine at this commit:

bash .github/invariants/invariants.sh check | tail -1
Every rule above was applied to its subject and refused nothing.
bash .github/format/format.sh check | tail -1
Every tracked source file above is written the way the formatter would write it.
bash .github/doc-paths/doc-paths.sh check | tail -1
Every path these documents name resolves against the tracked set.
bash .github/lint/lint.sh check | tail -1
Every lint the groups above carry was refused, outside the register printed with it.

What this does not cover

• src/server/write_queue.rs. Read as evidence and not edited. It already
  says where it belongs and what it does not do.

• The header's opening sentence. It names the records 0027, 0028, 0029,
  0037, 0038 and 0069 and the issues Build the HTTP transport, with timeouts, connection reuse and cancellation #27 through Implement the library query surface a client needs to show a first screen #39, and three modules in this
  directory sit outside that, federation, destinations and write_queue.
  Each of the three is now reached by a paragraph naming its own record, and
  whether that opening sentence should be widened is a separate reading about
  what 0003 places where. It was not made here.

• The delivery. Nothing in this tree opens a socket to send a queued write.
  Build the HTTP transport, with timeouts, connection reuse and cancellation #27 and Decide what creating and stopping the core means, including a host that suspends it #115 are open and nothing is claimed about when either lands.

• 0047 and 0003. Both records are read and neither is edited. A record is
  added or superseded rather than edited in place, which
  docs/decisions/0001-decision-records.md fixes.

• The other directory indexes. Whether another mod.rs header in this tree
  leaves out a module it registers is a separate reading and was not made here.

• Behaviour. No production line changes. The whole diff is doc comments.

• A check that would refuse this. Nothing in this tree reads a module header
  against the registrations below it, and the document check reads only .md
  files. This adds no rule, so the next gap of this shape is caught by a reader
  or not at all.

• The shell analysis. It was not run on this machine, because the analyser
  is not on this machine's path:

    command -v shellcheck ; echo "exit=$?"
    exit=1
  

  What the run on this pull request reports is the reading, and nothing is
  claimed for it from here. This change touches no shell file.

Who has read it

Nobody other than the author. There is no second reader on this board tonight,
and the readings pasted above stand in place of one rather than a review having
happened.