041c03bf11
Switching to a two-branch workflow: contributors open PRs against `dev`, and `main` is fast-forwarded to a tested `dev` commit at each release. This separates "things land in staging" (can move fast) from "things ship to users" (slow, tested in a browser by the maintainer first). CONTRIBUTING: add a Branch model section explaining the split + how to retarget a PR. PR template: add an explicit "this PR targets dev" checkbox at the top so it's the first thing a contributor confirms. End-users cloning the repo will now land on `dev` by default; they can `git checkout main` if they want the curated branch.
3.0 KiB
3.0 KiB
Summary
Target branch
- This PR targets
dev, notmain. All PRs land indev;mainis curated by the maintainer at each release. If your PR is onmainby accident, click "Edit" on this PR and change the base.
Linked Issue
Fixes #
Type of Change
- Bug fix (non-breaking — fixes a confirmed issue)
- New feature (non-breaking — adds new behaviour)
- Breaking change (changes or removes existing behaviour)
- Refactor / cleanup (behaviour unchanged)
- Documentation only
- CI / tooling / configuration
Checklist
- I searched open issues and open PRs — this is not a duplicate.
- This PR targets
main - My changes are limited to the scope described above — no unrelated refactors or whitespace changes mixed in.
- I actually ran the app (
docker compose uporuvicorn app:app) and verified the change works end-to-end. Type-checks and unit tests are not enough.
How to Test
Visual / UI changes — REQUIRED if you touched anything that renders
Anything that changes what the UI looks like — buttons, icons, padding, colors, fonts, spacing, layout, CSS, HTML, SVG, or any static/js/ module that draws to the DOM — needs all of the following. PRs that change rendering without these WILL be closed.
- Screenshot or short clip of the change in the running app, attached below. Mobile screenshot too if the change affects mobile.
- Style match: the change uses Odysseus's existing visual language. Specifically:
- Reuse existing CSS variables (
--red,--fg,--bg,--card,--border, etc.) — do not introduce new color values, font sizes, or spacing units. - Reuse existing button/input/card/border classes. Don't invent parallel styling.
- No Unicode emoji in UI or code. Use inline SVG (matching the monochrome icon style already in
static/index.html) or plain text. - Monospaced font (
Fira Code) for primary UI text. Don't override. - Dark theme is the default; any light-mode work must be wired through the existing theme system, not hard-coded.
- Reuse existing CSS variables (
- No new component patterns. If a similar widget already exists in the app, extend it instead of writing a parallel one.
- I am not an LLM agent submitting a bulk PR. If you are, please open an issue describing the problem first — bulk auto-generated PRs that don't match the project's visual style are closed on sight, even when the underlying fix is correct.