Maintain verify-t3term

The feature map goes stale as soon as the app changes. This pass keeps .claude/skills/verify-t3term/ honest. Each feature gets read from source and driven live. Not every sentence needs a run.

Adapted from pstack's maintain-verification-skill (github.com/cursor/plugins, MIT) for this repo.

Outcomes

End with exactly one, and say which:

• clean. Every feature was read from source and driven live, and nothing needs changing. No branch, no pull request.
• changed. One pull request ships proven corrections to the skill's files.
• blocked. Coverage couldn't finish, or a proven fix couldn't ship safely. Say exactly what blocked it.

What it may edit

Only .claude/skills/verify-t3term/: SKILL.md, features/ and scripts/. Never product code under src/, tests/ or anything else. When the map describes behavior the app no longer has, decide which it is. If the app changed on purpose, the map is stale, so fix the map. If the app broke, that's a regression: report it to the user and leave the map as it was, so the next run still catches it.

The pass

0. Start from master. Fetch and work in a fresh worktree from origin/master, so the pass checks what users get. cargo build --locked there.
1. Index. Read features/README.md and list the files beside it. Fix entries that are missing, extra, duplicated or dead.
2. Source wave. One read-only subagent per feature file, all launched in one message (subagent_type: "Explore"). Tell each one not to edit files, and check git status afterward. Each reads its feature file and the code behind it (src/tui/, src/main.rs, src/client.rs) and returns four things: how the feature works from the user's side, with the entry points in source; claims in the file the code no longer supports, each with a file:line, or "none"; keys, labels or texts the file should use as handles; and one recipe for the live pass.
3. Reconcile. Every feature file has an answer. Merge recipes that share a scenario and screen size into as few runs as you can. Spot-check each cited drift in the source yourself; don't re-prove claims that came back clean. Then sweep recent merges for user-facing changes the map lacks: git log --merges --since=<last pass> --format='%h %s' origin/master, and the README's key table and "What you get" sections. Name a concrete source path before you call a feature missing.

4. Live pass. Required even when the source wave found nothing. You drive. Subagents don't. Start with scripts/smoke, which runs every recipe as written against master's build. A recipe it fails is drift or a regression, so triage it in step 5. Then follow verify-t3term's Launch section for what the recipes don't cover: one run per scenario, driven in order. Drive every feature at least once and hold these the whole time:

   • Run t3v doctor before the first drive of each run and after any failed drive. When doctor can't see the problem, such as a wedged screen on a healthy process, t3v restart or start a new run rather than hope.
   • The evidence captured so far survives every cleanup. Check its directory, don't assume.
   • Nothing a drive started outlives its use. Clean up failed attempts too, with t3v stop and t3v cleanup, never by process name.

   A doctor failure caused by a stale skill is drift. Fix it within the edit scope and try once more, restarting only what the fix touched, before you call the pass blocked. A feature you can't reach is "verified unreachable" only with the missing precondition named (a scenario the driver lacks, a T3 capability the fake doesn't serve) and the route you tried. If the map doesn't name that precondition, that's drift. Drive any driver fix live again before it ships. Tear down after the last drive, re-proofs included.

5. Triage. A wrong or missing description from the user's side is drift: fix it. Behavior that works but the driver can't reach is a driver gap: fix it in scripts/, keep the script executable and show its use in SKILL.md. A fix to t3v itself gets a test in scripts/t3v_lib/test_*.py that fails without it. CI's macOS job runs them; run them yourself with python3 -I -B -m unittest discover -s .claude/skills/verify-t3term/scripts/t3v_lib -t .claude/skills/verify-t3term/scripts. Behavior that is broken is a regression: write it up for the user with the recipe and the captures, and keep it out of this pull request.
6. Ship or stop. For changed, open one pull request of proven corrections. Read every changed file again first, and give it the decision log AGENTS.md asks for. A pull request needs a verdict from someone other than its author (the verify-pr skill). For clean or blocked, open nothing. Report the outcome and what the pass covered.

Keep short run notes in /tmp/t3v-maintain/<date>/: the features covered, the unreachable ones and why, the drift confirmed and the outcome. Don't commit them.

Reply: the outcome, features covered (source and live), drift fixed, regressions found with their recipes, and the pull request if there is one.