If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Mortennn/Dozer shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 2y ago

• 6 active contributors
• MPL-2.0 licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 63% of recent commits
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Mortennn/Dozer repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Mortennn/Dozer.

What it runs against: a local clone of Mortennn/Dozer — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Mortennn/Dozer | Confirms the artifact applies here, not a fork | | 2 | License is still MPL-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 922 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Mortennn/Dozer. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Mortennn/Dozer.git
#   cd Dozer
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Mortennn/Dozer and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Mortennn/Dozer(\\.git)?\\b" \\
  && ok "origin remote is Mortennn/Dozer" \\
  || miss "origin remote is not Mortennn/Dozer (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MPL-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MPL-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is MPL-2.0" \\
  || miss "license drift — was MPL-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Dozer/AppDelegate.swift" \\
  && ok "Dozer/AppDelegate.swift" \\
  || miss "missing critical file: Dozer/AppDelegate.swift"
test -f "Dozer/StatusIconClasses/NormalStatusIcon.swift" \\
  && ok "Dozer/StatusIconClasses/NormalStatusIcon.swift" \\
  || miss "missing critical file: Dozer/StatusIconClasses/NormalStatusIcon.swift"
test -f "Dozer/ViewControllers/DozerVC.swift" \\
  && ok "Dozer/ViewControllers/DozerVC.swift" \\
  || miss "missing critical file: Dozer/ViewControllers/DozerVC.swift"
test -f "Dozer/StatusIconClasses/HelperStatusIcon.swift" \\
  && ok "Dozer/StatusIconClasses/HelperStatusIcon.swift" \\
  || miss "missing critical file: Dozer/StatusIconClasses/HelperStatusIcon.swift"
test -f "Dozer/Constants.swift" \\
  && ok "Dozer/Constants.swift" \\
  || miss "missing critical file: Dozer/Constants.swift"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 922 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~892d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Mortennn/Dozer"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Dozer is a macOS menu bar utility written in Swift that selectively hides and shows status icons in the menu bar through a set of interactive Dozer icons. It solves the common macOS problem of menu bar clutter by allowing users to organize icons into two groups—one toggled by left-click, another by option-click—without requiring icon removal from the system. Single-target Swift macOS app: Dozer/AppDelegate.swift is the entry point, StatusIconClasses/ (NormalStatusIcon.swift, HelperStatusIcon.swift, RemoveStatusIcon.swift) defines the three icon types, ViewControllers/ (DozerVC.swift, GeneralVC.swift) manage UI, XIB/ files (Dozer.xib, General.xib) define layouts. Constants.swift centralizes configuration.

macOS users (High Sierra 10.13+) who want a cleaner menu bar by temporarily hiding third-party status icons; power users who accumulate many system utilities like Slack, 1Password, VPN apps, and want quick toggle access without manually hiding each one.

This is an actively maintained, production-ready single-maintainer project with a polished user experience (evidenced by the demo GIF and organized XIB layouts). It has reached Release status on GitHub with version history in CHANGELOG.md. However, test coverage is not visible in the file structure, suggesting limited automated testing infrastructure.

Single-maintainer risk (Mortennn owns the repo). No visible test suite (no Tests/ directory, no CI pipeline files like .github/workflows). The app directly manipulates macOS menu bar via private/undocumented APIs (status icon hiding), which could break on major macOS updates. Dependency management through Cartfile (outdated package manager) rather than SPM poses maintenance friction.

Based on repo structure, active development appears paused—no visible PRs in file list, no .github/workflows CI indicators. Last meaningful activity likely reflected in CHANGELOG.md. The project is in maintenance mode rather than active feature development.

git clone https://github.com/Mortennn/Dozer.git && cd Dozer && open Dozer.xcodeproj — then build with Xcode 12+. Dependencies install via Cartfile (run carthage update if Carthage is installed), though Cartfile.resolved is already committed.

Daily commands: Open Dozer.xcodeproj in Xcode, select the Dozer scheme, press Cmd+R to build and run. The app will launch and appear in the menu bar. Settings accessible via right-click on any Dozer icon.

