Anatomy of a
project built
with Agents

I began with a concrete architecture to test: separate the small navigation inputs from the large laser returns, solve the trajectory on Windows, then build the point cloud locally. The first afternoon turned that boundary into a usable proof of concept.

1. 10:08–10:27 AM

   Prove extraction before building the interface.

   The RESEPI parser reproduced the supplier’s IMU, GNSS and laser streams byte for byte. The validated path became a streaming Rust core with native and WASM front ends, handling records split across chunks and numbered files. This established the data boundary without loading an entire capture into memory.

2. 11:25–11:32 AM

   Make the licensed Windows step run unattended.

   A reference run matched the earlier trajectory to about a millimetre at maximum. The next obstacle was operational: the native application needed the licensed Windows session. A scheduled-task bridge completed a real solve without repeated desktop clicks, although the Windows user still had to be logged in.

3. 12:01 PM

   Close the first real browser loop.

   The browser read 704 MB of raw files and sent a 20.7 MB navigation package. Windows returned the trajectory and the browser displayed georeferenced points. The raw laser data stayed on the user’s computer. Successful data flow was the achievement; numerical point-cloud agreement was still to be established.

4. By 12:51 PM

   Let the picture challenge the result.

   Visual checks exposed a ground-plane convention error and sparse sampling that made the cloud look like wires. Fixing those improved scale and appearance, but the header-derived reconstruction still had roughly 49 cm median error in that comparison. A plausible picture was not enough to end the investigation.

5. 1:32–2 PM

   Turn the prototype into a simple sequence.

   The interface became four steps: raw files, base data, processing, then the viewer and download. Dense LAS export streamed accepted returns instead of keeping the full cloud in memory. Repeated feedback refined the stepper, spacing and controls while preserving local data handling.

6. 3:15 PM

   Release the first proof of concept.

   The frontend was published with a stable backend route and a tunnel fallback. The page, JavaScript, WASM and authenticated backend path were checked. This made the workflow available to try and exposed the next round of real-data and usability questions.

By this checkpoint. A working local-data workflow reached its first release. Extraction and trajectory handling had concrete evidence behind them; reconstruction accuracy and larger-data behavior drove the work that followed.

The 24 hours after the proof of concept were spent improving the workflow, reconstructing the maths and testing real data. I kept moving between using the app and challenging the evidence behind it.

1. 27 Aug · 3:43–4:37 PM

   Review before processing; upload without disrupting users.

   Selecting base-station files now filled the coordinate fields and waited for a visible Process button. Larger uploads gained isolated, retry-safe chunks. I required the rollout to wait for running jobs to finish, with the compatible backend deployed first.

2. 27 Aug evening → 28 Aug · 3:30 AM

   Keep working until the maths survives new data.

   Parallel investigations traced firing times, range decoding, calibration, orientation and LAS export. I challenged fitted corrections that depended on a reference cloud. Rules recovered from raw data replaced them, but an inverted live dataset exposed another gap. The night ended with a source audit and explicit follow-up work.

3. 28 Aug · 10:40 AM–1:22 PM

   Reduce the work before making the machines faster.

   A slow second Windows machine led to SSD scratch storage, cleanup of completed intermediates and browser-side trimming of base observations before upload. Short- and long-flight comparisons checked the resulting trajectories. Measured runtime gains varied: about 22% on one short case and 5% on the long case.

4. 28 Aug · 1:26–2:09 PM

   Compare the entire processing path.

   I asked for two coloured clouds in one viewer, then numerical comparisons, then separately generated trajectories. One real flight reached 1.23 mm median and 1.94 mm p99 separation across 41.65 million matched points, without fitting an alignment to the clouds.

5. 28 Aug · 2:12–3:44 PM

   Expand the dataset sweep and record the failures.

   The broader audit exposed orientation, base-coordinate and historical-processing differences. I asked Codex to log observations and finish the comparison set before fixing them. The sweep was still running at this milestone.

6. 28 Aug · 3:35–3:44 PM

   Benchmark what the user actually sends.

   When the concurrency test reused an obsolete, untrimmed base file, I asked for a repeat using the current frontend payload. The isolated native solves then reproduced the single-run trajectory and SBET byte-for-byte.

At this milestone. Six copies of one trimmed flight finished in 168.3 seconds versus 71.35 seconds for one: about 2.54× aggregate throughput on the second PC. The POC had gained a better workflow and stronger numerical evidence; dataset QA and production concurrency deployment still remained.

