# Support
Use the repository's GitHub interfaces so questions remain searchable and
maintainers receive the right context.
- **Bug or compatibility regression:** open a bug report with a minimal source,
language/theme IDs, Syntaxmate version, bundle version, expected output,
actual output, and `HighlightStatus`.
- **Grammar or theme asset issue:** use the asset issue form and include the
upstream project/revision when known.
- **Feature proposal:** start a feature request describing the general
downstream use case rather than one application's private integration.
- **Security issue:** follow `SECURITY.md`; do not create a public issue.
The public API, documented compatibility boundary, and current release line are
supported. Private modules, serialized tokenizer state, undocumented asset
paths, exact cache behavior, and internal numeric IDs are not compatibility
contracts.
There is no guaranteed response-time SLA for general support. Well-scoped bug
reports and pull requests with oracle evidence are prioritized.