suitenumerique · AntoLC · Jun 17, 2025 · Jun 11, 2025 · Jun 11, 2025 · Jun 17, 2025
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
@@ -1,11 +1,22 @@
 ## Purpose
 
-Description...
+Describe the purpose of this pull request. 
 
 
 ## Proposal
 
-Description...
+- [ ] item 1...
+- [ ] item 2...
 
-- [] item 1...
-- [] item 2...
+## External contributions
+
+Thank you for your contribution! 🎉  
+
+Please ensure the following items are checked before submitting your pull request:
+- [ ] I have read and followed the [contributing guidelines](https://github.com/suitenumerique/docs/blob/main/CONTRIBUTING.md)
+- [ ] I have read and agreed to the [Code of Conduct](https://github.com/suitenumerique/docs/blob/main/CODE_OF_CONDUCT.md)
+- [ ] I have signed off my commits with `git commit --signoff` (DCO compliance)
+- [ ] I have signed my commits with my SSH or GPG key (`git commit -S`)
+- [ ] My commit messages follow the required format: `<gitmoji>(type) title description`
+- [ ] I have added a changelog entry under `## [Unreleased]` section (if noticeable change)
+- [ ] I have added corresponding tests for new features or bug fixes (if applicable)
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -11,6 +11,8 @@ and this project adheres to
 ### Added
 
 - ✨(frontend) add customization for translations #857
+- 📝(project) add troubleshoot doc #1066
+- 📝(project) add system-requirement doc #1066
 
 ### Changed
 

diff --git a/docs/system-requirements.md b/docs/system-requirements.md
@@ -0,0 +1,110 @@
+# La Suite Docs – System & Requirements (2025-06)
+
+## 1. Quick-Reference Matrix (single VM / laptop)
+
+| Scenario                  | RAM   | vCPU | SSD     | Notes                     |
+| ------------------------- | ----- | ---- | ------- | ------------------------- |
+| **Solo dev**              | 8 GB  | 4    | 15 GB   | Hot-reload + one IDE      |
+| **Team QA**               | 16 GB | 6    | 30 GB   | Runs integration tests    |
+| **Prod ≤ 100 live users** | 32 GB | 8 +  | 50 GB + | Scale linearly above this |
+
+Memory is the first bottleneck; CPU matters only when Celery or the Next.js build is saturated.
+
+> **Note:** Memory consumption varies by operating system. Windows tends to be more memory-hungry than Linux, so consider adding 10-20% extra RAM when running on Windows compared to Linux-based systems.
+
+## 2. Development Environment Memory Requirements
+
+| Service                  | Typical use                   | Rationale / source                                                                      |
+| ------------------------ | ----------------------------- | --------------------------------------------------------------------------------------- |
+| PostgreSQL               | **1 – 2 GB**                 | `shared_buffers` starting point ≈ 25% RAM ([postgresql.org][1])                       |
+| Keycloak                 | **≈ 1.3 GB**                 | 70% of limit for heap + ~300 MB non-heap ([keycloak.org][2])                         |
+| Redis                    | **≤ 256 MB**                 | Empty instance ≈ 3 MB; budget 256 MB to allow small datasets ([stackoverflow.com][3]) |
+| MinIO                    | **2 GB (dev) / 32 GB (prod)**| Pre-allocates 1–2 GiB; docs recommend 32 GB per host for ≤ 100 Ti storage ([min.io][4]) |
+| Django API (+ Celery)    | **0.8 – 1.5 GB**              | Empirical in-house metrics                                                              |
+| Next.js frontend         | **0.5 – 1 GB**                | Dev build chain                                                                         |
+| Y-Provider (y-websocket) | **< 200 MB**                  | Large 40 MB YDoc called “big” in community thread ([discuss.yjs.dev][5])                |
+| Nginx                    | **< 100 MB**                  | Static reverse-proxy footprint                                                          |
+
+[1]: https://www.postgresql.org/docs/9.1/runtime-config-resource.html "PostgreSQL: Documentation: 9.1: Resource Consumption"
+[2]: https://www.keycloak.org/high-availability/concepts-memory-and-cpu-sizing "Concepts for sizing CPU and memory resources - Keycloak"
+[3]: https://stackoverflow.com/questions/45233052/memory-footprint-for-redis-empty-instance "Memory footprint for Redis empty instance - Stack Overflow"
+[4]: https://min.io/docs/minio/kubernetes/upstream/operations/checklists/hardware.html "Hardware Checklist — MinIO Object Storage for Kubernetes"
+[5]: https://discuss.yjs.dev/t/understanding-memory-requirements-for-production-usage/198 "Understanding memory requirements for production usage - Yjs Community"
+
+> **Rule of thumb:** add 2 GB for OS/overhead, then sum only the rows you actually run.
+
+## 3. Production Environment Memory Requirements
+
+Production deployments differ significantly from development environments. The table below shows typical memory usage for production services:
+
+| Service                  | Typical use                   | Rationale / notes                                                                       |
+| ------------------------ | ----------------------------- | --------------------------------------------------------------------------------------- |
+| PostgreSQL               | **2 – 8 GB**                 | Higher `shared_buffers` and connection pooling for concurrent users                    |
+| OIDC Provider (optional) | **Variable**                  | Any OIDC-compatible provider (Keycloak, Auth0, Azure AD, etc.) - external or self-hosted |
+| Redis                    | **256 MB – 2 GB**             | Session storage and caching; scales with active user sessions                          |
+| Object Storage (optional)| **External or self-hosted**   | Can use AWS S3, Azure Blob, Google Cloud Storage, or self-hosted MinIO               |
+| Django API (+ Celery)    | **1 – 3 GB**                 | Production workloads with background tasks and higher concurrency                      |
+| Static Files (Nginx)     | **< 200 MB**                 | Serves Next.js build output and static assets; no development overhead                |
+| Y-Provider (y-websocket) | **200 MB – 1 GB**             | Scales with concurrent document editing sessions                                        |
+| Nginx (Load Balancer)    | **< 200 MB**                  | Reverse proxy, SSL termination, static file serving                                    |
+
+### Production Architecture Notes
+
+- **Frontend**: Uses pre-built Next.js static assets served by Nginx (no Node.js runtime needed)
+- **Authentication**: Any OIDC-compatible provider can be used instead of self-hosted Keycloak
+- **Object Storage**: External services (S3, Azure Blob) or self-hosted solutions (MinIO) are both viable
+- **Database**: Consider PostgreSQL clustering or managed database services for high availability
+- **Scaling**: Horizontal scaling is recommended for Django API and Y-Provider services
+
+### Minimal Production Setup (Core Services Only)
+
+| Service                  | Memory    | Notes                                   |
+| ------------------------ | --------- | --------------------------------------- |
+| PostgreSQL               | **2 GB**  | Core database                           |
+| Django API (+ Celery)    | **1.5 GB**| Backend services                        |
+| Y-Provider               | **200 MB**| Real-time collaboration                 |
+| Nginx                    | **100 MB**| Static files + reverse proxy           |
+| Redis                    | **256 MB**| Session storage                         |
+| **Total (without auth/storage)** | **≈ 4 GB** | External OIDC + object storage assumed |
+
+## 4. Recommended Software Versions
+
+| Tool                    | Minimum |
+| ----------------------- | ------- |
+| Docker Engine / Desktop | 24.0    |
+| Docker Compose          | v2      |
+| Git                     | 2.40    |
+| **Node.js**             | 22+     |
+| **Python**              | 3.13+   |
+| GNU Make                | 4.4     |
+| Kind                    | 0.22    |
+| Helm                    | 3.14    |
+| kubectl                 | 1.29    |
+| mkcert                  | 1.4     |
+
+
+## 5. Ports (dev defaults)
+
+| Port      | Service               |
+| --------- | --------------------- |
+| 3000      | Next.js               |
+| 8071      | Django                |
+| 4444      | Y-Provider            |
+| 8080      | Keycloak              |
+| 8083      | Nginx proxy           |
+| 9000/9001 | MinIO                 |
+| 15432     | PostgreSQL (main)     |
+| 5433      | PostgreSQL (Keycloak) |
+| 1081      | MailCatcher           |
+
+## 6. Sizing Guidelines
+
+**RAM** – start at 8 GB dev / 16 GB staging / 32 GB prod. Postgres and Keycloak are the first to OOM; scale them first.
+
+> **OS considerations:** Windows systems typically require 10-20% more RAM than Linux due to higher OS overhead. Docker Desktop on Windows also uses additional memory compared to native Linux Docker.
+
+**CPU** – budget one vCPU per busy container until Celery or Next.js builds saturate.
+
+**Disk** – SSD; add 10 GB extra for the Docker layer cache.
+
+**MinIO** – for demos, mount a local folder instead of running MinIO to save 2 GB+ of RAM.
diff --git a/docs/troubleshoot.md b/docs/troubleshoot.md
@@ -0,0 +1,194 @@
+# Troubleshooting Guide
+
+## Line Ending Issues on Windows (LF/CRLF)
+
+### Problem Description
+
+This project uses **LF (Line Feed: `\n`) line endings** exclusively. Windows users may encounter issues because:
+
+- **Windows** defaults to CRLF (Carriage Return + Line Feed: `\r\n`) for line endings
+- **This project** uses LF line endings for consistency across all platforms
+- **Git** may automatically convert line endings, causing conflicts or build failures
+
+### Common Symptoms
+
+- Git shows files as modified even when no changes were made
+- Error messages like "warning: LF will be replaced by CRLF"
+- Build failures or linting errors due to line ending mismatches
+
+### Solutions for Windows Users
+
+#### Configure Git to Preserve LF (Recommended)
+
+Configure Git to NOT convert line endings and preserve LF:
+
+```bash
+git config core.autocrlf false
+git config core.eol lf
+```
+
+This tells Git to:
+- Never convert line endings automatically
+- Always use LF for line endings in working directory
+
+
+#### Fix Existing Repository with Wrong Line Endings
+
+If you already have CRLF line endings in your local repository, the **best approach** is to configure Git properly and clone the project again:
+
+1. **Configure Git first**:
+   ```bash
+   git config --global core.autocrlf false
+   git config --global core.eol lf
+   ```
+
+2. **Clone the project fresh** (recommended):
+   ```bash
+   # Navigate to parent directory
+   cd ..
+
+   # Remove current repository (backup your changes first!)
+   rm -rf docs
+
+   # Clone again with correct line endings
+   git clone git@github.com:suitenumerique/docs.git
+   ```
+
+**Alternative**: If you have uncommitted changes and cannot re-clone:
+
+1. **Backup your changes**:
+   ```bash
+   git add .
+   git commit -m "Save changes before fixing line endings"
+   ```
+
+2. **Remove all files from Git's index**:
+   ```bash
+   git rm --cached -r .
+   ```
+
+3. **Reset Git configuration** (if not done globally):
+   ```bash
+   git config core.autocrlf false
+   git config core.eol lf
+   ```
+
+4. **Re-add all files** (Git will use LF line endings):
+   ```bash
+   git add .
+   ```
+
+5. **Commit the changes**:
+   ```bash
+   git commit -m "✏️(project) Fix line endings to LF"
+   ```
+
+## Minio Permission Issues on Windows
+
+### Problem Description
+
+On Windows, you may encounter permission-related errors when running Minio in development mode with Docker Compose. This typically happens because:
+
+- **Windows file permissions** don't map well to Unix-style user IDs used in Docker containers
+- **Docker Desktop** may have issues with user mapping when using the `DOCKER_USER` environment variable
+- **Minio container** fails to start or access volumes due to permission conflicts
+
+### Common Symptoms
+
+- Minio container fails to start with permission denied errors
+- Error messages related to file system permissions in Minio logs
+- Unable to create or access buckets in the development environment
+- Docker Compose showing Minio service as unhealthy or exited
+
+### Solution for Windows Users
+
+If you encounter Minio permission issues on Windows, you can temporarily disable user mapping for the Minio service:
+
+1. **Open the `compose.yml` file**
+
+2. **Comment out the user directive** in the `minio` service section:
+   ```yaml
+   minio:
+     # user: ${DOCKER_USER:-1000}  # Comment this line on Windows if permission issues occur
+     image: minio/minio
+     environment:
+       - MINIO_ROOT_USER=impress
+       - MINIO_ROOT_PASSWORD=password
+     # ... rest of the configuration
+   ```
+
+3. **Restart the services**:
+   ```bash
+   make run
+   ```
+
+### Why This Works
+
+- Commenting out the `user` directive allows the Minio container to run with its default user
+- This bypasses Windows-specific permission mapping issues
+- The container will have the necessary permissions to access and manage the mounted volumes
+
+### Note
+
+This is a **development-only workaround**. In production environments, proper user mapping and security considerations should be maintained according to your deployment requirements.
+
+## Frontend File Watching Issues on Windows
+
+### Problem Description
+
+Windows users may experience issues with file watching in the frontend-development container. This typically happens because:
+
+- **Docker on Windows** has known limitations with file change detection
+- **Node.js file watchers** may not detect changes properly on Windows filesystem
+- **Hot reloading** fails to trigger when files are modified
+
+### Common Symptoms
+
+- Changes to frontend code aren't detected automatically
+- Hot module replacement doesn't work as expected
+- Need to manually restart the frontend container after code changes
+- Console shows no reaction when saving files
+
+### Solution: Enable WATCHPACK_POLLING
+
+Add the `WATCHPACK_POLLING=true` environment variable to the frontend-development service in your local environment:
+
+1. **Modify the `compose.yml` file** by adding the environment variable to the frontend-development service:
+
+   ```yaml
+   frontend-development:
+     user: "${DOCKER_USER:-1000}"
+     build: 
+       context: .
+       dockerfile: ./src/frontend/Dockerfile
+       target: impress-dev
+       args:
+         API_ORIGIN: "http://localhost:8071"
+         PUBLISH_AS_MIT: "false"
+         SW_DEACTIVATED: "true"
+     image: impress:frontend-development
+     environment:
+       - WATCHPACK_POLLING=true  # Add this line for Windows users
+     volumes:
+       - ./src/frontend:/home/frontend
+       - /home/frontend/node_modules
+       - /home/frontend/apps/impress/node_modules
+     ports:
+       - "3000:3000"
+   ```
+
+2. **Restart your containers**:
+   ```bash
+   make run
+   ```
+
+### Why This Works
+
+- `WATCHPACK_POLLING=true` forces the file watcher to use polling instead of filesystem events
+- Polling periodically checks for file changes rather than relying on OS-level file events
+- This is more reliable on Windows but slightly increases CPU usage
+- Changes to your frontend code should now be detected properly, enabling hot reloading
+
+### Note
+
+This setting is primarily needed for Windows users. Linux and macOS users typically don't need this setting as file watching works correctly by default on those platforms.