Thanks for helping improve OpenPetsKit. This guide covers local setup, development workflow, tests, and pull request expectations.
- macOS 14 or later.
- Swift 6.0 or later.
- Xcode command line tools.
Check your Swift version:
swift --versionFrom a local checkout, fetch dependencies through Swift Package Manager:
cd OpenPetsKit
swift buildRun the tests before making changes:
swift testSources/OpenPetsKit: Embeddable runtime, IPC, animation, configuration, host UI, pet loading, and bundled pet support.Sources/OpenPetsKit/Resources/Pets: Bundled pet assets, including Starcorn.Tests/OpenPetsKitTests: Unit tests for runtime behavior, IPC, config, pet bundles, UI layout helpers, installer/library behavior, and resource loading.docs: Integration notes for the shared pet system.
The desktop app, CLI, MCP server, assistant setup, and release packaging live in the separate OpenPets repository at https://github.com/alterhq/openpets.
- Create a focused branch for your change.
- Keep changes small and purpose-driven.
- Add or update tests for behavior changes.
- Update
README.mdor other docs when user-facing behavior changes. - Run
swift testbefore opening a pull request.
Prefer minimal, direct changes over large rewrites. If a change affects public APIs, config keys, socket behavior, or pet bundle format, call that out clearly in the pull request.
For the first cloud surface release, review public symbol names before tagging OpenPetsKit as a minor feature release. The matching OpenPets release should replace any local ../openpetskit development dependency with the published OpenPetsKit version before tagging.
- Follow the style already present in the codebase.
- Prefer clear names and straightforward control flow.
- Keep APIs small unless there is a concrete reuse need.
- Avoid adding compatibility layers unless they protect persisted config, shipped behavior, or external integrations.
- Add comments only when they explain non-obvious behavior or constraints.
- Use Swift concurrency and
@MainActorconsistently for AppKit/UI work.
Run the full test suite:
swift testUseful manual checks:
swift test --filter BundledStarcornPetLoads
swift test --filter UnixSocketClientServerFramingWhen changing pet rendering or message layout, add tests for geometry helpers where possible. When changing IPC, command coding, or config behavior, include round-trip or persistence coverage.
Pet bundles must include a pet.json manifest and a spritesheet with an 8x9 atlas layout. Keep contributed assets original or clearly licensed for redistribution.
If you add or modify bundled assets, include provenance and licensing details in the pull request.
OpenPetsKit can open callback URLs from notification actions and communicates over local IPC. Treat URL handling, local socket behavior, and file/archive extraction changes as security-sensitive.
Do not open public issues for vulnerabilities. Report security issues privately to the maintainers.
A good pull request includes:
- A short description of the user-facing or developer-facing change.
- Tests or a clear explanation of why tests were not added.
- Documentation updates for public APIs, config, pet bundle behavior, or integration guidance.
- Screenshots or a short screen recording for visible UI changes.
- Notes about security-sensitive behavior, migration concerns, or compatibility impacts.
Before requesting review, confirm:
swift testpasses.- New files do not include secrets, local machine paths, or generated build output.
.build/,.swiftpm/, Xcode user data, and other local artifacts are not committed.
Please include:
- macOS version.
- Swift version.
- How you installed or launched OpenPetsKit.
- Steps to reproduce the issue.
- Expected and actual behavior.
- Relevant logs or terminal output.
- Whether the issue involves runtime hosting, IPC, config, pet assets, or rendering.
Please describe the problem you want solved, the proposed behavior, and whether it affects public APIs, config, pet assets, socket behavior, or the embedded UI.