The next work appears on Friday afternoon and evening, then Monday. We refined the user experience, expanded the accuracy checks and connected two processing machines while keeping raw laser returns and point-cloud generation on the user’s computer.

1. 28 Aug · afternoon

   Find a useful performance limit and preserve visible detail.

   Further solver tests suggested five workers per machine; more workers added little throughput and increased latency. In parallel, I pushed for a preview that kept trees and wires. Repeated zoom checks led from redistributing points to a stable overview with additional nearby detail, within a bounded candidate pool.

2. 28 Aug evening → 31 Aug · 2:46 PM

   Make base and antenna inputs change the actual result.

   A long attempt to inject antenna settings into the native processor went nowhere, and I stopped it. On Monday we tested a simpler coordinate-based approach, corrected height along the local vertical, and removed large base-position errors. The form gained real antenna-database lookup and explicit corrections for unknown models.

3. 31 Aug · morning–4:05 PM

   Make inspection and export agree.

   We refined colours and viewing controls, removed technical clutter and made detail refinement the default. A thin flight-time tape linked trimming to the trajectory and full LAS export. An optional roll filter used the same rules. I tested the interaction and asked for a smaller, clearer toolbar.

4. 28 & 31 Aug · afternoons

   Expand reference coverage and fix the comparison tools.

   The corpus grew from 11 to 21 sessions. Better attitude interpolation, firing/return decoding, packet timing and azimuth checks improved agreement. A provisional 21/21 replay used preserved Windows trajectories and sampled geometry; its orientation rule was then released.

5. 31 Aug · 7:03–7:44 PM

   Put the measured concurrency into service.

   Five worker slots on each Windows machine gained queue-aware routing and job affinity. Deployment required restart recovery and authentication fixes. Twelve deliberately incomplete jobs exercised routing and expected failure handling across both machines; successful full-flight processing under that load remained a separate test.

6. 31 Aug · 8:42–10:02 PM

   Follow the exact live failure through to a fix.

   A flight I processed still looked badly sprayed. I kept challenging explanations based on earlier clean artifacts. Inspecting the fresh jobs exposed a processor orientation value being applied again to the laser rays. We removed that extra correction, reconnected the evidence disk and reran every retained reference before release.

At this milestone. The 10:02 PM release fixed the demonstrated current-flight problem and passed 18 of 21 reference replays. I chose to ship that result while leaving three older orientation cases explicit for separate investigation. The viewer, trimming, antenna workflow and two-machine routing had also advanced during this interval.

The next day broadened who could use the app and which base files it could accept. Much of the work was connecting a convenient interface to the exact backend and export behavior it promised.

1. Early afternoon

   Reject a wrong base file while it is still easy to fix.

   A flight/base-date mismatch moved from a failed native solve to an early check on the base-selection screen. Review caught an important exception: valid UTC/GLONASS files could appear about eighteen seconds short. Only clear mismatches were blocked; uncertain coverage kept the compatibility fallback. The correction was released at 2:10 PM.

2. In parallel

   Decline a slow processing machine.

   Another Windows machine had been installed and a real solve was advancing, but its observed speed was disappointing. I stopped it from becoming an additional production backend. Setting a machine up did not make it a useful capacity increase.

3. 3:45–4:55 PM

   Give agents useful controls and inspect the delivered file.

   WebMCP exposed the processing state and sampled trajectory. An agent retained eight survey sweeps, leaving seven turnaround gaps grey. I supplied the protected download gesture, then asked to open the actual LAS independently: it contained 21.9 million points. A completed processing response and a usable saved artifact were separate checks.

4. 5:17 PM

   Review the whole agent interaction before release.

   Review fixed a time-origin mismatch, registration lost on browser history restoration, invalid trim bounds and unbounded trajectory resampling. WebMCP, multiple retained time ranges and the receiver correction then shipped together. The human trim interface stayed simple while agents received richer selection data.

5. Evening

   Add native Trimble conversion across both machines.

   The converter worked on PC2 first. PC1 needed its complete DLL and resource bundle, not just one executable. A real T04 conversion produced observation and navigation files whose downloaded sizes and hashes matched. The app branch added chunked upload, capability-aware routing and stable backend ownership for converted files.

