slice-and-ship

Slice and Ship

Thesis: Ship one acceptance criterion end-to-end before starting the next. The slice — not the commit, not the feature — is the unit of audit and review. Most "clean up audit follow-ups" rollups exist because we audited the whole feature instead of each slice as it landed.

Refrain: Plan → Slice → Implement → Test → Sync → Closeout → Audit → Commit → Repeat

What Is a Slice

A slice is the smallest change that is independently:

1. Mergeable — could ship to production without the next slice landing.
2. Verifiable — has at least one test that exercises the new behavior.
3. Documented — any contract change (spec, API, env var) is updated in the same set of commits.
4. Bounded — typically one acceptance criterion from docs/plans/*.md. Rarely more than ~300 lines of diff total across its commits.

A slice is larger than a commit (a slice may be 2–4 atomic commits) and smaller than a feature (a feature is usually 3–8 slices).

For seed/demo work, mirror the user-facing walkthrough in the commit structure: accounts → hiring funnel → work state → money state → proof/reviews → optional secondary surfaces. Each layer should be usable and rollback-validated before the next layer lands. This preserves git archaeology: future-you can answer "why is this data shaped this way?" from the commit timeline.

The Loop

Start from the relevant docs/plans/*.md file when one exists. If execution reveals that the plan's slices are wrong, update the plan before continuing. Use module specs for implemented current-state behavior; use the plan for future intended changes.

Classify risk with workflow-routing first. T2/T3 work uses this full loop; T1 may use a scoped local closeout unless a T2 trigger appears; T0 skips slice ceremony. If new facts reveal a higher tier, stop and complete that tier's closeout before commit.

For each acceptance criterion in the plan:

1. Read the next criterion only. Resist the urge to scan the whole plan and "implement related things." That's how slices grow into features.
2. Implement the criterion. Backend + frontend + migration if needed — but only what this criterion requires.
3. Write the test before declaring the criterion done. New branch needs new test. See write-tests rule, "Test Plan from Predicate."
4. Sync the spec/docs in the same set of commits. State machine row, enum value, API surface, env var — see document-module rule, "Same-Commit Spec Sync."
5. Run contract closeout when the diff requires it. See the checklist below before "ready to commit."
6. Audit the slice. Run the relevant section of audit-bugs against the files this slice touched. Cite evidence. Fix findings before commit.
7. Commit atomically — usually 2–3 commits per slice (feat:, test:, sometimes docs:). See git-commits rule, "Change Sizing."
8. STOP. Do not start the next slice until the current one is fully audited and committed.