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/leits/MeetingBar 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.

GO — Healthy across the board

• Last commit 2w ago
• 28+ active contributors
• Distributed ownership (top contributor 26% of recent commits)
• Apache-2.0 licensed
• CI configured
• ⚠ 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 leits/MeetingBar repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/leits/MeetingBar.

What it runs against: a local clone of leits/MeetingBar — 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 leits/MeetingBar | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-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 ≤ 41 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of leits/MeetingBar. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/leits/MeetingBar.git
#   cd MeetingBar
#
# 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 leits/MeetingBar and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-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 "MeetingBar/App/AppDelegate.swift" \\
  && ok "MeetingBar/App/AppDelegate.swift" \\
  || miss "missing critical file: MeetingBar/App/AppDelegate.swift"
test -f "MeetingBar/App/AppStore.swift" \\
  && ok "MeetingBar/App/AppStore.swift" \\
  || miss "missing critical file: MeetingBar/App/AppStore.swift"
test -f "MeetingBar/App/Notifications.swift" \\
  && ok "MeetingBar/App/Notifications.swift" \\
  || miss "missing critical file: MeetingBar/App/Notifications.swift"
test -f "MeetingBar.xcodeproj/project.pbxproj" \\
  && ok "MeetingBar.xcodeproj/project.pbxproj" \\
  || miss "missing critical file: MeetingBar.xcodeproj/project.pbxproj"
test -f ".swiftlint.yml" \\
  && ok ".swiftlint.yml" \\
  || miss "missing critical file: .swiftlint.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 41 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~11d)"
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/leits/MeetingBar"
  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).

MeetingBar is a Swift-based macOS menu bar application that aggregates calendar events from local macOS calendars and displays the next upcoming meeting in the system status bar, with one-click join functionality for 50+ integrated meeting services (Zoom, Teams, Google Meet, etc.). It solves the friction of context-switching between calendar and meeting apps by surfacing meeting details and join links directly from the menu bar. Monolithic Swift app structure: MeetingBar/App/ contains core logic (AppDelegate.swift, AppStore.swift, AppIntent.swift, Notifications.swift), Assets.xcassets holds UI resources, and the project is built as a single Xcode workspace (MeetingBar.xcodeproj). State management likely centralized in AppStore.swift following an app-wide store pattern.

Knowledge workers on macOS (10.15+) who juggle multiple calendar events and meeting platforms daily—particularly remote workers and meeting-heavy professionals who want to join meetings without opening their calendar app or searching for join links.

Production-ready and actively maintained. The project has significant GitHub downloads, is distributed on the Mac App Store (id 1532419400), uses CI/CD workflows (codacy.yml, swiftlint.yml, main.yml), follows structured contribution guidelines, and maintains a CHANGELOG. Recent activity is evident from the organized issue templates and PR template.

Low-to-moderate risk. Primary risks: single-maintainer appearance (Andrii Leitsius in xcuserdata), dependency on macOS Calendar Framework which can shift across OS versions, and reliance on 50+ third-party meeting service URL patterns that may break. No visible test directory suggests limited automated test coverage for edge cases. SwiftLint is configured but test infrastructure isn't obvious in the file list.

Active development with community translation efforts (Weblate integration visible in badge), CI/CD pipeline configured for code quality (Codacy, SwiftLint), and structured issue/PR templates suggesting organized triage. The .all-contributorsrc file indicates organized contributor tracking.

Clone the repo, open the Xcode workspace, and build: git clone https://github.com/leits/MeetingBar.git && cd MeetingBar && open MeetingBar.xcodeproj. Xcode 12+ is required; no package manager dependencies visible (pure Swift/Cocoa), so build directly in Xcode (Cmd+B) or run via xcodebuild -scheme MeetingBar.

Daily commands: Open MeetingBar.xcodeproj in Xcode, select the MeetingBar scheme, press Cmd+R to build and run. The app installs to /Applications and registers as a menu bar application. For CLI builds: xcodebuild -scheme MeetingBar -configuration Release.

• MeetingBar/App/AppDelegate.swift — Entry point and menu bar lifecycle management—essential for understanding app initialization, menu updates, and calendar event polling
• MeetingBar/App/AppStore.swift — Central state management store for meetings, calendars, and user preferences—required to understand data flow and reactive updates
• MeetingBar/App/Notifications.swift — Meeting notification system and reminders—critical for understanding user alerts and meeting join workflows
• MeetingBar.xcodeproj/project.pbxproj — Xcode project configuration and dependency declarations—needed to understand build targets, linked frameworks, and external integrations
• .swiftlint.yml — Code style and linting rules enforced across the codebase—essential reference for code review and contribution standards

