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.
• The user 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. Release work follows docs/RELEASE_CHECKLIST.md. Local builds are unstamped ((dev)), 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) \
     scripts/dev-cargo.sh build --release --locked -p codewhale-cli --bin codewhale
   

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.