upstream-contributionlisted

# Upstream contribution **This repo is not yours.** It belongs to its maintainers, with their own queue, their own conventions and their own history of unmerged good intentions. Act like a guest. ## Remotes `origin` is **your fork**. `upstream` is the project, and its push URL is set to `no_push`: ```bash git remote set-url --push upstream no_push git remote -v # origin = fork, upstream = project (no_push) ``` The remote you type by reflex is the one that is safe to push to. **Never commit to local `main`** — keep it a clean mirror of upstream so rebases stay trivial: ```bash git fetch upstream && git checkout main && git reset --hard upstream/main ``` ## Issue before code For anything larger than a bug fix or a doc correction, **open an issue and wait for a maintainer response before writing the implementation.** Most projects have a graveyard of large unsolicited PRs. Volume of code is not what gets merged; agreement beforehand is. Use the repo's issue templates. If the work is speculative, say so. ## Branch and PR scope - Branch names: `<issue-number>-brief-description` when an issue exists, otherwise `<area>-brief-description`. - **One concern per PR.** Every file in the diff traces to the declared issue. Split an oversized PR before requesting review, not after. - **Never change a default silently.** The project runs inside other people's production. New behaviour arrives as a new parameter whose default preserves today's behaviour exactly. - **