Checked on 2026-09-14, macOS 26.6.2, Apple silicon. Minimum deployment target: macOS 13. Release bundles contain arm64 and x86_64 executables.
Source tag v0.5.9, commit 6f9c3061f671e86026cb721a539393aa9a802194, build 17.
Release evidence records accepted notarization,
stapling, corrected embedded sandbox permissions, copied-DMG startup, published
byte comparisons and successful release/source/website checks. Confirmed affected
0.5.7/0.5.8 users need one manual installation of 0.5.9.
Follow-up to the user's installed 0.5.7 → 0.5.8 failure. See diagnosis and evidence.
- Installed 0.5.7 and published 0.5.8 both contained literal build variables in the signed installer Mach permissions. Unified logs confirmed sandbox denial; this was not caught by earlier signature/notarization/startup checks.
- Manual signing now resolves bundle IDs first. A Security-framework check reads the embedded entitlements, rejects unresolved variables/wrong service names, and preserves Finder sandbox/network boundaries. The old installed app fails the new gate; the complete signed 0.5.9 local candidate passes after mounting.
- Two isolated Developer ID-signed sandbox hosts completed download, extraction, replacement and relaunch with Sparkle. Old PID 60859 exited and new PID 60910 launched build 2 at the same fixture path. Signature and entitlement checks passed after replacement. No production app/preferences were used by this test.
- The native fixture uses a minimal user driver and a local feed; the production driver's callback regression passed separately. Installed Finder refresh, production-feed/custom-driver end-to-end, Intel and macOS 13 runtime remain unrun.
- The tested local candidate was followed by the signed/notarized 0.5.9 release above. Old affected installations need one manual replacement; a feed cannot repair their current signed permissions.
Source tag v0.5.8, commit eb487e3250dc1a7d631332cfe4500ae769b96269, build 16.
Release evidence records accepted Apple notarization,
stapling, universal/nested-signature checks, copied-DMG launch and Gatekeeper,
published asset byte comparisons, and successful source/artifact/website CI.
Native launch was checked on macOS 27.2/Apple silicon; owner preferences were
unchanged. This does not add installed Finder, full updater replacement,
clean-Mac, Intel or macOS 13 runtime evidence to the feature checks below.
Checked on macOS 27.2 (26B5086k), Apple silicon, e2202df plus the uncommitted
settings worktree. See the task for commands and logs.
make verifypassed: 139 Core and 13 image tests, 5 public cases, 10 CLI regressions, 3 appcast tests and context checks. The final unsigned universal app/extension built.- Inspected all eight settings pages in English/light and Chinese/dark at 840×600. General's Theme and Interface language controls align with switches; Creation and tool pickers share the trailing treatment. Native menu choices, sidebar Up/Down, long-page scrolling, disabled icons/controls and About links were checked.
- The isolated production model passed immediate appearance application, clearing
the app override, store reload and failed-save rollback. Relaunching the fixture
retained Dark and English. Follow System read back as
systemand restored the current system appearance. New/missing/invalid theme values have Core coverage. - Existing creation and resource-processing windows changed light/dark without reopening. Template editor and creation Escape cancellation worked. Open with App's populated layout was checked by adding Preview to fixture preferences.
- Native tests used disposable preferences and generated images; no installed app, user files or owner preferences were changed. Actual OS appearance toggling, Intel and macOS 13 runtime remain unrun; no publication was performed.
Checked on macOS 27.2, Apple silicon, 55d9a1f plus the uncommitted Open with App
worktree. See the task.
make verifypassed: 127 Core tests, 12 image tests, 5 public cases, 10 CLI regressions, 3 appcast tests and context checks. The unsigned universal app and Finder extension built after the final stack/app-icon changes.- An isolated production settings window added VS Code through the real picker, defaulted to submenu, retained main placement when re-added, and removed its last entry. JSON readback confirmed bookmark/placement/removal persistence.
- Chinese light/dark and English dark at 840×600 were inspected through native screenshots. The final stack entry icon was inspected in Chinese/light. These fixtures used their own preferences and did not launch VS Code or run login setup.
- The ad-hoc-signed sandbox fixture ran the production operation coordinator and
NSWorkspace opening. A separate native app received the full Unicode file/folder
batch in order; wrong app identity and ordinary-directory app selection were
rejected. The ticket was single-use, the busy guard released, and source bytes,
folder and clipboard remained intact. Log:
/tmp/filemint-open-with-native.log. - Installed Finder callbacks, visible Finder child icons, actual third-party support, external-folder picker cancellation, keyboard-only navigation, Intel and macOS 13 runtime remain unrun. No installation, enablement or publication.
Checked on macOS 27.0 (26A428), Apple silicon, 6bf596d plus the uncommitted
resource/UI worktree. See the task and
the approved design.
make verify: 131 Swift tests (119 Core and 12 native image tests), 5 public Harness cases, 10 CLI regressions, 3 appcast tests and context checks passed. Unsigned Release app/extension build passed for arm64 and x86_64.- Production settings/views/controllers in an isolated app and preferences store were inspected at 900×650 Chinese/light and 840×600 English/dark. Three sidebar groups, file-tool disabled states, template editing/cancellation, folder guidance and About retained readable controls. No login setup or automatic update task ran.
- With the fixture's Finder resource master off, the main-app picker selected its
synthetic
Mountain.png; the real coordinator/panel saved a 1600×1000 JPEG. The saved Finder resource preference remained false. - The native New File panel accepted
界面验收.md, multiline Chinese and literal{{year}}; Command-Return created the file and its UTF-8 bytes were verified. - Six production image panels ran in Chinese/light and English/dark using only
fixture images. All completed two-image batches. Oversized stitch recovery,
OCR clear/retype, source preservation and result handling passed. Final run:
/private/tmp/filemint-design-resource-final.log. - AppKit view-cache exports miss SwiftUI layers and were not used as visual proof; live native screenshots and accessibility readback were used instead.
- The installed application was not replaced. Finder's installed callback, actual sandbox source/output grants, Intel execution and macOS 13 runtime remain unrun; these observations do not substitute for those scenarios. No commit or release.
Checked on macOS 27.0 (26A428), Apple silicon, 41067c3 plus the desktop-alias
worktree. See the task and official sources.
- Final automated verification passed: 112 Swift tests, 5 Harness cases, 10 CLI regressions and 3 appcast tests. Unsigned universal app/extension build passed.
- Production settings view: the opt-in alias checkbox, placement picker and blue symbol were inspected in Chinese/light and English/dark at minimum detail width. Main-menu placement changed successfully; master off disabled alias controls while preserving their values.
- An isolated, ad-hoc-signed sandbox fixture compiled the production coordinator.
Its source and synthetic Desktop were initially inaccessible. Cancelling the
source picker left zero outputs. Authorizing both exact fixture folders made
two aliases. Relaunching and repeating reused saved bookmarks without pickers,
making
Folder 2and报告 2.txt; both original fixture contents were unchanged. - Finder displayed the native arrow. Get Info identified the folder output as “替身” and showed the correct original; opening it displayed the original child.
- The isolated fixture did not replace the installed app. A later clean arm64
Debug build
0.5.6 (14)was installed at/Applications/FileMint.app; the installed settings page showed the opt-in发送替身到桌面switch and placement picker without changing preferences. The actual Finder extension callback, real Desktop/iCloud integration and removable volumes remain unverified. Rollback archive:build/local-install-backups/20260918-174004-desktop-alias-debug-clean/FileMint-before-debug.zip. - The four aliases created by the disposable fixture were removed from
build/desktop-alias-native.iS7cSz/Desktop; no test aliases remain there. - Logs and disposable fixture sources are in
build/desktop-alias-evidence/.
Checked on macOS 27.0 (26A428), Apple silicon, 559fc8f plus the UI-polish
worktree. The isolated native fixture compiled the production settings view and
shared tool images without loading or saving the owner's preferences.
- All five expanded tool sections, native checkboxes and placement/deletion controls were inspected in Chinese/light and English/dark, including the 632-point detail area corresponding to the app's 840-point minimum width.
- Module off kept every section visible and grayscale. Accessibility reported all child controls disabled; attempted pointer/keyboard changes to checkboxes, menu location and deletion mode left fixture JSON unchanged. Child-only disablement kept its enable checkbox available. Custom move location and deletion mode survived module off/on.
- All five shared symbols rendered colored, non-template images at 16 and 20 points. The compiled Finder adapter assigns these at either menu level and retains the pending-move icon in its submenu. This is not installed Finder menu/highlight verification; the existing app/extension were not replaced.
- The follow-up Debug install at
/Applications/FileMint.appwas inspected in Chinese/light appearance. Menu-position values now use system control text color, and the selected File & Folder Tools sidebar row has a slightly stronger mint surface while retaining its fine outline. The previous installed package is recoverable frombuild/local-install-backups/20260918-165507-file-tools-ui-tweak/. make verifypassed: 104 Swift tests, 5 public cases, 10 CLI regressions and 3 appcast tests. The unsigned universal app/extension build also passed.
See the task record for local evidence and limits.
Published FileMint 0.5.5 (13) from source tag v0.5.5 at commit 846f128ec8da4a47f0e2cd01ddd5c886f0da6a1d.
- The release process reran context, Core, harness, CLI and appcast verification: 97 Swift tests in 9 suites, 5 JSON harness cases, 10 CLI regressions and 3 appcast tests passed. The base-aware Chinese and English website build, unsigned universal candidate build and Sparkle driver verification also passed.
- The locally built universal DMG, main app, Finder extension and embedded Sparkle helpers passed Developer ID validation. Apple notarization submission 12215c00-123f-4332-b449-1c3bb7c1f31e was Accepted; stapling, mounted-image validation, final SHA-256 and appcast signature validation passed before upload.
- GitHub Release v0.5.5 contains the notarized DMG, its checksum and appcast. All three downloaded assets matched the local release files byte-for-byte. CI, Pages deployment and the published-release verification job succeeded; both public website homepages returned HTTP 200.
- The signed package was not installed over the owner’s existing app, and full signed Finder/Sparkle runtime acceptance remains unrun. This release record does not represent build or artifact checks as proof of those native scenarios.
See the 0.5.5 release record for exact assets, hashes, release links and runtime limits.
Checked on macOS 27.0 (26A428), 9bbc850 plus the existing file-tools worktree
and the menu-icon changes. The tools root uses wrench.and.screwdriver with a
mint/blue palette; the pending-move root uses arrow.right.square with a
mint/teal palette. Both resolve through the actual menuIcon helper as 16 × 16
non-template images. An isolated AppKit rendering of both icons with their
Chinese labels was inspected in light/dark appearances.
make verify-context and the unsigned universal make build passed. This was
an appearance-only change; Core tests were not rerun at that point.
Built the current worktree as an arm64 Debug app with ad-hoc local signing,
get-task-allow, App Sandbox and Hardened Runtime disabled, then installed it
at /Applications/FileMint.app. The previous installation is recoverable from
build/local-install-backups/20260918-debug-menu-icons/.
- The installed app and embedded Finder extension passed deep strict signature
verification and report version
0.5.4 (12). Their main executable bytes match the Debug build output. - After restarting Finder, the Documents background context menu showed New File
and its format entries. A selected-directory context menu showed File & Folder
Tools with Copy Names, Copy Paths and Move File / Folder. PluginKit reports one
FileMint extension, from
/Applications/FileMint.app. - The temporary Move Selected Items Here action was not prepared during this install check, so no pending move state was created. Its two icon symbols were already verified in the isolated light/dark rendering above.
DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer make verifypassed 97 Swift tests, 5 harness cases, 10 CLI regressions and 3 appcast tests. The installed app is running for manual acceptance; release signing and notarization are outside this Debug install.
Changed the two Finder root icons to palette-colored, non-template SF Symbols:
mint/blue for File & Folder Tools and mint/teal for Move Selected Items Here.
Both remain 16 × 16. The arm64 Debug build was installed at
/Applications/FileMint.app; the previous monochrome install is recoverable from
build/local-install-backups/20260918-color-menu-icons/.
- After restarting Finder, the actual selected-file context menu showed File & Folder Tools with Copy Names, Copy Paths and Move File / Folder. The installed FileMint extension was the only PluginKit registration.
- No pending move was prepared, so this check did not change the user's pending move state. The move icon was verified through the same palette helper and the isolated AppKit rendering.
make verify-context, the arm64 Debug build, andDEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer make verifypassed.
Checked on macOS 27.0 (26A428), with installed Debug 0.5.4 (12) at
/Applications/FileMint.app; source checkout was 9bbc850 plus existing
file-tools worktree changes. No build or installation was performed in this check,
so exact source-to-installed-binary correspondence was not established.
- Reproduced: the Documents background context menu had no FileMint New File entry. PluginKit listed exactly one enabled FileMint extension at the installed path, but its process was absent. Strict signature verification passed and the installed extension retained its App Sandbox entitlement.
- System logs showed the Finder-hosted extension received SIGTERM at 10:14:11 and Finder lost its connection. The sender of that signal was not established. Separate sandbox-rejection logs referred to an unsigned Release build under DerivedData, not the installed Debug extension.
- Recovery passed:
killall -TERM Finderrestarted Finder; the installed extension process returned. The actual Documents background context menu then showed New File and its custom, text, Markdown, JSON, HTML, CSS and Shell items. PluginKit still listed exactly one enabled installed extension. - No application code, preferences or extension enablement was changed. File creation, desktop menus and recurrence after another Debug replacement were not tested. Automated tests/build were not run for this runtime recovery.
Subsequent local-install check on the same date: at the user's explicit request,
the arm64 Debug build was installed at /Applications/FileMint.app and opened.
Both app and Finder extension processes were observed at that installed path,
with exactly one enabled extension registration. Ad-hoc signatures passed strict
deep verification; both targets retain App Sandbox and get-task-allow. This
development build is signed without Hardened Runtime because its ad-hoc Debug
dylib was rejected by the release-style library validation. No system security
setting or release signing configuration was changed. The preferences JSON hash
was unchanged. The prior installed app is archived locally at
build/local-install-backups/20260917-175149/FileMint-installed.zip; the same
directory contains the installation record and build log. Debugger attachment,
complete Finder creation and public-release notarization were not tested.
Checked on macOS 27.0, Apple silicon, at 73e02f5 plus the settings-navigation
worktree changes. This is local development evidence, not release acceptance.
- Final
make verifypassed 83 Swift tests, 5 JSON cases, 10 CLI regressions and 3 appcast tests. The unsigned universal app build passed. Logs are retained locally underbuild/settings-preview/; no signed installer was produced. - The actual built app was opened in Chinese/light appearance: settings pages, template actions and the expanded/scrollable Full Disk Access guide were inspected. The app's About menu selected About in the same settings window. The sidebar New File action opened its directory picker; cancelling returned to settings. No file was created and no settings toggle was changed during QA.
- An isolated native preview compiled the actual page views with in-memory fixture models, without preferences storage, bookmarks, Finder registration or network operations. At 840×600, English/dark template actions, creation settings, About and the editor sheet were readable; Escape cancelled editing.
- After the user's visual feedback, the final sidebar used a continuous background, subdued mint selection and a thin mint keyboard focus outline. Chinese and English dark layouts were inspected; Down moved from Creation to Templates & Types, and accessibility exposed the selected page button.
- The fixture is layout/interaction evidence only. Real persistence, login-item changes, updater installation and signed/installed Finder cold-launch/window isolation were not rerun. macOS 13 retains the system focus indicator and its native appearance was not tested on that OS. No release was published.
See the settings task for scope and remaining release checks.
Published 0.5.4 (12) subsequently passed local Developer ID signing, Apple notarization and stapling, downloaded-asset comparison and GitHub release verification. See the 0.5.4 release record for the exact source commit, submission ID, checksum and runtime scope.
- General now has a default-on automatic update switch. Attempts persist across launches and are spaced at least seven days apart; the first overdue check waits at least 60 seconds. Manual checks remain usable with the switch off. Release discovery shows an in-app/menu indication without a download or window.
- Apple public documentation and a DTS response were reviewed; the bundled
extension's loading and user enablement are separate. The app remains
sandboxed and uses status plus system settings guidance. Sources and the
supported boundary are in
FINDER_EXTENSION_ENABLEMENT.md. - Initial
make verifyandmake buildattempts were blocked by the machine's unaccepted Xcode license (exit 69). Command Line Tools also failed with a PackageDescription linker error. After the user completed Xcode setup, Xcode 27.0 (27A266a) passed its first-launch check. No system setting or license was changed by the agent. - The normal
make verifycommand then passed all 60 tests in 5 suites and all 5 JSON harness cases using/Applications/Xcode.app/Contents/Developer.make buildwithCODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NOsucceeded. Both the app and Finder extension contain arm64 and x86_64; their versions match, and the accessory-launch flag, Finder extension metadata and bundled license were checked. This is an unsigned local build, not a signed release, notarized installer or completed installation. Globalxcode-selectstill points to Command Line Tools; the Makefile selects Xcode for these commands. - Independent validation used the installed Swift compiler directly with its
matching SDK, writing artifacts to
/tmp/filemint-validation: all Core sources compiled; all 60 Swift Testing tests in 5 suites passed; all 5 JSON harness cases passed. The app, shared UI and Finder status bridge passed Swift 6 type checking. Existing download-closure capture warnings remain. - A temporary native smoke executable compiled the actual
UpdateModel.swiftwith in-memory preferences and a controlled mock update client. It exercised the real 60-second one-shot timer: no immediate request, exactly one delayed check, attempt recorded before completion, cancellation on disabling, manual checks with auto off, retained cooldown after toggling, and an in-flight manual check unaffected by toggling all passed. It made no network request and did not open an installer or change the user's preferences. git diff --checkpassed. Packaged-app visual inspection, a real automatic GitHub request, and sleep/wake behavior remain native acceptance follow-ups. The existing installed app was not replaced, and no release was published.
- 54 Swift Testing tests pass, including Desktop menu destinations, installer quarantine preflight, repeated menu creation, update validation and bilingual About text, plus the permission-copy tests and all 5 public JSON harness cases.
- Coverage includes 40 simultaneous creations with distinct payloads, exact custom filenames, verbatim UTF-8 and CRLF, dangling symlinks, atomic replacement, template/date rendering, single-pass expansion, custom types, preference migration/storage, startup defaults, saved off switches, locale resolution, expiring one-use requests and captured Finder destinations.
- Release compilation passes. Nested code signatures, both architectures, app/extension versions and the bundled license are checked by verify_bundle.sh.
- The DMG passes hdiutil verification. Its SHA-256 manifest uses a portable basename. Packaging removes its staging app, preventing residual registrations.
| Scenario | Observed result |
|---|---|
| Launch at login | FileMint appeared in macOS Login Items; app switch disabled and re-enabled registration |
| Preference persistence | Startup and menu bar switches remained off after quit/relaunch; restored to on afterwards |
| Permission guide | Button opened Privacy & Security → Full Disk Access; no full-disk permission was automatically granted |
| Folder permission | Test directory was authorized once; later creation after relaunch reused the saved access |
| Custom type | TOML type with starter content saved and appeared in Finder immediately |
| Quick creation | Created Untitled.toml and Untitled 2.toml with correctly rendered names |
| Hidden UI | Quick creation worked with the settings window closed and menu bar item hidden |
| Custom filename/content | Actual UI saved demo.js; on-disk UTF-8 bytes matched pasted Chinese, emoji, multiline JavaScript and literal {{year}} |
| Content editing | Return inserted a newline; Undo restored the prior content; suffix changes preserved edits |
| Format picker | Entering a known suffix then opening the list showed all enabled types |
| Collision confirmation | Cancel was visibly the default button; Return dismissed the confirmation, preserved the draft and left the original bytes unchanged |
| Cancel | Cancelling the remaining draft did not create demo.md |
| Language | Follow System resolved to Chinese; native menus/pickers and application labels localized correctly |
| Old registrations | Removed old 0.1.0 and staging/development copies; refreshed System Settings showed one installed FileMint entry |
Runtime inspection found and fixed a menu bar binding feedback loop that repeatedly saved preferences during SwiftUI updates. The setter now rejects unchanged values and defers system writebacks outside the render transaction. Idle observations showed 0.0% CPU for the app and Finder extension processes after the fix. This is an idle observation, not a benchmark for every workload.
File creation performs no background traversal of user folders and no clipboard polling. File writes and Finder request processing run away from the main thread. Menu snapshots are bounded; consumed request files were removed as expected.
App/Dock assets, Finder toolbar, menu bar and the colored Finder root mark use the Folded F identity. The installed extension's real NSBundle image API loaded the 16-point root mark and both 18-point toolbar/menu marks with alpha. The macOS icon service returned the updated Folded F for /Applications/FileMint.app, and no obsolete pinned FileMint path was found in Dock preferences. The application window also displayed that icon. Direct capture of Dock/context-menu surfaces was unavailable in the UI driver, so those checks use asset and system-icon service evidence rather than claiming a captured Dock/menu screenshot.
For published version 0.5.1, GitHub workflows built, verified and attested the DMG; that provenance is not Apple notarization. Future public versions use local Developer ID signing and Apple notarization, then upload the validated DMG to GitHub. First-launch and Finder extension approval remain subject to macOS policy and are explained in INSTALL.md.
Intel execution, reboot/login execution and a clean-Mac first install were not performed on this host. Universal compilation, native login registration/status, and the actual runtime checks above are the evidence available here. The final 0.5.1 release download and its attestation were verified separately after publication.
- The first 0.5.2 candidate passed 51 core tests but failed user acceptance: Documents and the actual desktop background still had no FileMint menu. Its targetless-Desktop fallback did not address the cause and has been removed. That candidate is not approved for publication, regardless of its Apple result.
- Temporary native diagnostics confirmed that the running extension registered Desktop, Documents and Downloads, but only received Downloads observation events. A real Documents context menu never called FileMint's menu function.
- Adding the dynamically resolved user home as an observation ancestor produced Documents observation and container-menu callbacks. The native Documents menu then displayed New File and all enabled types. The user also confirmed that desktop, Documents and Downloads menus appeared; they explicitly did not test actual file creation. All temporary diagnostics were removed afterwards.
- Menu and quick-ticket validation share the configured folder scope, separate from observation roots. A native check with home excluded confirmed that its background did not receive a FileMint menu merely because it was observed.
- The user subsequently required menus in their home directory itself. Default scope now includes the OS-resolved real user home, using the existing user-ID lookup rather than a username, Finder display label or fixed /Users path. Old three-folder defaults gain home once; restricted scopes, later removal, language and saved bookmarks survive migration.
- The original three-folder JSON was restored before testing the migration. Installed 0.5.3 (11) then showed New File both on the home background and on a file in home without manually adding a home entry to that legacy JSON.
- Documents → New File… opened the native panel with Documents as its exact destination. The test draft was cancelled without writing a file. No additional system privacy or folder-bookmark permission was granted during these checks.
- All 54 Swift tests and 5 public harness cases passed. Tests cover different usernames, a relocated /Volumes home, old-settings migration and saved removal, out-of-scope targets, and ticket-to-file creation in a temporary Desktop.
- The universal Release build, nested Developer ID signatures and bundle checks
passed. The installed copy is 0.5.3 (11) with one enabled PluginKit registration.
Clean-Mac notarized-install trust and actual user-folder file creation remain
separate acceptance items. Public release was initially planned to wait for
Apple notarization; the owner subsequently authorized a clearly labeled
one-time 0.5.3 release while the submission remained
In Progress. - About and both READMEs retain the verified Special Thanks / 特别感谢 to 阿逼, linking to https://github.com/bibinocode for signing and notarization help.
- A live
xcrun notarytool infoquery using the localFileMintKeychain profile returnedAcceptedforFileMint-0.5.3.dmg, submission11ed351a-020e-4107-bfae-72d0a8daec52. The response identified the original submission creation time as2026-09-14T09:56:50.589Z; it did not report the later transition time. - A live GitHub Release query still found the exact 4,177,677-byte asset with
SHA-256
712219fe3e3b163baf0fabfec16a78b305ac09311d1eba51a71010ea04c0f6ae. The asset therefore remains byte-identical to the accepted submission. It was published before acceptance and has no stapled ticket, but Apple publishes the accepted ticket online for Gatekeeper, including already-downloaded copies. Offline first-launch behavior and a clean-Mac networked launch remain untested. - The Release title and body still said
pendingat the start of this follow-up. They can be edited in place fromdocs/RELEASE_NOTES.md; the DMG and checksum must not be deleted, replaced or re-uploaded. A future version remains the path for a distribution with a locally stapled and validated ticket.
- The owner explicitly requested publication before Apple finished processing
the existing
notarytoolsubmission11ed351a-020e-4107-bfae-72d0a8daec52. Apple reportedIn Progressimmediately before publication and again after the release checks. The published DMG has no stapled notarization ticket. The release title, notes, README and install guide identify this limitation; Gatekeeper may block the download. SHA-256 is not notarization evidence. - The published
FileMint-0.5.3.dmgis the exact 4,177,677-byte submitted DMG from binary source commitc3d924a81eeb5e2efdb0b637eefe405947593dde, SHA-256712219fe3e3b163baf0fabfec16a78b305ac09311d1eba51a71010ea04c0f6ae. Annotated tagv0.5.3points toab4f8096c8f3796d3f3f4a1ee6c0ef8d3e83eab9, which adds only release documentation and verification scripts; no app or package code changed. A local manifest records both commits separately. make verifypassed before and after the release-description change: 54 Swift tests and 5 public harness cases. The published DMG checksum, disk-image integrity, universal app/Finder extension, version/build0.5.3 (11), nested Developer ID signatures, hardened runtime and secure timestamps passed local checks. The one-time 0.5.3 path explicitly detects the absence of a stapled ticket; later release verification still requires one.- GitHub Release
is public, stable and Latest with only the DMG and portable
.sha256assets. The downloaded assets matched the local bytes exactly.make verify-updatespassed against the live 0.5.3 release, covering the latest-version response, cancellation, retry, size, SHA-256, quarantine and cleanup. It did not install or launch the published app. - Verify uploaded DMG passed after publication, checking the uploaded checksum, universal bundle and Developer ID signatures. The job did not claim a notarization ticket or a GitHub Actions build attestation. Clean-device Gatekeeper behavior and actual user-folder file creation remain unverified. The former automatic Accepted-only publisher is paused so the 0.5.3 assets cannot be silently replaced after Apple finishes; a newly stapled public build needs a new version.
- The supplied Developer ID Application certificate for team
8S66M2ZLD5matches the public key in the locally generated FileMint CSR. macOS Keychain reports a valid code-signing identity for this certificate and its private key. - The local
.cerinConfig/Signinghas the same SHA-256 as the supplied file and is ignored by Git. It is not a signing private key. make verifypassed before the distribution workflow change: 48 Swift tests and all 5 public harness cases.- A disposable
0.5.99Release package built both architectures and passedverify_bundle.sh. The Finder extension, main app and DMG each passed strict Developer ID signature checks for the intended identity and team, hardened runtime where applicable, and secure timestamps.hdiutil verifyaccepted the DMG. It was submitted to Apple asfb386d9a-0ac0-4491-9c2a-1236c2c403c9; at 2026-09-14 16:44 China time, Apple still reportedIn Progress. This test DMG is not a public release, and its notarization has not yet been verified. - The exact identity was exported to an encrypted local
.p12; its generated password is stored in the login Keychain. No signing identity was uploaded to GitHub. The emptyrelease-signingenvironment created during exploration was removed after the decision to build locally; it had no secrets or deployments. - The supplied Apple Team API key was parsed locally and validated by Apple's
notary service, then stored in a local
notarytoolKeychain profile namedFileMint. No notarization credential was added to GitHub.
Checked locally on 2026-09-13 after the report that the guide did not change after permission was enabled:
- System Settings → Privacy & Security → Full Disk Access showed FileMint.app switched on. No privacy switch was changed during this verification.
- The old app only displayed setup instructions; it did not query this system permission. The revised guide says the system switch is authoritative, explains both enabled and off/missing cases, and explicitly says its continued visibility does not mean access is denied.
- Chinese and English native UI screenshots showed the full guide, folder list and folder actions without clipping. Saved folder authorization has its own label. The original Follow System language preference was restored afterwards.
- The confirmation button opened the Full Disk Access pane. Returning to the app retained the neutral explanation rather than manufacturing an enabled state.
make verify, universal Release compilation, nested signatures andverify_bundle.shpassed. The verified app replaced the local/Applications/FileMint.appand was reopened with the new guide visible. Re-entering the system privacy pane still showed FileMint.app switched on.- Temporary build registration was removed; PluginKit reported one enabled
FileMint Finder extension, from
/Applications/FileMint.app.
This verifies the visible macOS switch and the app's explanatory UI, not an in-app Full Disk Access detection API or unrestricted access to every file. Apple describes the independent sandbox and privacy restrictions, and the lack of a TCC API surface, in On File System Permissions. This follow-up updated the local app only; published DMG assets were not rebuilt or republished as part of this change.
Checked locally on 2026-09-13:
make verifypassed before the work (35 tests and 5 harness cases) and after implementation (46 tests in 4 suites and 5 harness cases). New coverage checks numeric versions, no downgrades, stable-only releases, exact repository/asset URLs, redirect hosts, absent/invalid checksums, mismatches and requested credits.make verify-updatesused the actual app client against the public v0.2.0 release. It received download bytes before cancellation, removed the partial download, retried successfully, checked all 3,946,055 bytes and SHA-256, and confirmed quarantine metadata. Temporary smoke artifacts were removed.- Native About showed the installed version/build,
© XiaoDaiGua-RayandXiaoDaiGua-Ray · GPT-Astra. Chinese layout was visually inspected. Both languages' strings are covered by unit tests. The page's update button and the application-menu command returned the real up-to-date result for 0.2.0. - A temporary build numbered 0.1.99 exercised the complete UI upgrade path against the real 0.2.0 release: available version and size, download progress, verification, installation guidance and Reopen Installer. Finder visibly opened the DMG containing FileMint.app, Applications and LICENSE.txt. The published app was not installed; the test disk image was ejected afterwards.
- Settings now has an explicitly owned, non-restorable AppKit window. A real
Finder cold launch delivered the creation URL before did-finish-launching,
with
NSApplication.launchIsDefaultUserInfoKey == false; only the creation panel opened. A request with settings already closed behaved the same way. - Repeating New File with an existing draft preserved its filename and focused the same panel. Cancelling left no visible app windows. Explicit app reopening still opened settings. The user's existing hidden-menu-bar preference remained off throughout, so these checks also cover that configuration.
- The UI driver reopens apps when asked to inspect an app with no windows. A temporary event-only diagnostic distinguished that driver action from a Finder URL: it reported a reopen with no visible windows after cancellation. These diagnostics recorded no paths/content and were removed from the implementation.
- Final
make packagerebuilt the normal 0.3.0 (3) version, validated the universal app and nested signatures, created a valid DMG and passed the portable SHA-256 manifest check. The packaging staging directory was removed. The final app replaced the temporary 0.1.99 build in/Applications/FileMint.app, passedverify_bundle.shthere and reopened on About. Startup stayed enabled, the menu bar stayed hidden, and the Follow System language setting was preserved.
The tagged release workflow independently rebuilds, verifies and attests the final uploaded bytes before publishing. No clean-Mac install, Intel execution or macOS 13 runtime was performed in this follow-up; universal compilation targets macOS 13+. The end-to-end update check used a test version number rather than publishing a fake remote update.
Checked locally on 2026-09-13 after the user's clarification that the Dock icon belongs only to the settings window:
- The installed app's crash report at 14:05:22 showed
EXC_BREAKPOINTinFinderActions.open(_:activate:)oncom.apple.launchservices.open-queue. The callback inherited main-actor isolation and trapped even on success, terminating the extension after it had handed the request to the app. It is now explicitly@Sendable; only error presentation hops to the main actor. Apple's NSWorkspace callback contract documents execution on a concurrent queue. - The main app now launches with
LSUIElement = true. Opening settings or About switches to.regular, and closing the settings window switches back to.accessory. Minimizing keeps.regularso settings remains reachable. A creation panel on its own does not change the policy or open settings. make verifypassed before the change (46 tests) and after it (47 tests), plus all 5 public harness cases. The new test runs five independent menu snapshots through ticket consumption and actual file creation, checking incremented names, no replay and request cleanup. Universal Release build, ad-hoc nested signatures andverify_bundle.shpassed; bundle verification now requires the main app's accessory-launch flag.- Native Finder background and file context menus were inspected through the
accessibility tree. A disposable directory required its first folder
authorization; the creation panel handled that flow without opening settings.
Subsequent quick actions created
Untitled 2.txtthroughUntitled 5.txt. All five files were checked on disk, each with the expected empty content. Fresh context menus continued to show FileMint after each action, and the same Finder extension process survived all app-launch completions. - The live macOS
NSRunningApplication.activationPolicywas.accessoryafter quick creation, with only the custom creation panel, and after closing settings. It was.regularwith settings open and minimized. Creating again after closing settings kept.accessory. This is system runtime state evidence, not a captured Dock screenshot. - Both quick and custom Finder routes were exercised from a cold main-app launch. Custom cold launch showed only the creation panel; cancellation kept settings closed. For this check the app process was confirmed absent first, and its activation policy was read before selecting it in the UI driver: inspecting a stale app handle while launch is pending can itself reopen settings and must not be attributed to the Finder request.
- No new Finder extension crash report appeared. The verified bundle replaced
/Applications/FileMint.app; PluginKit reported one enabled registration, from that installed app. The temporary test-folder authorization was removed, and decoded preferences exactly matched their pre-test values, including the hidden menu bar, enabled login item, language and original folder bookmarks.
This follow-up updates the local app and source. Existing DMG files and published GitHub release assets were not rebuilt or republished. The native checks ran on this Apple silicon host; no Intel, macOS 13 or clean-Mac runtime claim is made.
Checked locally on 2026-09-13 for the 0.4.0 release:
- The source defaults are
MARKETING_VERSION = 0.4.0andCURRENT_PROJECT_VERSION = 4. The main app and Finder extension generated from the Release build both report version0.4.0. make verifypassed: 47 Swift tests across four suites, including repeated Finder menu creation, and all five public JSON harness cases.APP_VERSION=0.4.0 BUILD_NUMBER=4 make packagebuilt a universal, ad-hoc-signed DMG. Nested-code verification, both architecture checks and theLSUIElementbundle assertion passed.hdiutil verifyaccepted the DMG, and its portable checksum was12077691867d094f18b64f563f090183cc5303e2ad33bdde372264886019f654.- The release tag workflow rebuilds from this committed source, creates and verifies a distinct final DMG, creates a GitHub artifact attestation, and publishes the final checksum. The published asset's checksum and attestation are verified after that workflow completes; local and CI DMG bytes are not expected to match.
Verified after publication on 2026-09-13:
- GitHub Release v0.4.0
is a non-draft, non-prerelease latest release for commit
9f663ea. - The Release workflow completed its build, attestation and publication job successfully in 2m15s.
- The published
FileMint-0.4.0.dmgis 4,263,439 bytes and its published SHA-256 is6e6595c213e0d628c2cf3834ec41c2c9b50dc237f90349061f741c2368728031. A fresh release download passedshasum -a 256 -candhdiutil verify. gh attestation verify FileMint-0.4.0.dmg --repo FileMintApp/FileMintcompleted successfully against that downloaded DMG.
Investigated on 2026-09-13 after a report that the GitHub DMG still lost its Finder menu after creation:
- The user-provided
Downloads/FileMint-0.4.0.dmgand a fresh GitHub download both matched the published SHA-256 above. The release was built with Xcode 16.4 and reports build 3; the earlier local build used the newer local Xcode and build 4. Version labels alone do not identify the active extension copy. - At 14:41:04,
launchdexplicitly reported an attempt to bootstrap the same Finder extension from two paths: an existingbuild/DerivedData/.../FileMint.appand a conflicting/Applications/FileMint.app. It retained the development path. At 14:41:12, PluginKit removed the extension instances and Finder logged an interrupted connection. There was no new Swift crash report for this event. - The release preparation had created and registered another development app after the previous cleanup. Both that app and the standalone build extension were saved as ZIP backups, unregistered where present, and removed from the discoverable build directory. The installed app was restored from the exact published DMG; main-app and extension executable bytes were compared with it.
- Real Finder checks with the GitHub app created
Untitled.txtthroughUntitled 10.txt, plus a custom file containing exact Unicode and literal{{year}}text. Background and file context menus remained available after creation. All processes inspected pointed to/Applications/FileMint.app, and PluginKit listed one installed registration. No new extension crash report appeared. The same installed extension instances survived the checks. - Packaging now owns a fresh temporary build under
build/package-work.noindex. Its exit handler unregisters only those temporary app/extension paths and removes the temporary directory.make buildretains its separate development output. A full successful package and a deliberately failing signing attempt both left no temporary bundle or registration, while the installed app kept working through five more consecutive quick creations. The failure test used a nonexistent signing identity and failed at signing as intended. make verifypassed before and after: 47 tests and 5 public harness cases. Release compilation and successful DMG packaging passed. Test folder access was removed afterwards; the decoded preferences matched the values before this round's folder authorization. Preferences had been removed during the user's uninstall, so this round began with fresh application defaults.- In-app updates download and verify a DMG, then open it for manual replacement. They do not copy an app into the development directory. Their old handoff text omitted ejecting the installer volume; the revised Chinese and English text adds ejecting it and reopening the installed copy from Applications. Cache deletion is not an eject operation, and an open installer is not proof of a completed installation. This is a separate handoff gap, not the development path conflict proven by the system log.
The installed and tested app remains the original published 0.4.0. These build workflow and instruction changes do not replace existing GitHub release assets or claim to add an automatic installer. The updated in-app text will ship with the next application release.
Prepared on 2026-09-13:
- The application version and local packaging defaults are now
0.5.0(build 5). The Release workflow continues to use its run number for the published build. This release includes the isolated packaging cleanup and bilingual installer ejection guidance described above; installation still requires manual app replacement. make verifypassed before and after the version update: 47 Swift tests and all 5 public harness cases.APP_VERSION=0.5.0 BUILD_NUMBER=5 make packagepassed universal build, nested ad-hoc signatures, bundle checks and DMG verification. Its local checksum is5b4acae4d6bb06f8127870cb717607f75f67b9987e56a09b4787c27286915e91.- Packaging removed its temporary directory and extension registration.
PluginKit still listed only
/Applications/FileMint.appversion0.4.0. The installed main-app and extension executable SHA-256 hashes were unchanged, preserving the user's requested baseline for testing the online update.
Verified on 2026-09-13:
- Release v0.5.0
is the latest non-draft, non-prerelease release. Tag
v0.5.0points toca9c2a9578fe96f96c88afa2fa105657493e768c. - The Release workflow
completed successfully in 1m46s. The published app is
0.5.0(build 4). - The public DMG is 4,263,537 bytes with SHA-256
7b6d2d72cc95c4f09a6bf65ac72e0335ffc0faffe10a47dde9e89591d5136969. A fresh download matched its checksum file and the GitHub asset digest. Attestation verification passed with the exact release source digest,refs/tags/v0.5.0and the repository's Release workflow as constraints. - The downloaded DMG was mounted read-only without opening Finder or running
its app.
verify_bundle.shpassed the nested signatures, universal binaries, matching app/extension versions and accessory-launch flag. The volume was ejected immediately after inspection. - The same
UpdateClientand update policy used in 0.4.0 returned the public 0.5.0 update when checked with current version0.4.0.make verify-updatesthen passed the live same-version check, cancellation after receiving bytes, partial-download cleanup, full retry, checksum/size verification, quarantine preservation and installer cleanup. - No app was installed during these checks. The local GitHub 0.4.0 app and its extension remain the user's baseline for their manual online-update test. These client and artifact checks do not claim completion of the user's Finder replacement/ejection/relaunch flow.
Investigated and checked on 2026-09-13 after the user completed a real in-app 0.4.0 → 0.5.0 download and Finder replacement:
- The installed app was version 0.5.0 (build 4), executable permissions were
correct, and strict nested code-signature verification passed. The cached DMG
matched the published 4,263,537-byte artifact and SHA-256. The failure was not
damaged download bytes: the installed executable had quarantine
0387, and the kernel denied execution as created without user consent.spctlreported “File created by an AppSandbox, exec/open not allowed”. - A real sandboxed diagnostic reproduced
0086after writing into private cache and0287after adding download metadata. Selecting the destination through NSSavePanel instead produced0082after writing and0283after download metadata, including with atomic writes. Apple's DTS explanation identifies the sandbox no-user-consent bit as an execution block separate from ordinary Gatekeeper approval. - The user installation was recovered by downloading the same public artifact
with system save authorization, copying it with Finder and ejecting the
installer. The recovered app retained internet quarantine (
0383), matched the source executable bytes and opened normally. No quarantine attributes, sandbox restrictions or Gatekeeper protections were removed. - The production updater now gets a save-panel destination before downloading, uses cache only for partial download and verification, and atomically writes fresh verified bytes to the authorized URL. It does not move cache quarantine into the user's installer. Saved installers retain their checksum proof and are revalidated before every open. A known execution block or changed saved file prevents opening; completed user-saved files are not automatically deleted.
make verifypassed before the change (47 tests) and after it (48 tests), plus all five harness cases.make verify-updatespassed cancellation after bytes arrived, preservation of an existing destination, cache cleanup, full retry, normal quarantine and rejection of a modified saved installer on reopening.- The new interactive sandbox harness uses the actual production UpdateClient.
It rejected an unapproved container save, started no download after cancelling
the system save panel, and saved/validated the public installer with quarantine
0283after save-panel confirmation. It has the existing sandbox/network/ user-selected-file permissions, with no executable-writing entitlement. - A temporary, unpublished build numbered 0.4.99 (600) then exercised the full
FileMint About interface against public 0.5.0. Cancelling the save panel left
the available update intact. Confirming a destination showed progress, verified
and opened the DMG, and offered Reopen Installer. The on-disk installer matched
the public hash and had quarantine
0283. Both temporary test volumes were ejected after the test; the 0.4.99 build is not a release. - Local 0.5.1 (build 6) universal packaging and nested signatures passed, with
DMG SHA-256
c3e5ef7d7204fd77ba90ac07270d364f45b8dffcac5e90be6d5575d3b88ea783. Build and staging app registrations were cleaned by the packaging exit handler.
These checks supersede the earlier assumption that non-sandboxed update smoke tests could validate the installed application's download-to-launch behavior. The old 0.3.0–0.5.0 updater cannot acquire this fix before replacing itself; release/install instructions require a fresh browser download for that upgrade.
- Release v0.5.1
was published from
47ae1ebcd7d2ed81c1f21a530cdb229dac906287by the successful Release workflow. Its public DMG is 4,288,842 bytes with SHA-256e03889baa63f62653ed098ef61a1d3dc835e5451d0d71599aefd7d59e029aa08. - The actual sandbox regression client downloaded that public release through
a confirmed system save dialog into
Downloads/FileMint-0.5.1.dmg. Quarantine was0283. The public checksum and an attestation constrained to the exact release tag, commit and Release workflow passed. - Strict nested signatures, universal architectures and app/extension versions passed on the mounted public bundle. Finder then replaced the installed app; the installed executable matched the mounted original bytes. The volume was ejected before launch. No quarantine flag was removed or rewritten.
- The installed app retained normal internet quarantine (
0383, then03c3after launch). The running LaunchServices record reported 0.5.1 (build 5), the process finished launching, and its native creation panel was visible. A user-owned draft in that panel was left untouched. - PluginKit listed one enabled 0.5.1 extension under
/Applications/FileMint.app. Diagnostic processes had exited; their temporary builds, unpublished 0.4.99 installers and test caches were cleaned up. The public 0.5.1 installer remains in Downloads. Existing app settings were not reset.
Worktree based on 4788db0, macOS 27.2 / Apple silicon, Xcode. These observations
cover the development worktree, not the installed Finder extension or a release.
- Clipboard image task: native synthetic PNG preview, 1600×1000 output, identical numbered copy and cancel-without-write; real PNG/TIFF encoding and alpha/orientation regression coverage.
- Multiple-template task: same-suffix choices, persisted format default, independent name/content, exact native meeting-note output. Tab/Shift-Tab cycles through text/image controls, skips disabled controls and preserves content; Cmd-Return still creates.
- Office-template task: native DOCX/XLSX import, managed reference readback, exact-byte native creation and numbered output. Independent document readers verified text, formatting and a formula. Chinese/light and English/dark surfaces inspected; template settings fit 840×600.
- Final
make verify: 137 Core + 13 image tests, 5 public cases, 10 CLI and 3 appcast tests passed (/tmp/filemint-final-verify.log). Unsigned universal build passed (/tmp/filemint-final-build.log). - Installed Finder callbacks, sandbox permission cancellation, macOS 13/Intel runtime and Microsoft Office runtime remain not run. No installation, Developer ID signing, commit or publication was performed.
The 0.5.10 release verification records the
clean tagged build, Accepted Apple notarization, stapled DMG, downloaded GitHub
asset comparison, successful CI/site/release jobs and native acceptance. An
isolated copy of public 0.5.9 upgraded through the production About UI and
public feed to 0.5.10 (18), replacing and relaunching at the same temporary
path. The user's /Applications/FileMint.app remained at 0.5.9; installed
Finder refresh, Intel/macOS 13 and managed-device paths remain untested.