Restore the two sections of the parity document that left the branch (#155)

[iderex]

Refs #155

What this changes

docs/quality-parity.md, and nothing else. Two sections come back, and the
three rows of ## The table that were replaced in the same hunk.

The five declared check names the table gave no verdict to, under
## What this board adds that the target does not have. Three platform suite
entries, vet and required contexts, each with kept or dropped and a reason,
in the same terms the table uses.

The whole of ## Which contexts arrive, and on which pull requests, which is
the walk of which contexts reach which commits: that the command above it reads
a commit no pull request produced, that one name is reported twice on the same
commit, that two names come from a code-scanning upload rather than from a job,
that the upload is conditional while the step failing on findings is not, that
no workflow here narrows itself to some pull requests, and that one job can
start and still be unable to do its work.

How the absence arrived

d3edfc95b8526033c79cb26afe48282c2c090e32 took its tree from an older state of
the default branch and landed on top of a newer one, under a message describing
a change to how one workflow pin is commented. This file was among the seven
paths it replaced and went from 631 lines to 209.

This one is an insertion rather than a blob restore, because #156 added a row to
the parameter table well below both sections, so the two hashes differ on
purpose and the diff is what to read. What the diff says is that the file now
differs from the state before the removal by that row and the two paragraphs
above it, and by nothing else:

git diff --stat 90656ba HEAD -- docs/quality-parity.md
 docs/quality-parity.md | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)
grep -c 'require_extra_approval_for_unattributed_changes' docs/quality-parity.md
1

So nothing here was retyped and nothing #156 landed was dropped.

What failure it prevents

Issue #26 assembles the required set out of this document. A name this tree
declares and this document gives no verdict to can be read as kept or as dropped
with equal justice, so two readers build two different gates from the same page.
Five names were in that state. They are declared here and the restored section
judges each of them:

git grep -h -E '\{Name: "(test \(|vet"|required contexts")' origin/main \
  -- internal/contexts/contexts.go | sed 's/^[[:space:]]*//'
{Name: "test (linux/amd64)", Why: theSetIsEmpty, Until: "#26"},
{Name: "test (windows/amd64)", Why: theSetIsEmpty, Until: "#26"},
{Name: "test (darwin/arm64)", Why: theSetIsEmpty, Until: "#26"},
{Name: "vet", Why: theSetIsEmpty, Until: "#26"},
{Name: "required contexts", Why: theSetIsEmpty, Until: "#26"},

The second failure is a reader taking the table for the whole answer while the
question of which contexts arrive on which pull requests is answered nowhere.
That walk is #62's deliverable, and it had left the branch.

One of the three restored table rows is wrong on the default branch today rather
than merely shorter, which makes this more than a length repair. The prettier
row there says the prose half is issue #50 and that nothing in this tree formats
Markdown. Both halves have stopped being true:

gh issue view 50 --repo Flowfin/lab --json number,state --jq '"#\(.number) \(.state)"'
#50 CLOSED
git grep -n 'name: prose format' origin/main -- .github/workflows/
origin/main:.github/workflows/prose.yml:53:    name: prose format

Every paste in the restored text was re-run

Restoring prose that was true when it was written is not the same as restoring
prose that is true now. So every command the restored text pastes was run
against the current origin/main and against the live platform before this
change, rather than trusted because it had once been true, and all of them
still reproduce. That includes the two run logs and every historical check-run
listing.

One is worth naming. The paste reading zizmor.yml lines 76 to 84 reproduces
only because the comment the same removal took out of that file is back. Had
this landed first, that paste would have named the wrong lines.

The commands that read the tree at a moving reference, re-run in order:

