Contributing

Semwright is development software. Contributions should make a narrow operation more reliable, more inspectable, or easier to verify,not simply make the surface larger.

Before changing code

Read the product repository’s CONTRIBUTING.md, VERIFY.md, architecture notes and the release blockers for the revision you are working against. The website links to a frozen product snapshot; the product repository remains the authority for engineering contribution rules.

A useful contribution starts with an observable failure or missing capability. Preserve the distinction between implementation, automated evidence and live-environment support.

The design constraints

A frontend must not bypass the broker. A provider must not gain authority from its own metadata. A stale reference must not be silently repaired into a different target. An uncertain mutation must not be retried through a broader backend just to make a demo succeed.

Security-sensitive changes should gain a regression fixture. New driver capabilities should be typed, versioned and deliberately narrower than arbitrary code execution.

Verify what you touched

Run the repository’s documented gates for the affected area and report the exact commands and environment. Do not turn a missing dependency into a passing test, and do not describe a headless fixture as live desktop evidence.

For website contributions, run the website’s check, unit tests, production build and browser tests. Private working notes under dummy-docs/ never belong in Git.

Where to start

The public source and current contribution policy live on GitHub. Pick a concrete boundary from the issue tracker or release blockers, reproduce it, then make the smallest change that can be verified.

Source: product contribution guide, reviewed 22 September 2026.