01It starts in the file’s own folder
The working directory is the directory of the file in the tab, not the project root. If that folder has gone, it falls back to the open folder, and then to your home directory. Two tabs holding files in different folders give two shells in different places.
02A clean tab reloads itself, silently
Run a formatter and the tab updates. It does not ask, deliberately: once a terminal can write to these files, a confirmation per file would mean a dialog storm for a command you just typed yourself.
03A tab with unsaved edits is never overwritten
It asks — “changed on disk. This tab has unsaved changes. Reload and discard them?” — with Reload and Keep Mine. Choosing Keep Mine moves the recorded modification date forward, so it does not ask again about the same change.
04Your login shell, with -l
The shell is started as a login shell so ~/.zprofile and friends are read. Tools installed by Homebrew or a version manager are on PATH because the shell set it up the way it always does.
05TERM and COLORTERM are set properly
TERM is xterm-256color and COLORTERM is truecolor, so programs that check before emitting 24-bit colour actually emit it.
06TERM_PROGRAM says Linelark
That is the variable tools read to find out which terminal they are inside, and answering it honestly is how they adapt correctly.
07Linelark_FILE names the front file
The working directory only ever said which folder. This says which file, which is the thing a command-line tool usually wants.
08It is set or removed, never inherited
The app can itself be launched from one of these shells. Without clearing it, an untitled tab would inherit a stale value and claim to be somebody else’s file.
09Debug leakage is stripped
OS_ACTIVITY_DT_MODE and friends are removed from the child environment, or programs launched from a development build think they are being debugged.