cw-dogfood

name	cw-dogfood
description	Use when a Codewhale change needs proving in the real product, or when asked to build/install/dogfood the local binaries: stamped release build, atomic install, fresh-shell verification, and the manual QA that gates cannot cover.

cw-dogfood

Green gates prove the code compiles and asserts. They do not prove the product works. Freezes, route contamination, focus theft, streaming cadence, and approval-flow regressions all live in the runtime, where no unit test looks. This stage puts the actual binary on your PATH and makes you use it.

Stage 4 of the loop: cw-orient → cw-slice → cw-gates → dogfood → cw-land → cw-handoff.

When to use

• The change is user-visible: TUI layout, motion, streaming, model or Fleet selection, approvals, commands, install paths.
• Before landing a release candidate, or before claiming a runtime behavior is fixed.
• Hunter asks to "install the build", "dogfood this", or "get this on my machine".

Workflow

1. Gate first. Run cw-gates to the rung the change deserves. Never install an ungated build.

2. Build stamped. Local builds are unstamped ((dev)) since #5245, and the installer refuses an unstamped binary on purpose — the stamp is what proves the thing on your PATH is the thing you just built:

   CODEWHALE_BUILD_SHA=$(git rev-parse HEAD) \
     cargo build --release --locked -p codewhale-cli -p codewhale-tui
   

3. Install atomically. Use the script; do not hand-copy:

   scripts/release/install-dogfood.sh          # defaults to target/release
   

   It refuses a dirty source tree (override deliberately with CODEWHALE_ALLOW_DIRTY_DOGFOOD=1, and then say so wherever you report the install), verifies the binary embeds current HEAD, installs codewhale and codew into ~/.cargo/bin and ~/.local/bin (override with CODEWHALE_INSTALL_DIRS), re-signs ad-hoc on macOS, and verifies resolution from a fresh login shell.

   Never cp over a running binary. On Apple Silicon that poisons the kernel's code-signature cache for the inode, and later execs hang until reboot. The installer does tmp-copy plus atomic mv for exactly this reason.

4. Verify from a fresh shell, not this one. A correct target/release binary and a stale codew on PATH is the classic false pass:

   zsh -lc 'type -a codew codewhale; codew --version'
   

   The version string must contain the short HEAD SHA you just built.

5. Use the product. Run it in a real terminal and exercise what you changed. crates/tui/AGENTS.md is the authority on what to look at; pick the terminal sizes relevant to the change from 40x12, 60x16, 80x24, 100x32, 140x40. Judge motion from repeated frames, never a single screenshot, and check it against docs/MOTION_CONTRACT.md. Remove inherited NO_COLOR, TERM=dumb, and tmux motion overrides when they would invalidate what you are looking at.

   Scenarios worth exercising when they are in scope:

   • Liveness under fanout — spawn several workers; typing, render, cancel, and the roster stay live throughout, and Esc cancels mid-fanout.
   • Route isolation — multiple terminals on distinct provider/model routes, zero cross-terminal contamination, no provider+model mismatch.
   • Running-turn input — during a busy turn, Enter queues a follow-up, an empty Enter promotes the oldest, Ctrl+Enter steers, Shift+Enter newlines.
   • Approvals — ordinary tool approval vs. repository-law approval; the screen must name the repository constitution where it applies, and decorative motion must go still when the user owns the next action.
   • Empty, narrow, and first-run states — compact layouts remove chrome before content.

6. Headless surfaces, when the change touches them. codewhale exec is the one-shot worker path; codewhale app-server is the local control/API surface. They must agree about routing, permissions, and event states — a disagreement is a runtime bug, not a QA note.

   scripts/release/app-server-smoke.sh
   codewhale exec --auto --output-format stream-json --model <model> "Reply PONG"
   

   Provider calls spend tokens. Ask before running the paid ones.

7. Record what you saw. Dimensions, inputs, visible state, side effects. A screenshot proves layout and color; only live observation or a recording proves motion and continuity.

Red flags / don't

• Don't cp a binary over a running one. Use install-dogfood.sh.
• Don't verify in the shell that already has the old binary resolved.
• Don't claim animation or cadence quality from a still image.
• Don't substitute a full-screen assertion harness for looking at and using the product.
• Don't install from a dirty tree without saying so in the report — the version stamp will not show the dirt.
• Don't delete target/dogfood/* bundles if the lane keeps them: they are release evidence.
• Don't spend provider tokens on smoke runs without approval.

Output

• The exact build command, including the CODEWHALE_BUILD_SHA stamp.
• The installer's destinations and its fresh-shell verification result.
• codew --version from a fresh login shell, with the SHA visible.
• Per scenario: terminal size, what you did, what you observed — and which scenarios you did not exercise.