Contributing to Spice

Thank you for helping improve Spice. Start with the issue tracker of the repository that owns the behavior. For cross-repository changes, open the coordination issue in spice-framework/development.

Before implementation

Describe the developer outcome, affected public contract, compatibility and security implications, and the verification evidence the change will add. Public contracts or architecture changes normally require an ADR or RFC.

Change requirements

• Keep source valid, idiomatic Go and generated output deterministic.
• Add meaningful success, failure, boundary, cancellation, and ordering tests where applicable.
• Update documentation, examples, compatibility metadata, and benchmarks when behavior changes.
• Never hand-edit generated or vendored content.
• Run the repository-owned fast gate while iterating and its complete local verification command on the exact commit proposed for merge.
• Report commands actually run; do not describe an unexecuted check as green.

External contributions use conventional issues and pull requests. Maintainers may use a documented direct-main workflow while the project is in single-writer mode, but the same local gate and reviewable-commit standard applies.

Commit and pull request scope

Keep commits bounded and independently understandable. A pull request should state what changed, why, public compatibility effects, tests and executable evidence, and known follow-up work. Repository extraction must preserve useful history and must not delete the prior durable source before the new repository and a clean-room consumer are green.