Add kind: decision commitments and depends_on entry for cross-owner waits (CUST-WP-0074-T03)

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: claude-fable-5-1
Assistant-Process: 237582@bnt-lap001
Assistant-Session: f2b3d9f1-8fb9-4b9c-bc2b-837ec5dfc826

spec/coordination-model-v0.2.md

@@ -65,6 +65,7 @@ prj- workplan  →  CoordinationCase
   driver       ←  the prj- workplan (commitment: sequence the effort)
   implementers ←  child workplans in other repos (related / depends_on)
   commitments  ←  depends_on edges (kind: response | completion)
+                  needs_human: true tasks (kind: decision)
   observations ←  State Hub task/workplan status, receipts
 ```
 
@@ -72,7 +73,17 @@ prj- workplan  →  CoordinationCase
 implementer (or upstream driver) named by the target id. The beneficiary
 is the waiting plan. Satisfaction is the target reaching a terminal
 satisfactory status (`done` / `finished` / `archived`), matching the
-v0.1 worker-coordination dependency rule.
+v0.1 worker-coordination dependency rule. Task-block `depends_on`
+(fleet standard `task-wait-qualifiers_v0.1.md`, CUST-WP-0074) is the
+same commitment with a task rather than a workplan as beneficiary; task
+targets are satisfied at `done` / `cancel`.
+
+**`kind: decision`** — a task with `needs_human: true` is a commitment
+whose obligor is a person (or the decision named by `decision_id`), not
+a workplan. Satisfaction is the person's recorded action or the
+decision resolving. The engine observes it and never wakes a worker for
+it. A task carrying both `depends_on` and `needs_human: true` is two
+commitments; the case is satisfied only when both are.
 
 `related:` without `depends_on` is context, not a commitment.