• Dozer/AppDelegate.swift — Entry point for the application; manages app lifecycle, status items, and the helper app communication—every contributor must understand the overall architecture here.
• Dozer/StatusIconClasses/NormalStatusIcon.swift — Core abstraction for hiding/showing menu bar icons; the primary feature implementation that all UI flows depend on.
• Dozer/ViewControllers/DozerVC.swift — Main view controller managing the UI for controlling which icons are hidden; directly drives user interactions with the status icons.
• Dozer/StatusIconClasses/HelperStatusIcon.swift — Manages the helper app status item visibility and communication; critical for the 'reveal hidden' functionality.
• Dozer/Constants.swift — Centralized configuration and constants used across the codebase; changes here ripple through the application.
• Dozer/Other/Dozer.entitlements — Specifies app sandbox and system permissions required to manipulate menu bar icons on macOS.

• AppDelegate (NSApplication, NSStatusItem, Cocoa) — Orchestrates app lifecycle, initializes status items, manages helper app communication, and coordinates between UI and system
  • Failure mode: If AppDelegate fails to initialize, the entire app crashes; if status item creation fails, no UI is available
• NormalStatusIcon (AXUIElement, Accessibility API) — Encapsulates the logic to hide and show individual menu bar icons via AXUIElement calls
  • Failure mode: If AXUIElement calls fail, icons cannot be hidden/revealed; partial success may leave inconsistent state
• DozerVC (Main UI) (NSViewController, NSTableView, XIB layout) — Displays list of menu bar icons, allows user to select which to hide, and updates in real-time
  • Failure mode: If UI fails to load, user cannot interact with the app; if table view crashes, the app becomes unresponsive
• HelperStatusIcon (NSStatusItem, NSMenu) — Manages a secondary status item that reveals the list of hidden icons without opening the main window
  • Failure mode: If helper item fails, users cannot reveal hidden icons from the menu bar without opening the main app
• Gener — undefined

Add a new menu bar icon to the hide list

1. Open DozerVC.swift and inspect the data structure used to track visible icons and their states (Dozer/ViewControllers/DozerVC.swift)
2. Create or modify a NormalStatusIcon instance with the target icon's metadata (name, position) (Dozer/StatusIconClasses/NormalStatusIcon.swift)
3. Call the hide() method on the icon instance to conceal it from the menu bar (Dozer/StatusIconClasses/NormalStatusIcon.swift)
4. Update the UI in DozerVC to reflect the newly hidden icon in the list (Dozer/ViewControllers/DozerVC.swift)

Add a new user preference setting

1. Define a new constant key in Constants.swift for the preference (Dozer/Constants.swift)
2. Add a corresponding UI control (checkbox, slider, etc.) to the General.xib interface file (Dozer/XIB/General.xib)
3. Implement the preference handler in GeneralVC.swift to read/write the value using UserDefaults (Dozer/ViewControllers/GeneralVC.swift)
4. If the preference affects icon hiding, update AppDelegate.swift or the relevant StatusIcon class to respect the new setting (Dozer/AppDelegate.swift)

Modify the helper app's status item appearance

1. Create or update the icon asset in Assets.xcassets/HelperStatusItemIcon.imageset (Dozer/Other/Assets.xcassets/HelperStatusItemIcon.imageset/Contents.json)
2. Update the HelperStatusIcon class to load and apply the new icon (Dozer/StatusIconClasses/HelperStatusIcon.swift)
3. Reference the icon in DozerIcons.swift to ensure it's properly exported (Dozer/DozerIcons.swift)

• Swift + Cocoa — Native macOS development required for direct menu bar manipulation via AXUIElement and system-level icon access
• NSStatusItem (Status Bar) — Official macOS API for managing status bar icons and interactions
• UserDefaults — Lightweight, built-in persistence for user preferences and hidden icon lists
• Xib/XIB files — Interface Builder support for rapid UI prototyping on macOS without code-heavy constraint management

• Helper app status item for revealing hidden icons

  • Why: Once an icon is hidden, the user needs a way to reveal it; a persistent status item achieves this without cluttering the main app
  • Consequence: Adds complexity to app delegation and requires separate status item state management

