···5757 it does error, prefer finding a solution that satisfies the type system naturally before resorting
5858 to an assertion
59596060+### commit workflow
6161+6262+we use conventional commits with these rules:
6363+6464+- accepted types: `feat`, `fix`, `refactor`, `docs`, `chore`
6565+- optional scope is the package name, e.g. `refactor(package-a):`
6666+- omit the scope when the change does not involve any specific package, or when it touches most/all
6767+ packages
6868+- never list multiple packages in the scope (e.g. `refactor(package-a,package-b)` is forbidden)
6969+- append `!` after the type/scope to mark breaking changes, e.g. `feat(package-a)!:` or `refactor!:`
7070+7171+scope selection when multiple packages are involved:
7272+7373+- if the change primarily involves `package-a` over `package-b`, pick `package-a`
7474+- if changes in `package-a` and `package-b` hinge on `package-c` (even if `package-c` itself was not
7575+ modified), pick `package-c`
7676+7777+granularity — each commit should represent one logical change:
7878+7979+- split distinct changes into separate commits rather than bundling them
8080+- pair each changeset with the single commit it describes, so the changeset's git hash maps to the
8181+ right change; do not write one changeset covering multiple commits
8282+- pair each README update with the commit it documents, rather than batching doc updates across
8383+ multiple changes
8484+6085### documentation
61866287- documentations include README, code comments, commit messages