# shopPRO - Koniec Pracy (release workflow)

Execute the full release workflow for shopPRO. This is a sequential pipeline - each step depends on the previous one succeeding. Stop and report if any step fails.

## Step 1: Run tests

Run the full PHPUnit test suite:
```bash
php phpunit.phar
```
All tests must pass. If any test fails, stop here - do not proceed to commit. Report the failures and wait for instructions.

## Step 1b: SonarQube scan

Run the SonarQube scanner:
```bash
sonar-scanner
```

After the scan completes, query the SonarQube issues via MCP tool `mcp__sonarqube__issues` with `project_key: "shopPRO"` and `resolved: false`. Fetch all open issues (bugs, vulnerabilities, code smells).

Then open `.paul/docs/TODO.md` and append the found issues at the bottom under a new section:

```markdown
## SonarQube - {VERSION} ({DATE})

- [ ] [SEVERITY] FILENAME:LINE - description (rule)
- [ ] ...
```

Rules:
- Only add issues that are NOT already present in `.paul/docs/TODO.md`
- Group by type: first Bugs/Vulnerabilities, then Code Smells
- Skip INFO severity Code Smells - only include MINOR and above
- If there are no new issues, write: `## SonarQube - {VERSION} - brak nowych issues`

## Step 2: Determine version

Read the latest git tag to determine the current version number:
```bash
git tag --sort=-v:refname | head -1
```
The new version is the previous version incremented by 1 (e.g., v0.333 -> v0.334). Use this version number throughout the remaining steps.

## Step 3: Update documentation

Update these docs files **only if** changes in this session affect them.
Do not update files in root `docs/` directory.

| File | When to update |
|------|---------------|
| `.paul/docs/CHANGELOG.md` | Always - add a new version entry at the top describing what changed |
| `.paul/docs/TESTING.md` | If tests were added/removed - update test count and structure |
| `.paul/docs/DB_SCHEMA.md` | If database schema changed |
| `.paul/docs/ARCHITECTURE.md` | If architecture/files changed significantly |
| `.paul/docs/FORMS.md` | If form system was modified |

## Step 4: SQL migrations

If database schema changes were made, create a migration file at `migrations/{version}.sql` (e.g., `migrations/0.334.sql`). Do NOT put SQL files in `updates/` - the build script reads from `migrations/` automatically.

If no DB changes were made, skip this step.

## Step 5: Commit

Stage all relevant changed files (source code, templates, tests, docs, migrations) and commit with a descriptive message. Do NOT stage `.serena/`, `.env`, or credentials files.

Use this commit message format:
```
feat/fix/refactor: concise description of what changed

Longer explanation if needed.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
```

## Step 6: Push

```bash
git push
```

## Step 7: Build update package

Tag the new version and run the build script:
```bash
git tag v0.{VERSION}
powershell.exe -ExecutionPolicy Bypass -File build-update.ps1 -FromTag v0.{PREV_VERSION} -ToTag v0.{VERSION} -ChangelogEntry "{changelog_description}"
```
The `{changelog_description}` should be a short Polish description of the changes (matching the CHANGELOG entry).

## Step 8: Commit and push the package

Stage the generated update files and commit:
```bash
git add updates/0.30/ver_0.{VERSION}.zip updates/0.30/ver_0.{VERSION}_manifest.json updates/versions.php updates/changelog-data.html
git commit -m "build: ver_0.{VERSION} - {short_description}"
git push
git push origin v0.{VERSION}
```

## Step 9: Report summary

Print a summary:
- Version number
- Test results (count, assertions)
- Files changed
- Commit hashes
- Update package path
- Tag name