`rm -rf Gentleman.Dots` uses a CWD-relative path and can delete an unrelated directory

[Albe841114]

Problem

The installer deletes Gentleman.Dots using a path relative to the current working directory. If the user runs the installer from a directory that happens to contain an unrelated Gentleman.Dots folder, that folder is deleted instead of — or in addition to — the intended clone.

Where it happens

Two call sites, both passing a bare relative path:

installer/internal/tui/installer.go:111:

result := system.RunWithLogs("rm -rf Gentleman.Dots", nil, func(line string) {

installer/internal/tui/installer.go:1199:

result := system.Run("rm -rf Gentleman.Dots", nil)

Neither resolves the path against a known clone location, and neither verifies that the target is the clone the installer created.

Steps to reproduce

1. Create a directory named Gentleman.Dots containing unrelated work — for example, a local checkout with commits that have not been pushed.
2. Run the installer from that directory's parent.
3. The directory is removed.

Expected behavior

The deletion targets an absolute path the installer itself resolved, and refuses to delete a directory it did not create — or one that holds unpublished work.

Actual behavior

rm -rf Gentleman.Dots is executed against whatever the current working directory contains under that name. Work that exists only locally is unrecoverable.

Additional note on what "safe to delete" means

A related trap is worth flagging for whatever guard is added: a clean working tree is not sufficient proof that deletion is safe. A clean checkout can still hold local commits that exist on no remote. git status --porcelain is empty and the work is still unrecoverable — committing it makes it more deletable, not less.

A sufficient check is: working tree clean, no untracked files, no stashes, and HEAD reachable from a remote-tracking branch. A branch with no configured upstream should be treated as unsafe.

Environment

Gentleman.Dots v2.12.2 (0258450), Arch-based Linux (CachyOS).