git grep -L 'push:' origin/main -- .github/workflows/
origin/main:.github/workflows/dco.yml
origin/main:.github/workflows/dependency-review.yml
origin/main:.github/workflows/pull-request.yml
git grep -n 'paths:\|paths-ignore:' origin/main -- .github/workflows/ ; echo "exit=$?"
exit=1
git grep -L 'branches: \[ *"\*\*" *\]' origin/main -- .github/workflows/
origin/main:.github/workflows/dco.yml
origin/main:.github/workflows/dependency-review.yml
origin/main:.github/workflows/scorecard.yml
git grep -n 'branches:' origin/main -- .github/workflows/dependency-review.yml ; echo "exit=$?"
exit=1
git grep -n 'types:' origin/main -- .github/workflows/
origin/main:.github/workflows/dco.yml:13:    types: [opened, synchronize, reopened]
git grep -c '^\s*if:' origin/main -- .github/workflows/
origin/main:.github/workflows/scorecard.yml:1
origin/main:.github/workflows/zizmor.yml:1
git grep -n 'gh api' origin/main -- .github/workflows/
origin/main:.github/workflows/contexts.yml:93:          if ! gh api "repos/${REPOSITORY}/rules/branches/${DEFAULT_BRANCH}" \
git log -1 --format='%h %ad %s' --date=short --diff-filter=A -- .github/workflows/contexts.yml
2b954f5 2026-08-12 Refuse a required context and a check name that disagree (#71)

and the one reading the target board:

gh api repos/Flowfin/jellyfin-plugin-sso/rules/branches/main \
  --jq '.[] | select(.type=="required_status_checks")
        | .parameters.required_status_checks[].context' \
  | grep -E '^(test|vet)' ; echo "exit=$?"
exit=1

On the size

This is 425 lines added, above the 400 the corpus carries as a cap, and it is
not a scope that was planned wrong. One property holds across every changed
byte: each is a byte the default branch held at 90656ba, put back by reversing
one commit's hunk on this file, and the two commands under How the absence
arrived are how a reader checks that property instead of reading the diff.
Splitting it would produce two changes to one file where the second cannot land
until the first has, for a document the removal took out in one piece.

What was run

At 5078b9427b9d69ea281d7c1958d0c8fad1715a4a, on Windows, with no graphical
session and as an ordinary user:

go build ./cmd/... ./internal/...
go vet ./cmd/... ./internal/...
gofmt -l cmd internal
go test -count=1 ./cmd/... ./internal/...
ok  	github.com/Flowfin/lab/cmd/contexts	0.377s
ok  	github.com/Flowfin/lab/cmd/lab	2.577s
ok  	github.com/Flowfin/lab/cmd/notices	11.402s
ok  	github.com/Flowfin/lab/cmd/pullrequest	0.813s
ok  	github.com/Flowfin/lab/internal/check	1.029s
ok  	github.com/Flowfin/lab/internal/contexts	0.595s
ok  	github.com/Flowfin/lab/internal/hardware	1.028s
ok  	github.com/Flowfin/lab/internal/invariants	1.498s
ok  	github.com/Flowfin/lab/internal/notices	0.800s
ok  	github.com/Flowfin/lab/internal/prose	1.244s
ok  	github.com/Flowfin/lab/internal/pullrequest	1.024s

go build, go vet and gofmt -l each printed nothing, which is the passing
result for all three.

The one check in this tree that reads this file is the prose format, and it is
the reason the five declared names are pasted with their leading indentation
stripped, since prose-carries-a-tab refuses a tab in tracked Markdown:

go test ./internal/prose -run 'TestThisRepositorySatisfiesTheProseFormat' -count=1 -v
    prose_test.go:279: 
        examined ../..
        32 prose files read, and testdata is not read
        0 refused

go run ./cmd/lab check .
examined .
1 experiment directory walked, 1 record read
18 decision records read
the time this run read is 2026-08-21T14:10:52Z
0 refused

That check judges whitespace and characters. Whether the restored sentences are
true is not something it reads, and the re-runs above are what stands behind
them instead.

No test was skipped for needing elevation, and none was run with any.

What this does not do

It does not finish #155. One path group that commit removed is still missing,
LICENSE with the ## License section of README.md, and that one is #148.

It does not touch the second question #155 raises, which is whether anything
here should refuse a merge that removes a tracked path without saying so in its
body. Nothing in this tree reads what a change removed, and restoring a file
does not change that.

It does not move #26 or #62. What both landed is this text; what was missing is
the text. The required set on the default branch is untouched and is still
empty, so nothing here is a report of a required context that failed to arrive.

No second person has read this change. The evidence above stands in place of
one, and that is a disclosure rather than an assurance.