• AppDelegate (NSStatusBar, Timer, EventKit) — Manages app lifecycle, menu bar creation, polling timer loop, and event handling for meeting join actions
  • Failure mode: Missing meetings in menu bar if polling fails; menu bar unresponsive if timer blocks main thread
• AppStore (SwiftUI @ObservedObject, Combine, EventKit) — Central state for upcoming meetings, user preferences, calendar sources, notification settings, and vendor detection logic
  • Failure mode: Meeting list stale if calendar fetch fails; incorrect vendor detection if URL patterns don't match
• Notifications (UserNotifications) — Schedules and delivers local reminders for upcoming meetings with configurable lead times
  • Failure mode: Users miss meetings if notifications blocked by system or notification service crashes
• Asset Catalog (Vendor Icons) (NSImage, Asset Catalog) — Provides 50+ meeting service icons for visual identification in menu and meeting list
  • Failure mode: Generic icon displayed if vendor icon missing; loss of visual recognition for meeting type

• System EventKit Calendars → AppStore — Polling fetches upcoming meeting events from all enabled calendars (iCloud, Exchange, local) every 5-10 seconds
• AppStore Meeting List → AppDelegate Menu Bar — ObservedObject binding triggers UI update to display meeting titles and times in menu bar
• AppStore Meeting Details → Notifications — Upcoming meetings with reminder thresholds trigger local notification scheduling
• AppStore Vendor Detection → Asset Catalog + Meeting Item UI — Parsed meeting URL determines vendor type, which selects appropriate icon for display
• User Menu Bar Action → AppDelegate → NSWorkspace — Clicking meeting triggers app delegate to open meeting URL via browser or vendor app

Add Support for a New Meeting Service Vendor

1. Add vendor icon to assets (PNG or SVG format) (MeetingBar/Assets.xcassets/vendor-icons/)
2. Register vendor in AppStore meeting type detection logic (MeetingBar/App/AppStore.swift)
3. Add vendor-specific meeting URL parsing and join logic (MeetingBar/App/AppStore.swift)
4. Update .all-contributorsrc if adding new collaborator (.all-contributorsrc)

Add a New Calendar Source (Exchange, Caldav, etc.)

1. Implement calendar provider adapter in AppStore state management (MeetingBar/App/AppStore.swift)
2. Add calendar sync logic and event fetching in polling loop (MeetingBar/App/AppDelegate.swift)
3. Handle authentication and credential storage in state (MeetingBar/App/AppStore.swift)

Customize Menu Bar Meeting Display or Add New Notification Type

1. Modify menu bar status item formatting in AppDelegate (MeetingBar/App/AppDelegate.swift)
2. Add notification scheduling logic or alert conditions (MeetingBar/App/Notifications.swift)
3. Update AppStore to track new meeting state flags (MeetingBar/App/AppStore.swift)

• SwiftUI + Combine — Native macOS framework for building menu bar UI with reactive state management and minimal dependencies
• EventKit (Apple Calendar Framework) — System-level calendar access supporting iCloud, Exchange, and local calendars without separate authentication
• GitHub Actions CI — Built-in release automation and code quality checks (Codacy, SwiftLint) for maintainability
• Xcode + Swift — Optimized for macOS menu bar apps with direct OS integration for status items and notifications

• Polling calendar every 5-10 seconds instead of event subscriptions

  • Why: Simple to implement, works across all calendar sources (iCloud, Exchange, local), avoids complex event listener setup
  • Consequence: Slightly higher CPU/battery usage on frequent polls; improved reliability and broader calendar support

• Single SwiftUI @ObservedObject AppStore vs. modular state per feature

  • Why: Simpler to manage calendar sync state and meeting list globally; easier for menu bar refresh
  • Consequence: AppStore becomes large monolithic object; could become difficult to test and refactor at scale

• Support 50+ meeting vendors via URL pattern matching rather than native SDK integrations

  • Why: No external dependencies, works offline, supports emerging services, minimal maintenance
  • Consequence: Cannot access vendor-specific meeting features (transcripts, recordings); relies on URL stability

• Does not provide real-time collaboration or in-app meeting experience—delegates to native vendor apps
• Does not sync calendar data to cloud; operates only on local system calendars
• Does not support Linux or Windows—exclusively macOS 10.15+
• Does not provide calendar management UI—read-only display of meetings with join functionality

