fix: a manifest too big to read back says so in the report a script reads

[donislawdev]

Stability report finding T4. You asked me to analyse it and decide, so this is the decision with the reasoning.

Stacked on #75 - merge that first, and this base retargets to main automatically.

What was wrong

A run of 25 000 files writes a manifest of about 25.9 MB against a 16 MB reading limit:

$ tfg generate --format txt --size 1b --count 25000 --out ./big   -> exit 0
$ tfg verify  big/manifest.json                                   -> exit 5
$ tfg cleanup big/manifest.json                                    -> exit 5

25 001 files, and nothing in this toolset can ever verify or remove them - untouchable rule 7 makes the manifest the only authority over what may be deleted. The run itself is correct: every file was produced and every one is right.

The warning existed and was the right sentence, printed first. Two measurements say why that was not enough:

• on stderr it was 1 line among 25 003 (now 1 of 2, since fix: a note is reported once per thing it says, not once per file #73 grouped the notes)
• in the machine-readable report it was absent entirely - --json came back clean, exit 0, no trace

This tool plugs into CI. A fact only a person reading prose can learn is a fact a pipeline cannot act on.

I rejected the report's own fix, with citations

It proposed exit 8 as a "one-line stopgap". Three reasons that is wrong:

1. docs/CLI.md §3 defines 8 as "przebieg skończony, ale nie wszystko powstało". Here everything was produced.
2. res.Failures is nought, so the emitted sentence would read "0 files could not be produced. The manifest says which ones" - false twice over, and pointing at a manifest nothing can read.
3. Exit codes are a frozen contract (cli.go). Redefining one is a major version, not a stopgap.

And the report did not know its headline fix was already rejected. manifestreach_test.go records your decision of 2026-08-26 in its own comment: "a note rather than a refusal... What was missing was that nobody was told." I did not reopen that.

So the fix goes where the gap actually is: summary.too_large_to_read_back.

Absent, not false

The field does not appear on an ordinary run, which is why manifest_version stays 1.0. Measured against the previous binary:

	result
ordinary manifest	identical
20 generated files	byte for byte identical

Third case under "the schema grows by adding fields", after tool.go and by_target. docs/MANIFEST.md updated in the same commit.

Guards

Two, two mutations, both caught. The second takes off omitempty - a build writing the field into every manifest would satisfy the first guard while changing the bytes of every document this tool has ever written.

Found while doing this, recorded as O184, not fixed

🔴 The window does not warn about the ceiling at all. TooLargeToReadBack has zero hits in internal/gui. Somebody generating 25 000 files from the window is told nothing - worse than the CLI's buried note. That is a D1 parity gap in quality, and closing it properly means deciding where a run-level note lives, since notes are per file today. Yours to call.

preflight --quick green on all 12.

🤖 Generated with Claude Code