# Contributing

Contributions should make the field kit safer, clearer, more testable, or easier to adapt without tying it to one vendor.

## Before proposing a change

1. State the operator problem and the observable improvement.
2. Link first-party evidence for time-sensitive product, version, pricing, or capability claims.
3. Keep examples free of secrets, customer data, proprietary training material, and signed URLs.
4. Add or update a failure case when behavior or authority changes.
5. Preserve the distinction between facts, inference, proposals, and unknowns.

## Review checklist

- [ ] The change is newly authored or its compatible source and attribution are documented.
- [ ] The smallest required authority is explicit.
- [ ] Consequential actions show the exact target and payload before confirmation.
- [ ] Missing, stale, conflicting, and adversarial inputs fail visibly.
- [ ] Links and version claims have a review date.
- [ ] Templates remain usable as plain Markdown.

Open an issue for structural proposals. Keep pull requests focused on one problem and include the evidence used to verify the result.