SPEC and anchor README: the certificate exception stated exactly (an anchor can be certified over the undecided sibling of the decided block; measured in a fixture, not exercised), with both adversaries; internal finding identifiers replaced by descriptions

SPEC.md

@@ -464,10 +464,17 @@ Falcon key can rewrite at most the tail since the last anchor, so fork depth <=
 block 20,746,736 (about 20 seconds at the measured rhythm; <= 128 blocks, about 75 seconds, from block
 17,225,968 to block 20,746,736; <= 32 blocks, about 16 seconds, before that); rewriting anything below an anchor changes that anchor's parent hash, forces the
 anchor to be reproduced, and reproducing it requires Falcon signatures the adversary does not have.
-Added 2026-10-01 (AIP-22 erratum of that date; derived, not exercised): the certificate's seals carry no
+Added 2026-10-01 (AIP-22 erratum of that date): the certificate's seals carry no round, so an anchor
-round, so if the validators had also sealed, at the height of the last anchor's parent, a block in a
+can be certified over the undecided sibling of the decided block, with honest validators' seals, if
-round that did not decide it, those honest seals can certify an anchor over that block, and the
+at the height of the last anchor's parent the validators sealed that sibling in rounds that did not
-rewrite can reach the anchor's parent, one block deeper than the bound above.
+decide it (an adversary that controls the order of messages across three round changes at that
+height can bring that about); the rewrite can then reach the anchor's parent, one block deeper than
+the bound above. Before stage 5 of AIP-22 (not activated on chain 2800) forging the headers takes a
+quorum of classical keys, which this adversary holds and a single validator does not; from stage 5
+the anchor's header needs its proposer's Falcon-512 seal, which this adversary lacks and a single
+validator has. Measured in a test fixture with the production rules; not exercised on any network.
+With a repair in code, not yet deployed, no node takes the anchor's parent as decided from such a
+certificate, only its grandparent, the block both siblings share.
 History below H remains protected by ECDSA alone, permanently (source:
 `anchor/consensus/common/.../PqAnchorConfig.java`, interval javadoc; `anchor/README.md`).
 
@@ -980,7 +987,8 @@ implementation exists to compare against].
 - The EIP-4788 (Cancun) beacon-roots system call targets a contract with no code on chain 2800, so
   it is a per-block no-op that Besu reports at ERROR level in its log; state is unaffected. A
   client must not treat the empty beacon-roots contract as an error in its own sync
-  [MEASURED 2026-08-07, finding D-153 in the repository's findings register; not restated in any
+  [MEASURED 2026-08-07, a dated finding in the operator repository's findings register (the empty
+  beacon-roots contract and its per-block ERROR line); not restated in any
   bundle file, see section 9, G8].
 
 ---
@@ -1087,7 +1095,8 @@ step `13034000:3` reads "enforced since 2026-08-14" in prose: the step was confi
 the effective minimum was held at 1 by the ceiling until the window's end (source: `anchor/README.md`;
 `PqAnchorLapse.java`).
 
-**D6. Correction of 2026-08-19 (repository finding D-235): `aere.falcon.forkBlock=14050000` armed a
+**D6. Correction of 2026-08-19 (a finding of the operator repository's register: the per-block Falcon
+quorum described as blocking was not enforced): `aere.falcon.forkBlock=14050000` armed a
 RETIRED rule and changed no enforcement.** The fleet was configured on 2026-08-15 with that value,
 intended as a per-block blocking Falcon quorum, and public material said so. In the shipped code
 the rule it arms (`FalconSealValidationRule`) retires at the anchor activation height 13,014,000 in
@@ -1142,19 +1151,19 @@ are the authoritative in-protocol trace of the expansion (source: `registries/RE
 
 ---
 
-**D8. The COMMIT seal message under an armed anchor (found 2026-09-02, D-311).** A verifier of the
+**D8. The COMMIT seal message under an armed anchor (found 2026-09-02 on the public testnet).** A verifier of the
 COMMIT enforcement that checks the seal over the ECDSA committed-seal hash refuses EVERY commit as
 soon as the anchor is armed, because the emitter signs the anchor form (section 2.6). The shipped
 client before 2026-09-02 had exactly this divergence between its emitter and its verifier; it was
 found on the public testnet 28001 at the first enforcement height (the chain stopped at block
 999), fixed by deriving both sides from one function, proven with unit and plumbing tests, a
 rehearsal with the anchor armed, and the testnet itself, and the fleet was moved to the fixed
-build on 2026-09-02 (image `d311-20260902`, version `26.4.0-aere.1-d203201-wt95fac2d7`). A
+build on 2026-09-02 (version `26.4.0-aere.1-d203201-wt95fac2d7`). A
 third-party client implementing COMMIT enforcement MUST verify over the anchor form whenever
-`height + 1 >= aere.pq.anchorBlock` (source: `testnet-public/D-311-DOVADA-2026-09-02.md`,
+`height + 1 >= aere.pq.anchorBlock` (source, in the operator repository: the testnet proof of
-`deploy/validators/d311-2026-09-02/SURSA.md`).
+2026-09-02 and the source record of the fixed build).
 
-**D9. Osaka header fields under QBFT (found 2026-09-02, D-322).** On an AERE QBFT chain with the Osaka
+**D9. Osaka header fields under QBFT (found 2026-09-02 on the public testnet).** On an AERE QBFT chain with the Osaka
 fork active from genesis (the public testnet 28001: `osakaTime=0`, `futureEipsTime=0`), Besu writes the
 EIP-7928 block access list hash (`balHash`) and the EIP-7843 `slotNumber` ONLY in block 0; every later block
 omits both fields (measured on blocks 1 and 47744 through `eth_getBlockByNumber`). A second client that
@@ -1195,7 +1204,7 @@ the gap as real rather than assume.
 - **G7. The `0x100` P-256 (RIP-7951) input/output format.** Live and classical, upstream Besu;
   not specified in this bundle.
 - **G8. The EIP-4788 no-code observation** (section 6.5) rests on a dated repository finding
-  (D-153, 2026-08-07), not on a bundle file; a bundle-resident statement (or a fixture proving the
+  (2026-08-07, in the operator repository's findings register), not on a bundle file; a bundle-resident statement (or a fixture proving the
   no-op) does not exist yet.
 - **G9. Whether a certificate reused by an adversary for its one permitted fork block passes
   eligibility in every corner case** was argued from code and never executed as a run (source:

anchor/README.md

@@ -70,9 +70,11 @@ anchor itself; and a message without a valid seal is REFUSED from blocks 17,250,
 heights were set on all nine validators on 2026-09-05 and take effect as the chain reaches them;
 until each height passes, that message type is still accepted without a seal. What a quantum
 adversary cannot do at any height is rewrite history past the last anchor without also forging
-Falcon-512 and SLH-DSA-SHA2-128s signatures (added 2026-10-01, AIP-22 erratum of that date: except at
+Falcon-512 and SLH-DSA-SHA2-128s signatures (added 2026-10-01, AIP-22 erratum of that date: except the
-the height of the last anchor's parent, if the validators had also sealed there a block in a round
+last anchor's parent while headers carry ECDSA seals, before stage 5 of AIP-22, since an anchor can be
-that did not decide it; derived, not exercised). None of this has been audited by a third party.
+certified, with honest validators' seals, over the undecided sibling of the decided block; measured
+in a test fixture with the production rules, not exercised on any network; SPEC.md, interval
+section). None of this has been audited by a third party.
 
 The threat it addresses is not "harvest now, decrypt later". A signature is public; there is nothing
 to harvest. The threat is **retroactive rewriting**: validator keys recovered later can be used to