[adamXbot]

Why

Someone who installs privacycommand.app has no way to get the CLI without cloning the repo and running swift build. This PR ships the CLI inside the app and gives both install paths a way to put it on PATH.

It also renames the CLI from auditctl to privacycommand, matching the app and the cask, while nobody has it on PATH yet. "auditctl" is also the name of Linux's audit control tool, which made the command hard to search for.

What changes

Rename.

• The SwiftPM executable product is privacycommand.
• Its targets become privacycommandCLI and privacycommandCLIKit (+ privacycommandCLIKitTests). A target named privacycommand would collide with the app's module and its Sources/privacycommand folder.
• Usage text, --version, the TUI title, CI's smoke test, the issue template and every doc use the new name.

Embedding (Xcode app target). A new Embed command-line tool run-script phase calls privacycommand/Scripts/embed-cli.sh, which follows the existing guest-agent phase:

• builds the SwiftPM product for the app's ARCHS (universal for Release/Archive, the active arch for Debug), using its own scratch path under DerivedData. Sharing .build with the host-only guest build made each one rebuild the whole package every time.
• writes the app's version and the identifier org.privacykey.privacycommand.cli into the binary's __TEXT,__info_plist, so privacycommand --version prints the real version.
• strips the copy (strip -S -x), which takes the universal binary from 15.0 MB to 7.8 MB. strip re-signs a linker-signed arm64 slice, so unsigned builds still run.
  • Stripping at link time with -Xlinker -S -x broke on Xcode 26.6, whose SwiftPM passes -Xlinker values to clang unwrapped. That was this PR's first App CI failure.
• copies the binary to Contents/Helpers/privacycommand and signs it with EXPANDED_CODE_SIGN_IDENTITY, --options runtime, and --timestamp when signing with a real identity. When CODE_SIGNING_ALLOWED=NO (App CI) it skips signing.

Homebrew. packaging/homebrew/privacycommand.rb gains binary "#{appdir}/privacycommand.app/Contents/Helpers/privacycommand".

DMG installs. A new app-menu item, Install Command Line Tool…, sits below Check for Updates… and above Services. It goes in the app's own .commands, because SurfaceCommands is hash-locked shared code.

• It symlinks the embedded binary into /usr/local/bin. If that folder isn't writable (most Macs), it shows the equivalent sudo mkdir -p … && sudo ln -sf … command with a Copy Command button.
• Once the link exists, the item reads Uninstall Command Line Tool…. The item re-checks state whenever the app becomes active.
• It refuses to link from a disk image or an App-Translocated copy.
• It recognises Homebrew's link in /opt/homebrew/bin.
• It replaces a stale link to another copy of the app.
• It never touches a file or link that it didn't create.

The filesystem logic is in Core, in CommandLineTool, with 12 unit tests that use temp directories. CommandLineToolInstaller is the menu and alert layer. Both files are hand-added to the pbxproj.

Docs. README "Get it → Command line" describes the two install paths. The in-app manual, CONTRIBUTING (the build-from-source section stays), privacycommand/README.md, BUILDING.md and .github/ARCHITECTURE.md are updated too.

Verification (on this Mac, ad-hoc signed; no Developer ID cert here)

• swift build, then .build/debug/privacycommand /System/Applications/Calculator.app (CI's smoke test): exits 0.
• swift test: 290 Core tests (4 skipped, as before) and 47 CLI-kit tests, 0 failures.
• xcodebuild of a fresh universal Debug bundle:
  • Contents/Helpers/privacycommand is Mach-O universal (x86_64 arm64) with flags=0x10002(adhoc,runtime) and identifier org.privacykey.privacycommand.cli.
  • The app passes codesign --verify --deep --strict.
  • --version prints privacycommand 0.1.5, both natively and under Rosetta.
• Before the rename, the same pipeline also passed:
  • a Release xcodebuild archive and scripts/verify-archive.py.
  • an unsigned universal build, CI's path.
  • preview against the real outdated casks on this machine.
  • CI's Xcode 26.6 backend, reproduced with swift build --build-system xcode.
• Drove the running app over Accessibility:
  • menu order is About → Settings… → Check for Updates… → Install Command Line Tool… → Services.
  • Install showed "Install the command-line tool from Terminal" with the sudo command for /usr/local/bin/privacycommand. Copy Command put it on the clipboard.
• just lint and just docs-check pass.

Not verified here

• A Developer ID–signed, notarized build. The phase uses the guest agent's identity/flags path, which already ships notarized.
• The in-app Uninstall flow and the Homebrew-link alert, because /usr/local/bin is root-owned here. Both are covered by the CommandLineTool unit tests.
• A real brew install --cask with the new stanza. That needs a release.

Note for in-flight work

Uncommitted CLI work in another worktree (feat/privacy-cli-brew-preview-f18825: upgrade, pkg support) still edits Sources/auditctl/…. Git records this PR's moves as renames, so merging main into that branch should carry its edits into Sources/privacycommandCLI/. New user-facing text there needs the new name.

🤖 Generated with Claude Code