The Mac app was healthy, signed, and running. The workstation still did not appear.
A signed macOS process, green tests, and an idle run loop did not prove that the user had a usable app. The launch investigation that separated disk work, window state, and observation error.
The Mac companion passed its focused tests. The application was signed. The process launched and stayed alive.
The workstation window did not reliably appear.
This is exactly the kind of bug that a build report turns into a false success. Nothing crashed. There was no red test. From the process table, the application looked healthy. From the user's chair, there was no product.
We had combined three different failures
The first diagnosis treated “no visible window” as one problem. It was at least three.
The application performed recording-corpus work during launch. That synchronous disk path could delay construction of the workstation. Window restoration then had its own lifecycle behavior: macOS could retain state that did not match the product's one-workstation rule. Finally, the accessibility report we were using to inspect windows could say zero while WindowServer still knew a real window existed.
One symptom had mixed launch performance, scene ownership, and measurement error.
The repair started by removing corpus indexing from the launch path. Inventory now begins in an honest not-loaded state and waits for an explicit refresh. The next build sat idle at zero-percent CPU instead of blocking on external-drive enumeration.
That fixed one problem. It did not prove the window.
The observation tool was wrong too
Accessibility still reported zero windows in one check. Later, WindowServer reported exactly one opaque on-screen MHG Trainer window measuring 1360 by 861 pixels.
The app had become a good demonstration of its own evidence rules: a sensor can be wrong even when its output is precise.
We stopped treating one diagnostic interface as an oracle. After the Mac was unlocked, Accessibility independently saw one named, frontmost workstation. Command-N kept the count at one. Command-W reduced it to zero. Reopening the already-running application restored one frontmost workstation instead of creating a duplicate.
The final launch boundary uses one singleton SwiftUI scene with explicit presentation and restoration behavior. The affected launch/storage suite passed 86 tests, and the focused scene suite passed 45.
A visible window only opened the next gate
Once the workstation appeared, Review still had to cross the external-file permission boundary.
The installed app authorized the exact data root, loaded the unchanged 20-clip queue, showed clip one of twenty, and advanced playback. Forward and Back moved through the queue without modifying the source folder. The same run started and stopped the Mac camera. With nobody in frame, body pose remained at “waiting for observation,” which was the correct result.
A broader test harness also hung and left an orphan process. We terminated it and did not count that run as a pass.
That detail belongs in the story because green evidence does not make failed evidence disappear. The accepted result was bounded: one reliable workstation lifecycle, one verified review queue, playback navigation, and camera start/stop. Recording, golfer pose, complete annotation, and training export were still open.
The product is the surface the person sees
I keep returning to the same rule: designed, compiled, signed, launched, and visible are different states.
A healthy process is not a visible window. A visible window is not a usable workflow. A loaded queue is not a saved review. A camera permission grant is not a recorded golfer.
The fix was not one clever line of Swift. It was separating the states until each one could be observed independently.
The process had been running all along. The product arrived when the workstation appeared and the user could actually do the next thing.