sync

.github/copilot-instructions.md

@@ -112,6 +112,17 @@ Top-level directories (one level down):
 - Prefer frontend changes inside features/<domain>/ and keep API calls in services/.
 - Trust these instructions and only search the repo if something is missing or contradicts these notes.
 
+## Branching and Release Policy
+
+The repository uses the following branch layout by default:
+
+- `main` — stable, reflects the last tagged release. Protected and only updated via PRs that have passed CI and reviews.
+- `develop` — integration branch for active development. Feature branches should branch from and be merged into `develop`.
+
+Release and hotfix branches follow `release/vX.Y` and `hotfix/vX.Y.Z` naming; tags should use semantic versions like `v1.2.3`.
+
+When preparing a new release, create `release/vX.Y` from `develop`, finish testing, then merge into `main` and tag. Merge the release branch back into `develop` afterwards.
+
 ## Chat Tools (LLM Function Calling)
 
 To add a new chat tool:

.github/workflows/code-quality.yml

@@ -2,9 +2,9 @@ name: Code Quality Checks
 
 on:
   pull_request:
-    branches: [ main ]
+    branches: [ main, develop ]
   push:
-    branches: [ main ]
+    branches: [ main, develop ]
 
 jobs:
   backend-checks:

INSTALL.md

@@ -95,3 +95,13 @@ If you want to modify the code, contribute to the project, or just prefer runnin
    Then open `http://127.0.0.1:8000` in your browser.
 
 For hot-reloading during development, see the Development Workflow section in the `README.md`.
+
+### Branching notes for contributors
+
+When contributing, branch from `develop` and open pull requests against `develop` (unless the change is an urgent fix to `main`).
+
+- Feature branches: `feature/<short-desc>`
+- Release branches: `release/vX.Y` (short-lived)
+- Hotfix branches: `hotfix/vX.Y.Z` (branch from `main`)
+
+The `main` branch always reflects the last release; `develop` is the integration branch used for ongoing development.

README.md

@@ -144,3 +144,22 @@ To maintain visual consistency across your project, you can configure **Project
 4.  **Additional Information**: Add specific technical parameters or LoRA triggers (e.g., "<lora:my_style:0.8>, dark lighting, no humans"). These details are appended to the generation prompt to ensure your specific generation pipeline rules are followed.
 
 When you click "Create Prompt" for an image, the AI will intelligently fuse your image's specific description with your global style and additional parameters into a single, optimized prompt line.
+
+## Branching Strategy
+
+This repository uses a simple Git Flow variant to keep releases stable while allowing ongoing development:
+
+- `main` — the stable branch that always reflects the last tagged release. Protected; merges to `main` should be done only via reviewed PRs and after passing CI.
+- `develop` — the integration branch for ongoing development. Feature branches are branched from and merged into `develop`.
+- `release/vX.Y` — short-lived release candidate branches created from `develop` when preparing a release.
+- `hotfix/vX.Y.Z` — branch from `main` for urgent fixes; merge back into both `main` and `develop`.
+- `feature/<short-desc>` — feature branches off `develop`.
+
+Workflow summary:
+
+1. Develop features on `feature/*` branches and open PRs against `develop`.
+2. When ready, create `release/vX.Y` from `develop`, finalize tests and fixes, then merge into `main` and tag `vX.Y`.
+3. Merge the release back into `develop` if any release-specific changes were made.
+4. For urgent fixes, create `hotfix/*` from `main`, merge into `main` and `develop`, and tag as appropriate.
+
+See CONTRIBUTING.md for PR and review requirements.