`<config>/history` was two different things at once. The window keeps the
input bar's command store there as a *file* (`terminal::history`), and the
daemon put each pane's `HISTFILE` in a *directory* of the same name. A path
is one or the other, and the daemon created its directory the moment
`per_pane_history` was switched on, so the daemon won.
After that the window's `append` opened a directory, got an error, and — the
call site being `if let Ok(mut f) = open(..)` — dropped the command line
without a word. Up and Ctrl-R went on offering whatever had been recorded
before the setting was turned on and never grew again. Nothing in the UI or
the log said why, and the two halves are in different crates, so neither side
had any reason to notice the other's name.
Per-pane files move to `<config>/pane-history/`, which leaves the old name to
the file that should have had it. An install that already tripped over this
is carried across on the next start: the directory sitting at the old name is
exactly what belongs at the new one, so it is renamed rather than abandoned —
but only when it *is* a directory, since a plain file there is the window's
store and moving that would take the very thing this repairs, and only when
the new name is free, so a second call cannot bury a directory in use.
Verified end to end against a daemon: with the setting on it now creates
`pane-history/` 0700 with the pane files in it, and an append to
`<config>/history` succeeds where it previously failed. Seeding an
old-layout install with `history/pane-9` and starting the daemon leaves the
line intact at the new path.
Guards: one reads the window's source for the names it passes to
`config_path` and fails if the daemon's directory is among them, so moving
either side onto the other trips it; one covers the three ways the move can
lose data (directory moves, file stays, occupied target is not overwritten).
Both were checked against injected regressions. The privacy page and the
integration test that read the path follow it.
The page said shell history is "your shell's own file, exactly as before
— unless you turned on per-pane history, which merges back into it". The
merge is real, but it is not the whole account: with per-pane history on,
tty7 points each pane's `HISTFILE` at `<config>/history/pane-<n>`, and
what accumulates there is the command lines someone typed.
That is the most sensitive thing tty7 causes to be written anywhere, and
the page named neither the location nor the mode. It enumerates
`<config>/scrollback/*.bin` down to its 0600 and its retention rules;
this belongs on the same footing.
Verified rather than read off the source: with the setting on and the
server restarted to pick it up, a fresh pane reports
HISTFILE=<config>/history/pane-1
and the directory is created `0700`. The files inside are the shell's own
writing, under the user's umask, which the page now says.
The guard asserts the path appears, not the prose around it — the path is
the part a reader needs in order to go and look.
The privacy page accounts for every file tty7 leaves in the config
directory, and `crash.rs` has a test holding it to that. The test named
two files. There are three: the updater appends `<config>/update.log`
while it installs a release — what it verified, what it replaced, and why
it stopped if it did.
It is written whenever an update runs, not only under `TTY7_LOG`. That
makes it exactly what the test's own comment describes as belonging on
the page: "a file written without being asked for". It is also the only
account of a swap that happens after the window is gone, which is why it
exists.
The guard now names all three, and was checked against the page as it
was.
Also corrects a filename I got wrong in the previous commit: the doc
comment on `install_crash_log` called this file `tty7-updater.log`. There
is no such file — I invented the name while describing what a silent
panic costs, and it went in unchecked. It is `update.log`, and finding
that is what turned up the missing page entry.
"What is stored, and where" listed settings, keychain entries, scrollback
and shell history, and omitted both files that carry incidental personal
data:
crash.log written whenever tty7 panics — the hook is installed
unconditionally, so nobody opts in. Time, version, panic
message, backtrace. Capped at 256 KiB, never uploaded.
tty7.log only while TTY7_LOG or RUST_LOG is set, and genuinely absent
otherwise. At debug it carries the directories and workspace
names in each request.
A page that enumerates storage and leaves out the two files most likely
to end up attached to a bug report is answering the wrong question, so
both rows say what is in them and what to check before sending them on.
Noticed while reading a debug log for something else: a dependency had
written this machine's hostname and working directory into it.
"What leaves your machine" needed no change — nothing sends either file
anywhere, which is why each row says so.
The test lives next to the panic hook, where a change to what gets
written is a change someone is already making.
38 pages under docs/, written against the source rather than the README:
config keys and their clamps from core::config, default keybindings from
ui::keymap, every CLI verb and flag from tty7-cli, agent aliases and
hook/fork/resume support from core::cli_agent, and Settings paths taken
from the actual en-US strings.
docs/features.md and its zh-CN translation are retired — everything in
them now lives in a page of its own, plus the two things they carried
that nothing else did (IME input, the performance notes). README and
README.zh-CN point at docs/ instead.
Screenshots and videos are placeholders for now: docs/images/placeholder.svg
with a caption naming what each shot should be.
Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com>
l0ng-ai
l0ng-aiandl0ng-ai