• Blocking Main Thread in Polling Loop (High) — MeetingBar/App/AppDelegate.swift: If calendar fetch operations (EventKit queries) run synchronously on polling timer, they block menu bar responsiveness and UI updates
• Monolithic AppStore State Object (Medium) — MeetingBar/App/AppStore.swift: Single @ObservedObject managing all app state (meetings, preferences, calendar sync, notifications) reduces testability and modularity; difficult to reason about state mutations
• Vendor Detection via URL Pattern Matching (Medium) — MeetingBar/App/AppStore.swift: String-based pattern matching for meeting URLs is brittle and may miss edge cases; no fallback for new vendor formats or URL changes

• MeetingBar/App/AppDelegate.swift (polling timer) (I/O bound) — EventKit calendar queries executed every 5-10 seconds; repeated calendar syncs may cause latency spikes if many events exist
• undefined (undefined) — undefined

No obvious pod/package dependencies listed, so no Cocoapods or SPM setup needed—pure native macOS APIs. Potential trap: Event Kit framework requires NSCalendarReadUsageDescription in Info.plist (not visible in file list but must be present); if missing, calendar access silently fails. macOS 10.15+ minimum version constraint is baked in—older macOS will not run. Meeting service URL schemes are hardcoded; adding a new service requires updating AppIntent.swift and testing across all scheme variants (zoom.us, zoommtg://, etc.). No visible test fixtures or mocks, so testing meeting service integrations requires manual QA.

• Event Kit Framework — Core to MeetingBar: powers all calendar event fetching, recurring event expansion, and attendee data from macOS Calendar.app; mastering EKEventStore, EKEvent predicates, and observer callbacks is essential for bug fixes.
• URL Schemes (Custom Protocol Handlers) — MeetingBar's integration with 50+ meeting services relies on parsing and launching zoom://, teams://, meet://, etc. URLs; understanding URL component parsing and NSWorkspace.shared.open() is critical for adding/fixing service support.
• NSStatusBar & Menu Bar Integration — MeetingBar's entire UI lives in the menu bar; NSStatusBar, NSStatusBarButton, and NSMenu APIs control the status item display, icon, and dropdown menu behavior.
• UserNotificationCenter — Notifications.swift drives macOS notifications for upcoming meetings; understanding UNUserNotificationCenter, UNNotificationRequest scheduling, and delegate callbacks is necessary for notification feature improvements.
• AppKit State Management Pattern — AppStore.swift likely implements a centralized state container (similar to Redux or MVVM); understanding this pattern is key to adding new features or debugging state sync issues across the menu bar UI and preferences windows.
• macOS Calendar Permissions & Privacy — Event Kit access requires NSCalendarReadUsageDescription entitlement and user permission grant; debugging permission-related issues (e.g., 'no calendars shown') requires understanding Privacy & Security controls and bundle identifiers.
• SwiftLint Rule Enforcement in CI — MeetingBar's .swiftlint.yml and main.yml enforce style rules in the pipeline; PRs will fail if lint violations exist; understanding which rules are enabled (and why) prevents merge friction.

• ianyh/Amethyst — Similar Swift macOS menu bar app architecture; study for NSStatusBar and AppKit UI patterns in production
• matryer/xbar — Cross-platform menu bar plugin system; MeetingBar could adopt similar extensibility for custom meeting services
• Dimillian/IceCubesApp — Modern Swift async/await architecture for macOS; reference for modernizing MeetingBar's event handling if using Swift 5.5+
• orbitdb/orbit-db — While different stack, it showcases decentralized event sync patterns relevant if MeetingBar adds multi-device calendar sync
• swiftlang/swift — Upstream Swift language; MeetingBar should track Swift concurrency (async/await) adoption for Event Kit callbacks

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 vendor icon tests for meeting service detection

The repo integrates 50+ meeting services with vendor icons (amazon_chime_icon, bluejeans_icon, calcom_icon, etc. in Assets.xcassets/vendor-icons/). There's no evidence of unit tests validating that meeting URLs are correctly mapped to their vendor icons. Adding tests would prevent regressions when new services are added and ensure icons display correctly.

• [ ] Create Tests/VendorIconDetectionTests.swift to test meeting URL → vendor icon mapping
• [ ] Add test cases for each vendor icon in Assets.xcassets/vendor-icons/
• [ ] Test edge cases: malformed URLs, new meeting services, case sensitivity
• [ ] Integrate tests into existing .github/workflows/main.yml CI pipeline
• [ ] Document the vendor icon mapping logic if it exists in a model file

Add AppDelegate.swift and Notifications.swift unit tests

MeetingBar/App/AppDelegate.swift and MeetingBar/App/Notifications.swift handle critical lifecycle and user notification logic but no test files are evident in the structure. These components directly impact user experience (menu bar updates, notifications for upcoming meetings). Tests would catch regressions in notification delivery and app lifecycle handling.

• [ ] Create Tests/AppDelegateTests.swift with tests for app launch, menu bar initialization, and permission handling
• [ ] Create Tests/NotificationsTests.swift with tests for meeting reminder notifications, notification timing, and permission requests
• [ ] Mock calendar access and notification center interactions
• [ ] Add tests to .github/workflows/main.yml to run on each PR
• [ ] Reference MeetingBar/App/AppStore.swift as the state management layer to mock in tests

Document and test AppIntent.swift Siri Shortcuts integration

MeetingBar/App/AppIntent.swift suggests Siri Shortcuts support, but there's no documentation in README or CONTRIBUTING.md about this feature, and no integration tests validating the Shortcuts work correctly. This is a valuable but underdocumented feature that could help new contributors and users.

• [ ] Add 'Siri Shortcuts' section to README.md with examples of available intents
• [ ] Create Tests/AppIntentTests.swift to test each Shortcuts intent (join meeting, list meetings, etc.)
• [ ] Add test case to .github/workflows/main.yml that validates Shortcuts compilation
• [ ] Document in CONTRIBUTING.md how to test AppIntent changes locally using Shortcuts app
• [ ] Add a sample Shortcuts workflow (.shortcut file) to repo demonstrating common use cases

• Add automated tests for AppIntent.swift meeting service URL parsing: create a test suite (Tests/ directory missing) that validates correct URL scheme routing for at least 10 major services (Zoom, Teams, Google Meet) to prevent future URL pattern breakage.
• Expand Notifications.swift with delivery time customization: users can set notification timing (15 min, 5 min, at-join) per calendar; currently likely hardcoded. Add preferences UI and conditional notification logic.
• Create a CONTRIBUTING.md guide with step-by-step macOS Event Kit setup for new developers: CONTRIBUTING.md exists but likely lacks concrete Event Kit Framework basics (NSCalendarStore, EKEventStore init, permission handling), which is a blocker for first-time contributors.

MeetingBar demonstrates a reasonable security posture for a macOS menu-bar application. The main concerns are: (1) incomplete dependency information preventing vulnerability assessment, (2) exposure of maintainer email in security policy, (3) user-specific Xcode data in repository, and (4) potential input validation gaps given integration with multiple meeting services. The codebase lacks visible examples of critical vulnerabilities like hardcoded credentials or SQL injection risks. A comprehensive dependency audit and implementation of strict input validation for meeting URLs would significantly improve the security score. The project has a defined security policy with a 48-hour response commitment, which is a positive indicator.

• Medium · Hardcoded Email in Security Policy — SECURITY.md. The SECURITY.md file contains a hardcoded email address (leits.dev@gmail.com) for security vulnerability reporting. This email address is publicly visible in the repository and may attract automated spam or phishing attempts. Fix: Consider using a dedicated security reporting platform (e.g., GitHub Security Advisory, HackerOne) or implement a contact form that doesn't expose the email directly in the repository.
• Medium · Missing Dependency Manifest Information — Package.swift or xcodeproj dependencies section. The provided dependency file content is empty or not included in the analysis. This makes it impossible to verify if the project uses outdated, vulnerable, or malicious dependencies. Swift Package Manager dependencies in Xcode projects should be regularly audited. Fix: Provide a complete list of dependencies and versions. Use swift package resolve to list all dependencies and regularly run vulnerability scanning tools like OWASP Dependency-Check or Snyk.
• Low · Xcode User Data Committed to Repository — MeetingBar.xcodeproj/xcuserdata/. User-specific Xcode configuration files (.xcuserdatad directory) are committed to the repository. These files may contain local machine paths, build settings, or other environment-specific information that shouldn't be shared. Fix: Add the xcuserdata directory to .gitignore to prevent committing user-specific Xcode settings.
• Low · Missing Input Validation Enforcement — MeetingBar/App/ (specific implementation files not visible). No visible input validation patterns detected in the file structure for meeting URL handling and event data. Given that this application integrates with 50+ meeting services, improper URL handling could lead to open redirect or injection vulnerabilities. Fix: Implement strict input validation for all meeting URLs and calendar event data. Use allowlists for supported meeting service domains and validate all URLs before opening them.
• Low · Lack of Code Signing Verification Details — MeetingBar.xcodeproj/project.pbxproj. No evidence of code signing or notarization requirements visible in the build configuration for the macOS application. This could allow installation of tampered versions. Fix: Ensure the application is properly code-signed and notarized by Apple. Add codesign verification in build scripts and document the signing process for contributors.

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.