examples/legacy_smoke: four committed-capture counts become false when #697 lands, and README:23-24 already contradicts :118

[JarryShaw]

examples/legacy_smoke/ states a committed-capture count in four places. All four are correct on main
today and all four become false when #697 lands, because #697 stops tracking the four rendered
reports (out.json, out.plist, out.txt, pcapng.txt), taking the tracked set from six to two.

site	text
examples/legacy_smoke/README.rst:118	"Four files in ../captures/ are committed outputs rather than inputs"
examples/legacy_smoke/README.rst:139	"rewrites every timestamp line in all four files"
examples/legacy_smoke/README.rst:141	"the PCAP three having been generated at UTC-05:00"
examples/legacy_smoke/Makefile:14	"## Regenerate the four committed fixtures in ../captures/."

Makefile:21's @echo also names all four, and the whole "Regenerating the committed fixtures" section
(README.rst:115-144) plus the fixtures target will describe regenerating files that are no longer
tracked.

A pre-existing contradiction in the same file, independent of #697

README.rst:23-24 and :118 already disagree on main:

:23-24   The captures live in ``../captures/``. Only ``in.pcap`` and ``dhcp.pcapng`` are
         committed; the rest are generated, so build them once before running anything else:
:118     Four files in ``../captures/`` are committed outputs rather than inputs, and they are

Six files are tracked today (dhcp.pcapng, in.pcap, out.json, out.plist, out.txt,
pcapng.txt) = 2 inputs + 4 committed outputs, so :118 is right and :23-24 is wrong as of now.
#697 flips the polarity of both rather than removing the inconsistency.

Suggested fix

Drop the counts rather than updating them — an updated number rots on the next capture, and count-free
prose is correct both before and after #697. This is the same approach taken for the test-tree comments
in #700 / PR #703, which replaced "there are six today" with "or stops committing one".

These files are owned by #697, so the change belongs on that branch rather than as a separate PR;
otherwise #697 merges with four false statements in files it is itself editing. Found while reviewing
#703, verified independently twice.

[JarryShaw]

Checked this against the actual tip of chore/untrack-rendered-capture-reports-685 (PR #697), commit 6fca065e2 — that commit already carries the fix for all four statements plus the pre-existing contradiction, so no additional commit is needed on the branch.

git ls-files -- examples/captures on the branch shows only dhcp.pcapng and in.pcap tracked, confirming the untracking already landed in that same commit.

Before/after for each flagged statement (before = main today, after = current branch tip):

README.rst:118

• before (main): "Four files in ../captures/ are committed outputs rather than inputs, and they are produced by two of the scripts here."
• after (branch, now :118): "Four files in ../captures/ are reports rather than inputs -- out.json, out.plist, out.txt and pcapng.txt -- and they are produced by two of the scripts here. Git does not track them, so a fresh clone does not have them."

README.rst:139 (the "rewrites every timestamp line" sentence, now around :149-151)

• before (main): "...which is how these fixtures came to disagree with each other, the PCAP three having been generated at UTC-05:00 and pcapng.txt at UTC+08:00."

• after (branch): "...which is how these reports came to disagree with each other while they were still tracked, the PCAP three having been generated at UTC-05:00 and pcapng.txt at UTC+08:00."

  ("fixtures" → "reports", plus "while they were still tracked" added to scope it as history.) The literal phrase "rewrites every timestamp line in all four files" is unchanged, but it isn't false either way -- it describes how many report files the two scripts produce, not how many are committed, so it stays true on both sides of the untracking.

README.rst:141 -- same sentence as above; covered by the same edit.

Makefile:14

• before (main): "## Regenerate the four committed fixtures in ../captures/."
• after (branch): "## Build the four reference reports in ../captures/. Git tracks none of them -- they are generated output, so a fresh clone has to run this before it has them (examples/captures/pcapng.txt records packet -> NIL for four blocks that now carry octets #685)."

The section heading also changed from "Regenerating the committed fixtures" to "Regenerating the reference reports", and the branch added a new paragraph explaining why the four reports stopped being tracked (referencing #685 directly).

Pre-existing :23-24 vs :118 contradiction -- also resolved as a side effect: :23-24 ("Only in.pcap and dhcp.pcapng are committed; the rest are generated") is unchanged text that was already false on main (six files tracked there) and is now true on the branch (two tracked); :118 was reworded as shown above to agree with it. Both now say the same thing.

Left unchanged, deliberately: Makefile's @echo 'regenerated ../captures/{out.json,out.plist,out.txt,pcapng.txt}' still names all four files, but that's just echoing what the two preceding commands actually just wrote to disk -- not a claim about commit status -- so it isn't affected by the untracking and doesn't need rewording.

No commit added; verified read-only against 6fca065e2 (committer date 2026-09-22T23:33:39-04:00, i.e. before this issue was filed).

[JarryShaw]

Closing as invalid — this was filed against main, not against PR #697's diff

I verified the report above myself against the actual branch rather than taking it on trust, and it is correct: every statement this issue flags was already rewritten by 6fca065e2, the single commit on chore/untrack-rendered-capture-reports-685. The diff git diff origin/main origin/chore/untrack-rendered-capture-reports-685 -- examples/legacy_smoke/ shows it directly:

this issue claimed	what the branch actually says
README.rst:118 "Four files in ../captures/ are committed outputs rather than inputs"	"Four files in ../captures/ are reports rather than inputs -- out.json, out.plist, out.txt and pcapng.txt -- … Git does not track them, so a fresh clone does not have them."
README.rst:141 "the PCAP three having been generated at UTC-05:00"	"which is how these reports came to disagree with each other while they were still tracked, the PCAP three having been generated at UTC-05:00"
Makefile:14 "## Regenerate the four committed fixtures in ../captures/."	"## Build the four reference reports in ../captures/. Git tracks none of them -- they are generated output, so a fresh clone has to run this before it has them (#685)."
the section heading "Regenerating the committed fixtures"	"Regenerating the reference reports"
:23-24 contradicts :118	resolved. :23-24 ("Only in.pcap and dhcp.pcapng are committed") was false on main, where six files are tracked, and is true on this branch, where git ls-files -- examples/captures returns exactly dhcp.pcapng and in.pcap. :118 was reworded to agree with it.

The branch also adds a paragraph explaining why the four stopped being tracked — that nothing reads a report back, so a parser change leaves the committed copy quietly wrong with no failure to say so, which is exactly how pcapng.txt came to record packet -> NIL for four blocks that had started carrying their captured octets.

Two statements were correctly left alone and this issue was wrong to flag one of them:

• README.rst:139 "rewrites every timestamp line in all four files" — still true. It counts the files the two scripts produce, which is four either way; it says nothing about what git tracks.
• Makefile:21's @echo 'regenerated ../captures/{out.json,out.plist,out.txt,pcapng.txt}' — a factual echo of what the two preceding commands just wrote, not a claim about commit status.

Why this was filed wrongly, stated plainly

The finding came out of reviewing PR #703 and was checked against main's copy of examples/legacy_smoke/README.rst and Makefile. It was never diffed against #697's branch, which is the branch whose merge the issue predicted would falsify those statements. #697 had already fixed them — commit 6fca065e2 landed at 2026-09-22T23:33-04:00, roughly nine and a half hours before this issue was opened at 2026-09-23T13:11Z.

The lesson is narrow and worth recording: an issue of the form "statement X becomes false when PR Y lands" is a claim about Y's diff, so Y's diff is what has to be read — not the current contents of the file on main. No code change was made and nothing was pushed.