feat(tags): hard :solo:/:quick: definitions + mandatory review/audit assessment

Phase 0 of the autonomous-batch (speedrun) build. todo-format.md now carries fixed cross-project definitions: :solo: is the autonomy/eligibility tag (buildable, agent-verifiable, no design deliberation — at most one or two quick upfront-answerable decisions, which the speedrun pre-flight Q&A batches), and :quick: is a ≤30-minute effort hint that never gates eligibility. task-review and task-audit now treat the tag assessment as mandatory — a pass that skips it is incomplete.

task-review's :solo: gate 3 also moves from "no upfront decision" to the no-deliberation form: the stricter wording predated the pre-flight Q&A decision and would have wrongly excluded tasks with a quick answerable question.

1 files changed, 31 insertions, 0 deletions

diff --git a/claude-rules/todo-format.md b/claude-rules/todo-format.md
index 90d801f..5e9ca32 100644
--- a/claude-rules/todo-format.md
+++ b/claude-rules/todo-format.md
@@ -33,6 +33,37 @@ When a project's `todo.org` lacks the section, add it before filing or
 grading further tasks — propose the priority semantics and tag set from the
 project's existing usage, and confirm with Craig.
 
+### Hard definitions: `:solo:` and `:quick:` (fixed across projects)
+
+A project's scheme may add or rename its other tags, but these two carry
+fixed definitions everywhere, because autonomous execution
+(work-the-backlog / the no-approvals speedrun) reads `:solo:` as its
+eligibility gate and trusts the author's tag rather than re-deriving
+autonomy at run time.
+
+- **`:solo:` — autonomy.** The task can be completed *and verified* without
+  Craig's involvement beyond at most one or two quick decisions that can be
+  stated and answered before work starts. No open design question, no
+  "weigh these approaches," no waiting on Craig mid-task. Three gates, all
+  must hold: *buildable* (the agent has the capability and access),
+  *verifiable by the agent* (an objective or local check it can run itself —
+  handing off a residual human-in-the-loop confirmation as a structured
+  manual-testing reminder does not disqualify), and *no deliberation* (a
+  quick, upfront-answerable factual question is allowed — it gets batched
+  into the speedrun's pre-flight Q&A; a genuine design or preference call
+  is not). A wrong `:solo:` is worse than none: it tells Craig he can hand
+  the task off and walk away when he can't.
+- **`:quick:` — effort hint only.** Likely 30 minutes or less from start
+  through verification. Informational, for batching and estimating a run's
+  duration; never an eligibility gate. `:quick:` and `:solo:` are
+  orthogonal — a bounded refactor can be `:solo:` but slow; a five-minute
+  change hinging on a preference call is `:quick:` but not `:solo:`.
+
+Both tags are applied at task creation and **re-checked as a mandatory
+step** in the task-review and task-audit workflows, so the run-time gate
+can trust the tag. A review or audit that skips the `:solo:`/`:quick:`
+assessment is incomplete.
+
 ### Bug priority from severity × frequency (mandatory where a codebase exists)
 
 Some projects carry a codebase — source the project maintains under version