• UserDefaults for persistence instead of a database

  • Why: Dozer is a lightweight, single-user macOS utility with minimal data model; UserDefaults is simpler and built-in
  • Consequence: Not suitable for complex data relationships or multi-user scenarios; limited query capabilities

• Direct AXUIElement manipulation instead of Apple Events

  • Why: AXUIElement provides lower-level, more reliable access to individual menu bar icons
  • Consequence: Requires Accessibility permissions and may break with macOS updates if Apple changes internal UI structures

• Cross-platform support (macOS High Sierra+ only; not iOS, Linux, or Windows)
• Real-time synchronization of menu bar state across multiple Macs
• Programmatic creation or modification of third-party app menu bar icons
• Persistent undo/redo functionality for icon hide/show actions

The app relies on macOS private/undocumented APIs for menu bar icon manipulation (status bar position shifting), which Apple does not publicly support—updates to macOS can silently break functionality without warning. No visible code signing or notarization scripts indicate distribution may require additional manual steps. The Objective-C bridging-header.h dependency on private APIs means security/privacy reviews (Gatekeeper, notarization) could flag or reject the app on future macOS versions.

• macOS Status Bar (NSStatusBar/NSStatusItem) — Core to Dozer's functionality; manipulating NSStatusItem position and visibility is the entire point of the app, requiring deep AppKit knowledge
• Private APIs and Undocumented macOS Internals — Dozer likely uses private/undocumented APIs to hide and reorder menu bar icons (not exposed in public NSStatusBar API); understanding Apple's private API risks and detection methods is critical for long-term maintenance
• Swift-Objective-C Interoperability and Bridging Headers — The bridging-header.h file is required to call low-level Objective-C runtime or C APIs for menu bar manipulation; understanding memory management and type marshaling is essential
• macOS App Sandbox and Code Signing — Dozer requires specific entitlements (see Other/Dozer.entitlements) to access menu bar and run as a status bar app; distribution via Homebrew Cask requires notarization and valid signing
• XIB (Interface Builder) vs. Programmatic UI — Dozer uses XIB files (Dozer.xib, General.xib) for layout instead of code; understanding XIB compilation, outlet binding, and constraints is necessary to modify UI
• Event Handling and Responder Chain (AppKit) — Status icons respond to left-click, option-left-click, and right-click with different behaviors; understanding AppKit event delegation and NSResponder is needed to extend interactions
• Launch at Login (LaunchAgent vs. Executable Wrapper) — Scripts/LaunchAtLogin.sh suggests the app supports launch-at-login via SMAppService or legacy LaunchAgent plist; understanding macOS launch mechanisms is needed for onboarding workflow

• dwarvesf/hidden — Alternative menu bar icon hider for macOS with similar core functionality; competing project in same space
• Homebrew/homebrew-cask — Dozer is distributed via Homebrew Cask (brew install --cask dozer); understanding cask maintenance is essential for release workflow
• SwiftLint/SwiftLint — Dozer uses SwiftLint (Sindre flavor) for code style enforcement; repo config in .swiftlint.yml
• Carthage/Carthage — Dependency manager used in Cartfile; understanding Carthage workflows needed to manage framework dependencies
• apple/swift — The Swift language ecosystem; knowledge of Swift 5+ patterns, optionals, and macOS SDK is foundational

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions workflow for automated SwiftLint checks on PRs

The repo has .swiftlint.yml and Scripts/Swiftlint.sh configured, but no CI automation. New contributors won't get linting feedback until manual review. A GitHub Actions workflow would catch style violations early and reduce maintainer review burden.

• [ ] Create .github/workflows/swiftlint.yml that runs Scripts/Swiftlint.sh on push and pull requests
• [ ] Configure the workflow to fail the CI check if SwiftLint violations are found
• [ ] Test the workflow by running it on a branch with intentional style violations

Add unit tests for StatusIconClasses (NormalStatusIcon, RemoveStatusIcon, HelperStatusIcon)

The Dozer/StatusIconClasses/ directory contains three critical status icon implementations with no corresponding test files. These are core to the app's functionality (showing/hiding menu bar icons). Adding tests would improve code confidence and help future contributors avoid regressions.

