Documentation

LeanPool.JacobianDiffgeo.MeromorphicTrace.OrderMultiplicity

Order↔multiplicity bridges (meromorphic-trace, cluster 1) #

Unit: meromorphic-trace (docs/design/meromorphic-trace.md §2 D4, §4.2, §5 P2). Standing surface hypotheses throughout.

Route: both hard cases reduce to CC3's ordAtX_of_contMDiffAt_eq_zero (already built, local-multiplicity/meromorphic-and-divisors) applied to f' := holoRepr (resp. f'⁻¹ for the pole case), plus ONE shared CC4-level inChartAt-germ comparison (multiplicityENat_toP1_eq_of_eventuallyEq) identifying multiplicityENat (toP1 f') x with the multiplicityENat of the appropriate ℂ-valued companion, using the reusable holoRepr/toP1 facts exported by ToP1.lean.

Deviation: the design's third export, multiplicity_toP1_of_ordAtX_eq_zero (ordAtX f x = 0 → multiplicity (toP1 f) x = 1), is mathematically false as stated and is NOT proved here. Counterexample: f (z) = 1 + z ^ 2 near z = 0 has ordAtX f 0 = 0 (f 0 = 1 ≠ 0, a "regular value" in the vanishing-order sense) but toP1 f has multiplicity 2 at 0 as a map (f y - f 0 = y ^ 2, a genuine ramification point — ordAtX f x = 0 says nothing about deriv f x, only that f does not vanish/pole at x). The design itself flags this lemma as a non-essential "cheap corollary... even though we do not need it ourselves" for form-trace-tower's glue; nothing in this unit's own proof obligations needs it, so it is simply dropped rather than patched into a different (correct) statement under the same name.

Zero case (P2): at a zero of f, CC4's multiplicity of toP1 f IS the vanishing order.

Pole case (P2): at a pole of f, CC4's multiplicity of toP1 f IS the order of the pole (made positive).