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/KrishKrosh/TrackWeight 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 all four use cases

• Last commit 10mo ago
• 5 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 10mo ago
• ⚠ Single-maintainer risk — top contributor 86% of recent commits

_{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 KrishKrosh/TrackWeight repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/KrishKrosh/TrackWeight.

What it runs against: a local clone of KrishKrosh/TrackWeight — 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 KrishKrosh/TrackWeight | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 317 days ago | Catches sudden abandonment since generation |

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

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

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

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

# 4. Critical files exist
test -f "TrackWeight/TrackWeightApp.swift" \\
  && ok "TrackWeight/TrackWeightApp.swift" \\
  || miss "missing critical file: TrackWeight/TrackWeightApp.swift"
test -f "TrackWeight/ContentView.swift" \\
  && ok "TrackWeight/ContentView.swift" \\
  || miss "missing critical file: TrackWeight/ContentView.swift"
test -f "TrackWeight/ScaleViewModel.swift" \\
  && ok "TrackWeight/ScaleViewModel.swift" \\
  || miss "missing critical file: TrackWeight/ScaleViewModel.swift"
test -f "TrackWeight/WeighingState.swift" \\
  && ok "TrackWeight/WeighingState.swift" \\
  || miss "missing critical file: TrackWeight/WeighingState.swift"
test -f "TrackWeight/ScaleView.swift" \\
  && ok "TrackWeight/ScaleView.swift" \\
  || miss "missing critical file: TrackWeight/ScaleView.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 317 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~287d)"
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/KrishKrosh/TrackWeight"
  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).

TrackWeight is a macOS application that converts a MacBook's Force Touch trackpad into a digital weighing scale by accessing raw pressure sensor data through the OpenMultitouchSupport library. It calibrates trackpad force readings (which are already in grams) to measure weight of objects placed on the trackpad while maintaining finger contact. Single-target Xcode project structure: SwiftUI Views (ContentView.swift, HomeView.swift, ScaleView.swift, SettingsView.swift, DebugView.swift) paired with ViewModels (ContentViewModel.swift, ScaleViewModel.swift, WeighingViewModel.swift); core state managed in WeighingState.swift; app entry point in TrackWeightApp.swift. Private framework access handled via custom fork of OpenMultitouchSupport bundled as a dependency.

macOS users with modern MacBooks (2015+ Pro, 2016+ Air) who need a quick, hardware-based weighing solution without external scales; also appeals to developers interested in low-level macOS hardware access and Force Touch capabilities.

The project is actively maintained but early-stage: it's a single-maintainer personal project with a functional release pipeline (DMG builds via GitHub Actions in .github/workflows/build-and-sign-dmg.yml), no visible test suite, and Swift 6.0+ requirement suggesting recent modernization. It's production-ready for its narrow use case but not enterprise-grade.

High single-point-of-failure risk with one maintainer (KrishKrosh); hard dependency on a custom fork of OpenMultitouchSupport (krishkrosh/OpenMultitouchSupport) which could become unmaintained; requires App Sandbox disabled (security trade-off); no test coverage visible means regressions could ship undetected. macOS version constraints (13.0+) and hardware specificity (Force Touch trackpad) limit user base.

The repo shows recent activity with build automation setup (.github/workflows/build-and-sign-dmg.yml for DMG creation) and Swift 6.0 compatibility work. README documents calibration validation methodology. No open PRs or issues visible in file list, suggesting either a stable state or closed issue tracking.

git clone https://github.com/KrishKrosh/TrackWeight.git && cd TrackWeight && open TrackWeight.xcodeproj && xcode-select --install (if needed). Then in Xcode: disable App Sandbox in project settings (TrackWeight.xcodeproj → TrackWeight target → Signing & Capabilities) and build with Cmd+B or run with Cmd+R.

Daily commands: Open TrackWeight.xcodeproj in Xcode 16.0+, ensure App Sandbox is disabled (Build Settings → Code Signing → Entitlements), then press Cmd+R or Product → Run. Application launches as a macOS menu bar app.

• TrackWeight/TrackWeightApp.swift — Application entry point; initializes the app lifecycle and sets up the main window and menu bar integration.
• TrackWeight/ContentView.swift — Root SwiftUI view that orchestrates the primary user interface and navigation between Home, Scale, and Settings views.
• TrackWeight/ScaleViewModel.swift — Core business logic for trackpad pressure-to-weight conversion; interfaces with the OpenMultitouchSupport library to read sensor data.
• TrackWeight/WeighingState.swift — State model that encapsulates the weighing session logic and calibration; shared across ViewModels to maintain consistency.
• TrackWeight/ScaleView.swift — Main UI component that displays real-time weight readings and pressure visualizations; directly binds to ScaleViewModel.
• TrackWeight.xcodeproj/project.pbxproj — Xcode project configuration; manages signing, entitlements, and linking to the private OpenMultitouchSupport framework.
• TrackWeight/TrackWeight.entitlements — macOS entitlements file; grants necessary permissions for trackpad event capture and system-level sensor access.

