# Support

Thank you for using sqrail. Clear reports help a small project respond well and
turn one person's problem into a durable improvement for everyone.

## Choose the right path

- **Unexpected behavior or incorrect output:** use the
  [bug report](https://github.com/yhay81/sqrail/issues/new?template=01-bug.yml).
- **Unexpected runtime or memory use:** use the
  [performance report](https://github.com/yhay81/sqrail/issues/new?template=02-performance.yml).
- **A change to sqrail's public contract:** use the
  [feature proposal](https://github.com/yhay81/sqrail/issues/new?template=03-feature.yml).
- **Help using sqrail:** use the
  [question form](https://github.com/yhay81/sqrail/issues/new?template=04-question.yml).
- **A suspected vulnerability:** follow the
  [security policy](SECURITY.md) and report it privately. Never disclose it in
  a public issue.
- **A community conduct concern:** follow the private reporting instructions in
  the [Code of Conduct](CODE_OF_CONDUCT.md).

Before filing, search existing issues and read the
[CLI contract](docs/CONTRACT.md). Please reduce examples where practical and
remove credentials, personal information, proprietary SQL, and sensitive data.
Synthetic data that preserves the same shape is especially helpful.

## Scope and response

Support is provided by the community on a best-effort basis; there is no service
level agreement. Complete, reproducible reports are the easiest to investigate.
A quiet issue is not a rejection: additional evidence, a minimal reproducer, or
a focused pull request is welcome.

sqrail intentionally stays narrow. General SQL design, DuckDB internals, agent
framework integration, and operating-system sandboxing may be better handled by
their respective communities. The project will still help identify the right
boundary when the distinction is unclear.