Development Guide
Last updated
How to work on comic-dl itself — reporting, workflow, setup, review, and releasing.
On this page
The how-to for working on comic-dl itself, in the order a contributor meets the parts of it. Together these pages cover the whole lifecycle of a change — from the first bug report to the release that ships it.
Read these in order
| Page | You need it when |
|---|---|
| Reporting | Found a bug, a feature idea, or a security concern. |
| Workflow | About to branch, implement, and open a PR. Gates included. |
| Setup | Checkout doesn’t run, or gates need explaining. |
| Architecture | Need to know what each module does. |
| Testing | Writing or fixing tests. Offline-only rules. |
| Security Testing | Your change touches fetching, files, or the DB. |
| Error Style Guide | Writing or editing user-visible messages. |
| Code Review | A PR of yours gets reviewed — or you review one. |
| Releasing | Cutting a version. Maintainer-only in practice. |
The life of a change
- Report or pick — an issue exists or you file one
(reporting). The
good first issue,help wantedlabels mark ones new contributors can take. - Branch — a feature branch forks from
dev, never frommain. - Implement — small, signed commits, each a Conventional Commit.
- Gate — run
test.sh,lint.sh, anddocs.shlocally until they pass. - Review — open a PR against
dev; reviewers run the checklist in code review. - Merge — squash-merged into
dev, one commit per PR. - Validate — release-ready work is cut to
staging, proven there, then released tomainon the Monday cadence in releasing.
See also the architecture guide for what each module does, and the site support page for the supported-site contract used by the release pipeline.