6. 10:39–10:40 PM

   Test the running integration, not only the branch.

   A real browser attempt could not download the converted base data because the deployed dispatcher lacked the new endpoint. Local testing was redirected to the updated backend. The application changes were committed locally, but the complete Trimble feature was not yet pushed or released.

By this checkpoint. Early mismatch handling and agent-operated trimming were live. The Trimble path had real converter evidence and a local application integration, with review and release work still ahead.

This was a shorter, concentrated morning of review and architectural questioning. The central issue was how to support proprietary base files without making routing, cancellation and resource handling harder than the user’s task required.

1. By 9:29 AM

   Repair the cross-machine contract.

   Review accepted thirteen findings. Fixes covered dispatcher authentication, per-backend credentials, stable fallback-upload ownership and converter discovery. File support was narrowed to the verified T00, T01, T02 and T04 formats instead of promising every numbered extension.

2. Morning review

   Bound the work that a conversion can create.

   Conversion slots, restart-safe queues and timeout accounting were corrected alongside retry, cleanup and replaced-selection races. Header inspection avoided loading a whole RINEX file just to inspect metadata. The frontend, backend and dispatcher checks passed, but these review fixes were still local.

3. 11:10 AM

   Expose what browser cancellation actually does.

   Stopping a browser request did not immediately stop its native conversion. A running converter could occupy a slot until it completed or hit its five-minute timeout, while abandoned queue entries could remain longer. The audit made that limit explicit; it did not pretend a proposed cancellation endpoint had already been built.

4. 11:18–11:34 AM

   Investigate a simpler path before adding more state.

   I asked whether the browser could trim Trimble binary files, or the solver could consume them directly. A valid trimmer would need much more than slicing bytes, and a bounded direct-input experiment produced no usable result. RINEX remained the established contract. Moving trimming immediately after native conversion was proposed, with no application code changed by this investigation.

By this checkpoint. The conversion branch had a cleaner reviewed implementation and a more honest account of cancellation. The alternative simplifications remained research, ready to be judged against their cost.

Several problems initially sounded like slow processing. The day separated network recovery, queue waiting, base validation, camera interaction and package memory into distinct changes, each with its own evidence.

1. 9:39–9:54 AM

   Release Trimble support, then challenge its accuracy.

   The reviewed conversion path reached both backends, dispatcher and frontend. A later trajectory mismatch led to a full-versus-trimmed base-file control. The two solves were effectively identical, so sending a larger base window would not fix this discrepancy. The investigation moved to solver configuration and historical provenance.

2. 11:10 AM

   Keep a transient connection failure from losing the job.

   The frontend gained reconnection behavior for an existing trajectory job. A temporary network error no longer meant abandoning a solve that was still progressing on Windows. The deployed bundle was checked for the new behavior.

3. 6–6:51 PM

   Separate queue time and make early validation cheap.

   Waiting in a queue stopped consuming the solver’s runtime allowance. For base coverage, the normal path inspected the first and last 1 MiB of a large capture, expanding or streaming when necessary. On the tested 66-part capture, a correct base was accepted in about 1.9 seconds and a wrong one rejected in 1.2 seconds. This was preflight latency, not full-flight processing time.

4. 7:25–7:34 PM

   Protect interaction from repeated expensive work.

   A separate worktree removed synchronous detail rebuilding on every wheel event. Camera changes were combined into a refresh after a short pause, and stale refreshes were cancelled when replacing the cloud. The smoother-zoom change then shipped.

5. 7:41 PM

   Try a fuller memory-saving pipeline locally.

   The experiment streamed extraction, spooled navigation data to browser-managed storage, trimmed incrementally and applied backpressure while creating the ZIP. Independent archive checks and real-file timings passed. This was a local implementation, not the architecture already serving users.

6. 11:22 PM

   Let a broader review stop premature completion.

   Despite passing suites, a whole-workflow review found startup recovery that could overwrite a new run, ownership rollback mistakes and unstable retry routing. More work was required before committing. Passing isolated tests had not settled the lifecycle and concurrency contract.

By this checkpoint. Users received network, queue, preflight and zoom improvements. The more ambitious storage/recovery experiment remained under review, with concrete blockers rather than an assumed quality sign-off.

The day began by removing work that had become too complicated. In parallel, smaller changes kept improving the experience, while coordinate export, imagery and ground classification tested whether independent features could remain understandable together.