• [ ] Create DozerTests/StatusIconClasses/ directory structure
• [ ] Add NormalStatusIconTests.swift testing icon visibility toggle and menu interactions
• [ ] Add RemoveStatusIconTests.swift testing removal functionality
• [ ] Add HelperStatusIconTests.swift testing helper status icon behavior
• [ ] Ensure tests compile against the Dozer target

Refactor AppDelegate.swift and create ViewControllerManager to reduce complexity

Dozer/AppDelegate.swift likely contains multiple responsibilities (app lifecycle, status icon management, view controller coordination). The existence of separate DozerVC.swift and GeneralVC.swift suggests coupling. Extracting a dedicated view controller manager would improve testability and maintainability.

• [ ] Create Dozer/ViewControllers/ViewControllerManager.swift to coordinate DozerVC and GeneralVC lifecycle
• [ ] Move view controller instantiation and presentation logic from AppDelegate to ViewControllerManager
• [ ] Update AppDelegate to delegate to ViewControllerManager instead of managing controllers directly
• [ ] Verify all XIB references (Dozer.xib, General.xib) are still properly loaded through the new manager

• Add unit tests for StatusIconClasses/ (NormalStatusIcon.swift, HelperStatusIcon.swift, RemoveStatusIcon.swift) to verify icon click handlers and state transitions—currently zero test coverage visible.
• Migrate from XIB files (Dozer.xib, General.xib) to SwiftUI for modern macOS 11+ support and easier maintenance; non-trivial but isolated to ViewControllers/.
• Add GitHub Actions CI workflow (.github/workflows/ci.yml) to run SwiftLint on commits and build against multiple macOS SDK versions (10.13–latest) to catch API compatibility regressions early.

Dozer is a macOS menu bar utility with a relatively clean security posture. No critical vulnerabilities were identified. Main concerns are around build script integrity, dependency management, and proper configuration of entitlements/Info.plist. The codebase appears to be a native Swift/Objective-C application without web-based injection risks (SQLi, XSS). Recommended improvements focus on validating build scripts, implementing dependency verification, and ensuring entitlements follow the principle of least privilege. The application's limited scope (menu bar icon management) reduces attack surface.

• Medium · Missing Dependency Lock File Verification — Cartfile, Cartfile.resolved. The Cartfile.resolved exists but no integrity checks are visible. Carthage dependencies could be subject to man-in-the-middle attacks if fetched over insecure channels or if the resolved file is not properly validated. Fix: Ensure Carthage dependencies are fetched over HTTPS, verify checksums of resolved dependencies, and consider using a dependency verification mechanism or pinning specific commit hashes.
• Medium · Build Script Execution Without Validation — Scripts/LaunchAtLogin.sh, Scripts/SignFrameworks.sh, Scripts/Swiftlint.sh. Shell scripts in Scripts/ directory (LaunchAtLogin.sh, SignFrameworks.sh, Swiftlint.sh) are executed during build process. No evidence of input validation or code review controls visible. Fix: Review all build scripts for injection vulnerabilities, implement strict input validation, use shellcheck for static analysis, and require code review before modifications to build scripts.
• Low · Bridging Header Without Security Review — Dozer/Other/bridging-header.h. The bridging-header.h file may expose Objective-C APIs directly to Swift code. This could bypass Swift's type safety in certain scenarios. Fix: Review the bridging header contents to ensure only necessary APIs are exposed, minimize the scope of exposed functionality, and prefer Swift-native APIs where possible.
• Low · Entitlements Configuration Not Reviewed — Dozer/Other/Dozer.entitlements. The entitlements file (Dozer.entitlements) defines app sandbox and security permissions but its contents are not visible for security review. Excessive permissions could enable privilege escalation. Fix: Review entitlements to ensure principle of least privilege - only request permissions absolutely necessary for core functionality. Regularly audit entitlements during updates.
• Low · Info.plist Configuration Not Validated — Dozer/Other/Info.plist. The Info.plist may contain configuration that affects app security (LSUIElement, SMPrivilegedExecutables, etc.) but contents are not visible for security validation. Fix: Review Info.plist for overly permissive configurations, ensure LSUIElement and other security-sensitive keys are properly set, and document security-relevant configurations.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.