fix: close three data-loss paths found by the three-way audit

[d6veteran]

Akira, Robin, and Toni audited independently in separate lanes. All three found the same meta-pattern: a fix applied to one instance of a bug, with its siblings never checked.

Grades: B− systems, B− tests, C+ product.

223 tests (was 209). shellcheck clean.

Three data-loss paths, all reproduced before fixing

1. session done still deleted data — my fix moved the bug rather than closing it

This morning I replaced two git diff calls with git status --porcelain to catch untracked files. Akira checked the next case:

.gitignore contains .env
worktree/.env = SECRET_DB_PASSWORD=hunter2
git status --porcelain → ''      ← guard passes
session done → exit 0, "Session closed"
.env → DESTROYED

--porcelain omits ignored files; git worktree remove deletes them. A file is gitignored because it's generated or because it's secret, and the second kind exists nowhere else.

Guard now passes --ignored, exempting only .claude-session — the marker this command creates and is meant to remove. Without that exemption the guard blocked every session close, which the suite caught on the first run.

2. Damaged markers in CLAUDE.md deleted user content

block_install and block_remove locate the block by scanning for START then END. With END missing, both deleted everything from START to end of file. That's a file the tool tells users to hand-edit, so a lost marker is an ordinary accident.

Verified: a CLAUDE.md with a broken block plus a personal deployment runbook. claude-team use akira → runbook gone, exit 0.

Both writers now refuse on unbalanced or duplicated markers rather than guessing which of the user's lines belong inside the block.

3. A pipe silently corrupted the branch index

The index is a pipe-delimited table read with awk -F'|'. Git accepts | in a ref name, and "sprint-42 | scoped" is an ordinary plan slug. Result:

$ claude-team branch start feat/pipe --plan 'sprint-42 | scoped'
✓ Branch feat/pipe registered.
$ claude-team branch status
Active branch: none          ← already lost
$ claude-team branch done
error: No active branch found. Nothing to close.

Worse via session start: session done printed success, deleted the worktree, and left the row active forever.

Both write sites now reject the character — cheaper than hardening every reader. session start validates before creating the worktree, so a rejection leaves no orphan. Separately, session done now reports when its rewrite matched no row, since silence there is what turned a corrupt row into a success message.

Test infrastructure

• The branch section ran against ambient $PWD and asserted the repo's own name. Failed in a differently-named clone; failed ten ways outside a git repo. Both happen to contributors using this tool's own worktree sessions. Now has a fixture like every other git-touching section.
• Nothing asserted the generated description: field — the one Claude Code reads to pick a subagent. Collapsing all 17 to one string passed 209 tests. A content assertion catches it now, because regenerate-and-diff structurally cannot: the generator would agree with itself.
• A mktemp -d nested inside a string leaked a directory on every run, green or not.

Documentation

• gtm.md is marked Published and sold "Ten specialists" and "Bash 3.2+" while the product has 17 and hard-exits below Bash 4. A macOS reader following it hit a fatal error on first run.
• plugin.json hardcoded "Seventeen" — the same drift just fixed in the tests. The count is now simply gone. A number that isn't written can't go stale.
• Test count said 175 against an actual 209.

Verification

• 11 of 13 new tests fail against main, including user content below a damaged block survives (file missing: 'step one').
• The description: assertion proven by collapsing the generator's output and watching it go red.
• Suite now passes from a renamed clone, from outside a git repo, and leaks zero temp directories.

Still open

Akira's lock-breaking race under contention (a stale lock plus concurrent writers can discard a successful write), and _TMP_FILE cleanup being dead code because command substitution runs it in a subshell. Both are real and reported; neither is a silent data-loss path.

---

Generated by Claude Code