Make the next step
better for everyone.

Current source access

The application repository is private while public release preparation continues. Invited contributors can use their existing access and repository instructions. Public contribution access is not open yet.

The project’s original source is MIT licensed. Dependencies and bundled components retain their own terms and notices. A source contribution should preserve those notices and avoid adding material you do not have the right to distribute.

Write a useful bug report

Start with what you expected and what actually happened. Give the smallest set of steps that reproduces the problem, along with the app build and operating system. Describe whether the issue persists after resolving any visible host or provider error.

Build and operating system:
What I tried:
Steps to reproduce:
Expected result:
Actual result:
Relevant error, with private data removed:
Does it happen consistently?

Keep code changes focused

1. Explain the problem.

   Describe the behavior that needs to change and the case that exposes it. Read the instructions in the repository you are working in.

2. Preserve working behavior.

   Keep the change scoped and retain unrelated work. Add meaningful verification for the failure being fixed, rather than broad changes that are hard to assess.

3. Make review easy.

   Explain the result, how it was checked, and any remaining limitation. Do not include secrets, generated user state, or unrelated asset changes.

Help beyond code

A clearer setup instruction, an accessible label, a reproducible install check, or a correction to product documentation can be as useful as a code change.

For visual reports, include only the interface area needed to explain the issue. Use fictional or sanitized data and say which build produced the screenshot.