CANP-WP-0002 T05: required versus observed, and typed context dependencies

The answer to the capability question was conditional: keep both fields if
they carry the required/observed distinction, fix the terminology if they do
not. They did not.

Section 9 opened with "records known requirements or observations", mixing
both in one field — `models` was observational ("known to be compatible or
evaluated") while `capabilities` was prescriptive ("expected from the
execution environment"). Section 10 then described dependencies as what a
prompt "expects". Both fields said expected, so the overlap was real
ambiguity rather than redundancy, and the fix is terminology.

`dependencies` now means **required**; `compatibility` means **observed**. A
consumer must not refuse to run a package because its environment is absent
from a compatibility list. The same capability name may legitimately appear in
both: required to run at all, and separately observed to work well on
particular models. `compatibility.aliases` records the same capability under
other names, so a consumer can recognize a requirement its environment labels
differently.

Dependencies now have three kinds, separated by what the format can do about
them: `prompts` it resolves by id and version; `context` names what it does
not package at all; `capabilities` are what the environment must be able to
do. Context entries use `name` rather than `id`, because nothing can look them
up, and `description` is required because nothing else can explain an
unpackaged dependency. A capability takes no version and no
`requirement: generate` — it is not an artifact and cannot be fetched, pinned
or generated. Capability names are free-form kebab-case, validated for shape
and not membership, exactly as tags are.

Section 10.1 also draws the line the format had never stated: an input is
content the caller passes for one use; a context dependency is a standing fact
about the environment.

Spec: 9 rewritten, 9.1 and 10.1 and 10.2 new, 10 reframed, 18 (rules 19-20),
4 updated. Former 10.1/10.2 renumbered to 10.3/10.4 with cross-references.

Reference CLI: validate_capabilities, validate_context_dependencies, and a
`resolve` section listing required capabilities and context under "this tool
cannot verify these" rather than implying it checked. Tests 51 -> 65.

Also drops an invented `session-review` capability from the example package in
favour of an honest `long-context` observation.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bjefh8NUiEiahN4JLwoSKM

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 388925@bnt-lap001
Assistant-Session: 3507023f-e0fd-4a1e-9d90-a0d4217d1502

README.md

@@ -140,6 +140,29 @@ local:practice/pqrst-estimate@0.2.0
 An eval declares assessment, never results. Results are run evidence and live
 outside the immutable package.
 
+## Required versus compatible
+
+Two fields used to say overlapping things about capabilities. They now differ
+in one word each:
+
+| Field | Meaning | Absence means |
+|-------|---------|---------------|
+| `dependencies` | **required** — does not work without it | a consumer should warn or refuse |
+| `compatibility` | **observed** — known to work with it | nothing; it is information |
+
+Dependencies come in three kinds, separated by what the format can do about
+them: `prompts` are packages it resolves by id and version, `context` names
+things it does not package at all (an information space, an API, a corpus the
+caller supplies), and `capabilities` are what the environment must be able to
+do. `resolve` lists the last two, since the reference tool cannot verify
+either:
+
+```text
+requires (this tool cannot verify these):
+  capability  web-search
+  context     repository-tree — A listing of the repository under review.
+```
+
 ## Registries and identity
 
 An id names a package *within a registry* (`CannedPromptFormat-v0.1.md`