Cross-project dependencies / blockers

[justguy]

Problem

dependencies[] only resolves within a single tracker slug. A task cannot declare it is blocked on a task in a different project. This limits both humans and agents in multi-project setups — e.g. a Project Phalanx run tracker waiting on a feature landing in the project-phalanx dev tracker, or a downstream product project blocked on a core runtime task.

Desired behavior

• A task can list cross-project blockers, resolved against other projects in the same workspace.
• /blockers surfaces cross-project waits, not just same-slug ones.
• /next de-prioritizes tasks waiting on incomplete external dependencies.
• UI renders the external dep clearly (slug badge on the card).
• Agent contract in /help documents the shape so LLMs don't invent their own syntax.

Shape to decide

Two candidates:

1. Extend dependencies[] to accept "<slug>#<taskId>" in addition to bare task IDs. Pro: one field, no contract split. Con: mixes namespaces.
2. Add a separate external_dependencies[] with { slug, taskId } objects. Pro: clean separation, easier for readiness checks. Con: two fields doing related work.

Preference notes welcome.

Constraints

• Must be backwards compatible with existing dependencies[] values.
• Readiness lookups are reads only — no cross-project writes.
• Works in both the shared-workspace-many-projects topology and the multiple-isolated-workspaces topology (cross-project refs only resolve within the same workspace; a readable "unknown project" state is fine).

Definition of done

• Schema accepts cross-project references with a documented syntax
• /blockers surfaces cross-project waits
• /next de-prioritizes tasks waiting on incomplete external deps
• UI renders external dep (slug badge) on the card
• /help (workspace-template README) documents the new shape

Tracked internally as task t37 in the llm-tracker project tracker.