1. 10:53 AM

   Archive complexity instead of shipping it.

   The previous night’s storage, lease and recovery experiment was removed and preserved as a patch that could be reapplied. Review confirmed the experimental machinery was gone. The already released network, density and zoom improvements stayed. A cleaner future storage design was an idea, not a replacement built that morning.

2. 12:14–1:09 PM

   Keep the useful, narrow fixes moving.

   A separate UI polish branch shipped improvements to the existing screens. The base-coverage path then gained a silent full-file fallback for unfamiliar valid RINEX, while keeping clear mismatches blocked. The response to uncertain metadata became conservative instead of rejecting a potentially valid project.

3. Afternoon

   Make coordinate export honor its numerical contract.

   Browser-local custom CRS export went through real-file and integration checks. Review found that a horizontal transformation can still need each point’s actual height. It also rejected dynamic systems without a coordinate epoch and fixed cancellation after the file had already been committed. The export release followed at 6:13 PM.

4. 7:40–9:43 PM

   Keep color and coordinates independent.

   I challenged a design that made color/CRS combinations look like separate modes. Existing georeferenced points could be recolored without redoing their geometry. Export inherited the viewer’s color choice instead of asking again. Imagery coloring was reviewed and released that evening.

5. 10:22 PM

   Measure the memory trade before accepting lost precision.

   Ground export initially rounded intermediate coordinates. Once the cost was measured at 1.2 MB per 100,000-point chunk, full Float64 coordinates were retained until the final LAS encoding. The extra memory stayed bounded by chunk size rather than growing with the flight.

6. 11:51 PM

   Improve the ground prototype without changing its decisions.

   Neighbor reuse reduced a flight-sized synthetic solve from 5.26 to 2.64 seconds with identical tested heights and all 510,400 classification probes matching. That justified a real-flight rerun; it did not prove the total app workflow had become twice as fast.

By this checkpoint. Coordinate export, imagery and narrow UI/validation improvements were live. Ground classification and its late precision and performance work remained local, while the rejected recovery experiment stayed archived.

I kept asking whether improvements survived a different dataset and the complete user workflow. Optimizing the mathematics, fixing interface regressions and protecting responsiveness became separate loops, while a real cloud trial tested a different way to add capacity.

1. 8:23–9:41 AM

   Keep only optimizations that earn their place.

   Some proposed ground optimizations barely helped or made a synthetic case slower. Neighbor caching and fused scans survived measurement; block skipping was removed. On the tested warm solve, time fell from 4.97 to 4.04 seconds with every terrain height and point label unchanged.

2. Morning

   QA: Use the next dataset to find general failures.

   The second flight exposed a disappearing ground control. Further audit found nondeterministic interpolation at exact timestamps and LAS bounds calculated before final encoding. Integration also left an obsolete UI reference that crashed before the toggle appeared. The fixes addressed those mechanisms rather than lowering accuracy to accommodate one file.

3. 11:44 AM–12:22 PM

   QA: Inspect all four actual export combinations.

   Independent checks covered colored/uncolored and full/ground-only LAS files. The full exports contained 41.7 million points; the ground subset and non-color bytes matched. Both solves hit the iteration ceiling, prompting a higher ceiling with early exit. Those internal convergence settings stayed out of the user interface, and the integrated ground work shipped.

4. 12:57–1:08 PM

   QA: Move blocking work out of the interface.

   A progress bar that disagreed with its percentage led to extraction in a browser worker. Two datasets produced byte-identical output, while the worst measured rendering pause fell from about 1.9 seconds to under 20 milliseconds. A normal browser flow preceded release.

5. 3:15–3:54 PM

   Cloud Backend Experiment: Reject the slow cloud trial and measure the alternatives.

   The same request took 13m56s on the trial VM versus 1m46s on PC1; throttling affected the cloud result. I rejected that actual offer, and the VM was deleted. A separate repeated core-count experiment found little benefit beyond four fast physical cores for that request, with identical trajectories across runs.

6. Evening

   Improve ground detection

   A combined enrichment experiment used a 48 MB reserve and a 600,000-point display cap. It recovered about 52% more occupied cells in the inspected under-tree patches, while respecting color and trim choices. The local integration and review passed, but testing on an actual weaker laptop was still pending.

By this checkpoint. Ground export and responsive extraction reached production. Performance claims were checked against exact output, the unsuitable cloud machine was removed, and ground enrichment remained a separately evaluated local improvement.

