/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.

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.

**A clean "nothing found" is the result you were hoping for, which is exactly when to distrust it.** Four 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 — `command -v grep` — and reach for `find -L`, `rg --follow` or `ugrep -R` (`sota-shell-scripting` rules/06 §2).

• **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 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/06 §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.** 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 before changing anything

| Class | What it means | |---|---| | **READY** | Unambiguous, self-contained, finishable now. | | **NEEDS A DECISION** | Depends on a choice only the operator can make — naming, scope, priority, cost, anything security-, privacy- or money-relevant. State the question, **two or three options**, and **your recommendation with its reasoning** — rule 5's form, which applies here too. A bare recommendation is not a decision handed over. | | **DELIBERATELY DEFERRED** | The doc gives a reason to wait. Leave it, and say what the reason was. If the deferral names **no revisit trigger**, that is a finding: a deferral with no condition attached is a silent drop wearing a tracker row. | | **NOT AN ITEM** | Template checkboxes, worked examples, a `- [ ]` inside a code fence (it renders as sample output and no one was ever meant to tick it), completed rows still phrased as open. Say so rather than "doing" them. | | **ALREADY DONE** | Implemented, tracker never updated. The fix is a **doc correction, not code**. |

**ALREADY DONE is usually the largest class and the easiest to get wrong in the other direction.** The summary is always the stale half, and it is the half people read — a priorities table pointing at work its own ledger closed. Check the *ledger row*, the code, or the commit, never the header that summarises them.

Order READY by value against risk. Estimate **blast radius and uncertainty**, not minutes: how many files it touches, whether anything else depends on it, and what you would have to know that you do not.

3. Stop and let me steer

Do not execute until the operator confirms the list. The one exception is *every* item being READY **and** small — where small means: inside one file or one obvious unit, no interface, schema, dependency or security posture touched, and verification already exists for it. Say you are taking the exception and which bar it met, then carry on. An exception invoked without naming its bar swallows the rule.

**Hand every NEEDS A DECISION item over in rule 5's form**: the question, two or three options with what each costs and forecloses, and your recommendation **with its reasoning**. Batch them into this one interruption rather than asking serially — that is what this stop is for. Without the alternatives beside it the operator is ratifying a choice you already made rather than making one, and a recommendation whose reasoning went unsaid is the one that gets re-argued.

4. Execute — one at a time, smallest blast radius first

For each agreed item:

1. Make the change. 2. **Run this project's own verification** — find its entry point, do not assume one. `Makefile`, `package.json` scripts, `justfile`, `tox.ini`, `noxfile.py`, `.pre-commit-config.yaml`, and above all `.github/workflows/*` — CI is the definition of "passing" that actually gates this repo. Run what CI runs. 3. **Watch it fail before trusting it to pass.** If you did not see the check reject something, you do not know it ran — a suite that silently matched zero files exits 0 and prints `ok`. A green check whose environment cannot reach the defect is green and proves nothing; say what depth it reached (`sota-devsecops` rules/09 §2a). 4. **Updat