• ScaleViewModel — Orchestrates sensor polling, interp

Add a new calibration method or unit conversion

1. Define the calibration logic or conversion formula in WeighingState.swift by adding a new stored property and computed property for unit conversion (TrackWeight/WeighingState.swift)
2. Expose the conversion in ScaleViewModel.swift by adding a method that applies the new unit or calibration to the raw pressure reading (TrackWeight/ScaleViewModel.swift)
3. Add UI controls in SettingsView.swift to allow users to select between available calibration methods or units (TrackWeight/SettingsView.swift)
4. Bind the settings selection to ContentViewModel.swift so the chosen method is applied app-wide (TrackWeight/ContentViewModel.swift)

Add a new diagnostic or debug feature

1. Add a new data model or property to WeighingState.swift or ScaleViewModel.swift to capture the metric you want to display (TrackWeight/WeighingState.swift)
2. Add a new SwiftUI component or section to DebugView.swift to visualize the diagnostic data (TrackWeight/DebugView.swift)
3. If the data requires real-time updates, add an @Published property to the appropriate ViewModel and bind it in the debug view (TrackWeight/ScaleViewModel.swift)

Modify sensor data acquisition or pressure interpretation

1. Update the trackpad event polling logic in ScaleViewModel.swift where it interfaces with the OpenMultitouchSupport library (TrackWeight/ScaleViewModel.swift)
2. Adjust the pressure-to-weight mapping algorithm in WeighingState.swift or add a new conversion method (TrackWeight/WeighingState.swift)
3. Test the changes with DebugView.swift to validate raw sensor readings and ensure the conversion is correct (TrackWeight/DebugView.swift)

Update the user-facing scale display or add a new measurement view

1. Create the visual layout in ScaleView.swift or add a new file (e.g., DetailedWeightView.swift) with SwiftUI components (TrackWeight/ScaleView.swift)
2. Bind the view to the appropriate ViewModel (ScaleViewModel.swift or WeighingViewModel.swift) to receive live weight updates (TrackWeight/WeighingViewModel.swift)
3. Integrate the new view into ContentView.swift to make it accessible from the main navigation (TrackWeight/ContentView.swift)

• SwiftUI — Provides native, responsive macOS UI with real-time binding to ViewModel properties for live weight display updates
• Combine framework — Enables reactive data flow from sensor polling to UI updates with @Published properties and observation
• OpenMultitouchSupport (private framework) — Only way to access low-level trackpad pressure sensor data; standard macOS APIs do not expose force/pressure readings
• macOS entitlements & code signing — Required to grant the app permission to capture system-level trackpad events that bypass normal sandboxing restrictions

• Use private OpenMultitouchSupport library instead of public APIs

  • Why: Public macOS APIs (NSTouchBar, NSGestureRecognizer) do not expose trackpad pressure; private library is the only way to read sensor data
  • Consequence: App will not pass App Store review; requires direct distribution via DMG or web download. Fragile to OS updates that change private API signatures

• Calibration and baseline tracking in user session rather than one-time setup

  • Why: Trackpad pressure readings vary with finger moisture, ambient temperature, and wear; per-session baseline allows real-time adaptation
  • Consequence: User must follow specific steps each time (rest finger, then place object); no one-click weighing. Requires user discipline to minimize pressure variance

• Real-time polling loop in ViewModel rather than event-driven callbacks

  • Why: Simplifies state management and allows UI to stay synchronized with a single source of truth
  • Consequence: Continuous CPU usage even when idle; requires manual cleanup of timer/polling threads to avoid memory leaks

• macOS App Store distribution (blocked by use of private APIs)
• Cross-platform support (trackpad Force Touch is MacBook-only hardware)
• High-precision laboratory-grade metrology (consumer trackpad capacitive sensors have ±5–10% tolerance)
• Support for older MacBooks without Force Touch (requires modern trackpad hardware with pressure sensors)

App Sandbox MUST be explicitly disabled in Xcode project settings — if enabled, trackpad pressure data access will fail silently. The OpenMultitouchSupport dependency is a custom fork (not a standard CocoaPod), so building requires the fork to be available and compatible with your Xcode/Swift version. Force Touch pressure readings are only generated when capacitance is detected (finger contact required); this is a hardware limitation, not a bug. Unsigned builds require manual security clearance on first run. macOS version check (13.0+) enforced; older systems will reject the binary.

