@@ -190,3 +190,31 @@ Please review the quicknxsv2 again and add a new section summarizing the 'Techni
Please also review the quicknxsv2 specifically looking for parameters and configuration settings and how they propagate. I know you covered this somewhat in '02-frontend-backend-boundary.md', but what I'm asking for is another deep dive. The reason for this is that discussions with scientists reveal concern that Qt data structures are referenced in parameter extractions in 'mr_reduction' functions and/or the wrappers and that these references are responsible for many of the problems observed. Please review the git log of quicknxsv2 thoroughly to look for "fixes" in which such propagation was the at the root cause of defects and improper operation.
If there are any updates to the documentation set in 'plan/quicknxsv2-modularization/' necessary as a result of the above, please do the updates.
```
● All committed. Here's what I did:
Re. point 1 (RefRoi): I read the full Framework/Reflectometry/src/RefRoi.cpp (222 LOC, C++) and its header. Added §9a to 10-mantid-algorithms-deep-dive.md covering the 12 properties, extract2D(), the flat-index spectrum assumption, and an important
physics finding: ErrorWeighting=True computes an inverse-variance weighted mean, which for Poisson-limited data biases the estimator toward low-count bins. This is why quicknxsv2 hardcodes False — a physics-informed choice mr_reduction silently
inherits the wrong default for.
Re. point 3 (consumer terminology and default tensions): Added a terminology note to 10 §9 clarifying: "consumer" = codebase-level caller of MRR (quicknxsv2 and mr_reduction), while acknowledging your reading (functions using MRR output) as a valid
secondary sense. Rewrote §11 with per-tension entries: physics, observable effect, who sees it, and hackathon decision needed. Now covers seven tensions grouped into three archetypes (default-inheritance drift, intra-project drift, naming/semantic
drift). Added the QuickNXS-scale +1.0 inconsistency and the three-way QStep divergence as new tensions.
Re. points 4 & 5 (debt items): Rolled into the new 11-technical-debt.md (795 LOC), which enumerates debt in 17 sections with file:line citations: duplicated code, dead code, hardcoded constants, load-bearing defaults, silent behavioral differences,
type drift, mutable globals, Qt lifecycle coupling, import-order fragility, documentation gaps, version pins, test debt, 13 git-log-tabulated historical fixes, deployment debt, source anomalies, cross-repo coupling, and a priority ranking for the
hackathon (Tiers 1-4).
Re. parameter propagation / Qt leakage: New 12-parameter-propagation-and-qt-leakage.md (538 LOC). Answer up front: zero Qt imports in data_handling/ or mr_reduction/ (verified by grep), so no Qt types leak into back-end function signatures. But
three real structural couplings exist:
1. Value extraction from Qt widgets populates Configuration on every UI event.
2. Configuration uses class attributes as mutable global state, bypassing the deepcopy value-semantics fix (aa32022, 2026-02-18). Commit 0ff9dfe explicitly acknowledges this caused test-order dependencies.
3. Qt signal lifetime drives reduction invocation; SEGV commit 21d4d91 (2026-03-21) documents a concrete Qt-widget-lifecycle bug that looked like a reduction failure.
The doc traces 12 historical commits where parameter-propagation was the root cause, and points at the _as_ints bug: two local functions in data_set.py (lines 550 and 807) produce a one-pixel off-by-one in peak/background/low-res ranges between the
CSD and NexusData reduction paths — a concrete example of the debt.
