# Versionado semántico y Conventional Commits

## Fuente de verdad

La versión del producto vive en:

```txt
project/VERSION
```

Los `package.json` del monolito deben mantenerse sincronizados con ese valor.

## Conventional Commits obligatorios

Formato:

```txt
<type>[optional scope][!]: <description>
```

Tipos permitidos:

- `feat`
- `fix`
- `docs`
- `chore`
- `refactor`
- `perf`
- `test`
- `build`
- `ci`
- `style`
- `revert`

Ejemplos:

```txt
feat(orders): add awaiting-payment notifications
fix(monolith): clean stale deployments before start
chore(release): v0.2.0
```

## Herramientas Orquestra

Validar un mensaje:

```bash
python3 scripts/validate_conventional_commit.py --message "fix(monolith): clean stale deployments"
```

Instalar hook local de Git:

```bash
./scripts/install_git_hooks.sh
```

Bump semver:

```bash
python3 scripts/version.py bump patch
python3 scripts/version.py bump minor --commit --tag
python3 scripts/version.py bump major --commit --tag
```

Ver versión actual:

```bash
python3 scripts/version.py show
```

## Cierre de features

`scripts/commit_feature.sh` genera commits convencionales automáticamente usando el tipo del ticket:

- `feature` → `feat(...)`
- `fix` / `bug` → `fix(...)`
- `chore` → `chore(...)`

`verify.sh` valida:

- `project/VERSION` como semver.
- `package.json` sincronizados.
- último commit compatible con Conventional Commits.