ThreadMesh is currently specification-and-conformance-first. The repository also contains an experimental runtime, but contributions should turn observed behavior into portable semantics and negative tests rather than expanding the prototype without a protocol boundary.
- Read the vision, scope, and design principles.
- Search existing issues and Architecture Decision Records.
- Read the current status and mainline plan.
- Open a design issue before proposing a protocol-breaking change or a new coordination intent.
- Keep one pull request focused on one coherent outcome.
- Editorial: clarity, grammar, navigation, examples; no semantic change.
- Specification: protocol fields, operations, lifecycle, or required behavior.
- Safety: permissions, consent, privacy, threat mitigations, or defaults.
- Adapter: harness-specific mapping or conformance behavior.
- Implementation: reference runtime, SDK, CLI, inspector, or tests.
Specification and safety changes should include:
- the use case and failure mode;
- compatibility impact;
- security and context-sovereignty impact;
- at least one positive and one negative example;
- an ADR when the decision is durable or difficult to reverse.
- Use plain, precise language.
- Use MUST, SHOULD, and MAY only for normative protocol requirements.
- Distinguish current behavior from proposals.
- Do not claim compatibility with a harness without a testable adapter or primary-source reference.
- Do not close a normative issue with trusted-process prototype evidence alone.
- Prefer small examples that expose failure behavior, not only the happy path.
- Use imperative, descriptive commit subjects.
- Explain why the change is needed in the pull request body.
- Link the issue or ADR when applicable.
- Update
CHANGELOG.mdfor user-visible changes after versioning begins.
By participating, you agree to follow the Code of Conduct.