/sota-resume

description: Find and finish the open work in this project — inventory every tracker, checkbox and marker with a controlled search, classify what is actually actionable, agree the list, then execute one item at a time against the project's own verification. Run it at the START of a session.

Find and finish the open work in this project.

This is the other end of `/sota-close`: that command records open items where a new session will trip over them, this one picks them up. Neither assumes the other ran — most projects scatter their open work across files written by people who are not here.

0. Load the shell rules before the first search

Invoke the `sota-shell-scripting` skill and read its `rules/06` (ad-hoc commands) in full **now**, before step 1. Every step-1 sweep is an ad-hoc command whose *absence* you are about to report, and that file owns how such a sweep fails silently. The parentheses below are pointers into it, not substitutes: a citation loads nothing. Field-reported 2026-10-11: a resume pass ran ten sweeps with this command's paraphrase alone, and two of its defects were ones rules/06 prevents.

1. Inventory — and prove the search works before trusting it

Search widely before concluding anything:

• files named `TODO*`, `BACKLOG*`, `ROADMAP*`, `NEXT*`, `next-steps*`, `PLAN*`, `*.local.md`;
• unchecked `- [ ]` boxes in docs;
• `TODO|FIXME|XXX|HACK` markers in tracked source;
• `Unreleased`, "planned", "not yet", "for now" in the CHANGELOG and README;
• deferred items in ADRs and design docs — an ADR that says "we defer X" *is* a tracker row;
• open issues and PRs, if a remote is configured;
• **work nobody wrote down** — output another session left here with no tracker line.

`git status --ignored --porcelain` lists ignored paths (`!! campaigns/`); for each output-shaped one (results, campaigns, evidence, runs) count `find <dir> -newer <newest handoff> -type f`. For every sibling repo the trackers name, read `git -C <sibling> log --since="<handoff date> 00:00" --oneline`, or better the handoff's exact timestamp or `<last-known-sha>..HEAD`: a **bare** date gets the current clock time attached, so `--since=2026-10-24` run in the evening drops that day's morning at exit 0 (`sota-shell-scripting` rules/09 §5a; field-reported 2026-11-01, 2 of 19 commits, after this line had said exactly that). Field-reported 2026-10-24: a sibling session had run this repo's campaign tool into a gitignored directory three days earlier and recorded it only in its own repo. It made an operator-deferred item that carried a spend ALREADY DONE, and no text search above can find it, because nothing describes it. To classify **uncommitted** work, compare tree ids instead of reading diffs: stage the working tree into a throwaway index at a path that does not exist yet (`d=$(mktemp -d); GIT_INDEX_FILE="$d/index" sh -c 'git add -A && git write-tree'`; an empty `$(mktemp)` file is refused, `index file smaller than expected`) and compare it with `git merge-tree --write-tree <branchA> <branchB>` for the open branches it may duplicate. An identical id proves the uncommitted paths are exactly those branches combined (field-reported 2026-11-01: 65 paths, two open PRs; reproduced, and one extra edit breaks the match).

**A clean "nothing found" is the result you were hoping for, which is exactly when to distrust it.** Five failure modes produce a confident zero, and none of them prints an error:

• **The searcher skipped the tree.** `grep -r` does not follow symlinked directories, and

package dirs, dotfile checkouts and installed-plugin trees are symlink farms. Which flag rescues you depends on the *binary*: on BSD grep neither `-r` nor `-R` traverses one. Say which tool and which binary you used — `type grep`, which names a shell function or alias (`command -v` prints only the bare name for a function, so it cannot answer this); then call the real binary by path (`whence -p grep` in zsh, `type -P grep` in bash) — and reach for `find -L`, `rg --follow` or `ugrep -R` (`sota-shell-scripting` rules/06 §2). `rg` also skips any path an ignore rule matches **even when the file is tracked** (`git add -f`): search what the repository holds with `git grep`, or what is on disk with `rg --hidden --no-ignore`.

• **The flag meant something else.** `rg -r` is `--replace`, not "recursive"; it silently

rewrites every match to the next token and the output looks like content (`sota-shell-scripting` rules/06 §2a).

• **The pattern cannot match on this machine.** `\b` in `git grep -E` on macOS is read as the letter

`b` (no error): it usually matches nothing, exit 1, and can match the wrong lines. Use `-w`, a bracket boundary, or no boundary (`sota-shell-scripting` rules/06 §2f).

• **The lister answered about one page.** `gh issue list` and friends cap at 30 by default,

exit 0, empty stderr. A result whose size equals a round number you or the tool chose is a page until proven otherwise (`sota-shell-scripting` rules/09 §5).

• **The query asked your question, not the project's.** `grep` answers "does this string

appear", never "is this idea covered". A project that writes "parked" will not match "TODO".

**Run one query whose answer you already know, in the same invocation as the real one and through the same input path** — the same file list, the same `xargs`, the same redirections, differing only in the needle; a control on the same line that reads a different input proves only that the shell ran — and drawn from where your search is least likely to reach, because a control from inside a too-narrow scope passes anyway (`sota-shell-scripting` rules/06 §2). If the control returns nothing, the instrument is broken and the absence is worth nothing. Then report the **denominator** — how many files you actually scanned — beside the finding count. `0 found over 0 files` and `0 found over 900 files` are different answers.

2. Classify — show me this table bef