Contributing to this distribution

Start from the right repository

The application and public landing site have separate repositories and deployment paths. A documentation change belongs in the landing site; application behavior belongs in the Rust/React codebase. Follow the authorization and review process for the repository you can access. The upstream project has its own contribution process and version history.

Preserve responsibilities

Keep business rules out of HTTP transport adapters. Preserve public REST/Connect behavior, authentication and data rules unless a change is explicitly designed and reviewed. Database changes need corresponding SQLite, PostgreSQL and MySQL migrations and tests. Regenerate protocol outputs rather than editing them by hand.

Review before release

Keep changes scoped, include relevant tests, and state what you could not verify. Never use documentation to imply an untested release, a public source grant or permission to deploy. Publishing a website and deploying the application are independent decisions.

Turn the change into a reviewable question

Start with one observed problem and a reproducible example. Identify the owning code path and an existing test before changing implementation. Describe the expected behavior for the successful case and at least one relevant denied, invalid or interrupted case. Use synthetic data in screenshots, fixtures and logs.

• State the user-visible problem and the scope of the fix
• Explain whether API shape, authorization or stored data changes
• Add or update the test that would have caught the original issue
• Review generated files, migrations and documentation if the contract changed
• Include exact verification commands, results and any untested platform or flow

Review protocol and persistence changes together

A renamed field can affect REST JSON, Connect clients, generated TypeScript, MCP tools and saved data differently. Do not infer that compilation proves compatibility. For a database change, inspect the matching migrations and LATEST.sql definitions for SQLite, PostgreSQL and MySQL, then run the appropriate disposable-database tests. Keep a rollback or data-recovery plan with any release that changes persisted state.

Inspect the final diff before handoff

Inspect the actual patch after regeneration and testing. Remove temporary credentials, local data and unrelated formatting changes. Keep publishing or deployment separate from code review; use the repository owner's requested review and CI workflow rather than assuming a push authorizes production changes.

git diff --stat
git diff --check
git status --short