pardes.git/test/snapshots/headersweep.golden, branch main

A shell command from the workspace's or a column's tag runs as a command pane in the session's directory, never typed into the terminal with the keyboard

2026-10-01T03:12:17Z

A command clicked in a header tag, or written to /tagexec or a column's exec, was typed into the active terminal when it sat at an empty prompt, so it ran in that pane's directory and left no run or exit record. It now always gets a command pane of its own in the session's directory, as acme's row and column tags have no directory but the session's. tags.md writes the rule down: pane words act on the column's active pane, a column's words on the column, shell commands as their own panes, and over 9P a pane's word is refused. Co-Authored-By: Claude Opus 5.5

Config opens the startup file, DumpConfig the settings report, and the workspace tag reads Dump Themes Config Debug Exit

2026-10-01T03:12:17Z

Config (SPC f c) opens init, found as the settings report finds it (opts.startup_config_path: $XDG_CONFIG_HOME/pardes/init or ~/.config/pardes/init, and the macOS and Windows paths config.md gives). A pane that already holds it is gone to instead; a file on disk is looked at; with none, an empty pane is named for it, and Save makes its directory and any above it first (File.make_dirs, fs.makeDirs) before writing. Without a configuration directory it says so and opens nothing. The report Config used to open, the startup path and every live setting, is DumpConfig, in a +DumpConfig pane. No alias keeps the old meaning. The workspace tag's default words put Themes where NextColor was, NextColor staying a builtin, and Config beside it. A tag the user edited is kept as it was: a dump stores only an edited one (topbar_custom), and a restore puts back only that. theme.snap types NextColor onto the workspace tag to click it, and tagnav's walk back to Dump takes five long-word steps. The rest of the re-recorded goldens differ in the workspace words and their widths only. Co-Authored-By: Claude Opus 5.5

A middle or right sweep over a column's or the workspace's tag runs or looks for what it swept, as a pane tag's does

2026-10-01T03:12:17Z

Both headers acted on the press: a middle or right press ran, or looked for, the word under it (or the header's selection when it was on that) at once, so a drag had nothing left to do. A sweep of `echo SWEPT` in a column tag ran a bare `echo`. They have done so since the headers were drawn apart from the panes; it is no regression, and the -l/Restore allocator fix (ompukopz) does not touch it. Now a press on a header holds a HeaderSweep (the column by its serial, or the workspace), which the drag extends, held to the header's row and text as a pane tag's sweep is. It is painted in its button's tint meanwhile, and the release runs what it swept in that header's context; a release that has not moved runs the word or selection a click always did. The other of middle and right cancels it (acme 2-3/3-2); the select button is inert, as a header's command already takes the held selection as its argument. Running on the release, a builtin from a header is announced as one from a pane tag is: the press used to set the announcement and the release clear it at once. find, restore, theme, topbarexec, ttyhelp, tutor and windowops re-recorded for that badge alone. headersweep.snap sweeps the column and workspace tags with the middle button and a word part with the right one, and cancels a sweep; headersweep-restored.snap sweeps both after Dump and Restore. Co-Authored-By: Claude Opus 5.5