# Spec: OSS-Ready — Part 2: CI/CD + GitHub Templates

> Source PRD: `.vibeflow/prds/oss-ready.md`

## Objective

Automatizar qualidade (CI em todo push/PR) e publicação no PyPI, e padronizar a contribuição com templates de issues e PRs.

## Context

O repo já tem um workflow `docs.yml` para deploy de documentação. Não existe CI para testes/lint/typecheck — qualquer PR pode quebrar o código sem ninguém perceber. O Trusted Publisher do PyPI já está configurado (arandu → pe-menezes/arandu, workflow publish.yml, environment pypi). Faltam templates para issues e PRs.

## Dependencies

- `.vibeflow/specs/oss-ready-part-1.md` — pyproject.toml precisa estar atualizado (URLs, email) antes do publish workflow rodar.

## Definition of Done

1. **CI roda em push/PR** — Workflow `.github/workflows/ci.yml` executa pytest, ruff check, ruff format --check, e mypy em Python 3.11 e 3.12.
2. **Publish workflow existe** — `.github/workflows/publish.yml` publica no PyPI via Trusted Publishers quando uma release é criada no GitHub.
3. **Bug report template funciona** — `.github/ISSUE_TEMPLATE/bug_report.yml` com campos: description, steps to reproduce, expected behavior, environment.
4. **Feature request template funciona** — `.github/ISSUE_TEMPLATE/feature_request.yml` com campos: problem, proposed solution, alternatives considered.
5. **PR template existe** — `.github/PULL_REQUEST_TEMPLATE.md` com checklist: description, tests, lint, breaking changes.

## Scope

- Criar `.github/workflows/ci.yml`
- Criar `.github/workflows/publish.yml`
- Criar `.github/ISSUE_TEMPLATE/bug_report.yml` (YAML form, não markdown)
- Criar `.github/ISSUE_TEMPLATE/feature_request.yml` (YAML form)
- Criar `.github/PULL_REQUEST_TEMPLATE.md`

## Anti-scope

- NÃO modificar `docs.yml` existente
- NÃO adicionar codecov/coverage reporting
- NÃO adicionar pre-commit hooks
- NÃO adicionar dependabot/renovate
- NÃO criar workflow de release notes automáticas
- NÃO usar matriz com OS (ubuntu-only é suficiente)
- NÃO rodar testes com Postgres real (todos usam mock)

## Technical Decisions

| Decisão | Escolha | Justificativa |
|---------|---------|---------------|
| CI matrix | Python 3.11 + 3.12 no ubuntu-latest | pyproject.toml declara >=3.11; testar nas 2 versões estáveis |
| CI trigger | push to main + pull_request | Padrão; PR verifica antes de merge, push garante main limpo |
| Publish trigger | `on: release: types: [published]` | Padrão PyPI; tag-based é alternativa mas release é mais explícito |
| Publish method | Trusted Publishers (OIDC) | Já configurado no PyPI; sem tokens para gerenciar |
| PyPI environment | `pypi` | Configurado no Trusted Publisher |
| Issue templates | YAML forms (não .md) | UX melhor: campos estruturados, dropdowns, validação |
| Build tool no publish | `hatchling` via `python -m build` | Já é o build backend do projeto |

## Applicable Patterns

Nenhum `.vibeflow/patterns/` existe. Convenções inferidas:
- Workflow existente (`docs.yml`) usa `actions/checkout@v4`, `actions/setup-python@v5`, `actions/cache@v4`
- pip install com `pip install -e ".[dev]"` para testes

## Risks

| Risco | Mitigação |
|-------|-----------|
| Testes falham no CI por dependência não declarada | CI instala `pip install -e ".[dev]"` — mesmo comando do dev local |
| mypy falha no CI por tipagem incompleta | mypy já roda local com strict; se passa local, passa no CI |
| Publish falha por Trusted Publisher mal configurado | Já verificado: screenshot confirma config correta no PyPI |
| Rate limit no PyPI em primeiro publish | Improvável para projeto novo; retry manual se necessário |

## Budget

5 arquivos: `ci.yml`, `publish.yml`, `bug_report.yml`, `feature_request.yml`, `PULL_REQUEST_TEMPLATE.md`
