Task Wait Qualifiers rule 6: owner-return waits use blocked_on: message-from:<agent>

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

.claude/rules/workplan-convention.md

@@ -47,6 +47,7 @@ status: wait | todo | progress | done | cancel
 priority: high | medium | low
 depends_on: [OTHER-WP-0001, OTHER-WP-0002-T03]   # wait: external commitment
 needs_human: true                                # wait: human gate
+blocked_on: message-from:<agent>                 # wait: owner reply, no workplan id yet
 blocking_reason: "<why, one line>"               # required whenever status is wait
 decision_id: CCR-2026-0004                       # optional, tracked decision behind a human gate
 state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit

canon/standards/task-wait-qualifiers_v0.1.md

@@ -85,10 +85,12 @@ hub decision or a change request; it is optional and never a substitute for
    wait task is a human gate, else `blocked-external` when any is an external
    commitment, else `none`. "Everything waiting on a person" is therefore one
    query, not a reading exercise.
-6. A wait on a repo that has no workplan id yet is an external commitment
-   with the repo named in `blocking_reason` and in the workplan-level
-   `blocked_on:` field (watched by C-25). Upgrade to a `depends_on` id as
-   soon as the owner returns one.
+6. A wait on another owner's reply, with no workplan id yet, is an external
+   commitment qualified by `blocked_on: message-from:<agent>` on the task
+   block — the vocabulary C-25 already watches for unread replies. The
+   consistency check accepts it in place of `depends_on`; the hub read model
+   reports such a task as `unqualified` until an id exists, so upgrade to a
+   `depends_on` id as soon as the owner returns one.
 7. A human-gate task is never leased to a worker. Coordination tooling treats
    `needs_human: true` as a stop, not a wake condition.
 

workplans/CUST-WP-0074-qualified-wait-states.md

@@ -94,7 +94,9 @@ Rules:
 6. A wait on a repo that has no workplan id yet stays Case A with the
    repo named in `blocking_reason` and the workplan-level `blocked_on:`
    field (C-25). Upgrade to a `depends_on` id as soon as the owner
-   returns one.
+   returns one. *Revised during T05 (2026-09-28): the task block carries
+   `blocked_on: message-from:<agent>` instead; C-39 accepts it, the hub
+   read model does not yet (reports `unqualified`) — follow-up in T02.*
 
 The workplan-level `depends_on` (C-20) is unchanged. Task-level
 `depends_on` is the new commitment surface; `related:` stays context.