By: ValentinHirschi <valentin.hirschi@gmail.com>
fix factorized UV conversion and gauge-state sewing Resolve ttH tensor canonicalization without expanding graph numerators. Use matching W/Z virtual rules and complete covariant cut multiplets, retain optional CP symmetrization with warnings, and guard unsupported pole rules. Collect vacuum denominator branches before incidence fusion while keeping numerator factors intact. Migrate graph selectors and derived grouping references with signed physical targets retained. Validation details are recorded in PHASE_CONVENTIONS_FIX.md. User prompts (verbatim): Summarize what you changed and confirm that `just test_gammaloop` pass. Also make sure to push a PR to merge into \`[...]\_optimization\` Continue Summarize what you changed and confirm that `just test_gammaloop` pass. Also make sure to push a PR to merge into \`[...]\_optimization\` Also you said in the PR: """ Retained limitations: `uv::slow::epem_ttxh_gl00_uv` fails in the `UVOrchestrator::Compare` tensor canonicalizer with `ExternalIndexMismatch`; the proposed upstream repair is unverified and not included. The separate W/Z virtual-propagator/cut-projector gauge change awaits approval. Complex masses are rejected; Hermitian complex CKM sewing is supported, with documented restrictions on the optional CP optimization. """ This needs to be fixed. Yes, continue as planned and obviously no need to concern yourself with or support at all backward compatibility! Continue as planned but what was your rational for the new schema? But I want to keep: """ **Remove ****`symmetrize_left_right_states`****.** That optimization exchanges the forward graph’s sides using CP, which is not generally valid with complex couplings. Its configuration and saved assumptions are removed. """ because the user may know it's valid for his own theory, but you can emit a warning at runtime when the user uses it if you want. Continue, and also: Launch a subagent to study the slowdown occurring during generation and comparison with numerators of 50k+ diagrams. It's not due to the evaluation time of a single numerator but it's during the lookup with all previous accepted entries (of course it's unavoidable to have this growth in lookup time but maybe an agent can find a non-invasive easy improvement/optimization in feyngen for this).