agmission/server/docs/ADVANCED_REPORT_METRICS_VERIFICATION.md

Advanced Application Report — Metrics Calculation & Verification

Purpose: trace every displayed number on the Advanced Application Report (pages 1–3) back to its raw source field, document the exact formula and unit conversions at each step, and record whether it was verified correct, fixed, or left open for a product decision.

Scope: helpers/report_util.js (D1 analytics engine — pure computation over ApplicationDetail points), controllers/advanced_report.js (D2 datasource builder — formatting/localization/overrides), plus the shared conversion helpers in helpers/utils.js and helpers/geo_util.js.

Report layout referenced:

• Page 1 — Mission Information, KPI tiles, Mission Statistics, Products table, Weather box
• Page 2 — Mission Coverage grid (coverageCards, client-side page, suppressed for single-zone jobs)
• Page 2/3 — Zone Detail (one page per zone: Flight Statistics box + zone map)
• Page 3 — Flight Line Statistics table (per-line rows, nested under each zone)

---

Legacy Consistency Matrix

Every calculation reviewed, checked against the actual legacy code (not documentation prose — one documented legacy rule turned out to be wrong when checked against the real code, see §5 item 3), with an explicit verdict on whether a legacy equivalent exists and whether this report's logic matches it. Legacy source: workers/job_worker.js (import pipeline), controllers/job.js (legacy report datasource, makeJobAppDataSource/preAppReport_post), helpers/job_util.js.

