Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/whitiue/logiMathApp/llms.txt

Use this file to discover all available pages before exploring further.

LogiMath follows a feature-branch workflow: every change — whether a bug fix, new screen, or API endpoint — lives on its own branch until it is reviewed and merged to main. Merging to main triggers an automatic deployment to Render, so the branch model doubles as the release gate for production.

​
Feature branch workflow

1

Clone the repository and create a feature branch

Start by cloning the repo and immediately branching off main:
git clone https://github.com/whitiue/logiMathApp.git LogiMath
cd LogiMath
git checkout -b feature/my-feature
Use a descriptive branch name that reflects the work: feature/quiz-score-fix, feature/login-screen, fix/db-connection-timeout. Avoid generic names like feature/update or my-branch.
2

Start services with Docker Compose

With your branch checked out, bring up the full stack:
docker-compose up --build
The backend starts at http://localhost:8000 and PostgreSQL at localhost:5432. Keep this terminal open while you work.
3

Make your changes

Edit files under src/BackEnd/ for backend changes — the running container picks up Python changes via uvicorn --reload. For frontend changes in src/FrontEnd/, run the Flet app directly on your host machine (python mainApp.py in a separate terminal) since there is no frontend Docker service.
Check docker-compose logs backend in a separate terminal if the backend does not reflect your changes. A Python syntax error will prevent the reload.
4

Commit using conventional commits format

LogiMath uses Conventional Commits for all commit messages. The format is:
<type>: <short summary>

<optional body with bullet points>
Common types:
TypeWhen to use
featA new feature or user-visible behaviour
fixA bug fix
refactorCode change that neither fixes a bug nor adds a feature
docsDocumentation changes only
testAdding or updating tests
choreDependency updates, config changes, tooling
Good commit message:
git commit -m "feat: agregar validación en quiz submit

- Validar que todas las respuestas estén presentes
- Calcular puntaje correctamente
- Retornar detalles en response"
Bad commit message:
git commit -m "stuff"
Follow the atomic commits principle: one commit = one logical change. A commit should be independently testable and reversible without touching unrelated code. Never bundle a bug fix and a new feature in the same commit.
5

Push your branch and open a Pull Request

git push origin feature/my-feature
Then open a Pull Request on GitHub against main. Include in the PR description:
  • What the change does and why
  • How to test it locally
  • Any environment variable additions or schema changes
At least one other team member must review and approve before merging.
6

Merge to main — Render deploys automatically

Once the PR is approved, merge it to main. Render detects the push, builds the Docker image, and deploys the updated backend. Monitor the deployment in the Render dashboard.
Do not push directly to main. All changes must go through a Pull Request so that the team has visibility and the deployment pipeline is triggered only from reviewed code.

Build docs developers (and LLMs) love

Get started for freeTalk to us