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.
The post-launch PR flood from LLM coding agents drowned the repo in PRs
that don't run the app, attach no screenshots, and invent parallel
component styling. Even tiny correctness fixes accumulated into a visual
mess. Make the rules explicit in both the PR template and CONTRIBUTING:
- Run the app and view the change in a browser before submitting.
- Required screenshot for any UI/render touch (no longer "delete if not UI").
- Explicit style requirements: reuse CSS variables, no Unicode emoji
(use SVG icons), monospaced font, dark theme, no parallel widgets.
- Direct callout for bulk agent-generated PRs: open an issue first.
PRs that ignore these will be closed without merge, regardless of code
correctness.