Metric	Legacy equivalent?	Same logic?	Verdict
Point-to-point distance	Yes — geoUtil.distance(), literally the same function	✅ identical (not a copy, the same call)	Match
Midnight-wrap time diff (todDiff)	Yes — inline in 3 places in job_worker.js, same 80000/86400 constants	✅ byte-for-byte same formula	Match
Planned area (incl. exclusion-zone netting)	Yes — jobUtil.calcTTSprayAreas()	✅ mirrors exactly, including its shared double-subtraction bug on overlapping exclusions (§5 item 11)	Match (fixed to match, this session)
Spray-pass segmentation (line breaks)	Yes — getSprayOnSegments(), controllers/job.js:604	⚠️ partial — shares the core rules (llnum change, marker, ≥1km jump) but legacy also has a satellite-quality (satsIn) edge trim and a fuller endSegChecker() transition table this engine doesn't replicate	Needs a decision — see below
Turn time (state machine)	Yes — inline in job_worker.js:1486-1516	✅ same core pattern, plus a deliberate correctness addition (atFresh guard) legacy lacks	Match + intentional improvement
Avg Speed (per-point rule)	Yes — totalSpeedAcc/spraySpeedCount, gated on sprayStat>0 only	✅ fixed this session to include the line-start marker, matching legacy exactly (previously wrongly excluded it based on a doc error)	Match (fixed)
Avg XT Error (per-point rule)	Yes — gated on sprayStat===1||===3	✅ matches exactly	Match
Avg Height (per-point rule)	No legacy field at all	—	New (unavoidable)
Total Flight Time / Duration / Ferry Time	Yes — sum of consecutive-point deltas, each capped ≤120s	✅ fixed this session (was wall-clock last-minus-first; now matches legacy's capped-delta sum exactly)	Match (fixed)
Volume/material integration	Partial — legacy's getAppliedRate() 3-way priority (configured rate / flow-derived rate / lhaReq fallback), area × rate per record	⚠️ different method — this engine always integrates flow over time directly when flow data exists, with no per-record priority scheme; mathematically equivalent to legacy's flow-derived branch, but legacy prefers the configured-rate branch by default. The configured-rate branch itself is no longer used as a mission-level fallback here at all — see §5 item 10	Match where flow data exists; intentionally diverges where it doesn't (dashes instead of a configured-rate guess) — see §5 item 10
Volume integration's outlier gap	Legacy caps every time accumulator at 120s	✅ fixed this session — this engine's volume loop had no upper gap bound at all until now	Match (fixed)
Avg Speed / Avg XT / Avg Height — mission-level weighting	Legacy: one flat mean across every qualifying record in the whole job (no zones, no lines — just count-weighted)	⚠️ different — this engine derives the mission figure from a zone roll-up that's point-count-weighted pass→line, then time-weighted line→zone and zone→mission. Quantified divergence: a constructed case with uneven GPS logging density across zones showed 49.1 vs. legacy's-equivalent 18.2 (2.7×) for the same underlying readings	Open — flagging for a decision, see below. Not fixed without confirmation: reconciling this changes core architecture (mission would no longer be a pure function of the zone breakdown for these three fields specifically)
Avg Speed / Avg XT / Avg Height — zone/line-level weighting	No legacy equivalent — legacy never had a per-zone or per-line breakdown of these at all	—	New (unavoidable) — the weighting choice here (point-count then time) is a reasonable original design, not a legacy deviation, since there's nothing in legacy to deviate from
Coverage % (any level)	No legacy equivalent — legacy's "coverage" is a raw area figure (hectares), never a percentage	—	New (unavoidable)
Zone assignment (majorityZone/nearestZone)	No legacy equivalent — legacy never attributes a GPS point to a specific zone	—	New (unavoidable) — nearestZone()'s no-sanity-check fallback fixed this session after being found misattributing an entire unrelated real flight on live data, see §5 item 9
Products table Rate/Total Rate	Yes — controllers/job.js:933,940	✅ byte-for-byte same pattern (bare unit, no /ac suffix)	Match
Weather (wind/temp/humidity units)	Yes — same raw field units (windSpd m/s, temp °C)	✅ same conversions	Match
Mission Information passthrough fields (name, customer, pilot, aircraft, dates, etc.)	Yes — makeJobAppDataSource()	✅ same source fields; two intentional additions (License Number, Flight # tail-number fallback — the latter since reverted to match legacy exactly)	Match

Two items above need your explicit call before any further code change, since fixing them "properly" means non-trivial architecture work, not a quick patch:

1. Spray-pass segmentation's missing satellite-quality trim and transition table. Legacy trims low-satellite-count (satsIn<99) points from a segment's edges, and has a more detailed endSegChecker() covering specific sprayStat transition pairs. Replicating this would require adding satsIn to DETAIL_PROJECTION (controllers/advanced_report.js:47) and porting the trim logic — a real change, not a one-line fix. Is this in scope, or is the current simplified rule (llnum change / marker / ≥1km jump) acceptable given it covers the common cases?

2. Mission-level Avg Speed/XT/Height weighting. Matching legacy exactly here means tracking a separate, flat, count-weighted accumulator across the whole mission (mirroring legacy's job-level number) specifically for the mission's own tile, independent of the zone breakdown underneath it — which means the mission figure would no longer be mathematically derivable from the zone rows for these three fields, unlike every other reconciled metric in this report (area, time, distance, volume). That's a deliberate trade-off: closer to legacy, but a new kind of inconsistency within this report. Want this changed, or is the current zone-derived approach acceptable given there was never a zone-level precedent to begin with?

---

0. Foundational primitives

Three primitive functions do all the raw geometry/time work; every other figure in the report is built by combining their outputs. They are not the same function, and don't all feed the same metrics — being precise about which figure depends on which matters here.

Function	Formula	File	Verdict
geoUtil.distance(latLng1, latLng2)	turf.distance() (haversine great-circle, spherical earth ~6371km radius), after reordering [lat,lon] → [lon,lat] for turf	helpers/geo_util.js:176-181	✅ Correct — accurate for mission-scale distances, returns km
turf.area(feature) (called directly, no geoUtil wrapper)	Polygon surface area from its boundary shape — a completely separate calculation, no point-to-point distance summing involved	report_util.js:49,51-52 (plannedAreaM2())	✅ Correct
todDiff(t2, t1)	Seconds-of-day difference, corrected for the midnight rollover: if the raw difference is negative and ≥80,000s (~22.2h), recompute as (86400 − t1) + t2	report_util.js:33-37	✅ Correct — one narrow theoretical edge case at the WRAP_GUARD_S threshold (see below), not practically triggerable given ~1Hz sampling within a single continuous file

todDiff() edge case (low risk, not a live bug): the 80000-second cutoff creates a narrow "dead zone" — a same-file gap of 79999s returns a nonsensical -79999 (not treated as a wrap) while 80000s correctly flips to being treated as one. Triggering this on real data would require two consecutive points in the same file roughly 1.8–22 hours apart landing near midnight — not realistic for ~1Hz GPS sampling within one continuous flight file. If it ever did occur, the result degrades gracefully (a negative/zero duration renders as a dash per the formatters' ≤0 → DASH rule) rather than showing a wrong number. Verified every gpsTime difference in the engine routes through this function — no raw subtraction bypasses it.

What actually depends on which:

• Distance (Total/Spray/Ferry Distance) and Length (a flight line's length) — built directly by summing geoUtil.distance() over consecutive GPS points (report_util.js:151-152,225). No other function is involved.
• A flight line's Area Covered — indirect: Length × Swath Width (report_util.js:243). Needs geoUtil.distance()'s output plus a separate, unrelated input (the sprayer's configured swath).
• A zone's Planned Area — does not use geoUtil.distance() at all. It comes from turf.area(), measuring the drawn polygon's shape directly — a different calculation entirely.
• Avg Speed — not built from either function in the normal case; it comes straight from the aircraft's own GPS speed sensor reading (grSpeed, recorded per point). geoUtil.distance() only enters as a fallback when no valid sensor speed exists at all: Length ÷ Time (report_util.js:238).

---

1. Page 1 — Mission Information

Simple passthrough fields (no calculation), verified against the actual Mongoose schema (not just assumed from the field name):

Field	Source	File	Verdict
Mission Name	job.name	advanced_report.js:378	✅
Job Type	job.appType	advanced_report.js:379	✅
Crop	job.crop.name (populated ref) or raw job.crop (legacy string fallback)	advanced_report.js:380, schema model/job.js:74	✅
Date - Planned	moment(job.startDate) – moment(job.endDate)	advanced_report.js:362,381-382, schema model/job.js:66-67	✅
Date/Time - Actual	first apps[0].startDateTime → last apps[N-1].endDateTime, apps pre-sorted by startDateTime asc	advanced_report.js:366-374, query sort at advanced_report.js:146	✅ correct for sequential flights — ⚠️ see note below
Customer / Customer Address	job.client.name (ref UserTypes.CLIENT) / getFormattedAddress(job.client)	advanced_report.js:385-386, schema model/job.js:70	✅ — confirmed client and the separately-fetched applicator (via job.byPuid) are genuinely two different entities, not a naming collision
Pilot / Operator	job.operator.name (ref UserTypes.PILOT)	advanced_report.js:387, schema model/job.js:69	✅
License Number	job.operator.licence	advanced_report.js:388, schema model/pilot.js:9	✅ (spelling matches schema exactly)
Aircraft	job.vehicle.name + job.vehicle.model	advanced_report.js:389, schema model/vehicle.js:20	✅
Flight #	job.flightNumber (dash if absent)	advanced_report.js:390, schema model/job.js:73, set from imported data in workers/job_worker.js:714	✅ — reverted to match legacy exactly (controllers/job.js:1229); previously fell back to vehicle.tailNumber, which was removed since a tail number identifies the aircraft permanently, not this specific flight — see below
Applicator / Applicator Address	Customer.findOne({_id: job.byPuid})	advanced_report.js:168-171, schema comment model/job.js:161 ("Applicator userId")	✅
Remark	job.remark	advanced_report.js:411	✅

⚠️ Note (minor, low risk): "Actual Dates" assumes the app with the latest startDateTime also has the latest endDateTime (apps[apps.length-1].endDateTime). True for normal sequential single-aircraft flights; could misorder only if two flight files genuinely overlap in time.

---

2. Page 1 — KPI Tiles

Tile	Formula (source → engine → display)	Engine file:line	Display file:line	Verdict
Coverage	min(Σzone min(sprayedAreaM2, plannedAreaM2) ÷ Σzone plannedAreaM2(net of excludedAreas) × 100, 100) — each zone's contribution capped at its own plan before summing	report_util.js:45-58 (per-zone planned area), :385-392 (per-zone-capped mission roll-up)	advanced_report.js:344-352,400	✅ correct (fixed — see §5.1 and §5.6)
Avg Speed	mean grSpeed per pass (m/s, includes sprayStat==3 marker) → weighted by point-count to line → weighted by spray-time to zone → weighted by spray-time to mission → ×2.23694 (mph) / ×3.6 (km/h)	report_util.js:232,238 (pass), :267,289 (line), :316,326 (zone), :361 (mission)	advanced_report.js:319	✅ correct — matches the actual legacy avgSpraySpeed code (see §5, item 3 for the correction history)
Avg Height	mean sprayHeight per pass (m, >0 only, null if no FM sensor) → same weighted cascade → ×3.28084 (ft)	report_util.js:234,240,269,291,318,328,363	advanced_report.js:321	✅
Avg XT Error	mean |xTrack| per pass (m, ≠0, includes sprayStat==3) → same weighted cascade → ×3.28084 (ft)	report_util.js:233,239,268,290,317,327,362	advanced_report.js:321	✅ — confirmed this correctly includes the marker point, matching the legacy avgXtError gate (sprayStat===1 || sprayStat===3, workers/job_worker.js:1478); Avg Speed also includes the marker (both now confirmed to use the same inclusive rule — see §5, item 3)
Total Volume	Σ trapezoidal lminApp integration (L) across sprayed zones; if null (no flow-meter data): dash, same as zones/lines	report_util.js:227-228,241,315,350,360 (measured)	advanced_report.js:359-365	✅ fixed — mission-level estimate fallback removed, see §5 item 10
Zones Sprayed	count(zones with lineCount>0) / count(all zones)	report_util.js:340,365-366	advanced_report.js:399	✅ trivial, no arithmetic risk

---

3. Page 1 — Mission Statistics

Field	Formula	File:line	Verdict
Planned Area	areaStr(plannedM2) — manual Report-Settings override if set, else mission.plannedAreaM2 (net of exclusion zones)	advanced_report.js:346-347,400; engine report_util.js:352	✅ (fixed — see §5.1)
Sprayed Area	areaStr(sprayedM2) — manual override if set, else mission.sprayedAreaM2	advanced_report.js:348-349,401	✅
Total Flight Time / Total Duration (top box)	hm(mission.totalFlightS); totalFlightS = Σ consecutive-point deltas, each excluded entirely if ≤0 or >120s — matches legacy exactly (workers/job_worker.js:1447-1455)	report_util.js:142-158,372	✅ correct (fixed — see §5, item 9)
Total Spray Time	hm(mission.sprayTimeS) = Σ sprayed-zone sprayTimeS	report_util.js:348,354; advanced_report.js:403	✅ — reconciliation to zone sum unit-tested (test_report_util.js, NFR-3.3 case)
Ferry Time	hm(mission.ferryTimeS) = max(totalFlightS − sprayTimeS, 0)	report_util.js:373	✅ correct (inherits the fix to totalFlightS — see §5, item 9)
Total Distance	distStr(mission.totalDistanceM) = max(Σ all-point-pair distances gated at <1km jump, sprayDistanceM)	report_util.js:140-154,357	✅
Spray Distance	distStr(mission.sprayDistanceM) = Σ line lengthM	report_util.js:225,349,358	✅
Ferry Distance	distStr(mission.ferryDistanceM) = max(totalDistanceM − sprayDistanceM, 0)	report_util.js:359	✅
Avg App Rate	rateStr(volumeL, sprayedM2) = (volume in job units) ÷ (area in job units)	advanced_report.js:335-338,408	✅ fixed — now correctly dashes with no flow data, consistent with zones/lines — see §5 item 10
Avg Flow Rate	flowStr(mission.avgFlowLmin) = mission.volumeL ÷ (sprayTimeS/60), measured only, no estimate fallback	report_util.js:369; advanced_report.js:409	✅ correctly stays dash when unmeasured (consistent, unlike Avg App Rate)
Swath Width	job.swathWidth (job config value, not the analytics-derived per-line swath used in area math)	advanced_report.js:410	✅ — intentional: shows the job setting, distinct from pass.swathM used in area calc (report_util.js:242)

---

4. Page 1 — Products Table

Field	Formula	File:line	Verdict
Product Name / Restricted / EPA Reg# / Type	passthrough of populated job.products[].product fields	advanced_report.js:505-508, populate at :102	✅
Rate	${rate} ${getProdUnit(unit)} — bare unit string ("gal", "lb", "lit"...), no per-area suffix	advanced_report.js:509, utils.getProdUnit() at helpers/utils.js:717-747	✅ matches legacy exactly (controllers/job.js:933,940) — API doc example was wrong, now fixed, see §5 item 8
Total Volume Used	rate × (sprayedArea in job units), with oz→gal conversion when unit===OZ	advanced_report.js:511-513, utils.ozToGal() at helpers/utils.js:411-413	✅ math correct — inherits sprayedM2 override behavior; this is a config rate × area, always known and always labeled correctly, unlike the mission/zone rate fields (see §5 item 17)

Verified: job.products[].rate/unit schema (model/job.js:51-57) matches field access exactly; APTypes.CARRIER (helpers/constants.js:36-40) and Units/getProdUnit mapping (helpers/constants.js:5, helpers/utils.js:717-747) are correctly aligned — 0=oz, 1=gal, 2=lb, 3=lit, 4=kg, matching both enums.

---

5. Page 1 — Weather Box

Field	Formula	File:line	Verdict
Wind Speed	Manual: wi.windSpd (already knots, per schema) shown as-is. Aggregated: mpSecToKnot(avgWindSpd) = ×1.94384 (application_detail.windSpd is m/s)	advanced_report.js:536,547; schema model/job.js weatherInfo (knots), model/application_detail.js:37 (m/s); utils.mpSecToKnot at helpers/utils.js:371-374	✅ both paths verified against actual field units in the schema, not assumed
Wind Direction	Manual: raw compass string. Aggregated: round(avgWindDir)° + deg2Compass(avgWindDir) (16-point compass)	advanced_report.js:537,548; utils.deg2Compass at helpers/utils.js:219-231; source field model/application_detail.js:38 (degrees)	✅ correct, though the two paths render differently in style (plain string vs "270° WNW") — cosmetic only
Temperature	Manual: (wi.temp−32)×5/9 if US (assumes °F stored), else as-is. Aggregated: avgTemp direct (already °C per schema)	advanced_report.js:534,538,549; model/application_detail.js:39 (Celsius)	✅
Humidity	direct passthrough, rounded to 0 decimals	advanced_report.js:539,550; model/application_detail.js:40	✅
Aggregation query	AppDetail.aggregate() — $avg over windSpd>0, windDir∈[0,360], temp∈[5,60], humid∈[9,90]	helpers/job_util.js:325-338 (getDataWeatherInfo)	✅ sane outlier gates

---

6. Page 2 — Mission Coverage Grid (coverageCards)

Always populated for every zone regardless of Report Contents filtering (§6 of the API contract), even if the client suppresses the page for single-zone jobs.

Field	Formula	File:line	Verdict
Sprayed / Planned	${sprayedArea} / ${plannedArea} (dash on sprayed side if lineCount==0)	advanced_report.js:433-435	✅ — reuses already-verified zone sprayedAreaM2/plannedAreaM2
Coverage %	zs.coveragePct (dash if unsprayed) — uncapped, can show >100% on real overspray	advanced_report.js:436; engine report_util.js:349	✅ (fixed — see §5, item 6 companion fix)

---

7. Page 2/3 — Zone Detail

All zone-level fields reuse the same accumulator logic already verified for the mission-level KPIs (§2–3), rolled up to per-zone instead of per-mission. Zone-specific formulas:

Field	Formula	File:line	Verdict
Planned/Sprayed Area, Coverage %, Avg Speed/Height/XT Error/Flow Rate	same formulas as mission-level, applied per zone (Coverage % uncapped — see §5, item 6)	advanced_report.js:453-464	✅
Volume Applied / Avg App Rate	zs.volumeL — measured only	advanced_report.js:456-457	✅ — mission-level tile now matches this behavior too, see §5 item 10
Product	comma-joined names of the job's active-ingredient products (job.products, filtered to exclude APTypes.CARRIER) — mission-wide, identical value on every zone, same convention as crop: mission.crop	advanced_report.js:576-592	✅ correct by construction — not a per-zone calculation, deliberately mission-wide
Start Time / End Time (zone-level)	todStr(zs.startTimeS) / todStr(zs.endTimeS) — the zone's own first/last spray-on timestamp, engine-side _firstT/_lastT now also exposed as startTimeS/endTimeS instead of being discarded after deriving flightTimeS	advanced_report.js:598-599; engine report_util.js:524-525 (set right after flightTimeS at line 521, before the _firstT/_lastT cleanup at line 533)	✅ same source timestamps flightTimeS already derives from, no new engine logic
Flight Time	hm(zs.flightTimeS) = todDiff(last spray-end+turn, first spray-start) within that zone only — a different definition than mission totalFlightS (not gap-tolerant the same way, and doesn't include ferry to/from the zone)	advanced_report.js:458; engine report_util.js:308-309,318,331	✅ well-defined as its own metric — just not directly summable to the mission Total Flight Time field (different scope by design)
Avg Turn Time	secStr(zs.avgTurnTimeS) = unweighted mean of each line's own (already-averaged) turn time	advanced_report.js:460; engine report_util.js:285,297,306,316,329	✅ underlying turnTimeS values fixed (§5.4) — ⚠️ minor residual note: still an unweighted double-average across lines; could skew if a zone's lines have very uneven turn counts (not fixed, low-impact)
Map image	zone capture .jpg, falls back to mission map.jpg placeholder on capture failure	advanced_report.js:465	✅ (capture pipeline, not a calculation)

---

8. Page 3 — Flight Line Statistics Table

Column	Formula	File:line	Verdict
Start Time	secondsToHMS(startTimeS % 86400, format=1) → HH:MM:SS	advanced_report.js:340,479; helpers/utils.js:804-816	✅
Spray Time	secStr(sprayTimeS)	advanced_report.js:480	✅
Length	lenStr(lengthM) = ×3.28084 ft	advanced_report.js:481	✅
Avg Speed	same formula as §2	advanced_report.js:482	✅
Area Covered	toArea(areaM2, isUS) (ac/ha), 2 decimals	advanced_report.js:483	✅
Rate	rateStr(l.volumeL, l.areaM2) — measured only, dash when no flow data (the common case, matches the screenshot)	advanced_report.js:484	✅ — mission-level tile now consistent with this, see §5 item 10
Avg XT Error	same formula as §2	advanced_report.js:485	✅
Turn Time	secStr(l.turnTimeS) — mean of measured 5–120s off→on gaps before this line, null if none measured	advanced_report.js:486; engine report_util.js:168-184,285,297	✅ (fixed — see §5.4)
Unsprayed-zone placeholder row	single all-dash row per zone with lineCount===0	advanced_report.js:488-495	✅ matches FR-4.6

---

5. Findings Summary

Fixed this pass

1. §2, §3 — Planned Area ignored exclusion zones. plannedAreaM2() now nets out intersecting job.excludedAreas (mirrors jobUtil.calcTTSprayAreas), matching Job.ttSprArea. Fixed in helpers/report_util.js:45-58,97,103,301, wired in controllers/advanced_report.js:141. Tests added in tests/test_report_util.js.

2. Duration formatting rounding bug. hm() displayed "60m"/"1h 60m" instead of carrying into the hour. Fixed in controllers/advanced_report.js:327-334.

3. Avg Speed marker-exclusion — fixed, then found to be wrong, then reverted. Originally excluded sprayStat==3 from the speed average, citing AGGREGATED_FIELDS_CALCULATION.md's claim that legacy avgSpraySpeed excludes the marker. That claim turned out to be false — reading the actual legacy code (workers/job_worker.js:1459-1483) shows the sprayStat!==3 exclusion there applies to the spray-time accumulator, not speed; the speed accumulator (totalSpeedAcc) fires for every sprayStat>0 record, marker included, with no exclusion at all. The doc's prose conflated the two rules. Reverted the exclusion in helpers/report_util.js:236 back to including the marker (matching the real legacy code), inverted the test in tests/test_report_util.js to assert inclusion instead of exclusion, and corrected both this doc and ADVANCED_REPORTS_IMPLEMENTATION_PLAN.md §3 to stop citing that doc as authoritative on this point. Net effect: current code now matches legacy exactly. Lesson: verify claims against the referenced code directly, not against a doc's prose description of that code.

4. Turn Time leaked across zones when a line number was reused in a different zone (e.g. Zone A's line 1 and Zone B's line 1 both flown, but only Zone A's line 1→2 transition had a measured turn). turnGaps were keyed only by bare llnum, and zone assignment happens after the turn-time state machine runs (it only knows zone membership once finish() does point-in-polygon assignment on the completed passes) — so both line rows pulled from the same bucket and Zone B's line incorrectly showed a 20s turn that was actually Zone A's. Reproduced and confirmed empirically before fixing. Fixed by tagging each recorded gap with the passes index of the pass it follows (helpers/report_util.js:126-131,176), then resolving that pass's assigned zone once zone assignment is done and keying the lookup by zoneIdx:llnum (helpers/report_util.js:277-285) — matching how line rows themselves are already keyed. Two regression tests added (tests/test_report_util.js) using the existing "typical multi-zone mission" fixture, which already contained this exact scenario but never asserted on it.

5. Flight Line table order broke across a midnight wrap. The final .sort((a,b) => a.startTimeS - b.startTimeS) on the lines array used plain numeric subtraction — every other time comparison in this file deliberately uses the wrap-safe todDiff() instead. Reproduced directly: a line flown right before midnight (startTimeS: 86390) and one flown right after (startTimeS: 10, chronologically later) came out in reverse order (llnum 2 before llnum 1). Fixed by removing the sort entirely (helpers/report_util.js:287-303) — lineMap's Map insertion order already reflects true chronological order (a pass for a given zone+llnum is always first encountered at its true start time, since passes is built strictly in stream order and a pass can't start until the previous one ends), so no timestamp math was needed at all. Regression test added (tests/test_report_util.js).

6. Coverage % could show 100% while zones were still completely untouched. The mission-level ratio summed each sprayed zone's raw, uncapped area before dividing by total planned area — so an overlapped/oversprayed zone (overlap is never deduplicated, see §2) could numerically exceed its own planned size and mask an entirely different zone that was never sprayed at all. Reported directly against real data (Job #96: "Coverage: 100%" alongside "Zones Sprayed: 22/27" — 5 zones never touched, yet the raw sprayed-area sum exceeded the full 27-zone planned total once overlap was counted). Reproduced with a minimal case: one zone oversprayed at 14,357% of its own plan, one zone completely untouched — old formula: 100%; correct answer: 50% (one zone fully done, one zone at zero). Fixed by capping each zone's contribution at min(zone.sprayedAreaM2, zone.plannedAreaM2) before summing, both in the analytics engine (helpers/report_util.js:385-392) and in the datasource builder's independent recomputation, which now reuses the engine's corrected value when no manual Report-Settings override is active (controllers/advanced_report.js:344-352,400). mission.sprayedAreaM2 itself (the true, uncapped swept-area total shown as "Sprayed Area") is unchanged — only the coverage percentage is capped per zone (at the mission level only — see below). Regression test added (tests/test_report_util.js).

   Companion fix, same root question: a zone's own coveragePct (shown on its Zone Detail page and its Mission Coverage Grid card) was also capped at 100% (report_util.js:349, now removed). Real overspray of a single zone — swath overlap, turns, re-flown sections, all normal in actual spraying — is legitimate, useful information (e.g. how much extra product went down), and capping it at "100%" threw that away, showing an oversprayed zone identically to an exactly-matched one. Confirmed against real data (Job #96's Mission Coverage Grid: zones showing 367/366.3 ac ≈ 100.2% and 433.1/412.3 ac ≈ 105.0%, both displayed as a flat "100%"). Removed the cap (helpers/report_util.js:349) so the zone's own card/detail page now shows the true percentage, which can exceed 100%. This does not affect the mission-level fix above — the mission calculation caps each zone's contribution to the sum independently, using the raw area values directly, not this field. pctStr() (controllers/advanced_report.js:325) has no capping of its own, so it renders whatever value it's given correctly. Regression test added.

   Second companion fix — the manual Report-Settings override path had the same bug via a different mechanism. Job #96's report kept showing "Coverage: 100%" even after the fix above, because Job.rptOp.printArea/areaSize/coverage had a manual override active (confirmed directly via MongoDB: rptOp.areaSize and rptOp.coverage convert to exactly the report's displayed 37,335.7 ac / 42,341.8 ac). The datasource builder's override-fallback branch — used precisely because an override has no per-zone breakdown to cap against — still did Math.min(ratio, 100), so it reproduced the identical bug through a path the zone-capping fix doesn't touch at all. And the same contradiction persisted: "Zones Sprayed: 22/27" is always computed from real per-zone data regardless of any override, so it kept correctly showing 5 untouched zones right next to a now-doubly-explained "100%". Verified 42,341.8/37,335.7 = 113.41% — the override itself claims more was sprayed than planned; capping that hides real information the same way the original bug did. Removed the cap on this fallback branch too (controllers/advanced_report.js:353-355) — it now shows the true, possibly >100%, ratio. No test file exists for advanced_report.js (only report_util.js has unit test coverage); verified manually against Job #96's exact rptOp values, confirmed the formula now returns 113.41% instead of 100%.

7. Total Flight Time / Duration / Ferry Time used a wall-clock definition instead of legacy's 120-second-gap-capped sum. Re-verified directly (not just re-stated from before): the existing test_report_util.js "multiple files" test only proved inter-file gaps are excluded (a gap between two uploaded files) — it said nothing about a gap within one file. Tested that separately: one file, a spray segment, a 600-second internal gap (GPS dropout / idle) with no fileBreak() in between, then more spraying — mission.totalFlightS came back as 609 (the full last-minus-first span, gap included), where legacy's convention (sum of per-record deltas each capped at ≤120s, workers/job_worker.js:1447-1455) would have dropped that single 600s delta entirely, landing near 8s instead. Per explicit instruction to follow legacy's existing logic rather than invent new behavior: fixed — totalFlightS is now accumulated the same way, summing consecutive-point deltas and excluding any single gap that's ≤0 or >120s (helpers/report_util.js:142-158). This also let fileFirstT/fileLastT/closeFileTime() be removed entirely — the per-point accumulation naturally resets at fileBreak() since prev is already nulled there, so no separate file-boundary bookkeeping was needed. Verified: the 600s-gap case now returns 8 instead of 609. Regression test added (tests/test_report_util.js); the existing "multiple files" test still passes with the same expected value (both mechanisms agree when there's no internal gap), its description updated to stop citing the now-removed mechanism.

8. Products table "Rate" column is missing its per-area unit suffix. Resolved — not a bug. Checked legacy's own product-rate formatting directly (controllers/job.js:933,940, makeJobAppDataSource's product loop): rateStr: utils.toLocaleStr(rate,2,lang) + ' ' + utils.getProdUnit(unit) — byte-for-byte the same bare-unit pattern ("0.50 gal", no /ac) as advanced_report.js:509. The advanced report's Products table faithfully mirrors an established legacy convention; it was the API contract doc's example that was wrong (docs/ ADVANCED_REPORTS_API.md, showed "rateStr": "0.50 gal/ac"). Fixed the doc example to "0.50 gal" to match both the real legacy behavior and the actual implementation. No code change needed.

9. nearestZone() could attribute an entire, unrelated real flight to whatever zone happened to be "least wrong" — no matter how implausibly far away it actually was. Found on real production data: Job #95's "Spray_09" zone showed a full, convincing Zone Detail page — 55 flight lines, "Sprayed Area: 643.7 ac," "Coverage: 6.6%" — for ground that was never actually flown over. Traced the underlying GPS points: they're at 44.35°N, 44.36°N (southern Ontario) while Spray_09's actual polygon sits at 31.56–31.61°N (coastal Georgia) — over 1,400 km away. Confirmed via the job's own file metadata that this data (test-June23-01.zip, evidently a generic test recording) genuinely belongs to Job #95 — it's not a cross-job data mix-up — it simply has no real geographic relationship to any of the job's 9 zones. majorityZone() correctly found zero matches (as it should), which triggered the nearestZone() fallback — but that fallback had no distance sanity check at all, so it forced an assignment regardless of plausibility. This subsumes the old low-confidence longitude-compression note (previously item 11 in this section): fixed by rewriting nearestZone() to measure real great-circle distance (geoUtil.distance()) instead of raw lat/lon-degree math, and by adding NEAREST_ZONE_MAX_KM = 50 — a line whose closest zone is still farther than that is now genuinely unassignable (zoneIdx = -1), rather than forced onto the "least far" zone (helpers/report_util.js). Unassigned lines are excluded from every zone and zone-derived mission total (area, spray time, distance) the same way a truly-outside-every-zone line already was, and are now summarized separately in a new mission.unassigned field (lineCount, sprayTimeS, lengthM, areaM2) so this activity is visible in the datasource rather than silently vanishing or being mislabeled — surfacing it in the actual report template is a follow-up (not touched here, out of reach without the Stimulsoft designer). Verified end-to-end against Job #95's real zones and all 58,200 of its real GPS points, not just a synthetic case: Spray_09's lineCount went from 55 to 0, its sprayedAreaM2 from 643.7 ac to 0, and mission.unassigned now correctly reports the 55 lines, ~30.7 minutes of spray time (matching the original report's "Spray Time: 31m" almost exactly) that used to be fabricated into Spray_09's page. Three regression tests added (tests/test_report_util.js), including one reproducing this exact real-world scenario.

10. Total Volume / Avg App Rate estimate broke mission ≡ Σ(zones) and turned out not to be measurement-free. When there's no flow-meter data, the mission-level tile silently substituted job.appRate × sprayedArea (a legacy-derived estimate, controllers/job.js:850-858, "Total used volume, estimated"), while the zone/line breakdown underneath stayed dashed (measured-only) — visible directly on Job #104/#96 screenshots and reproduced cleanly on real Job #97 data (single zone, all 292.6 ac of it sprayed, no flow-controller data): the mission tile would show "Total Volume: 2,926 gal, Avg App Rate: 10.00 gal/ac" while that job's only zone — which covers the exact same 292.6 ac — showed "Volume Applied: –, Avg App Rate: –" on its own Zone Detail page. Examined what the estimate actually represents: job.appRate is a single static value configured before the flight ever happened — a target, not anything measured during or after it — so the formula assumes uniform delivery at that exact rate everywhere the aircraft flew, with no allowance for rate changes, drift, or real variation. Legacy's own one-page Application Report has shown this same assumption-based number for years, but legacy has no zone/line breakdown to contradict — the Advanced Report's zone hierarchy is what turns "a labeled estimate" into "a number that visibly disagrees with the zone that contains it." Decided (explicit product direction): since the estimate isn't measurement-free, drop it from the mission level rather than push it down to zones/lines — mission-level Total Volume/Avg App Rate now dash under the same no-flow-data condition zones/lines already do, restoring mission ≡ Σ(zones). The manual actual-volume override (rptOp.useActualVol/rptOp.actualVol) is unaffected — that's a user-entered figure, not an assumption-based guess. Fixed by removing the job.appRate × sprayedArea fallback block entirely (controllers/advanced_report.js:359-365); no test file exists for advanced_report.js (only report_util.js has unit coverage — see D1/D2 split in the implementation plan), verified manually against Job #97's real mission.volumeL === null engine output and the resulting dashed tile. The deeper question of whether "Avg App Rate" should mean a measured rate or a planned/configured rate remains — legacy's own Application.appRate field is itself defined as mean(lhaReq) (the requested rate recorded per GPS point, workers/job_worker.js:1643-1687), a third definition this engine doesn't currently read at all (lhaReq isn't in DETAIL_PROJECTION, controllers/advanced_report.js:47) — noted for a future pass, not blocking this fix.

11. majorityZone()'s "whole line to one zone" rule let a small zone lose most of its coverage credit to a much larger neighbor sharing a boundary. Found on real production data: Job #106's Zone 4 (18 ac planned) showed 12.4% coverage — its map thumbnail was almost entirely empty except one thin sliver — while Zone 3 (45.6 ac) showed only 68.8% with just half its polygon painted, and the adjacent, much larger Zone 2 (412.3 ac) showed 107.7%, over its own plan. Traced the cause: a pass whose GPS points straddle the boundary between two zones was being handed to whichever zone held the sampled majority of its points — for a pass mostly inside Zone 2 but genuinely also covering part of Zone 3/4, Zone 2 took 100% of the credit, Zone 3/4 got none of theirs. Confirmed via the underlying line numbers: 74/83–91 (the boundary-crossing passes) appeared in Zone 2's, Zone 3's, and Zone 4's Flight Line tables simultaneously — proof the same physical passes were being fragmented and miscredited across zone boundaries, not a rendering artifact. Fixed by adding a cheap sampled pre-check (straddlesMultipleZones, reuses majorityZone's existing sample — no added cost for the overwhelming majority of lines that stay inside one zone) that only escalates to a full, unsampled per-point zone lookup (splitPassByZone) for lines that actually touch more than one real zone; each resulting per-zone segment gets its own stats via computeSegmentStats (extracted, byte-identical to the old per-pass loop — DRY, zero behavior change for the non-split path). Turn-gap attribution (passLastZone) and the map-drawing draw.spray segments were updated to key off the new per-segment zone tags instead of the old per-pass one. Documented, deliberate trade-off: the single GPS interval that actually crosses the boundary isn't counted in either segment's length/area/volume — a per-crossing discrepancy of one GPS interval (a few meters), traded for not needing to split that edge's distance between two zones. Verified end-to-end against Job #106's real zones and all 40,156 of its real GPS points: Zone 4 went from 12.4% to 96.9% coverage, Zone 3 from 68.8% to 112%, Zone 2 correctly came back down from 107.7% to 98.1%, while Zone 1 — which doesn't border any other zone in this job — stayed byte-for-byte identical (99.8% both before and after), confirming the fix is scoped to boundary-sharing zones only. Two regression tests added (tests/test_report_util.js): one confirming the pre-existing majority-zone case (a line leaving a zone into empty space) is untouched, one reproducing the genuine cross-zone-boundary split and checking mission totals still reconcile exactly with the split zone roll-ups (NFR-3.3).

Confirmed bug — fix deferred

17. Ounce-configured jobs (job.appRateUnit === RateUnits.OZ_PER_ACRE) get mislabeled rate fields for measured data. None of the mission/zone/line volume or rate formatters have an oz-aware conversion path, unlike the Products table (which already does this correctly — see §4 above). rateStr() (advanced_report.js:335-338) always labels the number with the raw rateUnitString(job.appRateUnit, ...) ("oz/ac"), but the number itself always comes from toVolume(volL, isLiquid, isUS), which for isLiquid===true unconditionally means gallons, never ounces. So for measured flow data on an oz-configured job, "Avg App Rate"/"Rate" shows a real gal/ac figure under an "oz/ac" label — the number is correct, the unit suffix isn't. volStr has the same gap (hardcodes a "gal" label, no oz path). Legacy already solves this — controllers/job.js:853-858 converts with utils.ozToGal() and swaps the displayed rate-unit to GAL_PER_ACRE so label and number never disagree (the same pattern already applied correctly in the Products table's unit === Units.OZ branch, advanced_report.js:520) — but the Advanced Report has no equivalent of either step in the mission/zone/line paths.

Originally found alongside a second sub-bug: the mission-level estimate (job.appRate × area) fed an oz-denominated number into the same gallon-only conversion, producing a volume 128× too large (reproduced on Job 13603: 1,716.85 oz true volume computed and displayed as 1,717 gal). That sub-bug is now moot — item 10's fix removed the estimate-fallback block entirely (controllers/advanced_report.js:359-365 no longer computes an estimate at all), so there's nothing left to mislabel on that path. The mislabeling above, for genuinely measured flow data on an oz-configured job, is unaffected by that fix and remains open.

• Fix, not yet applied. Recommended approach mirrors legacy exactly: thread a "display rate unit" (raw job.appRateUnit, or GAL_PER_ACRE when it was oz) through rateStr/volStr instead of always assuming gallons for any isLiquid unit.

Open — deferred pending a product decision

18. Legacy's "Actual Spray Volume" fills in a guessed rate whenever the flow sensor reads zero; the Advanced Report's volumeL never does. Both engines agree exactly on every segment where the flow sensor (lminApp) actually reported something — confirmed on real Job 105 data (JBI - AutoCal, 21,824 real points, 3 files): a faithful reconstruction of legacy's own per-record formula (getAppliedRate(), workers/job_worker.js:1640-1662 + helpers/utils.js:1795-1820), using the real stored utmX/utmY (not an approximation), lands at 120.16 gal from flow-derived segments alone — matching the engine's real mission.volumeL (117.43 gal) to within rounding. The two methods are mathematically equivalent when both are looking at real sensor data; this is not a calculation-method difference.

• The gap to the DB's actual stored App.totalSprayMat (154.07 gal — the "Mat Sprayed"/"Actual Spray Volume" figure) is fully explained, and reproduces to the decimal: getAppliedRate() (helpers/utils.js:154-176,1798) reads a per-file configured rate from the imported file's own Q-file metadata (fileMeta.appRate — 0.16 gal/ac for this file, an equipment setting, not job.appRate) and substitutes it whenever record.lminApp is falsy for that GPS record, instead of treating a zero reading as zero volume. For Job 105, 4,078 of the ~18,634 contributing spray segments (≈22%) had lminApp === 0 — legacy added 33.91 gal for those moments using the substitute rate; the Advanced Report added 0. 120.16 + 33.91 = 154.07 — an exact match to the stored value, confirming this is the complete and only mechanism, not one contributing factor among several.
• The real, unresolved question is which behavior is more correct, and it can't be settled from the data alone: if a lminApp === 0 reading reflects a genuine sensor dropout/glitch while the nozzle kept running, legacy's fill-in is the more accurate total. If it reflects the nozzle genuinely being off at that instant (boom-section cycling, swath-overlap avoidance switching sections off, a tank running dry), the Advanced Report's "trust the zero" is more accurate and legacy has been quietly overstating volume by padding every such moment. Given how large and systematic the share is on this file (≈1 in 5 segments, not an occasional blip), a genuine zero-flow condition looks more likely than sensor noise, but this is a judgment call about equipment behavior, not something resolvable by re-reading either codebase.
• Not fixed. Needs a decision: leave the Advanced Report trusting real zero readings (current behavior, arguably the more defensible default absent evidence the sensor is unreliable), or add an equivalent "assume nominal rate on a zero reading" fallback to match legacy's number exactly.

Pre-existing platform bug — found here, but out of scope to fix in this report

11. Overlapping exclusion zones double-subtract their shared overlap in plannedAreaM2(), and can drive the planned area negative. Reproduced directly: a zone with two exclusions covering 60% and 60% (overlapping each other, together covering 90%) should net 10% remaining — instead returns a negative area, because each exclusion's overlap is subtracted independently instead of first unioning the exclusions together. Confirmed this is not new — jobUtil.calcTTSprayAreas() (helpers/job_util.js:117-149) has the byte-identical flaw and produces the exact same negative number on the same input, since plannedAreaM2() was deliberately written to mirror it. This affects the live Job.ttSprArea field today, not just this report — fixing it only here would create a new mismatch rather than remove one. Flagging as a separate platform issue, not fixing in report_util.js. Only triggers when a user draws two exclusion zones that overlap each other inside the same spray zone.

Low-confidence / low-impact notes (not fixed)

11. majorityZone() gives all point-in-polygon credit to the first matching zone only (break on match) — confirmed directly: two overlapping zones with 10 test points inside both produced counts: [10, 0], denying the second zone any credit for points genuinely inside it too. Matters only if spray zones (not just exclusion zones, which are already known to sometimes overlap) are ever drawn overlapping each other (report_util.js:63-77).
12. Zone-level avgTurnTimeS is an unweighted mean of each line's own (already-averaged) turn time — a double average, separate from the cross-zone leak fixed in item 4 above (report_util.js:329).
13. Manual Report Settings overrides (rptOp.areaSize/coverage) affect the mission summary (advanced_report.js:346-349) but not coverageCards/zonesDS, which always show computed values — pre-existing legacy-pattern behavior, not something newly introduced.
14. "Actual Dates" assumes the last app sorted by startDateTime also has the latest endDateTime (advanced_report.js:366-374) — true for normal sequential flights only.
15. A self-intersecting ("bowtie") zone polygon silently computes a near-zero area (shoelace-formula signed-area cancellation) rather than erroring — an inherent limitation of this class of area algorithm for any invalid, non-simple polygon, not specific to this code. Only matters if the zone-drawing tool ever allows saving such a shape.
16. Turn-time state machine has no branch for an off-period whose llnum doesn't match the line just being tracked (only reachable with anomalous data that doesn't carry over the previous line's number during ferry/off travel — not the convention this codebase's own test fixtures assume). Reproduced directly: a genuine 8s turn got silently dropped (turnTimeS: null) when the off-period in between carried an unexpected llnum. Fails safe — degrades to "unmeasured," never to a wrong value — consistent with every other edge case found in this engine (report_util.js:171-181).

---

Test coverage

tests/test_report_util.js — 40 passing cases covering: midnight-wrap time math, planned-area exclusion-zone netting (new), multi-zone/multi-file reconciliation (NFR-3.3), no-flow-controller degradation, SatLoc-style missing-sensor degradation, unsprayed-zone dash handling, boundary-straddling majority-zone assignment (a line leaving a zone into empty space, stays whole), genuine cross-zone- boundary splitting (new — a line actually crossing into a different zone becomes one segment per zone, reproduces the exact Job #106 real-world case, item 11), a degenerate zero-length/zero-time line dropped from the report instead of showing a "0 ft / 0 ac" row (new), nearest-zone fallback, the line-start-marker speed inclusion (matching the real legacy code — see §5, item 3), the cross-zone turn-time leak on a reused line number (new), line ordering across a midnight wrap (new), mission Coverage % never reaching 100% while a zone remains untouched (new), a zone's own Coverage % correctly showing >100% on real overspray instead of capping (new), totalFlightS excluding an internal >120s gap the same way legacy does (new), volume integration excluding the same gap (new), and a line implausibly far from every zone landing in mission.unassigned instead of being force-assigned (new — reproduces the exact Job #95 real-world case).

Run: npx mocha --exit --require tests/setup.js tests/test_report_util.js