• Force Touch (Haptic Pressure Sensing) — TrackWeight's entire value proposition relies on understanding how Force Touch sensors in MacBook trackpads measure pressure; this is the hardware substrate being repurposed as a scale
• Private Framework Access via Bridging — TrackWeight bypasses normal App Sandbox restrictions to access OpenMultitouchSupport, a private Apple framework; understanding this pattern is essential for low-level macOS development and explains the security trade-offs
• App Sandbox Entitlements & Disabling — The repo requires App Sandbox to be disabled entirely; understanding what this enables and disables (privacy boundaries, code signing, distribution) is critical for security and distribution decisions
• Capacitive Touch & Conductivity Detection — The core insight—pressure events only fire when conductive objects (finger, metal weights) touch the trackpad—is a capacitance principle; understanding why non-conductive objects don't register is important for users and edge case handling
• MVVM Pattern in SwiftUI — The codebase uses separate ViewModels (ScaleViewModel, WeighingViewModel) paired with Views; understanding this separation is essential for adding features or refactoring
• Sensor Calibration & Linear Regression — The README mentions calibration against a reference scale; understanding the pressure-to-weight mapping (likely linear) and how systematic error is handled is crucial for accuracy improvements
• macOS Menu Bar Applications — TrackWeight runs as a menu bar app (inferred from TrackWeightApp.swift structure), not a traditional windowed app; understanding the menu bar lifecycle and event handling in SwiftUI is needed for UI improvements

• krishkrosh/OpenMultitouchSupport — This is the forked private framework that TrackWeight depends on for low-level trackpad pressure sensor access
• Kyome22/OpenMultitouchSupport — The upstream original library by Takuto Nakamura that krishkrosh's fork is based on; reference for understanding multitouch event capture on macOS
• sysadminmatthieu/Force-Touch-Trackpad — Alternative macOS Force Touch exploration project; useful for comparing pressure sensor APIs and hardware calibration approaches
• Homebrew/homebrew-cask — TrackWeight is distributed via Homebrew Cask (brew install --cask krishkrosh/apps/trackweight); this is the packaging ecosystem
• apple/swift-argument-parser — Not currently in this repo but relevant for building CLI tooling around weight measurement or calibration if needed

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 calibration persistence and validation tests for ScaleViewModel

ScaleViewModel.swift likely handles calibration logic for converting trackpad pressure to weight, but there are no visible test files in the repo. Adding unit tests would validate the pressure-to-weight conversion algorithm, ensure calibration data persists correctly, and prevent regressions as the algorithm evolves. This is critical for accuracy claims.

• [ ] Create TrackWeightTests/ directory with ScaleViewModelTests.swift
• [ ] Add tests for calibration data storage using UserDefaults or Codable persistence
• [ ] Add tests for pressure sensor input normalization and conversion to weight
• [ ] Add tests for edge cases (zero pressure, max pressure, invalid calibration state)
• [ ] Integrate tests into build-and-sign-dmg.yml GitHub Actions workflow

Extract and document the OpenMultitouchSupport fork integration in a separate module

The README mentions a 'custom fork of Open Multi-Touch Support library' but there's no visible integration code or documentation showing how the private trackpad APIs are being called. Creating a dedicated module (e.g., TrackWeight/Core/TrackpadSensor.swift or TrackWeight/Services/TouchDataProvider.swift) with clear documentation would make the codebase more maintainable, help contributors understand the private API surface, and provide a clear boundary for this sensitive integration.

• [ ] Identify trackpad API calls scattered across ContentViewModel.swift, ScaleViewModel.swift, and WeighingViewModel.swift
• [ ] Create TrackWeight/Services/TrackpadSensorManager.swift to centralize all OpenMultitouchSupport interactions
• [ ] Document the private API methods being used, their parameters, and pressure sensor output format
• [ ] Add inline comments explaining why private APIs are necessary (public alternatives unavailable on macOS)
• [ ] Update relevant ViewModels to use the new TrackpadSensorManager singleton

Add integration tests for HomeView, ScaleView, and SettingsView state transitions

The repo has multiple Views (HomeView.swift, ScaleView.swift, SettingsView.swift, DebugView.swift) but no visible integration or UI tests. Adding snapshot or state-transition tests would catch UI regressions, validate that user interactions correctly update view models, and ensure the debugging features in DebugView don't interfere with production behavior.

