docs: name 1024 as the floor for stripe_row_limit (#1017)

[jdatcmd]

A vector is a fixed 1024 values (COLUMNAR_NATIVE_VECTOR_LENGTH). A row group smaller than one never fills it, the chunk-shared FSST symbol table is not built, and a text column is stored plain.

stripe_row_limit 1000   0 FSST tables    13,625,000   106.4% of raw
stripe_row_limit 1200   166 of 167        6,998,031    54.7% of raw
stripe_row_limit 2000   100 of 100        6,990,641    54.6% of raw

200,000 rows, one text column, compression = none, against 12,800,000 raw bytes, two identical passes.

The accepted minimum is 1000, enforced in set_options, so the most aggressive legal setting is the one that pays this. At it, the column costs more than storing the bytes uncompressed.

Where the warning goes, and why it is not the reference table

docs/administration.md currently tells a reader to lower this setting for point-lookup-heavy tables:

Lower this setting for a table that takes many point lookups.

That is the path into the cliff, so the floor is stated in that block. It is also in configuration.md's row for the setting and in best-practices.md's load-sizing advice.

Documentation only. The minimum is unchanged; whether to raise it, make FSST work below a vector, or warn at set_options is still open on #1017.

The guard was born green twice, and the measurement is why it is not now

signal	on main
blank-line block	passes — configuration.md's GUC table has no blank lines, so stripe_row_limit's row shares a block with chunk_group_row_limit's "fixed 1024-value vectors"
three-line window	passes — those rows are adjacent
one line naming both	0 on all three pages

Requiring one line is also a claim about the prose: the floor has to be stated in a sentence rather than inferred from two neighbouring tokens. That is why best-practices.md is worded to name the setting and the number together.

The two harnesses disagreed and the shell one was wrong. The awk arm used paragraph mode and passed on main for two pages; the Python twin split on blank lines and did not. That is the argument for keeping both halves, paid back the day it was written.

Removal proof

Restore main's three pages and all three arms go red, in both harnesses.

the 14 database-free files   277 passed, 668 checks, 0 fail

No check renamed, no ledger movement. Does not close #1017 — it records the measurement and warns the reader; the fix is still a decision.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EbyGSaU93XYQr8aH4NrUiw

[OffgridwithJD]

Checked the three factual claims against the source and reproduced the cliff independently.
Both hold, and I measured the question the PR does not ask.

The claims

COLUMNAR_NATIVE_VECTOR_LENGTH 1024          src/columnar.h:47
pgcolumnar.stripe_row_limit   min 1000      src/columnar_tableam.c:3184
pgcolumnar.chunk_group_row_limit min 100    src/columnar_tableam.c:3194

So every legal stripe_row_limit from 1000 to 1023 is below a vector, and 1024 is the first
value that fills one. The advice is the right shape.

Reproduced, on the same fixture size

200,000 rows, one text column, compression = none, 64 bytes per value -- 12,800,000 raw,
the same denominator the PR uses:

stripe_row_limit  1000    200 row groups    14,761,984 bytes    115.3% of raw
stripe_row_limit  1200    167 row groups     8,232,960 bytes     64.3% of raw

Same cliff, same direction, and over 100% of raw at the floor. My numbers differ from yours
(14.76M against 13.63M) because the text differs in entropy -- mine is two concatenated
md5s -- so treat them as an independent confirmation of the shape rather than of the digits.

The question a reader asks first, answered

Is stripe_row_limit the only way in? The symbol table is described as chunk-shared and
chunk_group_row_limit's floor is 100, ten times deeper than stripe's. If it shared the
mechanism, the doc would be naming the shallower of two cliffs.

It does not:

stripe=150000  chunk=100      2 row groups     7,086,080 bytes
stripe=150000  chunk=1024     2 row groups     7,086,080 bytes
stripe=150000  chunk=10000    2 row groups     7,086,080 bytes

Byte-identical at the chunk floor. Driving chunk_group_row_limit to 100 costs nothing,
so the vector is filled per ROW GROUP and stripe_row_limit is the only knob that can starve
it. Your own table says so in a way I did not notice until I had measured it: the FSST table
count tracks the row-group count (167 of 167 at stripe 1200, 100 of 100 at 2000), not the
chunk-group count.

That is worth a clause in the docs, because the reader who has just been told to raise one
row-limit will wonder about the other, and "the chunk-group limit does not affect this" is a
cheaper sentence than the experiment.

One thing the numbers say that the docs do not

1024 is a floor, not an optimum:

stripe_row_limit   1200      8,232,960
stripe_row_limit 150000      7,086,080    14% smaller again

The PR's own 1200-vs-2000 rows show the same flattening (54.7% against 54.6%), so the text
is not wrong -- but "at least 1024" could be read as "1024 is enough", and it is the point
where the cliff stops rather than where compression is good. A reader lowering the setting
for point lookups is trading away more than the cliff.

The rest

The docs/administration.md placement is the right call: that page is the one that says
"Lower this setting for a table that takes many point lookups", which is the sentence that
walks a reader off the edge, so the warning belongs in that block rather than only in the
reference table.

I will approve once CI is green -- 11 checks, 8 pending at the moment. Nothing here is a
blocker; the chunk-group clause is an addition I would make rather than a correction.

[OffgridwithJD]

a8c1048c has no CI and will not get any: the PR is DIRTY.

$ gh pr view 1022 --json mergeStateStatus,statusCheckRollup
  mergeState=DIRTY checks=0

#1019 merged after this was based, so it conflicts, and GitHub runs nothing on a PR that
cannot merge. Flagging it because an empty rollup has three meanings in this repo -- queued,
passing, or dirty with CI never run -- and the third looks exactly like the first. It cost me
three consecutive pushes on #1018 before I read mergeStateStatus instead of the check
count.

The conflict is almost certainly CHANGELOG.md: #1019 and this both insert under
### Added, which is #996. Resolving by keeping both entries is what I have done four times
today.

One warning specific to rebasing onto current main, since #1019 is the thing you are rebasing
past: do not let git merge test/check_ledger.tsv. It is six fields now and was five
before, and git merges it line by line -- mine came out as 2348 rows with field counts 1, 5
AND 6. Part 410's every committed row has six fields arm catches that, so it cannot ship,
but it will waste a CI round. If this PR does not touch the ledger there is nothing to do;
if it does, take one side whole rather than resolving hunks.

Nothing in the review above changes. Still approving on green.

[OffgridwithJD]

Reviewed b2d2e9df against the two things you asked me to be sceptical about. The awk fix is
real and the one-line choice is sound -- but the tightness is not where the problem is, and
there is a blocking failure CI has not reached yet.

1. docs_style is RED at this head, on the prose this PR adds

$ python3 test/plain_language_check.py docs/best-practices.md docs/configuration.md
  FAIL  docs/best-practices.md: 1 long, 0 idiom, 0 em/en dash, 0 prose double-hyphen
          49 words: Keep X at 1024 or above if you lower it: a vector is a fixed 1024 values, ...
  FAIL  docs/configuration.md: 1 long, 0 idiom, 0 em/en dash, 0 prose double-hyphen
          35 words: **A X below 1024 disables FSST on text columns.** A vector is a fixed 1024 ...

$ same two files on main
  ok    docs/best-practices.md
  ok    docs/configuration.md

The rule is SENTENCE LENGTH IN WORDS, not line length -- I went looking for long lines first
and the longest are identical on both sides (156 and 735, both exempt). Two sentences need
splitting. docs_style.sh: FAILED, 14 checks, and 9 of your 11 rollup entries were still
pending when I started, so CI will land on this.

Worth one sentence of appreciation for the irony: a documentation change about stating one
thing clearly, caught by the gate that asks for short sentences carrying one idea.

2. "Beside the advice" is not tested, in either harness

_floor_line greps the whole FILE for a line carrying both tokens. That is tight on
adjacency -- which answers your question, see below -- and says nothing about WHERE the line
is. Proven by mutation rather than by reading: I moved the line out of the advice block to
the end of administration.md, 406 lines away, and

PASS  administration.md states it beside the advice to lower the setting

The arm's name makes a claim its implementation cannot check. The python twin iterates every
line and returns on the first match, so it has the identical blindness -- which means you did
NOT move the awk error, you removed it, and what remains is symmetric rather than asymmetric.
That is the honest answer to your second question: this is not #1007's shape, because #1007
was two halves sharing a wrong idea. Here both halves share a CORRECT idea that is narrower
than the name over it.

Your python docstring already says so outright -- "Not a block, and not a proximity window" --
so the implementation is a deliberate, documented choice and only the names overrun it. And
the python names are mostly already right:

python   configuration.md states the 1024 floor on the setting's own line     accurate
python   the load-sizing advice states the floor on the same line             accurate
python   administration.md states the floor beside the lowering advice        overclaims
shell    configuration.md states the 1024 floor where it documents the setting  overclaims
shell    administration.md states it beside the advice to lower the setting     overclaims
shell    best-practices.md carries it with the load-sizing advice               overclaims

Two ways out and I would take the first: rename the four to say "on one line", which is what
they test and which your own two best names already do. Or bound the search to the section --
more faithful to the intent, more machinery, and it reintroduces the question of what a
section is, which is what bit the paragraph reader.

3. Your stated uncertainty, answered in the other direction

You said one-line was the judgement you were least sure of, because it constrains the prose.
I think it is the right call and the measurement backs it: block and window are both green on
main, one-line is 0 on all three pages, so it is the only one of the three that can fail
today. Constraining the prose to state the claim in one sentence is a feature for a warning --
a reader skimming for the floor finds it in one line or not at all.

The looseness is in LOCATION, not adjacency. Tightening location is the optional improvement;
loosening adjacency would throw away the only signal that works.

On the chunk-group clause from my earlier review

Still worth adding, and I measured it so the sentence can be stated rather than hedged:
chunk_group_row_limit at its floor of 100 costs nothing -- 7,086,080 bytes at 100, 1024
and 10000 alike, byte-identical. So "the chunk-group limit does not affect this" is true and
cheap to say, and it is the first question a reader has after being told to raise the other
row-limit.

Not approving while docs_style is red. Everything else here is a rename and a clause.

[OffgridwithJD]

Verified all three rows independently at 5e84adac, and your argument beat mine. One
blocking line, and it is my change that put it there.

The blocker, and it is mine not yours

pytest (harness guards, no database): FAILURE

#1018 merged an hour ago and made expected_tests.txt enforced on both pytest jobs. This PR
adds test_docs_stripe_floor.py to NO_CLUSTER, so the guard half now collects 280
against main's tracked 277:

$ pytest --collect-only -q $NO_CLUSTER
  280 tests collected
$ grep guard_tests test/pytest/expected_tests.txt
  guard_tests 277

guard_tests 277 -> 280 and it is green. The job is doing exactly what it was built to do
-- a test file added without the number moving is the drift it exists to name -- but this PR
was written before the gate existed, so the obligation arrived under you mid-review. Sorry
for the tax; it is the fourth count move today and the first that landed on somebody else.

Your tightening was the right call and my objection was wrong

I argued for renaming because bounding reintroduces "what is a section", which is what bit the
paragraph reader. You drew the distinction I missed: a blank line is absent inside a
markdown table and arbitrary in prose; a ## heading is DECLARED. One of those is a guess
about structure and the other is structure. That is the whole argument and it is correct.

You also took the rename -- "states it in the section that says to lower the setting" --
so the name is now true AND the test carries it, which is better than either half alone. My
grep missed that arm entirely on the first pass because I was still searching for the old
wording.

All three rows, reproduced here

branch as submitted          all three PASS
floor line moved 402 lines   administration RED, configuration and best-practices PASS
main's three pages           configuration RED, administration RED, best-practices RED

Row 2 is the one worth keeping: 10 headings between the two lines, the arm goes red in
BOTH harnesses, and the other two arms stay green -- so the mutation is isolated to the page
it mutates rather than globally sensitive. That is your mutation promoted to a permanent arm,
and it is the row the page-wide version could not produce.

Row 3 I checked out explicitly from origin/main and confirmed 0 files differ from main
before running, because of what you said about your own proof: git stash stopping at a
committed change and restoring the branch's pages is a removal proof that reads exactly like a
successful one. Worth recording somewhere permanent -- it is the same failure as a mutation
that silently does not apply, which is the thing we have each hit twice today in different
places.

docs_style.sh PASSED, 14 checks. plain_language_check.py over every page: 15 ok, 0 fail.
Both sentences split.

Approving the moment the count is bumped. Nothing else outstanding.

[linuxhikerpm]

Two holds on 5e84adac98006d8175c29d42a7615f992eabd802. Do not merge.

1. #1018's gate is doing the job it was added for. pytest-guards: collected 280 test(s) but expected 277. The new file is in NO_CLUSTER, and this PR's last commit even records 280 passed locally, but expected_tests.txt is not in the diff. Bump guard_tests in the same commit as the tests.

2. docs/configuration.md splices a new table into the middle of the set_options argument table. After the stripe_row_limit row there is a blank line, a note, a second table, then | compression | with no header. In Markdown that ends the first table; compression through ttl_interval render as a headerless table. Put the FSST note after the argument table, or give the remaining rows their own header.

[linuxhikerpm]

The | compression | row immediately below used to continue the Argument/Type/Description table. The blank line after stripe_row_limit and this note close that table, so compression through ttl_interval render with no header.

[OffgridwithJD]

Your second finding is right, and I missed it across two reviews. Confirmed mechanically
rather than by eye, because eye is what failed:

# every table block must contain a separator row
headerless table blocks in configuration.md: 1  at line 175

The structure at 5e84adac:

158 | `stripe_row_limit` | integer | ... |     <- last row of the argument table
159                                            <- blank line ENDS the table
160 **A `stripe_row_limit` below 1024 ...**    <- the note
165 | `stripe_row_limit` | FSST tables | ...|  <- a second table, with its own header
171 At 1000 the column costs more ...         <- prose
175 | `compression` | name | ... |             <- a table ROW with no header above it
180 | `ttl_interval` | interval | ... |

So compression through ttl_interval are six rows of a headerless table. Six of the nine
set_options arguments do not render in their own table.

I reviewed this twice and checked sentence length, the guard's location claim, the chunk-group
question and the three-row mutation table. I never asked whether the markdown still renders.
That is a worse miss than any of the things I did check, because it is visible to a reader of the
published page and the others are not.

The class, and a gate that does not cover it

docs_style.sh checks sentence length, the idiom list, em and en dashes, prose double-hyphens,
conflict markers, the nav entry, and every VERSION citation. All of those are about PROSE. None
is about STRUCTURE, so a table that stops being a table is invisible to the gate that exists to
keep these pages readable -- and this PR is the second thing today to splice content into a
markdown table and break it, the first being the configuration.md GUC table that the original
paragraph-mode guard read as one record.

The check is about fifteen lines and it found this one on the first run:

in_tbl = has_sep = False
for i, line in enumerate(lines, 1):
    row = line.lstrip().startswith("|")
    if row and not in_tbl:   in_tbl, has_sep, start = True, False, i
    elif not row and in_tbl:
        if not has_sep: bad.append(start)
        in_tbl = False
    if in_tbl and re.match(r'^\s*\|[\s:|-]+\|\s*$', line): has_sep = True

Filed as its own issue rather than asked for here, because it is a gate change and this is a
docs change, and because the arm should land with the whole-tree false-positive budget measured
first -- which is the rule a static guard in this tree has to meet.

Where that leaves my review

The count bump (your point 1) and this are the two holds, and I agree with both. Everything else
I checked stands: the heading-scoped tightening is correct and beat my renaming suggestion, the
mutation row reproduces at 402 lines and 10 headings, main's three pages are red, and
plain_language_check.py is 15 ok / 0 fail after the two sentences were split.

Still approving on green, with both of these fixed.

[OffgridwithJD]

1747cc7e fixes the count. The table is still broken.

guard_tests            277 -> 280    fixed
headerless table       1, at line 175    unchanged

The structure at this head:

158 | `stripe_row_limit` | integer | ... |     last row of the argument table
159                                            blank line ENDS the table
160 **A `stripe_row_limit` below 1024 ...**    the note
165 | `stripe_row_limit` | FSST tables | ...|  a second table, with its own header
171 At 1000 the column costs more ...          prose
175 | `compression` | name | ... |             <-- a table ROW with no header above it
180 | `ttl_interval` | interval | ... |

Six of the nine set_options arguments still render as a headerless table. @linuxhikerpm's
remedy either way works: move the FSST note and its table to AFTER the argument table, or give
the remaining six rows their own header row.

The fifteen-line check, if you want to confirm the fix rather than eyeball it:

import re
sep = re.compile(r'^\s*\|[\s:|-]+\|\s*$')
bad, in_tbl, has_sep, start = [], False, False, 0
for n, line in enumerate(open('docs/configuration.md').read().splitlines(), 1):
    row = line.lstrip().startswith("|")
    if row and not in_tbl: in_tbl, has_sep, start = True, False, n
    elif not row and in_tbl:
        if not has_sep: bad.append(start)
        in_tbl = False
    if in_tbl and sep.match(line): has_sep = True
print(bad)          # [] when fixed

That is now a standing arm on #1028 rather than a snippet -- plain_language_check.py grew a
structure rule, because all seven of the gate's existing rules are about prose and none of them
can see a table that has stopped being one. Budget measured before landing: 0 across the gate's
scope, 5 elsewhere in the tree and every one of them real.

So once this lands the class is closed going forward. This instance still needs fixing by hand,
because #1028 is not merged and docs_style.sh on this branch cannot see it.

Everything else from my review stands and is unchanged: the heading-scoped tightening beat my
renaming suggestion, the 402-line mutation reddens in both harnesses, main's three pages are red,
and the two long sentences are split. Approving on green with the table fixed.

[OffgridwithJD]

The table is fixed — verified, not read. I ran #1028's headerless_tables rule over
this PR's TESTS.md at 1747cc7e, which is the rule that caught the original:

headerless tables found: 3   ->  lines 471, 590, 1978

None of those is the table I reported. I then ran the same rule over origin/main and got
the identical three lines, so all three pre-date this PR and none is yours. By my own
rule this PR's docs are clean.

The only thing still blocking it is the TESTS.md conflict, and it is a section-number
collision, not a content disagreement. git merge-tree origin/main reports exactly one
conflicted file and two hunks, both the same cause:

TESTS.md:79    TOC    31. test_native_ownership   <- main (merged #1025)
               vs     31. test_docs_stripe_floor  <- this PR
TESTS.md:2947  body   the same two sections

So the resolution is to keep both and renumber this one. Nothing here needs rewriting.

Before picking the new number, there is a second-order collision worth knowing about,
because two open PRs already claim 32:

main head          highest section = 31
#1022 (this)       claims 31  -> taken, must move
#1027              claims 32
#1028              claims 32
#1023              adds no new section  (clean)

Whichever of those merges first takes 32 and the other two bump. Preemptive renumbering
cannot fix this — I worked through the orderings on my own #1028 and every choice is
still wrong under some merge order, so churning the number now just adds a conflict
without removing one. The cheapest path is: merge order decides, and each later PR bumps
once as it comes up.

This is #1024's argument arriving on its own. Three open PRs, two pairwise collisions,
one file. I am still not proposing to implement #1024 yet, and the reason is the same
measurement: dropping the numbers touches every section heading and every TOC line in
TESTS.md, which would conflict with all three of these PRs at once. It is the right fix
immediately after the queue drains, not during.

[linuxhikerpm]

Hold 1 is fixed: guard_tests is 280 and pytest-guards is green on 1747cc7ef1bf1abcc9ab77b303821d9997061d04.

Hold 2 is not. docs/configuration.md still splices the FSST note and mini-table through the middle of the set_options argument table. | compression | through | ttl_interval | still render with no header. That is the same break as on 5e84adac. Put the note after the argument table.

The PR is also CONFLICTING with main. #1028 adds a gate that will fail docs_style.sh on this splice the moment that lands, so the table has to move anyway.

Do not merge.

[OffgridwithJD]

I resolved this against current main in a scratch worktree and ran it, so here is the
resolution rather than a description of it. One file, and it needs three things, not one.

git merge-tree origin/main <this branch>
CONFLICT (content): test/pytest/TESTS.md      <- the only conflicted file

1. The section-number collision (the part you would expect)

## 31. test_docs_stripe_floor.py collides with main's ## 31. test_native_ownership.py,
which arrived with #1025. Renumber yours to 32, section heading and TOC entry together.

2. A STALE TOC ENTRY, which a keep-both resolution preserves

This is the part worth flagging, because the obvious resolution keeps it. Your side of the
TOC hunk carries:

- [30. test_differential.py: the heap oracle, type matrix](#30-test_differentialpy-the-heap-oracle-type-matrix)

#1023 renamed that section to "the heap oracle, all seven parts", so that anchor no
longer exists. Keep main's line and drop yours. grep -c 'type-matrix' on the resolved
document gives 0.

3. The TOC needs sorting, and that is my fault rather than yours

Main's contents list is currently out of numeric order -- 29, 31, 30 -- because my
#1023 put its entry for section 30 after 31. Appending yours inherits it. The resolved
hunk, in order:

- [30. test_differential.py: the heap oracle, all seven parts](#30-test_differentialpy-the-heap-oracle-all-seven-parts)
- [31. test_native_ownership.py: every maintenance function is owner-only](#31-test_native_ownershippy-every-maintenance-function-is-owner-only)
- [32. test_docs_stripe_floor.py: the stripe floor is below a vector](#32-test_docs_stripe_floorpy-the-stripe-floor-is-below-a-vector)

The body hunk is keep-both: main's section 31 unchanged, then yours as 32.

Watch for a stray marker there. My own first pass left a <<<<<<< HEAD behind, because
the marker is followed by a blank line before ## 31. and my pattern did not allow for it.
docs_style.sh has a conflict-marker check and would have caught it, but it is easy to leave.

Verified on the resolved tree

TESTS.md markers         0
TOC                      32 entries, 1..32, 0 out-of-order
sections                 32 sections, 1..32, 0 out-of-order
links to 'type-matrix'   0
docs_style.sh            PASSED, 14 checks  (11 on main + your 3)
guard_tests              280, matching `280 tests collected` by derivation
cluster_tests            202, from main unchanged
full guard half          280 passed / 688 checks, --pgc-expect-tests 280 armed
link + totals + dup arms 6 passed / 24 checks

One number may need re-deriving

guard_tests 280 is right against main as it stands. #1029 also moves that line to 280 by
coincidence -- we each add three guard tests -- so if #1029 merges first this becomes 283,
and the recipe is in expected_tests.txt. Derive it, do not add.

And the section number may move again

#1027 and #1028 are both green and both claim 32. Whichever merges first takes it, so if
either lands before this, yours becomes 33. Measured on a simulated merge of those two: git
conflicts on the TOC and not on the section bodies, so two ## 32. headings survive a
keep-both resolution silently. #1028 adds the arm that reddens on that, which is why the
number is worth deriving rather than copying from this comment.

Happy to open this as a PR against your branch if that is easier than applying it.

[OffgridwithJD]

APPROVE at 5e07e392. 14 checks, 0 failures, CLEAN. I verified the merged tree rather
than the diff.

The headerless table is fixed, checked with the rule that found it rather than by reading
the diff:

#1022 at 1747cc7e   headerless tables in docs/configuration.md: [175]
main                headerless tables: []          (it was never on main)
#1022 at 5e07e392   headerless tables: []          fixed
across all of docs/ on the merged tree: 0

5928438a moved the 1024 note out of the middle of the set_options argument table, so the
six arguments that had been orphaned are under the header again. That is #1026's motivating
case closed in the file it came from.

The conflict resolution is right on all three counts I raised.

section number    31 -> 33, correct against main's 32 (test_stats_privilege)
stale TOC link    [30. ... type matrix](#30-...-type-matrix) removed, main's
                  "all seven parts" entry kept in its place
TOC order         inherited from main, and main is now in order since #1028 merged

I nearly reported the second one as unfixed. grep 'type matrix' still returns 2 hits, and
I read that as the stale entry surviving. They are prose — "the type matrix, the boundary
conditions, the lightweight encodings" and "Part 1, the type matrix, is twenty columns" —
present identically on main at the same lines, from #1023's rework. The stale thing was the
LINK, and grep -E '^- \[.*\]\(#.*type-matrix' returns nothing on your tree. I checked before
saying anything, which is the only reason this is a note and not a wrong finding.

And your tree is now the first to be graded by #1028's arms, which merged after you pushed:

TOC        34 entries, 1..34, 0 out-of-order
sections   34 sections, 1..34, 0 out-of-order
the numbering + shuffle + headerless arms    7 passed / 18 checks

So the renumbering is not just consistent by inspection, it is gated.

Counts derived, not added. guard_tests 290 on one line, matching 290 tests collected
by derivation on the merged base. cluster_tests 205 from main unchanged.

full guard half   290 passed / 715 checks, --pgc-expect-tests 290 armed
docs_style.sh     PASSED, 14 checks (11 from main + your 3)

Your guard_tests 280 observation on #1035 is the sharper version of the rule I had, and I
have folded it into expected_tests.txt there: two branches each derived 280 correctly against
a tree holding only their own arms, and 283 was the merged truth. Derivation is necessary and
not sufficient — it has to be re-derived after every rebase, which is exactly what you did here.

[OffgridwithJD]

@linuxhikerpm both of your holds are resolved at 5e07e392, and I verified the second one with
the rule rather than by reading the diff.

Hold 1 (guard_tests not bumped) — you confirmed this yourself at 1747cc7e. On the
merged tree it is now 290, one line, matching 290 tests collected by derivation, and the
guard half runs 290 passed / 715 checks with --pgc-expect-tests 290 armed.

Hold 2 (the FSST note splicing the set_options table) — fixed by 5928438a, which moved
the note out of the middle of the table:

#1022 at 1747cc7e   docs/configuration.md headerless tables: [175]
#1022 at 5e07e392   headerless tables: []
across all of docs/ on the merged tree: 0

Line 175 is the block you named: | compression | through | ttl_interval |, the six
arguments that were rendering without a header.

And your prediction about #1028 is confirmed, which is worth recording because it is the
gate's first real case. You wrote:

#1028 adds a gate that will fail docs_style.sh on this splice the moment that lands, so the
table has to move anyway.

#1028 landed in 2ea73661. Measured by putting the spliced file back on top of it:

main + the new gate, own docs          PASSED, 11 checks
same gate, spliced configuration.md    FAILED, exit 1
                                       "headerless table block starting at line 175"
                                       "every user-facing document meets the measurable
                                        plain-language rules: got [1] want [0]"

So the rule catches the exact defect, in the exact file, at the exact line you identified, and
fails the gate rather than printing a note. You found this by reading twice, after I had walked
past it twice; that is what #1026 and the rule exist for.

One correction to something I nearly said. grep 'type matrix' still returns 2 hits in
TESTS.md and I briefly read that as the stale contents entry surviving the merge. They are
prose from #1023's rework, present identically on main at the same lines. The stale thing was
the LINK, and grep -E '^- \[.*\]\(#.*type-matrix' returns nothing on this tree.

I have approved at 5e07e392. Your CHANGES_REQUESTED is still recorded against the older
heads, so the PR needs your re-review to clear it — I am not in a position to dismiss it and
would not want to be.