Commits and pull requests

What a change carries when it arrives: a subject somebody can read, a changelog line, and a green gate.

Branches

git switch -c feature/dev-server-ports    # or bugfix/…

feature/* and bugfix/*, and pull requests target development. main is what has been released.

The commit subject

A plain imperative sentence saying what the change does. No prefix, no type, no ticket key:

Take the site from the directory you are standing in, everywhere
Give every project its own block of dev-server ports
Add dqx githooks, so hooks are changed deliberately

Not feat(dev): ports and not fix bug. The subject is read months later by somebody bisecting, and "what does this change" is the question they have.

The body is for why, when the subject cannot carry it: the failure this fixes, the measurement that decided it, what you tried first. Reference the files or functions you touched, and say what you tested.

One commit per finished piece of work

Not one per file and not one per afternoon. A commit that leaves the gate red is a commit somebody else has to bisect around.

Every pull request carries a changelog line

dqx changes --type patch "Take the site from the directory you are standing in"
dqx changes --list      # what is pending

That writes a small file under .semversioner/next-release/. The version number is derived from those files, so a release with none of them cannot work out whether it is a patch or a minor.

patch	a fix, or anything invisible from outside
minor	a new command, a new flag, a new key, new behaviour
major	something that used to work differently, where somebody has to change their config or their habit

Write it as you make the change, not at the end from memory - that is the whole reason the file exists rather than a changelog somebody edits. One line per pull request is normal; a change that does two things worth announcing may write two.

Do not run dqx release

That rolls the pending changes into a version and writes CHANGELOG.md and package.json. The pipeline does it on main after your pull request is merged, together with the build, the tag and the publish. Nothing about releasing is yours to do - and a version rolled in a pull request is a conflict with the next one.

What has to be true before you open it

bun run test:gate   # build, every test, and the coverage gate
bun run lint
bun run typecheck

• New behaviour has a test, and the test says why it exists rather than only what it asserts. See tests and the gate.
• Anything in src/core/config/** is written test-first. That layer decides what every project resolves to, and a wrong default is silent.
• src/core/** stays at 100%. The gate fails otherwise, naming the lines.
• Anything that touches the machine gets walked on a real project before it is called done. Unit tests do not catch a stack that started before its database was ready, a certificate that did not cover a new domain, or a copy that copied nothing and exited 0. All three passed the suite.

What the review looks at

The code style is the formatter's job, so a review is about the things a tool cannot check: whether the decision is in core and the I/O in an adapter, whether a message a person reads is advice they can follow, whether the comment explains the failure rather than the line, and whether the test would still be understandable in two years.

Every pull request is reviewed by the Dolphiq team before it merges. That is a four-eyes rule rather than a formality: this tool writes files in other people's repositories and holds their local certificates.

After the merge

Nothing for you to do. The release, the version number, the changelog, the build for both Mac architectures and the published documentation all happen on our side, from the pending changelog files your pull request added.