CONTRIBUTING.md
Rama main · réplica de lectura del repositorio original.
# Contributing to oc8
Thanks for considering a contribution. This document covers the legal and
process basics; for the actual "how do I build and test this" guide, start
at [docs/contributing/index.md](docs/contributing/index.md).
## Code of Conduct
All project participants are expected to follow
[CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).
## Developer Certificate of Origin
oc8 uses the [Developer Certificate of Origin](https://developercertificate.org/)
(DCO) instead of a Contributor License Agreement. It's the same lightweight
mechanism used by the Linux kernel, Docker, and many other open-source
projects: you certify that you wrote the contribution (or otherwise have
the right to submit it) by adding a `Signed-off-by` line to every commit,
using your real name:
```
Signed-off-by: Jane Doe <jane@example.com>
```
`git commit -s` adds this automatically. A pull request whose commits lack
a sign-off will be asked to add one (`git commit --amend -s` for the last
commit, or `git rebase --signoff <base>` for a whole branch) before it can
be merged.
No copyright is assigned to the project — you keep it. By submitting a
contribution you license it under the same terms as the code it changes:
**LGPL-3.0-or-later** for `backend/` and `frontend/` (see
[LICENSE](LICENSE)), or the license already declared
in a capa's own manifest for a change under `capas/`.
## Opening a pull request
1. Fork or branch, make your change, and follow
[Coding Guidelines](docs/contributing/coding-guidelines.md) and
[Git Guidelines](docs/contributing/git-guidelines.md).
2. Sign off every commit (see above).
3. Run the full check locally before opening the PR — lint, type-check,
and the full test suite (`backend/`: `python -m pytest && python -m
ruff check src tests`; `frontend/`: `npm run lint && npm run test:unit
&& npm run build`). A PR that doesn't pass locally won't pass CI either.
4. Describe **why**, not just what, in the PR description. If the change
touches core (`backend/src/oc8/`, `frontend/src/`) rather than a capa,
say which mechanism it adds or fixes and why it couldn't be a capa
instead — see the
[microkernel principle](docs/contributing/architecture.md#the-microkernel-principle).
## Reporting a bug
Open an issue with: what you expected, what happened instead, and the
smallest reproduction you can manage. If the bug is in a specific capa
rather than core, say so — it changes who's likely to pick it up.
## Reporting a security vulnerability
Do not open a public issue. Follow [SECURITY.md](SECURITY.md) instead.
## Building a capa instead of changing core
If you're building a connector, an MCP tool bridge, a runtime adapter, a
model provider, an approval channel, or a data-only bundle, you generally
don't need to touch core at all — see
[Developer documentation](docs/developer/index.md) and
[capas/README.md](capas/README.md).