verify

Builds, launches, and drives a Debug build of Rapture for Mac to verify changes against live filesystem surfaces.

Updated May 16, 2026
One-click install
npx skills add https://github.com/NoiseMeldOrg/rapture-mac --skill verify-noisemeldorg
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: verify
Source: https://github.com/NoiseMeldOrg/rapture-mac/tree/main/.claude/skills/verify
Command: npx skills add https://github.com/NoiseMeldOrg/rapture-mac --skill verify-noisemeldorg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Verifying changes to a menu-bar macOS app is hard because its behavior surfaces as filesystem side effects rather than UI, and naive verification attempts hit silent failures like App Nap stalls, Full Disk Access re-prompts, and LaunchServices quirks. This Skill provides a battle-tested procedure for building, launching, and observing a Debug build of Rapture for Mac end-to-end. ## Core Features & Use Cases - Deterministic build and launch workflow: Builds the Debug app with xcodebuild, isolates it from the installed copy, and confirms the correct binary is running. - Filesystem-driven verification: Drives the app by dropping .txt files into the debug notes destination or relay folder and reads state.json (triagedRecords, relayFiledRecords, lastError) as the oracle. - Known-failure recovery guidance: Documents fixes for App Nap stalls, TCC/FDA re-onboarding quits, sandboxed log limitations, keychain ACL hangs, and direct-exec launch failures. - Use Case: After modifying the triage pipeline, build the Debug app, drop a test .txt file into ~/Documents/Rapture Notes (Debug)/, wake the process with sample, and confirm the triaged record appears in state.json. ## Quick Start Build and launch the Debug version of Rapture for Mac, then verify my triage changes by dropping test files into the debug notes folder and checking state.json.

Frequently Asked Questions about verify

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify macOS menu-bar app changes without the test suite?▼

Build a Debug configuration with xcodebuild, launch it via the open command, and drive it through its filesystem surfaces. Drop test files into the app's input folders and observe outputs and state files like state.json to confirm behavior.

How to run a debug build alongside an installed macOS app with the same bundle ID?▼

Move the installed app aside (e.g., rename to Rapture.app.aside) because LaunchServices resolves the shared bundle ID to the installed copy. Then open the Debug build from its derived data path and confirm the running process path with ps.

Why does my debug macOS app stop processing files after launch?▼

App Nap is likely stalling the app's poll loops because a shell-launched app has no window or user input. Wake it by attaching the sample tool (sample <pid> 1) after each file drop, then wait for two poll ticks.

Why does a freshly built macOS app quit after granting Full Disk Access?▼

Each rebuild creates a new bundle signature, so TCC treats it as a new app and re-triggers the FDA prompt; a running process never picks up a new grant, so the app must quit and relaunch. Re-open the app after the grant and the test continues from on-disk state.

Why does log stream return nothing from a sandboxed macOS shell?▼

The sandboxed shell cannot access unified logging output from log show or log stream. Use on-disk state files, output artifacts, and sample stack captures as evidence of app behavior instead.

Can I run a macOS app binary directly instead of using open?▼

No, exec'ing the binary directly skips LaunchServices, so lifecycle hooks like a menu-bar label's .task never fire and the pipeline sits idle. Use open to launch, and pass environment variables via launchctl setenv beforehand.