Cortex is a Windows-first, local-first application with a React/Vite frontend and a Python backend. Contributions should preserve local data compatibility, loopback-only operation, and a clean launcher lifecycle.
Before changing code, read the repository agent operating contract. It defines the required inspect -> reproduce -> patch -> verify -> review workflow, the current bounded-execution boundary, and the evidence expected in a handoff.
Install Git, Python 3.10+, Node.js 22+, npm, and Ollama. Then:
git clone https://github.com/dovvnloading/Cortex.git
cd Cortex
python -m venv .venv
.venv\Scripts\Activate.ps1
python -m pip install -r requirements-dev.txt
python main.py --devInstall a small local model for smoke checks, for example
nemotron-3-nano:4b. Do not use real prompts, responses, memories, or user
data in tests or logs.
requirements.txt and requirements-dev.txt intentionally carry loose
version ranges so your local environment isn't forced onto one exact set of
versions. CI installs from requirements.lock.txt /
requirements-dev.lock.txt instead -- hash-pinned, fully resolved lock files
for the same Python 3.11 target CI actually runs -- so a change is verified
against the same dependency versions every time. If you edit
pyproject.toml's dependencies or dev extra, regenerate both locks and
commit the result, or CI's fast job will fail on a staleness check:
python -m pip install uv
uv pip compile pyproject.toml --python-version 3.11 --generate-hashes -o requirements.lock.txt
uv pip compile pyproject.toml --extra dev --python-version 3.11 --generate-hashes -o requirements-dev.lock.txtThe development requirements pin the same Ruff version used by CI, and the
first thing check.ps1 does is verify your environment actually has it --
linting with a different Ruff means a green run here and a red one in CI for
no reason the diff explains. If it reports drift, reinstall:
python -m pip install -r requirements-dev.lock.txtOne script runs the repository's fast quality gates on your machine:
./scripts/check.ps1That is the quick tier -- environment and lockfile checks, lint, backend
tests, contract drift, the artifact-boundary review, and frontend
types/lint/unit tests. The lockfile check needs uv (python -m pip install uv); without it that one step reports skip rather than failing, and CI still
enforces it. Before opening a pull request, run the full tier, which adds
compileall, the Playwright browser installation and tests, and the bundle
build:
./scripts/check.ps1 -Tier fullUse -SkipFrontend or -SkipBackend to narrow the run while iterating.
Packaging (PyInstaller) and WebView2 signature verification are deliberately left out of both tiers: they take 35+ minutes and need Windows packaging tooling. CI covers them.
Point Git at the tracked hooks directory once per clone:
git config core.hooksPath .githooksThe pre-push hook then runs the quick tier and aborts the push if anything
fails. Bypass it in an emergency with git push --no-verify.
The individual commands, if you prefer to run them by hand:
python -m pytest
python -m compileall -q main.py backend
Push-Location frontend
npm ci
npm run typecheck
npm run lint
npm test -- --run
npm run build
Pop-LocationWhen API models change, regenerate and review both contract artifacts:
python tools/generate_contracts.py --write- Keep each pull request limited to one staged architectural concern.
- Do not stage local databases, frontend build output, credentials, or private planning files.
- Add focused tests for behavior, persistence compatibility, and safe failure.
- Update the README and changelog for user-visible runtime changes.
- Include a rollback procedure for data or launcher changes.
- Use Conventional Commit subjects, for example
fix(storage): preserve legacy chat migration sources.
The repository workflow uses draft pull requests, required CI, review before
ready status, and squash merges into main.
Python should be typed and readable, with safe user-facing errors and no raw prompt/response logging. TypeScript should use strict typing and accessible controls. Keep network access explicit and loopback-safe. Avoid adding framework dependencies to backend domain and repository modules unless the boundary requires them.
Please use GitHub private vulnerability reporting for security issues rather than public issues. See SECURITY.md.