The work continued through the night. A fast standalone viewer was not enough: I wanted large raw surveys, ground and imagery, useful detail and smooth interaction to coexist within a practical memory budget.

1. Morning–12:55 PM

   Separate device problems from stale application assets.

   The iPad file-picker problem remained unresolved, with the same SSD working on macOS. Separately, another browser error requested an old WASM asset that returned 404 while the current asset was available. These were different failures and needed different explanations.

2. 3:03 PM

   Measure the full raw workflow, not only loading a LAS.

   Preparing all 44 million points added 35.7 seconds in the real-flow comparison and about a GiB of point buffers. The dense view itself ran at 15–18 FPS, despite the ordinary preview staying fast during preparation. That result redirected the work toward view-dependent detail.

3. 5:20 PM

   Make detail useful across the actual controls.

   An eight-million-point drawing budget worked with ground, imagery, roll and time filtering. Preparation finished before the viewer appeared, and experiment controls were removed. The measured August flight view was responsive, but the implementation still retained the source cloud in memory.

4. 10:17–10:39 PM

   Explain the large-file failure before raising a limit.

   The new survey hit a deliberate 55-million-point retention guard after trajectory processing had succeeded. Drawing fewer points had not bounded retained memory. An interim 120-million cap was released, but still could not accommodate the larger survey. Indexing the original files became the real architectural direction.

5. Midnight–3:55 AM

   Compare indexing approaches and preserve exact coordinates.

   Experiments favored a simpler 32-frame index over finer indexing and concurrent reads with inconsistent gains. Indexed coordinates matched sequential decoding. Two-worker decoding and progressive detail delivery were then taken into the app with bounded caches, rather than changing the whole viewer framework.

6. 5:32 AM · next morning

   Pass the large integrated case locally.

   The normal app processed the 390-million-point SSD dataset with ground and satellite colors. Initial preparation took about 5.5 minutes; fresh detail took about eleven seconds. Chrome-process RSS peaked around 4.75 GB and settled near 4.1 GB, above the rough original target but far more practical than retaining the whole cloud.

By this checkpoint. The night produced a working integrated indexed viewer with an eight-million-point draw budget and eviction of old detail. The large-case result was local at 5:32 AM; release followed after the next morning’s checks.

The overnight memory work reached users in the morning. Attention then returned to input guidance, exporting, phone interaction and reference comparisons, while a separate outlier investigation established a trustworthy baseline.

1. 8:22–9:08 AM

   Release the viewer and explain missing navigation inputs.

   The indexed viewer shipped after review and checks. A separate failed-package comparison succeeded when the matching navigation companion files were included. The immediate product change was frontend guidance: a browser cannot silently read sibling files the user has not selected.

2. 12:17–12:44 PM

   Make export work in a fresh session.

   Processing in a worker had initialized that worker’s WASM instance, but not the instance needed by export. Fresh-session tests exposed the gap. Explicit export initialization and a cancel/retry race fix were reviewed and released, preserving the save-dialog behavior.

3. 1:35 PM

   Recheck geometry with the comparison population stated.

   Fifteen of the eighteen previously passing fixtures retained exactly the same error statistics. Three fresh full LAS exports covered 251 million matched points with none exceeding 3 mm, using saved Windows trajectories and no alignment or fitting. The three historical orientation exceptions remained.

4. 2:14–2:27 PM

   Let the phone prototype change the design.

   After slimming the toolbar, I asked to restore the full trim timeline inside it. Landscape kept a thin row, while portrait wrapped within the same bar. The phone layout shipped after checks that also preserved the normal desktop screens.

5. 3:48–4:03 PM

   Keep new review findings visible without a broad rewrite.

   A fresh review found nine actionable issues and two larger opportunities, including hidden rendering and preview allocation costs. The issues, proposed fixes and regression checks were documented and parked. They were not silently counted as another completed reliability release.

6. 6:30–10:30 PM

   Define outliers through controlled comparisons.

   Windows filtering on/off runs established which points were actually removed. The close browser baseline nearly reproduced those removals; the cheap early method missed most. Review challenged storage, cancellation and memory behavior. The frozen local algorithm then recovered 99.986% of Windows removals across three independent datasets, while conflicting historical references stayed open.

By this checkpoint. The indexed viewer, export fix and phone layout were live. Outlier filtering had substantially stronger reference evidence and remained browser-local research awaiting integration.

