# Development Workflow & GitHub

## Attribution Policy

**NEVER** attribute any commit, PR, code, or work to Claude, AI, or any automated tool.
- No `Co-Authored-By` lines mentioning Claude or AI
- No "Generated by AI" or similar notes in PR descriptions
- No references to AI assistance in commit messages, comments, or code
- All work is attributed solely to the developer

## Branch Strategy

Every feature, fix, or change gets its own branch off `main`:

```bash
git checkout main
git pull origin main
git checkout -b <branch-name>
```

Branch naming:
- `feat/<short-description>` — new features
- `fix/<short-description>` — bug fixes
- `refactor/<short-description>` — refactoring
- `docs/<short-description>` — documentation changes

## Commits

Commits must be **focused and atomic** — one logical change per commit.

Commit message format:
```
<type>: <concise summary in imperative mood>

<optional body explaining why, not what>
```

Types: `feat`, `fix`, `refactor`, `docs`, `chore`, `perf`

Rules:
- Keep the summary line under 72 characters
- Use imperative mood ("add filter" not "added filter")
- The body explains *why* the change was made when it's not obvious
- Do not bundle unrelated changes
- Do not include `Co-Authored-By` lines

## Pull Requests

PRs are reviewed by experienced developers. Quality matters.

### Creating a PR

```bash
git push -u origin <branch-name>
gh pr create --title "<type>: <summary>" --body "$(cat <<'EOF'
## Summary
<1-3 bullet points explaining what and why>

## Changes
<list of specific changes made>

## Testing
<how this was tested>
EOF
)"
```

### PR Standards

- **Small and focused** — one concern per PR. If a PR touches unrelated areas, split it.
- **Clear title** — follows the same `<type>: <summary>` format as commits
- **Descriptive body** — reviewers should understand the change without reading every line of code
- **No noise** — don't include formatting-only changes, unrelated refactors, or generated files unless that's the point of the PR

### Merging

After the user approves:

```bash
gh pr merge <pr-number> --squash --delete-branch
```

Use `--squash` for feature branches to keep main history clean. Use `--merge` only when individual commits are meaningful.

After merging, update local main:

```bash
git checkout main
git pull origin main
```

## Workflow Checklist

1. Create branch from up-to-date `main`
2. Make focused changes
3. Commit with clear message (no AI attribution)
4. Push branch and create PR
5. Address review feedback if any
6. Merge when approved (squash by default)
7. Clean up: switch to main, pull, delete local branch

## What NOT to Do

- Do not push directly to `main`
- Do not create PRs with dozens of unrelated changes
- Do not reference AI, Claude, or automated tools in any git metadata
- Do not amend published commits without explicit instruction
- Do not force-push without explicit instruction
- Do not include generated binary files (APKs, .dm files) in PRs unless specifically requested
