# Contribute a reviewable change

Change the owning source, update the public explanation and bring evidence for the behavior you touched.

Source context: Source-guided
Source: https://github.com/lssm-tech/contractspec/blob/d58fa5b7de53a947811e5cc68346be028ce18528/CONTRIBUTING.md

## Read the instructions for the selected checkout

Begin with the repository's AGENTS.md and the instructions in the owning package. The integration branch is actively changing, so locate the current owner rather than relying on a historical directory map.

Keep the problem statement small: the incorrect behavior, why it matters, the intended change and the compatibility impact. A focused issue or pull request is easier to review than a large cleanup tied to an unrelated feature.

## Change the owning source

Application routes are thin wrappers; reusable docs and marketing bodies live in their bundles. Portable contract declarations, runtime execution and provider integrations have different owners. Respect those boundaries when choosing where a fix belongs.

For generated docs or agent configuration, update the canonical input and use the existing generator. Hand-editing a generated file can hide the problem until the next regeneration.

| Change | Likely owning source | Accompanying update |
| --- | --- | --- |
| Learning article | Library docs content and manifest | Navigation, related links and metadata |
| Contract declaration | Canonical model or domain package | Reference docs and compatibility examples |
| Runtime behavior | Owning runtime or adapter | Focused behavior and failure tests |
| Published package change | Owning package | Release notes/capsule through the current workflow |

## Bring the evidence that matters

Run the narrow checks required by the checkout for the changed area. Include a meaningful failing case when behavior is fixed. If a change affects a public package boundary, distinguish source tests from emitted declarations and an isolated consumer.

Report commands actually run and any blocked checks. Do not describe a source reading, a stubbed provider or a metadata smoke test as a production qualification.

## Explain the result to the next maintainer

A useful change description leads with the problem, then explains the new behavior and its validation. Mention intentional compatibility changes and the migration path. Keep unrelated reformatting and architectural moves out of the same review.

The repository's contribution guidance calls for paired changeset and release-capsule records for published-package release work. Follow the current release workflow in the chosen checkout rather than copying old command sequences from a different branch.