Derive the directories beside the six, rather than counting them twice [#322]

[iderex]

The issue this belongs to

Closes #322

What changed

README.md and src/lib.rs each counted the directories under src/ that are not one of the six things 0003 says the core owns, and each said three while the tree carried four. Both counts are deleted rather than moved to four. README.md hands the reader the command that returns the set instead, in the way that same section already derives what each directory holds, and src/lib.rs keeps its walk through each module without opening on a number.

The derivation only answers because src/lifecycle/mod.rs now carries the sentence the other three already carried. It said what it holds and never said where it sits, so README.md's claim that each of those directories declares its position in its own first paragraph was false of it, and the only file saying why lifecycle is beside the six was src/lib.rs - one file away from where README.md sends a reader to look.

What failure it prevents

A reader counting src/ against that paragraph met a directory the paragraph does not account for, and the natural reading of an unaccounted directory beside six that are named is that it is one of the six. It is the first file anybody reads about this repository and the error ran in the direction that makes the boundary look smaller than the tree draws it.

This has already happened twice on one paragraph. #234 closed the same defect there on 2026-08-29, replacing two with three and keeping the enumeration:

gh api repos/Flowfin/core/issues/234 --jq '"\(.state) \(.closed_at)"'
closed 2026-08-29T12:14:40Z

git log origin/main --diff-filter=A --format='%h %ad %s' --date=short -- src/lifecycle/mod.rs
8d2d2da 2026-09-02 Hold 0115's creation, its capability answer and the core's lifetime (#115)

Four days, in a change about the core's own lifetime that had no reason to open either paragraph. A repair that wrote four would buy until the next directory.

It was found by counting the directories against that paragraph while reading the board, not by anything reporting it.

Evidence

The tree at the base, 85e9ec1abd2f5c7d4a6d6b1f1d6b439bfb526c2f, against what the two documents said:

git ls-tree --name-only origin/main src/
src/artwork
src/cache
src/clock
src/diagnostics
src/failure
src/lib.rs
src/lifecycle
src/measurement
src/playback
src/server
src/session

git show origin/main:README.md | sed -n '72p'
Three directories beside those six are not concerns from that record and say so in

git show origin/main:src/lib.rs | sed -n '20p'
//! Three more modules are here and none of them is one of the six. [`failure`] holds

Ten directories, six of them 0003's, so four beside them. At the head being pushed the command README.md now hands the reader returns exactly those four:

git rev-parse HEAD
9f297aa1d8b1d7d5d1cb0ac2ca0e07e2b3b8d6ba

git grep -l 'not one of the six' -- src/
src/clock/mod.rs
src/diagnostics/mod.rs
src/failure/mod.rs
src/lifecycle/mod.rs

and src/lib.rs is not in that set, so the command answers out of the modules rather than out of the document that cites it.

The two commands the gate runs, at the head being pushed:

cargo build --locked --all-targets >/dev/null ; echo "exit=$?"
exit=0

cargo test --locked
test result: ok. 587 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 11 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 28 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 125 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

772 tests, none failed. The check that reads the documents I touched, and the two that read the Rust I touched:

bash .github/doc-paths/doc-paths.sh check
ok    78 document(s), 360 named path(s) resolved, 0 excused as examples

cargo fmt --check ; echo "exit=$?"
exit=0

bash .github/lint/lint.sh check | tail -1
Every lint the groups above carry was refused, outside the register printed with it.

What a guard here refuses, and the proof it bites

This change adds and edits no guard. It is prose in two documents and a doc comment in a third, and nothing in this tree refuses any of it - which is the thing the section below is about.

What this does not cover

No mechanism. Nothing here compares a document's description of the tree against the tree. That is what #234 said in its own closing paragraph and it is still true, so a document that writes a count tomorrow is refused by nothing and this change does not make it decidable. What it does is narrower: it takes the count out of the two places that carried one, so this paragraph cannot go stale in this particular way. The class is untouched.

The derivation rests on a literal. git grep -l 'not one of the six' -- src/ answers because four modules carry that phrase, so a module added tomorrow that writes the sentence differently is missing from the set and nothing says so. That is weaker than a check and stronger than a number, and it is the trade this change makes rather than one it hides.

I re-ran the readings in the two paragraphs this touches and audited neither README.md nor src/lib.rs further.

The past-tense sentence in src/lib.rs that a defect was found while adding the second of the three is left alone. It is an account of when something was read, it was right when it was written, and moving it would rewrite what happened rather than repair what is claimed.

Nothing here reaches the eleven src/ directories' contents, the six modules 0003 names, or any behaviour. No test was added, because what changed is three sentences of prose and no code path.

Who has read it

Nobody other than me. There is no second reader on this board tonight, and the evidence above stands in place of one rather than the question being left open.