1 files changed, 51 insertions, 0 deletions
diff --git a/claude-rules/todo-format.md b/claude-rules/todo-format.md
index 895526f..5c34966 100644
--- a/claude-rules/todo-format.md
+++ b/claude-rules/todo-format.md
@@ -263,3 +263,54 @@ are noise that pollute his `cj:` greps.
     ** DOING [#A] Kostya's contract :admin:kostya:
     *** 2026-05-15 Fri @ 14:00:00 -0500 Kostya basis — part-time, 20 hr/week
     Nerses confirmed 5/15 13:30 CDT: Kostya runs at 20 hr/week part-time, mirroring Vrezh's structure. Plugged into Exhibit A § 2 of the contract draft.
+
+## Cross-Project Dependency Tags
+
+A task can be blocked by work that has to happen in a *different project* — a rulesets task that can't finish until `.emacs.d` ships a companion function, say. Left unmarked, two things go wrong: the what's-next workflow keeps recommending the blocked task even though it can't move, and the blocker sits at low priority in the other project, so the dependency stalls silently.
+
+Two plain org tags track it, one on each side, so neither the waiter nor the blocker loses sight of the dependency: `:blocked:` on the task that's waiting, `:blocker:` on the task that owes the work. The cross-project detail — which project, what work — goes in the task *body*, not a property. This applies to *any* project pair; the convention here and the surfacing in `open-tasks.org` live in the shared rule + workflow layer, not in one project.
+
+### `:blocked:` — the waiting side
+
+The task that can't proceed carries `:blocked:`. Its body names the project it's waiting on and what that project owes:
+
+```
+** DOING [#B] Wrap-teardown feature :feature:blocked:
+Blocked on emacsd: needs the ai-term companion functions
+(cj/ai-term-quit, -live-count) before the manual validation can run.
+```
+
+`open-tasks.org` reads the `:blocked:` tag to pull the task out of the "do this next" cascade (it can't be worked) and surface it in a dedicated "Blocked on other projects" section, reading the body for which project to name and nudge.
+
+### Registering with the blocker — the reciprocal handoff (required)
+
+Setting `:blocked:` is not complete until the blocking project knows it's blocking. The moment you mark a task `:blocked:` on another project's work, send that project a dependency handoff:
+
+```
+inbox-send <project> --text "Blocking dependency: <this-project>'s task \"<task>\" is blocked on you — it needs <what>. It stays blocked until this lands. Tag the owning task :blocker: on your side so it surfaces as priority work."
+```
+
+This is what closes the gap: without it, the blocker only learns it's blocking by accident. The handoff lands in `<project>`'s `inbox/` and its normal inbox processing tags the work (below). A `:blocked:` task with no matching reciprocal handoff is half-done — the dependency is invisible to the one project that can clear it. Skip the send only when the blocker demonstrably already tracks the work (e.g. it's the same handoff that spawned the dependency); it dedups against an existing task either way.
+
+### `:blocker:` — the blocking side
+
+When a project processes a blocking-dependency handoff (inbox process mode), it tags the owning task `:blocker:` and names the requesting project in the body:
+
+```
+** TODO [#B] ai-term wrap-teardown companion :feature:blocker:
+Rulesets' wrap-teardown feature is blocked on this — it needs the three
+ai-term functions. Surface first so rulesets unblocks.
+```
+
+The blocking task does *not* carry `:blocked:` — it isn't blocked, it's the blocker. `:blocker:` is a priority signal: `open-tasks.org` surfaces a `:blocker:` task *first*, since clearing it unblocks work in another project, so a dependency that would otherwise stall at low priority gets pulled forward. This is the "surface dependencies first" half of the design.
+
+### Resolving the dependency
+
+When the blocker delivers:
+
+1. The blocking project completes its `:blocker:` task, drops the `:blocker:` tag, and notifies the waiter (`inbox-send <waiter> --text "Delivered: <what> — you're unblocked."`).
+2. The waiting project drops the `:blocked:` tag; the task is workable again. Either side noticing the delivery can lift its own tag — the notification just makes it prompt.
+
+### Not the same as VERIFY
+
+`:blocked:` marks "waiting on another *project's* work"; `VERIFY` marks "waiting on Craig's input." If Craig's input is what's needed, it's a VERIFY, not `:blocked:`. And `:blocker:` only ever sits on the project that *owes* the work, never the one waiting.