Fix wt list column sizing, alignment, and headers

[max-sixty]

Eight fixes to wt list — four to how the table lays out, one to what a detached or prunable worktree shows, and three to the page that documents it.

The table

A single 58-character branch name sized the Branch column for every row: at 60 columns the table degenerated into a branch list with nine columns hidden, and at 200 it still lost Message. Branch now sizes to min(longest, 32) and elides with …, the way Message already does. --format=json still carries the whole name.

Remote⇅ in a repo with no remote held its blank seven columns open while Message, Commit, Age and Path — each with something to say on every row — were dropped for want of them. The empty-column penalty now exceeds every base priority, and the allocation loop stops admitting empty columns once a populated one has failed to fit. Remote⇅ also learns it is empty before any task reports: a repo with no remote has no branch that can track one, read O(1) off the bulk config map.

main↕ and main…± said main in a repo whose default branch is trunk. Both columns are sized by their data (↑99 ↓99, +999 -999), so a name inside that budget costs the table nothing; a longer name, or one wt can't resolve, gives way to a generic base rather than widening two columns on every row. One decision serves both columns, taken from the tighter budget, so they can never name different things.

Four alignment defects: a right-aligned numeric header (HEAD±) stood over the deletions half of its two-part field, so a lone +1 landed to its left — the header now centres over the separator. Age was left-aligned, so now and 4m didn't line up on the unit; it is right-aligned with its header. Data rows carried up to 14 characters of trailing padding the header line never had, which a reader selecting a row picks up. The footer ran to 67 characters in a 40-column terminal the table itself fit — the hidden-column list is longest exactly where there is least room — and now wraps at the terminal width.

Detached and prunable rows

A detached worktree rendered as a bare hash under Branch, wearing ⚑ on loan from branch_worktree_mismatch — which it was only flagged with because a worktree with no branch has no branch-implied path to sit at. It gets ⊘, and stops claiming to be off-template, so ⚑ again means only what it says. A prunable worktree showed four · loading glyphs that never resolved: its directory is gone, so no task is ever spawned for it and no cell is coming. Those cells render blank, leaving ⊟ in Status as the row's whole story.

The page

Documentation corrections

• The summary footer counted hidden columns ("3 columns hidden") without saying which, and the page never explained that the table drops columns to fit. The footer now names them ("hidden: Path, Commit, Message"), and a paragraph under ## Columns covers the drop order, [list] columns, and that --format=json shows everything.
• The JSON section documented deprecated schema 1 at 159 lines and nine sub-tables while schema 2 — what a future release makes the default — got 88 lines and one table. Schema 2 now carries the full reference (envelope, item fields, a sub-table per object, the three value vocabularies) and the worked jq recipes. Schema 1 keeps a paragraph, the deprecation pointer, and a schema-1 → schema-2 mapping table covering every field it documented.
• The CI-cache line pointed at wt config state, a group with no default action; it names wt config state cache.
• wt list statusline --format=json was documented as "a one-entry array in the wt list --format=json schema", which holds only under schema 1. It emits the current schema — an array under 1, the envelope under 2 — and the line now records why that surface stays silent about an unset [list] json-schema while plain wt list nags: a prompt consumer can't act on a warning drawn over its own line.
• The Status-symbols section documented every subcolumn except the branch marker. Both JSON schemas gain an additive marker field, so the value is readable without parsing it back out of symbols.

UX survey items: #24, #34, #58, #89, #90, #91, #92, #93.

