---
name: on-task-done
description: "Task-completion flow: `/cr` (a `/code-review` answered with `/code-review-response`, which ends with `/distill`), update docs (spec/cheatsheet/compiler/optimizer), then run `mise run on-task-done` (build, clippy-fix, golden + format fixtures, doc-stdlib, format, tests; the longest task there is) and commit its generated changes. Invoke ONLY when the user asks for it by name or explicitly asks to run the completion flow — never on your own initiative, and not because a task looks finished."
---

# Overview

First, review the branch with `/cr`: a review answered with
`/code-review-response`, which ends with `/distill`.

Then update docs if applicable:

- docs/spec-*.md
- docs/cheatsheet.md
- docs/compiler.md and docs/optimizer.md, only when what they map changes: a
  phase, pass, or IR, or a rule that holds across phases. How one works belongs
  in its module doc.

Then, run `time mise run on-task-done`, which includes:

```sh
cargo build
mise run clippy-fix
mise run update-golden-fixtures
mise run update-golden-format-fixtures
mise run doc-stdlib
mise run format
mise run test
mise run test-wado
mise run check
mise run check-grammar
mise run check-highlight
```

`on-task-done` is the longest task there is.

## Notes

- Don't pipe it into `tail` — you lose the full log. Redirect to a file and inspect it afterwards if you need to trim output.
- The changes generated by the command are necessary. Commit them.
- Run it in the background and read the log when it lands.
- If the changes only include Wado programs, only `mise run test-wado` is required.
- If the changes only include documentation, only `mise run format` and `mise run check` are required.

## Flaky Commands

Some commands are flaky and may segfault:

- `mise run update-golden-fixtures` — the `golden-dump` batch tool sometimes segfaults mid-run (pre-existing issue). If it fails, run the individual golden generation manually for any new fixtures, then proceed.
- `mise run test` (i.e., `cargo test -p wado-compiler-tests --test e2e`) — the e2e test runner sometimes crashes with SIGSEGV when running all tests in parallel (pre-existing issue unrelated to compiler correctness).

If `cargo test` segfaults, reduce parallelism:

```sh
cargo test -p wado-compiler-tests --test e2e -- --test-threads=4
```

Or run individual fixture tests directly:

```sh
cargo test -p wado-compiler-tests --test e2e -- <fixture_name>
```