render-pipeline: verbatim and abstract are \trivlist boundaries too (#722 follow-up)

[d-q222]

What

#722 closed the \trivlist boundary for center, flushleft, flushright,
quote, quotation, verse and every \newtheorem/proof, and left two
gaps open on purpose:

1. verbatim and abstract are \trivlist-derived too, but were never
   measured, so they were deliberately not added to TRIVLIST_ENVS;
2. only the 10 pt base size was swept.

Both are now measured, over 918 probe documents against pdflatex (pairs in
both directions, with and without a blank line, six-deep chains, solo and
paragraph controls, at 10 pt, 11 pt and 12 pt). Measurement, not
pattern-matching: three of the four things a "they're all trivlists" guess
would have predicted were already right, and the two real bugs have different
causes.

verbatim diverged, but only where the pipeline reads the pair as one
ParaStyle run. \@verbatim is \trivlist \item\relax ... and
\endverbatim is \endtrivlist (latex.ltx), so \end{verbatim} leaves
vertical mode and the next \begin takes \partopsep. verbatim/verbatim
and verbatim/flushleft were short by exactly that: -1.992 bp at 10 pt,
-2.989 bp at 11 pt and 12 pt. It accumulates — six verbatims in a row
drifted 0, -1.992, -3.985, -5.978, -7.970, -9.963 bp at 10 pt.
verbatim against center, quote, quotation, verse, flushright, a
theorem or any of the three lists was already correct in both directions.

abstract diverged on both sides, for two different reasons.
\end{abstract} is \endquotation -> \endlist -> \endtrivlist, so it is
the same boundary, and what followed it was short by one \partopsep
(-1.992 / -2.989 / -0.996 bp at 10/11/12 pt). The other direction is not
a TRIVLIST_ENVS problem at all: the pipeline builds the \small
\abstractname head as a block inserted in front of the body the compiler
produced, and the boundary skip the compiler had hung on that body stayed
there and fired a second time below the head. \end{itemize}\begin{abstract}
came out +5.305 / +5.729 / +6.273 bp long, while
\end{center}\begin{abstract} was already right (a center's closing skip
rides on its own env_close, not on the next block). take_lead moves that
leading skip to the head with the position it belongs to.

No boundary diverged only at 11 pt or 12 pt, so the size sweep found no
third bug — but it did find that one boundary is not size-invariant at all,
which a 10 pt-only sweep would have pinned as a single rule:
\end{abstract}\begin{thm} is \topsep-only at 10 pt and 11 pt but
26.401 bp at 12 pt, because the abstract's \@topsepadd was fixed inside
\small (6/9/12 pt) while a theorem opens with \thm@preskip =
\normalsize's \topsep (8/9/10 pt) and no \partopsep, and which of the
two \addvspaces wins changes with the class option. That is pinned as its
own constant.

Why

The same \addvspace rule #706 and #712 found reaches every \trivlist, and
#722 said so but only measured the environments it had probes for. A
verbatim block between two paragraphs of a listing-heavy document, or an
abstract after a list, is not exotic; the errors accumulate down the page
and move page breaks.

Pipeline-only, as #706/#712/#722 were: nothing under vendor/ changed, no
re-pin.

Overlap check

• Claim GH-TRIVLIST-REST held by daniel-parent (coord.py claim returned
  CLAIMED).
• gh pr list --state open --search topsep|verbatim|abstract: render-pipeline: two adjacent lists share one \addvspace, not two (#706) #712 and render-pipeline: every \trivlist boundary shares one \addvspace, not two (#712 follow-up) #722
  are this stack's own parents (this branch is based on render-pipeline: every \trivlist boundary shares one \addvspace, not two (#712 follow-up) #722's head); render-pipeline: a verbatim body inside a list is a trivlist inside that list (14/17) #268
  (verbatim-trivlist-in-list, DRAFT) is about a verbatim body's geometry
  inside a list, not about boundary skips, and touches neither
  TRIVLIST_ENVS nor abstractenv.rs. No other open PR or claim touches
  crates/render-pipeline/src/adapter.rs TRIVLIST_ENVS,
  crates/render-pipeline/src/abstractenv.rs or
  tests/vmode_boundary_skips.rs.

Test results

cargo test --test vmode_boundary_skips
test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

cargo test --test abstract_env
test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

cargo test --no-fail-fast, this branch (a12ec1d3):  480 passed; 13 failed (107 suites)
cargo test --no-fail-fast, base       (237b95fa):   479 passed; 13 failed (107 suites)

Diffing every test <name> ... <result> line between the two runs gives
exactly one line — the added
an_abstract_shares_one_addvspace_with_the_environment_on_either_side ... ok.
No other test's result changed in either direction, so "0 new failures" is a
line-by-line fact rather than a count that happens to match. The same 13
failures on both sides are the known adapter.rs:1308 vendor/compiler pin
(every_line_is_where_pdflatex_put_it, three letter_class_geometry,
the_raggedleft_group_closes_no_trivlist,
shared_colorbox_path_draws_border_with_content_inside, two uline, four
sout/underline, xcolor_fixtures_match_pdflatex).
hw2_sets_three_pages_with_the_reference_breaks ... ok on both.

Oracle: MacTeX 2026 pdfTeX 1.40, T1 Latin Modern, PyMuPDF glyph origins, 918
probe documents at the 10 pt / 11 pt / 12 pt article base sizes (every
ordered pair of 9 shapes x 12 partners, with and without a blank line,
six-deep chains, solo/paragraph/blank-line controls), plus nine twocolumn
probes. pdflatex is an oracle only and never runs in the product path.

Not done

• A \begin{abstract} on the line directly after body text, with no blank
  line, is not recognised at all — measured, and left alone. The compiler
  does not break the paragraph there, so it reports one text run across the
  \begin, the pipeline finds no block inside the body to restyle, and no
  \abstractname head is set; the body lands 32.553 / 36.115 / 42.744 bp
  high, on the previous line. Two adjacent abstracts fail the same way
  (the second is dropped). This is a compiler-side paragraph-splitting gap
  rather than a boundary skip (\begin{center} in the same position does
  break the paragraph), and fixing it means a change under vendor/ plus a
  re-pin, which this line of work has stayed out of. It is the only
  divergence left in the 918-document sweep and is documented at the top of
  tests/vmode_boundary_skips.rs.
• lstlisting, Verbatim (fancyvrb) and alltt are \trivlist-derived
  too and are not added here: they were not measured, which is exactly
  the reason render-pipeline: every \trivlist boundary shares one \addvspace, not two (#712 follow-up) #722 gave for leaving verbatim out.
• The twocolumn abstract after a list sets its body 3.985 / 4.483 /
  4.981 bp low at 10/11/12 pt — measured, and left alone because it is
  untouched by this PR: base and branch print byte-identical baselines for
  all nine two-column probes. The \abstractname head is exact, and the
  center-before and standalone cases are exact. That branch is a
  \section* and ordinary paragraphs rather than a quotation, so it is a
  different shape, not a \trivlist boundary.
• Only the article class was swept. report/book share \@listI but
  have their own abstract, and were not measured.

🤖 Generated with Claude Code

https://claude.ai/code/session_012c9XLkHjePPGBuarrmE2mz

[d-q222]

Independent verification — VERIFIED

Reviewed at a12ec1d3, base 237b95fa (#722). Worktrees ~/flashtex-wt/vrfy-728 and
~/flashtex-wt/vrfy-722, per-PR CARGO_TARGET_DIR=…/target-vrfy-728 and
…/target-vrfy-722, CARGO_BUILD_JOBS=4, fetched as
git fetch origin pull/N/head:refs/review/pr-N.

I was pointed at this PR to confirm a claimed self-caught regression in the
two-column abstract. That regression does not exist, and — importantly — this PR
never claims it does; it says the opposite, twice, and the measurement backs the PR.
The claim it does make (a line-by-line test diff) reproduces exactly.

---

1. Line-by-line test diff — VERIFIED, to the line

Whole crates/render-pipeline suite, --no-fail-fast, debug, both sides:

$ cargo test --no-fail-fast          # branch a12ec1d3
$ cargo test --no-fail-fast          # base   237b95fa
$ grep -oE '^test [A-Za-z0-9_:]+ \.\.\. [a-zA-Z]+' <log> | sort > <side>.lines
$ diff base.lines branch.lines
111a112
> test an_abstract_shares_one_addvspace_with_the_environment_on_either_side ... ok

base lines:   496
branch lines: 497
base:   passed=479 failed=13 suites=107
branch: passed=480 failed=13 suites=107

Exactly one added line, zero changed lines, in either direction. That is the claim
the PR makes and it holds. The 13 failures are name-for-name identical on both sides:

$ diff <(grep '\.\.\. FAILED' base.log | sort) <(grep '\.\.\. FAILED' branch.log | sort)
(no output)

every_line_is_where_pdflatex_put_it              opening_lines_are_one_paragraph_not_one_each
letter_paragraph_gaps_are_the_class_parskip      page_one_texttop_fil_pushes_the_first_baseline_down
the_raggedleft_group_closes_no_trivlist          shared_colorbox_path_draws_border_with_content_inside
sout_paints_a_rule                               sout_with_ulem_is_not_an_unsupported_error
text_mode_underline_paints_a_rule                text_mode_underline_is_not_an_unsupported_error
uline_paints_a_rule_under_the_argument           uline_with_ulem_is_not_an_unsupported_error
xcolor_fixtures_match_pdflatex

$ grep -c 'adapter.rs:1308' branch.log   ->  13

— the known stale vendor/compiler pin, not this PR's. (Counted in debug
deliberately: these are debug_asserts and a --release run would have shown a
misleading green.)

Targeted, on the branch:

$ cargo test --test vmode_boundary_skips
test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
$ cargo test --test abstract_env
test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

2. The fix genuinely fails on the base

I copied this branch's tests/vmode_boundary_skips.rs into the #722 worktree unchanged
and ran it against #722's source:

$ cargo test --test zz_review_vmode728          # 728's tests, 722's code
test an_abstract_shares_one_addvspace_with_the_environment_on_either_side ... FAILED
test the_boundary_error_does_not_accumulate_across_six_environments ... FAILED
test two_adjacent_paragraph_shape_environments_step_by_topsep_plus_partopsep ... FAILED
test result: FAILED. 4 passed; 3 failed

panicked at tests/zz_review_vmode728.rs:201:5:
10pt itemize -> abstract (adjacent): bravo: 176.608 bp, pdflatex 171.303 bp (+5.305)

+5.305 is the exact 10 pt figure in the PR body. The other two failures are the
verbatim cases the PR added to pre-existing tests — right, since verbatim is not in
TRIVLIST_ENVS on the base (adapter.rs:5004, 6 entries -> 9).

3. The two-column abstract — measured independently, and it is NOT regressed on #722

I rendered six abstract shapes on both revisions and compared every word's x and
baseline (scratch probe, deleted afterwards):

probe	#722 base	#728 branch
twocolumn + \maketitle + abstract	identical	identical
twocolumn, \end{itemize} -> abstract	identical	identical
twocolumn, \end{center} -> abstract	identical	identical
twocolumn, \end{abstract} -> itemize	identical	identical
one-column, \end{itemize} -> abstract	body 176.608	body 171.303
one-column, \end{abstract} -> itemize	identical	identical

Literal, for the two rows that matter:

722  TC 4-twocol-end-then-itemize n=9 :: Abstract@72.000/134.765 Abstract@72.000/156.585 body@113.318/156.585 … •@86.945/178.503 two@96.907/178.503 Tail.@81.963/200.421
728  TC 4-twocol-end-then-itemize n=9 :: Abstract@72.000/134.765 Abstract@72.000/156.585 body@113.318/156.585 … •@86.945/178.503 two@96.907/178.503 Tail.@81.963/200.421

722  TC 5-onecol-after-itemize  … Abstract@172.498/176.608 body@210.710/176.608 … after.@222.795/194.540
728  TC 5-onecol-after-itemize  … Abstract@172.498/171.303 body@210.710/171.303 … after.@222.795/189.235

So on #722 the two-column \end{abstract} sets nine words in the right places — it does
not expand to nothing, and there is nothing for this PR to have fixed there. The only
behavioural change is the one-column \end{itemize}\begin{abstract} shift of exactly
5.305 bp, which is the one the PR describes.

This matches what the PR says of itself — abstractenv.rs:276-282 ("measured it changes
nothing there … every two-column probe comes out byte-identical with and without this")
and the "Not done" bullet ("base and branch print byte-identical baselines for all nine
two-column probes"). The PR's own account of the two-column branch is accurate; the
claim I was asked to check was not a claim of this PR. Anyone carrying that
description forward should drop it.

Reading the change

take_lead (abstractenv.rs:269-320) is the right shape: the compiler hangs the
incoming skip on the block that was first, and inserting the head in front of it makes
the head that block, so the skip has to travel with the position. It moves all six
fields (eject_before, vspace_before, addvspace_before, addvspace_flex,
vspace_flex, endlist_adjust) rather than the one that happened to be wrong, and the
let … else { return } makes it a no-op for any non-Paragraph pair. Applying it to
the two-column branch on a positional argument, with the measurement recorded as showing
no change, is documented honestly at :276-282.

The \end{abstract}\begin{thm} size-dependence note is the kind of thing a 10 pt-only
sweep would have got wrong, and it is pinned as its own constant rather than folded into
a rule.

Verdict

VERIFIED — the line-by-line diff is exactly one added line, the new test fails on
the base with the stated figure, and the two-column branch is byte-identical across the
pair as the PR states.

Nothing was edited, pushed or merged; both scratch probe files deleted, both worktrees
clean.

— independently verified by daniel-parent's review lane