• [ ] Create TrackWeightUITests/ directory with HomeViewTests.swift, ScaleViewTests.swift, SettingsViewTests.swift
• [ ] Add tests validating navigation between HomeView → ScaleView → SettingsView
• [ ] Add tests for settings persistence (verify SettingsView changes update UserDefaults and reflect in ScaleView)
• [ ] Add tests for DebugView to ensure debug mode can be toggled without crashing
• [ ] Consider adding snapshot tests using SnapshotTesting library for visual regression detection

• Add unit tests for ScaleViewModel.swift weight conversion logic: create TrackWeightTests/ScaleViewModelTests.swift with test cases for pressure-to-grams calibration across known weight ranges (validate against the documented validation process)
• Document the OpenMultitouchSupport integration: add a developer guide explaining how pressure events are captured, which header files to check, and where the force touch bridging happens (currently opaque to new contributors)
• Implement persistent calibration storage: currently calibration is in-memory; add UserDefaults or JSON file persistence in SettingsView.swift / SettingsViewModel so calibration survives app restarts

TrackWeight has a moderate security posture with several concerns. The primary risks stem from reliance on undocumented/private macOS APIs, dependency on a custom third-party fork of OpenMultitouchSupport, and unclear data handling practices around sensitive trackpad sensor data. The application lacks visible documentation on security entitlements, data retention policies, and privacy controls. Build and signing processes

• High · Use of Private/Undocumented APIs — TrackWeight codebase (references in README and likely in main Swift files). The application leverages a custom fork of the Open Multi-Touch Support library to gain private access to mouse and trackpad events on macOS. Using private APIs violates Apple's App Store guidelines and can lead to app rejection, compatibility issues across macOS versions, and potential security vulnerabilities if Apple changes internal implementations without notice. Fix: Evaluate if there are alternative approaches using public macOS APIs. If private API access is necessary, implement robust error handling and version detection to ensure compatibility across macOS versions. Document API version dependencies clearly.
• High · Third-Party Dependency Management Risk — TrackWeight.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved. The project depends on a custom fork of OpenMultitouchSupport. Custom forks may not receive timely security updates, and the fork's maintenance status and security posture are unclear. There is no evidence of dependency pinning or version management strategy visible in the provided file structure. Fix: Verify the fork is actively maintained and regularly audited for security issues. Implement strict version pinning in Package.resolved. Establish a process for regular dependency audits and updates. Consider contributing improvements back to the original project if feasible.
• Medium · Missing Security Configuration Documentation — TrackWeight/TrackWeight.entitlements. The TrackWeight.entitlements file is referenced but no detailed security entitlements configuration is visible. For an application accessing low-level trackpad hardware and potentially user input, proper entitlements and sandboxing are critical. Fix: Review and document all entitlements used. Ensure the principle of least privilege is applied - only request entitlements necessary for functionality. Enable App Sandbox where possible. Add comments explaining why each entitlement is required.
• Medium · Potential Data Handling Concerns — TrackWeight/ScaleViewModel.swift, TrackWeight/WeighingViewModel.swift, TrackWeight/ContentViewModel.swift. The application captures detailed touch pressure data from the trackpad. There is no visible documentation about data retention, privacy policies, or whether this data is transmitted, stored, or logged anywhere. Fix: Implement clear data handling policies. Ensure no trackpad data is persisted without explicit user consent. If data is stored, implement encryption. Add privacy documentation and ensure GDPR/privacy regulation compliance. Include user-facing privacy controls.
• Medium · Build and Signing Process Security — .github/workflows/build-and-sign-dmg.yml, scripts/setup-signing.sh. The build-and-sign-dmg.yml workflow and setup-signing.sh script handle code signing. Without visibility into the actual script contents and signing certificate management, there's a risk of compromised build artifacts or leaked signing credentials. Fix: Ensure signing certificates are stored securely in GitHub Secrets, not in the repository. Implement branch protection rules for main branch. Use ephemeral signing credentials where possible. Audit all GitHub Actions permissions. Document the signing process and key rotation procedures.
• Low · No Visible Input Validation — TrackWeight/SettingsView.swift, TrackWeight/ContentViewModel.swift. While the application primarily interacts with hardware sensors, any configuration inputs or settings from SettingsView.swift may lack proper validation. Fix: Implement strict input validation for all user-provided settings. Use type-safe configurations and validate ranges/formats. Add unit tests for input validation logic.
• Low · Debug Code Exposure — TrackWeight/DebugView.swift. A DebugView.swift file is present in the production codebase, which may contain debug code, logging, or development-only functionality that could expose sensitive information. Fix: Ensure debug views are completely disabled in release builds using preprocessor directives (#if DEBUG). Remove or restrict any sensitive logging. Consider using os_log with appropriate privacy levels instead of print statements.

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.