# Contributing

This private repository is maintained by OllyGarden employees and approved
collaborators. The generated site is public and serves operational Go module
metadata, so changes require careful path validation.

## Before making a change

- Search current issues and pull requests for overlapping work.
- Confirm the exact module declaration and source repository before adding or
  changing a vanity path.
- Align broad domain, GitHub Pages, or existing-path changes with the owning
  team before implementation.
- Follow the repository contract and validation guidance in `AGENTS.md`.

## Commits and scope

Use Conventional Commits for commits and pull request titles:

```text
<type>(<optional scope>): <short imperative description>
```

Common types are `feat`, `fix`, `docs`, and `chore`. Examples:

- `feat: add lotus module redirect`
- `fix(grafts): correct documentation redirect`
- `docs: refresh module inventory`

Mark breaking changes with `!` before the colon and explain them in a
`BREAKING CHANGE:` footer. Pull requests are squash-merged, so their titles
must also follow Conventional Commits.

Keep one logical change per pull request. Do not include unrelated refactors,
dependency updates, generated changes, or broad formatting. Update the README
inventory whenever a vanity page is added or removed.

## Validation

Always run:

```bash
git diff --check
```

Validate every changed page's `go-import` meta tag, source repository,
pkg.go.dev redirect, and body link. Run the repository-wide vanity-page scan
described in `AGENTS.md`, and check changed relative Markdown links. For a
deployment-sensitive change, verify the live GitHub Pages source and custom
domain. After deployment, inspect the live response with `?go-get=1`.

## Pull requests

Include:

- a summary and motivation;
- the affected vanity path and source repository;
- exact validation commands and results;
- risk and rollout notes, or `None`;
- a linked issue when applicable; and
- matching documentation or configuration updates.

Do not commit secrets, credentials, private source code, customer data, or
production exports. Authors must review and own the correctness and licensing
of work created with automated tools.