Contributing

Please start with the protocol and current release status. This repository values reproducible counterexamples and precise scope over claims that a model is generally reliable.

For a new example, provide the original requirement, complete relevant material, expected outcome, and why a competing outcome is unsupported. Label synthetic observations and fixture assessments explicitly. Keep private data, credentials, machine paths, and proprietary source code out of issues and pull requests.

For benchmark changes, preserve existing item identities and version any change in meaning. A disputed key needs an argument from the supplied premises, not a vote among models. Do not rewrite historical results after changing the packet. New translations and sanitized payloads require their own identity and hashes.

For an integration claim, identify the actual runtime, how the final return is intercepted, which boundaries are enforced, and what was demonstrated. Mock tests do not establish runtime isolation or reduced lead usage.

Run the offline tests and repository checks before submitting a change. Schema validation has an explicit development dependency. No live API call belongs in an ordinary pull request check.

Write documentation in complete English sentences. Keep headings and diagrams readable, avoid decorative punctuation, and explain technical terms when first introduced. Reports should distinguish observation, inference, proposal, and unmeasured behavior.