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.
 

spec/cross-owner-wait-mode-v0.1.md

@@ -18,10 +18,20 @@ theme holding the open-workplan count up.
 
 Any of:
 
-1. A task is `wait` / `needs_human` and names another repo, owner, or
+1. A task is `wait` with a task-block `depends_on` naming a workplan or
-   workplan id.
+   task in another repo (fleet standard
+   `the-custodian/canon/standards/task-wait-qualifiers_v0.1.md`). Prose
+   that names another repo, owner or workplan id without `depends_on`
+   remains an entry condition only until the CUST-WP-0074-T05 backfill
+   completes; it is an unqualified wait and should be converted.
 2. A workplan is `blocked` on a `depends_on` target whose `repo` is not
    this repo.
+
+A task with `needs_human: true` is a **human gate**, not a cross-owner
+wait. It does not enter this mode; it is a `kind: decision` commitment
+(coordination-model v0.2 §5) satisfied only by the named person or the
+resolution of its `decision_id`. A task carrying both `depends_on` and
+`needs_human: true` enters this mode for the `depends_on` part only.
 3. A `prj-` driver lists both repos (preferred). If no driver exists,
    still open a **case object** from the waiting plan — do not author a
    new workplan.
@@ -47,7 +57,9 @@ commitment.
 Lease/wakeup **only** selected gita-registered worker targets for the
 implementer that is actually unblocked. Safety, sensitive-text stops,
 human flags, and “no silent reroute” are exactly the v0.1 worker service.
-This mode does not add a second wakeup path.
+This mode does not add a second wakeup path. A human-gate task
+(`needs_human: true`) is never leased or woken: it is a stop condition,
+and a worker that reaches one checkpoints with `blocked_reason` and exits.
 
 If the service is not running, the case still exists as a derived object
 and a hub-projectable receipt of `observed` / `waiting`. Agents follow