StrideBR

StrideBR is a flexible platform for planning, organizing and recording physical activities.

StrideBR is built around configurable modalities instead of assuming one fixed sport. The project combines weekly training planning, a reusable exercise library and a dynamic activity-recording engine in one web application.

Current capabilities

• User signup, authentication and profile settings
• Multiple independent weekly training plans
• Calendar-style week and agenda views
• Planned workouts with start/end times, including workouts that cross midnight
• Exercise library with global and personal exercises
• Exercise categories and modality associations
• Workout prescriptions with sets, repetitions, load, rest, block and cluster
• Custom exercise-prescription columns
• Dynamic activity modalities, models and fields
• Repeated activity units such as attempts, laps, intervals or sets
• Typed and normalized measurement values
• Global stopwatch, timer and set-counter tools
• Workout execution from a scheduled workout, with set/exercise progress and activity creation
• Profiles, usernames, onboarding and privacy controls
• Mutual friends and snapshot schedule sharing
• Exercise image/video references by URL
• Moderator/admin/owner roles, feature flags and audit logs
• Closed-alpha feedback with moderation queue
• Versioned legal acceptance, email-verification/password-reset foundation and invite-only registration
• Admin user management with block/unblock/edit/delete controls

Route drawing, deeper statistics, synchronized shared schedules, public discovery, events, API and mobile clients remain planned features.

The architecture and product rules are documented in docs/architecture.md. Deployment notes are in docs/DEPLOY_ALWAYS_DATA.md and the current product roadmap is in docs/PRODUCT_ROADMAP.md.

Stack

Technology	Purpose
PHP 8.4	Application backend
Apache 2.4	Web server
PostgreSQL 17	Database
PDO	Database access
Composer	PHP dependency management
JavaScript	Client-side interactions
HTML / CSS	User interface
Docker Compose	Local development environment

Quick start with Docker

Requirements

• Git
• Docker with Docker Compose

Clone the repository:

git clone https://github.com/BrunoWithoutH/StrideBR.git
cd StrideBR

Optionally create a local environment file:

cp .env.example .env

Start the application and PostgreSQL:

docker compose up --build

Open:

http://localhost:8080

The first database startup automatically executes, in order:

src/database/stridebr.sql
src/database/stridebr_activities_schema.sql
src/database/stridebr_seed.sql
src/database/migrations/20260815_product_foundation.sql
src/database/migrations/20260815_alpha_readiness.sql

Database initialization scripts run only when the PostgreSQL data volume is empty. To recreate a development database from scratch:

docker compose down -v
docker compose up --build

Run the application in the background:

docker compose up -d --build

Check services:

docker compose ps

Open a shell in the application container:

docker compose exec app bash

Open PostgreSQL:

docker compose exec postgres psql -U stridebr -d stridebr

Stop the environment:

docker compose down

Environment variables

The application reads these database variables:

STRIDEBR_DB_HOST
STRIDEBR_DB_PORT
STRIDEBR_DB_NAME
STRIDEBR_DB_USER
STRIDEBR_DB_PASSWORD

Application error visibility can be controlled with:

STRIDEBR_APP_ENV=development
STRIDEBR_APP_ENV=production

Never commit production credentials. .env files are ignored by Git; .env.example contains development-only defaults.

The default Docker development ports are:

Web:        localhost:8080
PostgreSQL: localhost:5434

The application container connects to PostgreSQL internally through postgres:5432.

Manual setup

A manual environment needs:

• PHP 8.4 or compatible PHP 8.x
• pdo_pgsql
• PostgreSQL 17 or compatible supported version
• Composer
• a web server configured with public/ as its document root

Install dependencies:

composer install

Create a PostgreSQL database and execute the SQL files in the order shown above. Then provide the database connection through environment variables.

Project structure

StrideBR/
├── .github/
│   └── copilot-instructions.md
├── docs/
│   └── architecture.md
├── public/
│   ├── assets/
│   ├── function/
│   ├── pages/
│   ├── user/
│   ├── calendario.php
│   ├── home.php
│   ├── index.php
│   ├── login.php
│   └── signup.php
├── src/
│   ├── config/
│   ├── database/
│   ├── function/
│   ├── includes/
│   └── layout/
├── Dockerfile
├── compose.yaml
├── composer.json
└── README.md

Database model

The planning side is centered on:

user
└── cronograms
    └── planned workouts
        └── exercise occurrences
            ├── standard prescription fields
            └── custom prescription fields

The activity-recording side is centered on:

modality
└── activity model
    └── fields

user
└── activity record
    └── activity units
        └── typed values

A unit is intentionally generic and can represent an attempt, lap, interval, set, throw, descent or another model-defined occurrence.

See docs/architecture.md for the complete design and development boundaries.

Development checks

Lint every project PHP file:

find public src scripts -type f -name '*.php' -print0 | xargs -0 -n1 php -l

Check JavaScript syntax:

find public/assets/js -type f -name '*.js' -print0 | xargs -0 -n1 node --check

When Docker is available, a clean database initialization is the preferred integration check:

docker compose down -v
docker compose up --build

Security

• Passwords use PHP password hashing APIs.
• Authenticated identity comes from the server-side session.
• State-changing browser operations use CSRF protection.
• User-owned resources are checked against the authenticated user.
• SQL input is handled through PDO prepared statements.
• Database secrets come from environment variables.

If a credential has ever been committed to a public Git history, rotating it is required even after removing it from the current files.

License

See LICENSE.