docs(rulesets): rename STALLED to VERIFY across skill + workflow

Renamed the org TODO keyword STALLED to VERIFY in respond-to-cj-comments.md (skill) and daily-prep.org (workflow). VERIFY reads as the next step rather than as a stuck state; the meaning is unchanged — items needing Craig's input.

2 files changed, 8 insertions, 8 deletions

diff --git a/.ai/workflows/daily-prep.org b/.ai/workflows/daily-prep.org
index e739847..319e94f 100644
--- a/.ai/workflows/daily-prep.org
+++ b/.ai/workflows/daily-prep.org
@@ -98,7 +98,7 @@ Each actionable entry under =* Day's Priorities= is a *pointer to a todo.org tas
 <one line on why it's today's priority — deadline, blocker, what just landed>
 #+end_example
 
-All the substance — descriptions, drafted messages, research findings, sub-tasks, =STALLED= asks, recommended-approach blocks — lives in the matching =todo.org= task, created or updated by Phase 3. If a todo.org task doesn't exist yet, create one (with the conventional priority cookie / Linear ID in the heading) and link to it. This keeps everything in one place (todo.org), so the prep doc never accretes content that then has to be transferred back.
+All the substance — descriptions, drafted messages, research findings, sub-tasks, =VERIFY= asks, recommended-approach blocks — lives in the matching =todo.org= task, created or updated by Phase 3. If a todo.org task doesn't exist yet, create one (with the conventional priority cookie / Linear ID in the heading) and link to it. This keeps everything in one place (todo.org), so the prep doc never accretes content that then has to be transferred back.
 
 Exceptions that stay in the prep doc as content (not links):
 - *Completed-today entries* — once a task is done, its heading becomes a dated log entry (=** YYYY-MM-DD Day @ HH:MM ...=, see [[file:../../.claude/...][feedback_done_tasks_become_dated_log_headings]] — i.e. the dated-heading rule) and stays in the prep doc as the day's record. If the work also has a durable todo.org home, the dated entry links to it.
@@ -798,4 +798,4 @@ Filter: "If I didn't mention this, would someone on the team make a worse decisi
 duplicate the work?" If no, cut it.
 
 *** 2026-05-12: Day's Priorities entries are thin links to todo.org tasks — never duplicated content
-Craig's call. The prep doc's =* Day's Priorities= entries point at todo.org tasks (=** TODO [#X] <title> — [[file:../todo.org::*<title>][todo.org]]= plus a one-line "why today"); all the substance — descriptions, drafts, research, sub-tasks, STALLED asks, recommended-approach — lives in the matching todo.org task, which Phase 3 creates or updates. Completed-today entries still become dated log headings in the prep doc (the day's record), linking to their durable todo.org home if there is one. Full statement in *Prep Doc Structure ▸ Day's Priorities entries are thin links to todo.org tasks* above. Follow-up: Phase 3 sub-steps 3b–3f still say "add to the prep doc" — reword them to "create/update the todo.org task, link from the prep doc" on the next pass. (Supersedes the 2026-03-09 "Day's Priorities use org-mode TODO headings" entry's implication that the content lives in the prep doc — the headings still use TODO keywords / dated-log headings, but the body is a link.)
+Craig's call. The prep doc's =* Day's Priorities= entries point at todo.org tasks (=** TODO [#X] <title> — [[file:../todo.org::*<title>][todo.org]]= plus a one-line "why today"); all the substance — descriptions, drafts, research, sub-tasks, VERIFY asks, recommended-approach — lives in the matching todo.org task, which Phase 3 creates or updates. Completed-today entries still become dated log headings in the prep doc (the day's record), linking to their durable todo.org home if there is one. Full statement in *Prep Doc Structure ▸ Day's Priorities entries are thin links to todo.org tasks* above. Follow-up: Phase 3 sub-steps 3b–3f still say "add to the prep doc" — reword them to "create/update the todo.org task, link from the prep doc" on the next pass. (Supersedes the 2026-03-09 "Day's Priorities use org-mode TODO headings" entry's implication that the content lives in the prep doc — the headings still use TODO keywords / dated-log headings, but the body is a link.)
diff --git a/.claude/commands/respond-to-cj-comments.md b/.claude/commands/respond-to-cj-comments.md
index 0f05455..4978f06 100644
--- a/.claude/commands/respond-to-cj-comments.md
+++ b/.claude/commands/respond-to-cj-comments.md
@@ -1,5 +1,5 @@
 ---
-description: Scan a target file for inline `cj:` annotations (Craig's in-line questions and instructions; multi-line continuations recognized across most comment markers) and process each via subagent-delegated accuracy. Each item is classified instruction / question / both, then dispatched to an instruction subagent (proposes a file:line patch) or a question subagent (researches with explicit scope, reports answer + evidence + confidence). Main thread reviews proposals before editing — subagents don't write to the source file. Org-mode TODO parents flip to DOING; new content lands under timestamped subheadings one level deeper; on completion, top and second-level tasks advance to `DONE` while third-level-and-deeper tasks get their heading rewritten to a dated action description (no DONE keyword) so they become an in-place event log. Public-facing writing (commits, PRs, Slack, email, public docs) gets `/voice personal`; private writing skips the voice pass. Summary lists handled instructions, answered questions with evidence + confidence, follow-ups, unresolved items, and an explicit clean / N-remain verdict. Anything needing Craig's input becomes a `STALLED` task in `todo.org` under the relevant parent (he answers inline with `cj:`) rather than a separate summary file. File/URL references render as clickable org-mode links. Use when a file accumulates inline `cj:` comments. Do NOT use for general code review (`/review-code`), new work without inline comments, or trivial items.
+description: Scan a target file for inline `cj:` annotations (Craig's in-line questions and instructions; multi-line continuations recognized across most comment markers) and process each via subagent-delegated accuracy. Each item is classified instruction / question / both, then dispatched to an instruction subagent (proposes a file:line patch) or a question subagent (researches with explicit scope, reports answer + evidence + confidence). Main thread reviews proposals before editing — subagents don't write to the source file. Org-mode TODO parents flip to DOING; new content lands under timestamped subheadings one level deeper; on completion, top and second-level tasks advance to `DONE` while third-level-and-deeper tasks get their heading rewritten to a dated action description (no DONE keyword) so they become an in-place event log. Public-facing writing (commits, PRs, Slack, email, public docs) gets `/voice personal`; private writing skips the voice pass. Summary lists handled instructions, answered questions with evidence + confidence, follow-ups, unresolved items, and an explicit clean / N-remain verdict. Anything needing Craig's input becomes a `VERIFY` task in `todo.org` under the relevant parent (he answers inline with `cj:`) rather than a separate summary file. File/URL references render as clickable org-mode links. Use when a file accumulates inline `cj:` comments. Do NOT use for general code review (`/review-code`), new work without inline comments, or trivial items.
 disable-model-invocation: true
 ---
 
@@ -60,7 +60,7 @@ Pick a number.
 
 Wait for the answer:
 
-- **Option 1 ("do it from here")** — proceed. Plan to write a handoff file at `<other-project>/inbox/YYYY-MM-DD-handoff-from-<this-project>-<topic>.org` as part of the cleanup pass at the end of the run. The handoff covers: scope of changes, files touched, carry-forward context, any pending Craig-asks (STALLED entries, drafts awaiting approval), and subagent-output traceability.
+- **Option 1 ("do it from here")** — proceed. Plan to write a handoff file at `<other-project>/inbox/YYYY-MM-DD-handoff-from-<this-project>-<topic>.org` as part of the cleanup pass at the end of the run. The handoff covers: scope of changes, files touched, carry-forward context, any pending Craig-asks (VERIFY entries, drafts awaiting approval), and subagent-output traceability.
 - **Option 2 ("switch projects")** — stop the skill, output a short confirmation, exit. Do not read the file.
 
 If the target file is *inside* the cwd's project root, skip this step silently.
@@ -199,14 +199,14 @@ Never leave the reader guessing about whether the file is ready for follow-up wo
 
 Keep answers direct. If a question has a simple answer, one sentence. If it needs nuance, two or three. Do not pad. The user reads the summary, not the intermediate work.
 
-**Items needing Craig's input go to `todo.org`, not a summary file.** When the run leaves something that needs Craig to decide, answer, or approve — a blocker, an open question, a draft awaiting sign-off, anything in the Follow-ups list above that requires his action — add a `STALLED` task in `todo.org` under the parent task it belongs to (the one whose subject it concerns), phrased so Craig can answer inline with a `cj:` comment:
+**Items needing Craig's input go to `todo.org`, not a summary file.** When the run leaves something that needs Craig to decide, answer, or approve — a blocker, an open question, a draft awaiting sign-off, anything in the Follow-ups list above that requires his action — add a `VERIFY` task in `todo.org` under the parent task it belongs to (the one whose subject it concerns), phrased so Craig can answer inline with a `cj:` comment:
 
 ```
-*** STALLED <what you need from Craig>
+*** VERIFY <what you need from Craig>
 cj: <Craig answers here>
 ```
 
-Pair it with a dated child header for the work-log entry where one fits (`*** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ <desc>` — generate the timestamp with `date "+%Y-%m-%d %a @ %H:%M:%S %z"`). Do **not** default to writing a summary file in `/tmp/` and opening it in `emacsclient` — Craig prefers the in-place `STALLED` task: it lives next to the work, surfaces in his agenda, and he resolves it inline rather than having to go find a separate doc. The chat summary above still gets written (it's the FYI recap); the `STALLED` task is the durable home for anything he must act on. (Craig's standing instruction, 2026-05-12 — this replaces the older "long summary → /tmp file → emacsclient" step.)
+Pair it with a dated child header for the work-log entry where one fits (`*** YYYY-MM-DD Day @ HH:MM:SS -ZZZZ <desc>` — generate the timestamp with `date "+%Y-%m-%d %a @ %H:%M:%S %z"`). Do **not** default to writing a summary file in `/tmp/` and opening it in `emacsclient` — Craig prefers the in-place `VERIFY` task: it lives next to the work, surfaces in his agenda, and he resolves it inline rather than having to go find a separate doc. The chat summary above still gets written (it's the FYI recap); the `VERIFY` task is the durable home for anything he must act on. (Craig's standing instruction, 2026-05-12 — this replaces the older "long summary → /tmp file → emacsclient" step.)
 
 **Org-mode links where they help.** When you reference a file or URL — in the chat summary or in a `todo.org` entry — use clickable org-mode link form with absolute paths (`[[file:/absolute/path][label]]`, `[[https://...][label]]`), not `=verbatim=` paths, which aren't clickable in Emacs.
 
@@ -229,7 +229,7 @@ Contents:
 - Top-of-file note: this work happened cross-project. The acting Claude was running in `<this-project>` cwd; the file lives in `<other-project>`. The target project's next Claude reads this during inbox processing and folds the work-log into its own `session-context.org` before deleting the handoff.
 - Scope of changes: what `cj:` items were processed, what was changed, what's still open.
 - Files touched: full paths, line-level granularity where it helps.
-- Pending Craig-asks: every `STALLED` entry the run created or left in place.
+- Pending Craig-asks: every `VERIFY` entry the run created or left in place.
 - Subagent traceability: which subagents ran, what they cited, what changes they proposed.
 - Carry-forward findings: anything substantive the next session needs to know.