Development Workflow

Scope Split

Product code and repository documentation changes use PRs. Infrastructure and operational work uses GitHub issues as OPS logs.

Product code includes theme files, Twig, CSS/SCSS, JavaScript, PHP, modules, extensions, docs, build pipeline, and architecture docs.

OPS work includes OpenCart installs, web server configuration, PHP-FPM, database, SSL, permissions, storage, cron, dependency installation, server paths, and vhosts.

Branch Naming

Use short, descriptive branch names with a type prefix:

• chore/... for maintenance and repository setup.
• docs/... for documentation-only changes.
• feature/... for theme or user-facing functionality.
• fix/... for bug fixes.

Commit Convention

Use concise conventional-style commit messages:

• chore: initialise project foundation
• docs: update development workflow
• feature: add product card template
• fix: correct oc3 template path

PR Workflow

1. Create a branch from latest main.
2. Keep the scope small and focused.
3. Commit the intended changes only.
4. Push the branch.
5. Open a PR to main.
6. Fill in Summary, Changed Files, Validation, and Notes.
7. Address review feedback in the same PR branch.

Review Process

Codex performs implementation through PRs. ChatGPT owns architecture and review guidance. The user can ask проверь PR #X; ChatGPT reads the PR, diff, and comments directly in GitHub.

Merge Policy

Merge only after ChatGPT approval. The preferred merge method is squash. Do not merge unreviewed implementation changes into main.

OPS Workflow Pointer

Operational work should be logged in GitHub issues using docs/ops-workflow.md. Do not open PRs for server state when repository code does not change.