Reviewable files: src/commands/list/** (layout.rs, columns.rs, render.rs, model/item.rs, mod.rs, json_v2.rs), the list section of src/cli/mod.rs, src/styling/line.rs, and .claude/skills/writing-user-outputs/SKILL.md. Generated mirrors and snapshots are regenerated.

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

🤖 Generated with Claude Code

https://claude.ai/code/session_01XAUYWFN9d9oh6jyoQiouHb

[worktrunk-bot]

Three findings, all reproduced against a build of this head. The layout work itself reads well — the RepoFacts bundle, the base_label budget derivation, and dropped_populated all hold up under the cases I tried, including custom columns with an out-of-band priority.

The footer wrap doesn't survive progressive mode, which is every TTY run — see the inline comment on src/commands/list/mod.rs. ProgressiveTable::prepare puts the whole footer through truncate_visible, which counts \n as zero width, so the wrapped string is cut as if it were one line. At 40 columns the entire hidden-column list is replaced by a … sitting on its own row:

○ Showing 4 worktrees, 3 ahead, hidden:
…

The buffered path (wt list | cat with COLUMNS set) wraps correctly, which is what the new width_30/width_60 snapshots cover — so the tests pass while the interactive case the PR describes is the one still broken.

Trailing padding still survives on a row whose last cell is empty — src/styling/line.rs inline. Reproduced with [list] columns ending on a custom column that's empty for some rows; the header line and the populated row come out clean, the empty ones keep their five spaces.

The hidden-column list ignores [list] columns order — src/commands/list/layout.rs inline.

Repros

Four worktrees, no remote, target/debug/wt at 9c65cf2.

Progressive footer (script -qc "stty cols 40; wt list" /dev/null), at widths 40 and 60:

○ Showing 4 worktrees, 3 ahead, hidden:
…

○ Showing 4 worktrees, 3 ahead, hidden: Remote⇅, Path,
  Com…

Trailing padding ($ marks end of line):

$ COLUMNS=120 wt --config-set '[list]
columns = ["branch", "status", "ticket"]
[list.custom-columns.ticket]
template = "{% if branch == \"feature-beta\" %}T-1{% endif %}"' list | cat -A
  Branch         Status    ticket$
@ main               ^     $
+ feature-alpha      ↑     $
+ feature-beta       ↑     T-1$
+ feature-gamma      ↑     $

Hidden-column order — configured order is message, commit, branch, status, so in display order the dropped pair is Message, Commit:

$ COLUMNS=30 wt --config-set '[list]
columns = ["message", "commit", "branch", "status"]' list
  Branch         Status
...
○ Showing 4 worktrees, 3
  ahead, hidden: Commit,
  Message

One thing outside the diff: src/commands/list/model/status_symbols.rs still documents the Gate 2 priority as ✘ > ↻ > ⊟ > ⊞ > ⚑ > / — in the module docstring under # Gate 2: Worktree state, and again in the WORKTREE_STATE comment inside PositionMask::FULL. ⊘ is missing from both, and the Gate 2 Inputs list doesn't mention the new has_branch argument. docs/src/content/docs/list.md and model/state.rs were both updated; this file is the one that wasn't. Happy to push that as a commit if you'd like.

[worktrunk-bot]

The three fixes from last round check out. I reproduced the hidden-column ordering against a build of this head (display_sort_key has selected in scope, and candidates are pre-filtered by the selection, so a hidden kind is always in it and never lands in the usize::MAX bucket — Gutter maps to (0, 0) and is always allocated anyway), and the empty-last-cell trim. Two things left.

⊘ is still missing from five places in status_symbols.rs. Three sites got it this push; these didn't. One is inline below; the other four are outside the diff:

• PositionMask::FULL's WORKTREE_STATE entry, whose comment reads WORKTREE_STATE: ✘↻/⊟⊞⚑ (1 char, priority: conflicts > in-progress operation > prunable > locked > duplicate_branch > branch_worktree_mismatch > branch). This is the site I named last round; what moved was the const WORKTREE_STATE declaration a dozen lines above it (Worktree: ✘↻/⚑⊘⊟⊞). Both the glyph set and the priority prose need detached, sitting between locked and duplicate_branch — WorktreeState's own docstring in model/state.rs gives the order as Prunable > Locked > Detached > DuplicateBranch > BranchWorktreeMismatch.
• the Gate 2 walkthrough in the module docstring, step 4: "…continuing down through ⊞, ⚑, /, nothing."
• StatusSymbols' display-order list: "Worktree state: ✘, ↻, /, ⚑, ⊟, ⊞ (operations + location)".
• the Gate 2 comment inside refresh_status_symbols: "takes priority over metadata family (⚑⊟⊞/)".

Happy to push all five as one commit if you'd like.

Optional, on StyledLine::trim_end. The empty-segment branch I suggested last round is subsumed by moving the existing trimmed.is_empty() test above the length comparison: "".trim_end_matches(' ') is empty, so one branch covers both an empty segment and an all-space one, and the loop drops to three cases with no special case left to explain.

while let Some(last) = self.segments.last_mut() {
    let trimmed = last.text.trim_end_matches(' ');
    if trimmed.is_empty() {
        self.segments.pop();
        continue;
    }
    if trimmed.len() == last.text.len() {
        return;
    }
    last.text.truncate(trimmed.len());
    return;
}

Same behaviour on every input I could construct — it's a refinement of my own earlier suggestion rather than a defect, so take it or leave it. (Left out of an inline suggestion because the range would span the explanatory comment too.)

Holding the verdict while the progressive-footer decision on src/commands/list/mod.rs is still yours to make.

[max-sixty]

All five ⊘ sites are in now, including PositionMask::FULL's priority prose with detached between locked and duplicate_branch — I'd patched the const declaration a dozen lines above and taken it for the site you named.

Took the trim_end refinement too; hoisting trimmed.is_empty() above the length comparison covers both cases in one branch and leaves nothing to explain.

The progressive-footer decision is the only thing still open here.

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

[worktrunk-bot]

Four of the five ⊘ sites landed — the Gate 2 walkthrough step, PositionMask::FULL, the display-order list, and the refresh_status_symbols comment all name it now. The fifth didn't: status_symbols.rs line 60 still reads the attribute family (⊟⊞⚑/) is metadata, always known, so the docstring now lists ⊘ in the priority order on the line above and drops it from the family breakdown on the line below. The inline thread from last round is still open on that line with the one-click suggestion.

Nothing else new on this push — trim_end and the two realigned snapshots read as intended. Verdict still held on the footer decision, which remains yours.

[worktrunk-bot]

The footer fix is right, and the shape you took is better than the one I sketched: leaving redraw_line alone and giving finalize its own writer means the multi-row case never has to be re-derived from lines_up. Walking the escape stream by hand, the resting position comes out correct both when the write fits (24 rows: footer at rows 6–8, cursor rests at 9) and when write_prompt_reserve pushes past the bottom and the screen scrolls. The per-row budget in prepare is a no-op for single-line content — truncate_visible returns the input unchanged at width <= max_width, and the table's max_width is the same terminal_width() that format_summary_message wraps to, so a correctly wrapped footer row is never re-cut.

Two things, both about the invariant this makes load-bearing rather than about the fix.

The struct docstring still describes one physical row per lines entry. ProgressiveTable's docstring lists the structure as "Header row / N data rows / Spacer / Footer" and closes with "all redraw math is relative to that fixed resting position"; the lines field reads "Previously rendered content for each line (header + rows + spacer + footer)". After this change the final footer entry can span several rows, and prepare preserves \n for any entry it is handed — so "every entry except the final footer occupies exactly one physical row" is now what redraw_line's lines_up = self.lines.len() - line_idx and the overflow branch's MoveUp(self.lines.len()) rest on, and it is stated only in a comment inside finalize. CLAUDE.md asks for these specs to carry the contracts and invariants and be kept current.

A debug_assert! on the prepared string in update_row and update_footer would pin it as well as document it — a future multi-line row would fail a test instead of silently miscounting a redraw. I checked the producers: format_list_item_line, the header, the loading footer in collect/mod.rs, format_stall_footer, and sanitize_cell for custom columns (which maps \n to a space) — none can emit a newline today, so the assert stays quiet. Happy to push the docstring update and the asserts as one commit.

The new test pins the footer text but not the cursor accounting, which is what redraw_final_footer newly owns. A MoveUp that landed one row too high would clear the spacer and write the footer over it, and every assertion in the test still passes — split_once("Showing") only looks at what is below. The inline suggestion adds the spacer check. test_list_progressive_overflow also asserts final_cursor, and an equivalent assertion here would pin that the reserve survives a footer that grew into it; I left that out of the suggestion because the expected row depends on how many rows the footer wraps to at 40 columns, which I can't run here — say the word and I'll push it.