Developing swe-mux

git clone https://github.com/jatoran/swe-mux
cd swe-mux
uv sync --extra desktop
npm --prefix frontend ci
npm --prefix frontend run build   # a fresh clone serves no UI until this runs once
uv run --extra desktop swe-mux

The frontend bundle is git-ignored build output. A fresh clone serves a blank page rather than an error until that build has run once, and it is the single most confusing first-run symptom in the project.

Run it before opening a pull request. It is the same set continuous integration runs, and it is deliberately cheap enough to run often.

uv run pytest tests -q -n auto --dist loadgroup
uv run ruff check src/swe_mux tests packaging
uv run mypy
npx tsc --noEmit          # in frontend/
npm test                  # in frontend/

The Python suite runs across the host's cores and the whole gate is a matter of seconds rather than minutes. Continuous integration mirrors it on Windows and adds Linux and macOS legs, the production frontend build, and the full browser renderer suite.

git commit -s, not a contributor licence agreement. The difference is the point: a CLA would let the project relicense your contribution later, and a developer certificate of origin does not. That is the intended trade rather than an oversight.

The rule the licence gate exists to enforce is that a dependency's declared licence does not describe what its wheel ships. So the check has two halves that must both stay alive: one reads the resolved dependency closure's metadata and runs in the verification gate, and the other reads the built desktop bundle for payloads by artifact name. Neither substitutes for the other.

• GPL and AGPL may never enter.
• LGPL needs an allowlist entry and must ship as replaceable source inside the bundle.
• The third-party notices file and its data are both generated. Never hand-edit either; run the audit and commit what it writes.

The repository's own root documents are the ones to read, and they are written for this audience:

• CONTRIBUTING.mdWhat a change has to satisfy: the sign-off, the gate, and the dependency rules in full.
• CLAUDE.mdThe working rules for this repository, including the reload flows that let you apply a change without ending live sessions.
• SECURITY.mdWhere a vulnerability report goes, and the trust boundary it is measured against.
• The design documentsThe maintained design contract lives in the repository under .docs/. It is written for whoever maintains a subsystem next: it states invariants and the decisions already made, names incident dates, and is not written to be read as documentation. That is exactly why the pages you are reading exist beside it rather than linking into it.
• The site itselfsite/README.md is the design record for swemux.dev, including how these pages are generated and the gates that keep them honest.

Issues are for bugs. Ideas discussions are for feature requests, where a thumbs-up is a vote and the most-voted open ideas are drawn on the roadmap. Describe the problem rather than the fix.