From e949d7cd82a39df7e3abe943c64ecb3715961ef2 Mon Sep 17 00:00:00 2001
From: Nils Lehnen <30603423+iderex@users.noreply.github.com>
Date: Sun, 30 Aug 2026 23:22:23 +0200
Subject: [PATCH] Derive the commits the signature reading is taken at

The signature subsection of docs/quality-parity.md said its verification paste
was read at the three most recent non-merge commits and named 45bfe62, 2edacce
and 43b4fae. Eleven non-merge commits have landed since, so those are the
twelfth, thirteenth and fourteenth, and the sentence above the paste had stopped
being true while the paste under it stayed correct.

That is the harder half of this class to see. A reader checking the evidence
checks the output, and all three still answer true valid; what had gone wrong
was the claim naming them. The command now derives its own subjects from
git log, so the trio moves with the branch and cannot go wrong in that direction
again, and what a re-run refuses instead is the thing the paragraph is about,
which is a commit reaching the default branch without a signature the platform
verifies.

I found it by running every command this section pastes before quoting a row
back, which is how the four earlier repairs to it were found as well. Nothing
else in the section moved: the rule types on both boards, the nine pull-request
parameter rows on both boards, the enforcement and bypass paste, the two issue
states and the timeline all return what the document gives them.

Refs #55. It does not finish that issue, whose remaining leg is a ruleset
parameter no change in this tree reaches.

Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
---
 docs/quality-parity.md | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/docs/quality-parity.md b/docs/quality-parity.md
index d2cc7eb..317bd34 100644
--- a/docs/quality-parity.md
+++ b/docs/quality-parity.md
@@ -817,10 +817,12 @@ is smaller and worth stating exactly. The requirement is configured on both
 boards and the condition record 0023 makes it effective on has been met. That it
 has not cost a landing here is a separate reading and it still holds, because
 the commits reaching the default branch carry a signature the platform verifies.
-Read at the three most recent non-merge commits:
+Read at whatever the three most recent non-merge commits are when the command
+runs, so the trio moves with the branch instead of being three names typed into
+a document:
 
 ```
-for c in 45bfe62 2edacce 43b4fae; do
+for c in $(git log origin/main --no-merges -3 --format='%H'); do
   gh api repos/Flowfin/lab/commits/$c --jq '.commit.verification | "\(.verified) \(.reason)"'
 done
 true valid
@@ -828,6 +830,26 @@ true valid
 true valid
 ```
 
+WHAT STOOD HERE NAMED THREE COMMITS AND CALLED THEM THE THREE MOST RECENT. Read
+on 2026-08-30 they were the twelfth, thirteenth and fourteenth:
+
+```
+git log origin/main --no-merges --format=%h | grep -n '^45bfe62\|^2edacce\|^43b4fae'
+12:45bfe62
+13:2edacce
+14:43b4fae
+```
+
+Each of the three still answers `true valid`, so what stopped reproducing was
+the superlative above the paste rather than the output under it, and that is the
+half of this class hardest to see: a reader checking the evidence checks the
+output, and the output was right. What found it was running the command before
+quoting the row back, which is how every earlier repair in this section was
+found as well. A command that derives its own subjects cannot go wrong in that
+direction, and what a re-run refuses instead is the thing this paragraph is
+about, which is a commit reaching the default branch without a signature the
+platform verifies.
+
 Three commits are three commits and not a property of every account that may
 push here. This board takes experiments from anybody, an unsigned history
 refuses the merge rather than the commit, and the repair is rebuilding the