Files
tty7/crates/tty7-cli
l0ng-ai 4805cb1765 fix(doctor): notice a config directory that cannot be written to
Made the config directory read-only and asked doctor about it:

    CHECK            RESULT
    TTY7_CONFIG_DIR  set (/tmp/…)
    config           none yet — the defaults are the config
    server           ok (build 26.8.3)
    …
    rc=0

Meanwhile, on the same directory:

    $ tty7 new
    tty7: could not write the machine tree at /tmp/…/machine.json:
          Permission denied (os error 13)

Every `new`, every `tab new`, and every settings save fails, and the verb
whose entire job is "check this install" called it healthy. The config row is
about *reading* — it is answering "does the file parse", and there is no file
— so nothing in the table was wrong, and nothing in it was the answer either.
`tty7 doctor || alert` is exactly the thing that should have fired.

Now: a row naming the directory and what stops working, a headline on stderr
so `-q` still says it, `config.dir_writable` in the JSON, and exit 1 alongside
the unparseable-config case it sits next to.

The check writes a probe file and removes it, rather than reading the mode
bits. A read-only mount, an ACL, an immutable flag or another user's directory
all leave `0700` on something that refuses every write, and what is being
diagnosed is whether the write succeeds. A directory that cannot be reached at
all counts as unwritable — an install nobody can open is not a healthy one.

Verified against a live daemon in all three states: healthy exits 0, read-only
exits 1 with the row and the headline, and fixing the permissions goes back to
0. The unit test covers the probe both ways and that it cleans up after
itself; replacing it with an `exists()` check fails it.
2026-08-23 05:47:16 +08:00
..