docs(start-work): default to bundled test + feat commits per sub-task

Phase 3 commit-decomposition guidance + Phase 4 step 3 both now default to a single feat(scope): X with tests commit per sub-task rather than separate test: + feat: commits. Test + the code under test belong together for review — a reviewer sees the contract and the satisfaction in one diff instead of paging back and forth. Split into separate commits only when the test work is its own substantial review surface (characterization tests, fixture infrastructure, a new harness) or when the failing test serves as a deliberate bug-report artifact in a fix: narrative.

1 files changed, 3 insertions, 3 deletions

diff --git a/.claude/commands/start-work.md b/.claude/commands/start-work.md
index b9e87c8..935cab5 100644
--- a/.claude/commands/start-work.md
+++ b/.claude/commands/start-work.md
@@ -161,7 +161,7 @@ Then produce an approach that covers:
    - Pairwise or combinatorial tests, if parameter-heavy (see `/pairwise-tests`).
 7. **Migration and backwards-compat surface.** DB migration? API contract change? Frontend consumer impact? Config shape change? Flag if yes and describe the scope.
 8. **Feature flag.** Does this ship behind a flag or direct? Always worth asking once.
-9. **Commit decomposition.** One commit, or N commits? Each commit should be one logical change per `commits.md`. Size the Review-and-Publish ceremony ahead of time.
+9. **Commit decomposition.** One commit, or N commits? Each commit should be one logical change per `commits.md`. Default to bundling tests + the feature they cover into a single `feat(scope): X with tests` (or `fix(scope): X with tests`) commit — the test and the code under test belong together for review. Split into separate `test:` + `feat:` commits only when the test work is its own substantial review surface (characterization tests, fixture infrastructure, a new test harness) or when the failing test serves as a deliberate bug-report artifact in a `fix:` narrative. Size the Review-and-Publish ceremony ahead of time.
 10. **Branch name.** Following the project convention: `fix/<ID>-slug`, `feature/<ID>-slug`, `chore/<ID>-slug`, or `test/<ID>-slug`. Unticketed work uses a short descriptive slug.
 
 ### Gate
@@ -175,8 +175,8 @@ If the user redirects the approach, update the plan and re-present rather than s
 Follow the red-green-refactor cycle from `testing.md`.
 
 1. **Create the branch** using the name decided in Phase 3.
-2. **Red.** Write a failing test that demonstrates the bug or captures the new desired behavior. Run it. Confirm it fails for the right reason, not because the test itself is broken. Commit as `test: <desc>`.
-3. **Green.** Write the minimal code to make the test pass. Do not generalize yet. Do not add features the test does not require. Commit as `fix:` or `feat:`.
+2. **Red.** Write a failing test that demonstrates the bug or captures the new desired behavior. Run it. Confirm it fails for the right reason, not because the test itself is broken.
+3. **Green.** Write the minimal code to make the test pass. Do not generalize yet. Do not add features the test does not require. Commit as `feat(scope): <desc> with tests` (or `fix(scope): <desc> with tests`) — bundle test + implementation per the commit-decomposition decision in Phase 3 step 9. Split into separate `test:` + `feat:` commits only when that decision called for it.
 4. **Edge cases.** Add tests in all three categories per `testing.md`:
    - Normal: happy path, typical input.
    - Boundary: empty inputs, nulls, minimum and maximum values, single-element collections, Unicode, long strings, time and timezone boundaries, concurrent access.