next → main: docs brought in line with the code #134

Open
clawbot wants to merge 3 commits from next into main
2 changed files with 19 additions and 10 deletions
Showing only changes of commit c27e2cb629 - Show all commits
+14 -10
View File
@@ -171,16 +171,19 @@ local cache is reliable, and the UI is responsive on a five-year-old laptop.
All work on quak is test-driven. No exceptions. All work on quak is test-driven. No exceptions.
1. Every change starts on a feature branch off `main`. 1. Every change starts on a feature branch off `next`, and its pull request
targets `next`.
2. The first commit on the branch is the test suite for what is being added or 2. The first commit on the branch is the test suite for what is being added or
changed. Those tests must fail at that commit; the branch is red until the changed. Those tests must fail at that commit; the branch is red until the
implementation lands. implementation lands.
3. Subsequent commits add the implementation and any refactors needed to make 3. Subsequent commits add the implementation and any refactors needed to make
the tests pass. the tests pass.
4. A feature branch can only be merged into `main` when `make check` is green. 4. A pull request can only be merged into `next` when `make check` is green.
`main` is always green. CI runs `script/cibuild`, which builds the Once it has passed review, the repository manager squash-merges it into
`Dockerfile`: its `lint` and `test` phases, then the compile, so neither a `next`. Only sneak merges `next` into `main`. `main` and `next` are always
red branch nor one that does not compile can pass CI. green. CI runs `script/cibuild`, which builds the `Dockerfile`: its `lint`
and `test` phases, then the compile, so neither a red branch nor one that
does not compile can pass CI.
5. Tests are the canonical API documentation for this library. Every test file 5. Tests are the canonical API documentation for this library. Every test file
is commented thoroughly enough that a reader who has never seen quak can is commented thoroughly enough that a reader who has never seen quak can
learn how to use it from the tests alone. Comments explain why a behavior learn how to use it from the tests alone. Comments explain why a behavior
@@ -198,7 +201,7 @@ All work on quak is test-driven. No exceptions.
not the tests, and so not the full `make check`. This is deliberate so the not the tests, and so not the full `make check`. This is deliberate so the
TDD red-phase commit (failing tests, no implementation yet) can land. The TDD red-phase commit (failing tests, no implementation yet) can land. The
`test` phase is part of the image build, which is what CI executes via `test` phase is part of the image build, which is what CI executes via
`script/cibuild`, so a red branch still cannot reach `main`. `script/cibuild`, so a red branch still cannot reach `next`.
## Design ## Design
@@ -839,14 +842,15 @@ documents:
`yarn.lock`. Never `git add -A`. Never force-push to main. `yarn.lock`. Never `git add -A`. Never force-push to main.
- **The "Development workflow" section above.** All changes go on feature - **The "Development workflow" section above.** All changes go on feature
branches. Tests are written first and committed in a failing state before the branches off `next`, and every pull request targets `next`; only sneak merges
implementation. Tests are the canonical API documentation and must be `next` into `main`. Tests are written first and committed in a failing state
commented thoroughly. `main` is always green. before the implementation. Tests are the canonical API documentation and must
be commented thoroughly. `main` and `next` are always green.
- **Required checks before every commit:** `make lint` must pass — that is - **Required checks before every commit:** `make lint` must pass — that is
eslint plus the prettier check, and it builds the `lint` phase of the eslint plus the prettier check, and it builds the `lint` phase of the
`Dockerfile`, so it needs docker. The pre-commit hook enforces exactly that. `Dockerfile`, so it needs docker. The pre-commit hook enforces exactly that.
`make check` (which also runs the tests) must pass before merging to `main`. `make check` (which also runs the tests) must pass before merging into `next`.
`make fmt-check` is available for a host-side formatting check on its own, but `make fmt-check` is available for a host-side formatting check on its own, but
it is not a separate requirement: `make lint` already covers it, and running it is not a separate requirement: `make lint` already covers it, and running
both would check formatting twice. Never invoke eslint or prettier directly; both would check formatting twice. Never invoke eslint or prettier directly;
+5
View File
@@ -22,6 +22,11 @@ declares one.
# Completed Steps # Completed Steps
- 2026-09-29: The README's "Development workflow" and "For LLMs" sections now
say work branches from `next`, every pull request targets `next`, the
repository manager squash-merges reviewed pull requests into `next`, and only
sneak merges `next` into `main` (issue 135).
- 2026-09-29: Brought the README and this file in line with `next` after the - 2026-09-29: Brought the README and this file in line with `next` after the
milestone merge (issue 132). The Next Step says no implementation work is open milestone merge (issue 132). The Next Step says no implementation work is open
and the cache design (issue 36) waits on sneak's review. README corrections: and the cache design (issue 36) waits on sneak's review. README corrections: