[max-sixty]

Two of the five machine-readable-output requests NathanaelRea opened (#3696–#3700), reviewed as a set and implemented where the gap was real.

wt config approvals list --format=json (#3698)

The command already computed the four distinctions an orchestrator needs — no commands, approved, approval-required, and stale — read-only, without prompting or writing. It had no --format flag, so the only way to learn that a non-interactive run would stop for approval was to run the operation and catch NotInteractive, or to pass --yes and approve whatever was there.

{
  "state": "approval_required",
  "commands": [
    {"phase": "post-start", "name": "dev", "template": "npm run dev", "approved": false},
    {"phase": "pre-merge", "template": "cargo test", "approved": true}
  ],
  "stale": ["some removed command"]
}

state is what a caller branches on. stale stays a separate list rather than a fourth state, because it co-occurs with all three — and those are the approvals --yes would silently re-approve after their command template changed, which is exactly what an orchestrator preserving the approval model needs to see.

A flag on the existing read command rather than a new status verb, matching wt config show, wt config state get, wt config state logs, and wt list.

Closes #3698.

branch_outcome on removal (#3700, partly)

wt remove --format=json reported the branch as one boolean, collapsing five internal outcomes into two values:

Internal outcome	branch_deleted was
Deleted	true
Deferred — handed to a detached process, result never observed	true
NotAttempted — no branch, or --no-delete-branch	false
Retained — a sibling worktree has it checked out	false
Retained — the CAS refused; the ref moved under us	false

The last row is the exact race #3700 asks for protection against. Worktrunk already deletes with git update-ref -d <ref> <oid> and already fails closed when the ref has moved — then reported it as the same false that means "you asked me not to". And Deferred reported true on intent.

branch_outcome names it instead: deleted, deferred, not_attempted, retained_unmerged, retained_checked_out, retained_raced, retained_failed. A caller that sees retained_raced knows to re-read the ref and retry, which is what the guard detects it for.

This does not close #3700. That issue asks for an input — a caller-supplied expected OID that makes wt fail closed against the orchestrator's own observation. This is an output. They land in the same place on the default path, because the integration check already refuses to delete unintegrated content, so the caller was never going to lose commits — they just couldn't classify the refusal. Where the gap is real is --force-delete / -D, which takes the early return in delete_branch_if_safe and runs git branch -D with no integration check and no CAS. If an --expected-oid flag lands, it has to gate that path.

Notes

• Output-format break. branch_deleted is replaced, not supplemented, on wt remove --format=json and on wt step prune --format=json's live path. Per CLAUDE.md, output formatting is on the flexible side of the interface line; flagging it here so the release changelog picks it up.
• wt step prune --dry-run keeps branch_deleted. A dry run predicts; it runs nothing to have an outcome. Different thing, different name, documented as such.
• retained_raced and retained_checked_out have no deterministic CLI trigger. Both come from windows between wt's own fresh read and the ref mutation, which no hook can be scheduled inside. They're covered at the unit level (branch_fate_from_result_mapping, branch_fate_json_outcome_is_distinct_per_fate, and cas_rejects_delete_when_branch_advances in src/git/remove.rs, which drives the race with a stale snapshot). The integration tests cover the two reachable contrasts: retained_unmerged via a pre-remove hook that commits, and not_attempted via --no-delete-branch.
• print_json lives under src/commands/list/ and now has a third caller from outside that module. Worth a more central home; not moved here.

The other three

Reviewed but not implemented:

• Allow selecting the wt list JSON schema on the command line #3696 — already possible. wt --config-set 'list.json-schema = 2' list --format=json pins the schema per invocation above every config layer, as does WORKTRUNK_LIST__JSON_SCHEMA. Answered on the issue; what's left is a docs gap and making an out-of-range value fail rather than degrade in JSON mode.
• Add machine-readable error codes to JSON commands #3697 — the machine-readable error channel. A real gap and the one policy call in the set; not started.
• Include stable branch identity in structured hook-log entries #3699 — aimed at wt config state logs --format=json, which is a directory listing reconstructed from paths, under a model that overwrites. The append-only run record it wants is commands.jsonl.

Testing

cargo run -- hook pre-merge --yes green: 4533 tests, clippy, fmt, doctests, rustdoc, docs sync.

This was written by Claude Code on behalf of max-sixty

[worktrunk-bot]

Reviewed the full diff. The change is sound and well-tested — flagging one thing per repo policy rather than approving.

Data-loss surface (no-approve, not a defect). The diff edits src/output/handlers.rs, src/commands/step/prune.rs, and src/commands/worktree/types.rs, all of which carry the branch-deletion machinery (git branch -D, git worktree remove, the rm -rf background tail). Per this repo's review policy I don't auto-approve changes that touch the deletion surface — leaving the merge call to you.

That said, I verified the change is classification/reporting only and does not alter any deletion decision:

• BranchFate::deleted() is unchanged (Deleted | Deferred → true), so deletes_branch, the prune summary counts, and the dry-run branch_deleted field are all behavior-preserving.
• The new from_outcome centralizes the exact mapping the two old inline match blocks (in from_result and handle_branch_only_output) used — Integrated/ForceDeleted → Deleted, NotDeleted → Unmerged, RetainedCheckedOut → CheckedOut, RetainedRaced → Raced, Err → Failed — so no outcome reclassifies.
• On the live prune JSON path, every candidate in removed passes through record_fate before serialization (the two removed.push sites and the deferred-current tail), so c.fate.map(|f| f.json_outcome()) is Some by construction; the null fallback is unreachable there. Dry-run correctly keeps branch_deleted since it runs no removal.

The deferred → deferred and retained_raced distinctions are genuine honesty improvements over the old boolean, which reported a detached deletion as true and a CAS refusal as the same false a caller-requested retention gives.