update some bs

+ readme
+ some change in the bash script using ports

readme.md

@@ -1,20 +1,25 @@
-## under construction
+# QPP - Quick Problem Platfrom
 
-### Like LeetCode
+This is a lightweight, LeetCode-inspired problem-solving platform. You can run the server locally, contribute problems, and write unit tests.
 
-but more lightweight
+---
 
-run the bash script to start the server.
+## Getting Started
 
-if you want to contribute write tests like this:
+Run the provided bash/_batch_ script to start the server.
 
-### FileStructure:
+---
 
-In /problems/ create a folder named after the problem.
+## File Structure for Problems
 
-In this folder create ```manifest.json, test.py, description.md```
+Create a folder inside `/problems/` named after your problem. Each folder **must** contain:
+
+* `manifest.json` # Dont worry you can change the info anytime to reload
+* `test.py`
+* `description.md`
+
+**Example `manifest.json`:**
 
-**Manifest.JSON needs to exsist and _needs_ to look like this:**
 ```json
 {
     "title": "Title of the Problem",
@@ -24,45 +29,137 @@ In this folder create ```manifest.json, test.py, description.md```
     "test_code": "problems/problempath/test.py"
 }
 ```
-I do know it might be a bit tedious but this is required and its the easiest way.
 
-#### After you've decided on how you would name / write your Test write it like this:
+> This structure is mandatory but ensures the easiest workflow.
 
- - It is important to note that you _CAN_ write the Code the User is expected to write firstly. **BUT** after writing the UnitTest and it passing, comment out the written code.
+---
 
-It is supposed to look something like this (/sortlist/):
+## Writing Problem Descriptions
+
+* Use **simple and easy-to-understand language**. Avoid overly technical explanations.
+* Syntax:
+
+  * Normal Markdown
+  * Start headings with `##` (looks cleaner than `#`)
+  * Include cross-links to resources, e.g., [W3Schools](https://www.w3schools.com/) or [Python Docs](https://docs.python.org/3/)
+* Good formatting is always appreciated
+
+---
+
+## Developing & Running Locally
+
+To run the backend during development:
+
+```bash
+python -m flask --app ./src/app.py --host=0.0.0.0 --port=5000
+```
+
+For production testing:
+
+**Linux:**
+
+```bash
+python -m gunicorn -w 4 -b 0.0.0.0:8000 src.app:app
+```
+
+**Windows:**
+
+```bat
+:: Create database folder if missing
+md .\src\database
+python -m waitress --listen=0.0.0.0:8000 src.app:app 
+```
+
+> Ensure all required packages are installed via `requirements.txt`. Python is versatile enough for this small backend.
+
+---
+
+### Migrating Legacy Code
+
+When removing or refactoring legacy code:
+
+1. Check if the code is used anywhere; if critical, branch into a testing branch first.
+2. Ensure essential functionality is preserved.
+
+---
+
+## Committing Changes
+
+* Ensure your editor uses **LF** line endings (`\n`) instead of CRLF.
+* To automatically fix CRLF on commit:
+
+```bash
+git config core.autocrlf input
+git add --renormalize .
+git commit -m "Major Change"
+```
+
+* Recommended workflow:
+
+  1. Fork
+  2. Make changes
+  3. Submit a PR
+  4. Review & merge
+
+> Using WSL with VS Code for development is recommended for consistent line endings on Windows.
+
+---
+
+## Writing Unit Tests
+
+Follow this convention when writing unittests. **Implement the function first, then write tests.**
+
+### Example: Phone Number Validation
+
+**Function (`phone_validation.py`):**
+
+```python
+import re
+
+def is_valid_phone_number(phone_number: str) -> bool:
+    """Return True if phone_number matches '123-456-7890' format."""
+    return bool(re.search(r"^(\d{3}-){2}\d{4}$", phone_number))
+```
+
+**Unit Test (`test_phone_validation.py`):**
 
 ```python
-"""
-@TESTSAMPLE.PY / NAME THIS "test.py" in your actual project
-"""
 import unittest
+from phone_validation import is_valid_phone_number
 
-" )) First Point from the List "
+class TestPhoneNumberRegex(unittest.TestCase):
-#   def sortlist(lst = [4,3,2,1]) -> list:
-#       return sorted(lst)
 
-")) This is a 'easy' Test, if you want you can write more defined ones."
+    def test_if_valid(self):
-class TestSolution(unittest.TestCase):
+        test_cases = [
-    def test_sort(self):
+            ("123-456-7890", True),
-        self.x = []
+            ("111-222-3333", True),
-        self.assertEqual(sortlist(self.x), sorted(self.x)) # pyright: ignore[reportUndefinedVariable] <- This is only here so that pyright doesnt complain ; NOT NECCESARY!
+            ("abc-def-ghij", False),
+            ("1234567890", False),
+            ("123-45-67890", False),
+            ("12-3456-7890", False),
+            ("", False),
+        ]
+        print("\nPHONE NUMBER VALIDATION TEST RESULTS")
+
+        for phone, expected in test_cases:
+            try:
+                actual = is_valid_phone_number(phone)
+                status = "✓ PASS" if actual == expected else "✗ FAIL"
+                print(f"{status} | Input: '{phone}' -> Got: {actual} | Expected: {expected}")
+                self.assertEqual(actual, expected)
+            except Exception as e:
+                print(f"✗ ERROR | Input: '{phone}' -> Exception: {e}")
+                raise
 
 if __name__ == "__main__":
-    unittest.main()
+    unittest.main(verbosity=2)
-
-    """
-    PLEASE WRITE TEST ACCORDING TO 
-    CONVENTION IN NEW TEST
-    @regex-phonenumber/test.py
-    """
 ```
-#### Writing the description:
 
-**Please** by _God_ write simple and easy to understand terms. If you write like Einstein noone is going to understand you.
+### ✅ Unit Test Guidelines
 
-- Syntax:
+1. **Class Naming:** `Test<FunctionOrModuleName>`
-  - Normal Markdown.
+2. **Method Naming:** `test_<what_is_being_tested>`
-  - Start with "##" instead of "#" ; "##" looks better
+3. **Use tuples** `(input, expected_output)` for test cases
-  - Use CrossLinks ( something like [W3](https://www.w3schools.com/), or the [PyDocs](https://docs.python.org/3/))
+4. Include **edge cases** (empty strings, wrong formats)
-  - Good Formatting is always appreciated
+5. **Print results** clearly for easier debugging
+6. **Catch exceptions** and display failing input before raising

run.bash

@@ -21,5 +21,5 @@ export FLASK_ENV=production
 
 # Run with Gunicorn
 echo "Starting Flask app with Gunicorn..."
-exec gunicorn -w 4 -b 0.0.0.0:5000 src.app:app
+exec gunicorn -w 4 -b 0.0.0.0:8000 src.app:app