docs(plans): align awaits prose with merged agent-skills convention

The PR's original prose framed awaits: as for "external blockers that
aren't represented by an in-repo plan or an upstream spec" — the same
mutually-exclusive misreading caught and fixed by review on the
upstream agent-skills PR (JarvusInnovations/agent-skills#9, merged).

Our storage-foundation.md is literally the canonical counterexample:
gitsheets shows up in BOTH upstream-specs: (the specs we'll implement
against) AND awaits: (the v1.0 release we're waiting for). Different
axes of the same upstream — not exclusive categories.

Rewrite the paragraph to:

  * Call out orthogonality of depends / upstream-specs / awaits
    explicitly
  * Use the storage-foundation frontmatter example shown immediately
    above (gitsheets in both fields) as the worked illustration
  * Add the "trailing em-dash clause for the why" guidance that
    matches the upstream protocol's recommendation
  * Note the new smell warning (plans-next/dag warn when status:
    blocked has neither awaits: nor unfinished depends:) so readers
    know the smell isn't just rhetorical

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: themightychris

.claude/CLAUDE.md

@@ -69,7 +69,7 @@ pr: 42                   # merged PR once done (optional)
 
 `specs:` is for specs we own — the spec-drift-auditor matches them against implementation. `upstream-specs:` is for specs owned by dependencies (e.g., gitsheets) that this plan consumes; they're informational only and the spec-drift-auditor doesn't check them. Use the `<repo>:<path>` form so it's obvious where to look.
 
-`awaits:` captures external blockers that aren't represented by an in-repo plan or an upstream spec — upstream library releases, vendor deliveries, partner decisions. Each entry is a one-line free-form pointer (URL, `repo@tag`, "vendor X delivery", etc.). `awaits:` is structural ("we're waiting on this"); `status:` is lifecycle ("can the plan move?"). They're independent: a `planned` plan can carry `awaits:` from day one, a `blocked` plan should always have `awaits:` populated to say why. Resolution is just deleting the entry when the awaited thing happens. `plans-next` never lists a plan with non-empty `awaits:` under "Ready" — it surfaces in an "Awaiting external" section. Full convention: [`agent-skills/skills/specops/references/plans-protocol.md`](https://github.com/JarvusInnovations/agent-skills/blob/main/skills/specops/references/plans-protocol.md#external-blockers).
+`awaits:` captures external blockers — upstream library releases, vendor deliveries, partner decisions. Each entry is a one-line free-form pointer (URL, `repo@tag`, "vendor X delivery", etc., with a trailing em-dash clause for the *why* so the entry self-explains when grep surfaces it). The three structural fields (`depends:`, `upstream-specs:`, `awaits:`) are **orthogonal axes**, not mutually exclusive categories — the same upstream relationship can carry multiple. The example above is the canonical case: gitsheets appears in `upstream-specs:` (the specs we'll implement against) *and* in `awaits:` (the v1.0 release we're waiting for). Different axes of the same upstream. `awaits:` is also independent of `status:`: a `planned` plan can carry `awaits:` from day one; a `blocked` plan should always have `awaits:` populated to say why (the scripts warn if `status: blocked` is set with neither `awaits:` nor unfinished `depends:`). Resolution is just deleting the entry when the awaited thing happens. `plans-next` never lists a plan with non-empty `awaits:` under "Ready" — it surfaces in an "Awaiting external" section. Full convention: [`agent-skills/skills/specops/references/plans-protocol.md`](https://github.com/JarvusInnovations/agent-skills/blob/main/skills/specops/references/plans-protocol.md#external-blockers).
 
 A plan's body follows the template in [plans/README.md](../plans/README.md): Scope, Implements, Approach, Validation, Risks/unknowns, Notes, Follow-ups. The Validation section is the load-bearing part — it converts "in-progress" to "done."