The day returned to a familiar standard: a speed improvement had to preserve the result, fit the memory budget and survive integration into the real user flow. Backend storage trouble interrupted that work and created its own acceptance check.

1. 7:22–7:53 AM

   Challenge the computation, then reject an inadequate shortcut.

   The current pipeline already projected the full population while indexing, so filtering could reuse that work. A locality-based experiment finished in 1.7–3 seconds but caught only 1–44% of Windows removals. Its speed was attractive; its coverage was insufficient. The existing baseline was preserved while ambiguous cases were refined.

2. 10:55 AM–2:23 PM

   Resolve memory failures without increasing the allowance.

   The wider sweep initially completed eighteen of twenty-one datasets. Three stopped at a memory guard; one successful large case still took 9.1 minutes. After memory-handling changes, all twenty-one completed with identical rejection masks for the previous eighteen. The budget was unchanged.

3. 2:55–3:01 PM

   Prove recovery with real jobs after freeing storage.

   Low disk space had stopped native processing even though health endpoints remained reachable. Cleanup removed the blocker, then test jobs completed on both Windows machines and returned trajectories. Available space and an “online” response were not treated as substitutes for successful processing.

4. 4:29 PM

   Reuse the earlier scheduling lesson.

   The integrated filter was slower than expected. Reusing the fast yield scheduler brought three saved comparisons from 32.75, 21.16 and 113.25 seconds to 19.36, 11.14 and 68.70 seconds, with identical masks. Laptop cleanup also helped, so the change was not credited with the entire measured difference.

5. 5:08–5:18 PM

   Make the export reflect the user’s decision at click time.

   Filtering could finish after the user clicked Export. Both export paths now snapshot the toggle and readiness state at that click: later background completion cannot change the file or its receipt. The extra status wording was removed, review passed and outlier integration shipped.

6. By 6:03 PM

   Leave a maintained account of the method.

   Documentation was consolidated around the implemented algorithm and app integration, retaining experiments as evidence. A separate cross-section idea remained feasibility work about narrow source reads and additional memory, with no shipped slice-inspection feature.

By this checkpoint. Outlier removal reached the app with bounded processing, stable point identities and consistent viewer/export behavior. The all-dataset execution failures were resolved, and real backend processing was verified after cleanup.

The final day in this record moved between reliability in daily use, deliberate live load and small interaction details. Each new observation refined what “healthy” or “finished” could responsibly mean.

1. 1:36–1:42 PM

   Restore the APIs and fix the missing startup trigger.

   After reboot, the tunnel returned automatically but the APIs did not. Both were restored and given triggers for the licensed user’s Windows login. This improved recovery without interrupting running jobs; it did not provide startup before login or constitute a reboot test.

2. Afternoon

   Track outcomes as well as availability.

   Monitoring began separating jobs started, succeeded and failed, because those events can fall in different sampling intervals. Incident records retained the evidence and confidence behind a failure. The API launch also became windowless with configured restart attempts, while deliberate crash/restart verification remained open.

3. 4:25 PM

   Run actual load through the production path.

   Three baselines plus waves of two, five and ten produced twenty completed trajectory jobs. Every output matched its baseline byte for byte. A chunk-upload 502 recovered on the same backend. At ten simultaneous solves, short jobs were about 20–28% slower: the test established useful capacity with its latency tradeoff.

4. 4:36 PM

   Investigate delivery separately from solving.

   Two successful jobs had taken sixty and ninety-four seconds to download. Eighteen diagnostic downloads then matched exactly and completed much faster. Local reads and writes were fast. The intermittent delay was after solving, but its exact network, proxy or client cause was not established.

5. 6:11 PM

   Fix a real input failure that health checks missed.

   An unsupported antenna lookup happened before a trajectory job existed. The parser fix added 250 antenna signatures while preserving the 573 previously supported offsets, and it reached both Windows backends and the frontend. This showed why job-only monitoring could miss a user-visible failure.

6. 6:59–7:09 PM

   Keep both monitoring and controls understandable.

   Unsupported historical edge-log checks were removed from alerts, while confirmed failures and Windows-recorded outcomes remained. The viewer then adopted WingtraCloud’s pan-first mouse and touch mapping. The small frontend release preserved geometry and export behavior.

By this checkpoint. The record ended with a real twenty-job load result, broader antenna handling, improved startup/monitoring and familiar viewer controls. Reliability claims became more specific as real failures exposed the limits of the observations.