Installing a Mac text editor should not end with “the file opened.” A defensible installation record separates the distribution source, operating-system requirement, application identity, placement in Applications, and first launch. That separation prevents an old build, a similarly named app, or an unofficial download from becoming the writing environment by accident.
The STUDIO-514 verification status is blocked. The run was required to leave the existing environment unchanged, so it did not perform a fresh download, a new Applications placement, a Gatekeeper interaction, or a first launch. It only read inventory data from the current Mac and an existing executable. This article therefore describes a reproducible next test; it does not claim that a new installation succeeded.
Freeze the sample and the return point first
Use a test Mac that meets the macOS 13-or-later requirement. Treat the downloaded file, the app placed in Applications, and the first-launch record as one controlled sample. Before downloading, record the distribution-page URL, access time, stated system requirement, and expected filename.
The inventory run found macOS 15.7.7. The existing Rune Studio development CLI reported version 1.4.0, build 23, bundle ID com.disolo.rune.dev, and build mode dev-cli. Its executable existed, was executable, and had SHA-256 bcf22f096d7ceb506c2d245800311be2f0d3054b8e527bb61e9ecfab4e77d1dc. Those values identify the existing local tool; they do not authenticate a future download.
If the source, signature, OS requirement, or first-launch identity cannot be explained, reject the test download and return to the recorded official source and system requirements. Do not overwrite or remove the existing app during this test.
Use five product-independent installation checks
First, identify the developer-controlled distribution source. Record the URL instead of relying on a search-result label or a third-party mirror. Second, compare the requirement for that specific release with the test Mac’s actual macOS version. “Available for Mac” is not the same as “supported on this Mac.”
Third, record the downloaded filename and provider information before opening it. A locally calculated hash is useful for repeatability, but it does not prove authenticity unless the publisher supplies a trusted value for comparison. Fourth, place the test app in Applications and record the final name and location so the downloaded container is not confused with the installed app.
Fifth, preserve the first-launch evidence: the displayed app name, version, warning state, and any security prompt. If identity is unclear, stop and recheck the source instead of searching for a bypass. Font choice, pane layouts, and manuscript preferences belong to post-installation setup and must not be used to hide an incomplete first-launch check.
What the Stage 4 run actually established
The title-specific run used one command. It read the operating-system version, the development CLI’s version, build, bundle ID and build mode, plus the existing executable’s presence, permission, and SHA-256.
It did not obtain a fresh distribution file. It did not place a new app in Applications, exercise Gatekeeper, or record a first launch. The evidence cannot support “Rune Studio was downloaded and installed,” “Gatekeeper accepted it,” or “the existing executable matches an official distribution.” Because the title’s central operation was not performed, the status remains blocked.
Keep the public product scope separate
Rune Studio’s public documentation describes a current Mac version for macOS 13 or later with Japanese long-form editing, split views, vertical preview, and EPUB 3 export. Cloud synchronization and collaborative editing are outside the documented scope.
Those are Stage 3 product statements. They are separate from the Stage 4 inventory readout and from any future installation result. A useful feature list cannot substitute for distribution and first-launch evidence.
The next test that can clear the block
Use a separate test Mac or isolated test account. Record the official source and requirements, obtain a fresh file, and capture its identity. Place it in Applications, then record the app name, version, and any prompt shown on first launch. Quit and reopen it from Applications to confirm that the same build starts from the intended location.
The acceptance card has six independent rows: source, macOS requirement, downloaded identity, Applications placement, first launch, and repeat launch. A blank row leaves the result blocked. On failure, discard the test download, preserve the current installation, and return to the official source and requirement check.
What this guide deliberately excludes
STUDIO-512 tests the long-manuscript boundary and vertical output. STUDIO-519 tests large-manuscript operation at 299,999, 300,000, and 450,000 characters. STUDIO-295 evaluates an editor as part of an EPUB production workflow. This guide stops earlier: it asks whether the Mac app can be traced from a verifiable source to a repeatable launch.
Font selection, writing layouts, KDP rendering, price rankings, and competitor comparisons are outside this result. The current public feature scope is available on the Rune Studio product page, while installation remains blocked until the isolated run is completed.
