Batch 362-B (CORRECTION OF RECORD: BATCH 362-A IS WITHDRAWN -- a definition occurring in a statement's CONTENT may not be re-spelled by a proof batch; the truncation-point evidence is kept as a Refuted/ refutation of the transcription).

THE WITHDRAWAL (owner's ruling).  Batch 362-A re-spelled IsNormalOrder and IsBaseField in Definitions/FLM861BookDefs.lean to the truncation-point spelling.  Not admissible: the two definitions occur in the CONTENT of the three frozen book-facing statements (FLM_8_6_1, FLM_8_8_9, FLM_8_10_2 carry hY : IsVertexOperator bL form E Y as a hypothesis), so re-spelling them changes those theorems -- a stronger hypothesis makes them WEAKER -- and "never weaken a statement to make it provable" forbids exactly that.  A definition may be re-spelled only (i) against a COMPILED REFUTATION of the old spelling and (ii) as an owner-level decision recorded like the 344-A/345-A repairs; 362-A had neither (its probe showed only that the new spelling is STRONGER, which is not a refutation).  Both Lean files are restored VERBATIM from their pre-362-A state; nothing of the repair remains in Definitions/, and the batch-361-A WINDOW DEFECT OF RECORD notes and the SUSPECT mark on MM.FLM861Book.isVertexOperator_unique are back in force.

THE DURABLE EVIDENCE (NEW Refuted/MMFLM861BookWindowRefute.lean, self-contained, EXIT=0, no sorry, indexed in Refuted/README.md).  The repo's spelling is copied verbatim as MM.B362B.Drafted.IsNormalOrder and the truncation-point spelling as MM.B362B.Fixed.IsNormalOrder, and MM.B362B.window_gap proves: for X = the single mode -1 (the identity), Y = the single mode 0 and every NONZERO w, the repo's spelling admits the ZERO family as :XY: (witness window 0 cuts both sums to 0), while the truncation-point spelling admits NO window for it (at N = 0 the first tail is already w != 0; at every N >= 1 the cut sum is w while the claimed value is 0).  So the repo's transcription of (8.4.16) is REFUTED as a rendering of the book's relation (strictly weaker; it does not force the value to be the LIMIT), which is what an owner-level repair would need.  This does NOT refute isVertexOperator_unique itself (no second solution of the whole prescription is exhibited): the registered piece stays SUSPECT and un-attacked.

EVIDENCE: lake build FinalCheck EXIT=0 (9175 jobs, the same NINE 'declaration uses sorry' warnings); lake env lean Refuted/MMFLM861BookWindowRefute.lean EXIT=0, and the two older book refutations EXIT=0; the three book-facing statements byte-identical; forbidden_tokens on the touched files: admit=0 axiom=0 native_decide=0, sorry only where registered.  Records: NOTES.md sections 279--280; HANDOVER.md sections 3 and 6.
