shopPRO/.claude/commands/koniec-pracy.md

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:

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:

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 docs/TODO.md and append the found issues at the bottom under a new section:

## SonarQube — {VERSION} ({DATE})

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

Rules:

• Only add issues that are NOT already present in 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:

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:

File	When to update
docs/CHANGELOG.md	Always — add a new version entry at the top describing what changed
docs/TESTING.md	If tests were added/removed — update test count and structure
CLAUDE.md	If test count changed — update the "Current suite" line
docs/DATABASE_STRUCTURE.md	If database schema changed
docs/PROJECT_STRUCTURE.md	If architecture/files changed significantly
docs/FORM_EDIT_SYSTEM.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

git push

Step 7: Build update package

Tag the new version and run the build script:

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:

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