CtrlK
BlogDocsLog inGet started
Tessl Logo

cw-dogfood

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.

73

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

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-orientcw-slicecw-gatesdogfoodcw-landcw-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.
Repository
Hmbown/Codewhale
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.