tensor/CONTRIBUTING.md

# Contributing

Contributions to **Tensor** are governed by the Contributor terms
below; submitting one means you accept them.

## Contributor terms

1. This project belongs to its owner alone. The owner decides what is
   accepted, in what form and when; the decision is final and needs no
   justification.
2. By submitting a contribution you assign to Petr Balvín
   <opensource@petrbalvin.org> all present and future copyright and
   related rights in it, worldwide, for the full term of the rights,
   with the right to relicense and sublicense without restriction,
   including under proprietary terms.
3. Where that assignment is not effective, it counts as a perpetual,
   irrevocable, royalty-free licence with the same scope.
4. To the fullest extent permitted by law, you waive any right of
   attribution and integrity in the contribution. The project names no
   contributors and keeps no credits list.
5. By submitting you represent that the work is yours and that you
   hold the rights to assign it as above.

## Development setup

Requirements: Go 1.27.1 or newer (the version `go.mod` pins), and
[just](https://github.com/casey/just) for the recipes. A C compiler is
needed for the race detector, which `just test`'s sibling `just race`
and `just gates` run.

```sh
git clone https://sourcedock.dev/petrbalvin/tensor.git
cd tensor
just build
just test
```

The module has zero third-party dependencies: the standard library
covers everything, and a new dependency needs a reason that survives
review.

## Workflow

1. Branch from `development`. Never commit directly to `main`, which is release-only.
2. Commit in [Conventional Commits](https://www.conventionalcommits.org/) form:
   `type(scope): description`, subject line only, imperative mood, lowercase after the
   colon, no trailing full stop. Allowed types: `feat`, `fix`, `docs`, `style`,
   `refactor`, `perf`, `test`, `chore`, `ci`, `build`, `revert`.
3. One logical change per commit. A refactor, a behaviour change and a formatting pass
   are three commits, never one.
4. Record every user-visible change in `CHANGELOG.md` under `## [development]`.
5. Add or update tests. Coverage stays at 80 percent or more; it is a hard gate.
6. Update the documentation when the public API, the configuration or the behaviour
   changes. The reader-facing reference is `docs/API.md`, one section per package, and
   a new exported symbol belongs in it.
7. Open a pull request against `development`.

Releases are cut by merging `development` into `main` and tagging `vX.Y.Z`. The release
workflow runs the gates at the tag and publishes the release with its notes.

## Code style

`gofmt` and `go vet` run through `just fmt` and `just vet`, with zero diff and zero
warnings tolerated. `just gates` is the definition of done in one command, and the recipe
file names what it contains. Errors are checked explicitly, wrapped with `%w` so the
cause stays inspectable, prefixed `tensor: ` so the origin is always the library's, and
nothing panics outside `main`. The `golang` skill holds the rules the project follows;
the recipe file holds the commands.

New source files open with the project's two-line licence header, whose SPDX
identifier matches `LICENSE`. Configuration files, workflows and dotfiles do not carry
it.

## AI contribution policy

AI tools are welcome as productivity aids and are a normal part of modern software
development. What matters is that the contribution stays understandable, reviewable and
genuinely useful.

- **Disclose the assistance.** If AI helped draft any part of a commit, issue, pull
  request or review, say so.
- **Commit messages carry exactly one trailer**, on the line after the subject:

  ```
  Assisted-by: GLM 5.3
  ```

  Name the model that did the work, spelled the way its maker spells it, for example
  `GLM 5.3`, `DeepSeek V4.1 Flash` or `Qwen 3.8 Flash`. No `Co-Authored-By`, no `Signed-off-by`,
  no other trailers, and no prose: the trailer is the disclosure.
- **Issues and pull requests** attribute the assistance in a comment, for example
  `_Assisted-by: GLM 5.3_`. It does not belong in the pull request description.
- **Take responsibility.** You are accountable for the accuracy, completeness and
  intent of everything you submit, whether or not AI produced it.
- **Review before marking ready.** Read the diff carefully, run it locally, and add the
  tests it needs. Do not mark a pull request ready until you can defend every change in
  it.
- **Quality over quantity.** Contributions that look like un-reviewed output, or whose
  author cannot engage substantively during review, may be closed.
- **Preferred models.** Prefer open-weight models with transparent training data and
  minimal output filtering.

AI assists. It does not replace judgement.

## Continuous integration

Workflows live in `.gitea/workflows/` and run on the project's own runners:

| Workflow | Trigger | What it does |
|---|---|---|
| Test | push or pull request to `development` | build, format check, vet, the test suite with the coverage floor, the oracle digests and a benchmark smoke run |
| Race | dispatched by hand | the suite under the race detector, with the oracle digests across glibc and musl |
| Release | a `v*` tag | the same gates minus race at the tag, then the release with its notes from `CHANGELOG.md` |

The local equivalent is `just gates`, which is the same set plus the race detector in
one command.

## Reporting bugs

Open an issue at `https://sourcedock.dev/petrbalvin/tensor/issues` with the
version, the operating system and architecture, the exact command, the full output,
and the expected against the actual behaviour.

**Security issues do not go in the issue tracker.** Report them as
[SECURITY.md](SECURITY.md) describes.