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

workplans/CANP-WP-0002-format-open-questions.md

@@ -222,10 +222,10 @@ Delivered:
 1. § 3.2 defines `type` (`template` | `fragment`), closing the undefined-field
    gap. It is advisory: a fragment is a valid package and may be rendered
    alone; the field records intent so a consumer can warn.
-2. § 10.1 (new) covers naming and pinning: qualified dependency ids, the four
+2. § 10.3 (new) covers naming and pinning: qualified dependency ids, the four
    version selectors, `version` required for anything composed, and an
    explicit statement of why this is not range resolution.
-3. § 10.2 (new) defines both composition kinds, parameter pass-through into an
+3. § 10.4 (new) defines both composition kinds, parameter pass-through into an
    included package, mandatory cycle detection, and the reasoned refusal of
    inheritance.
 4. § 6.1 gains the included-default form; § 5.1 gains resolution rule 6 for
@@ -305,7 +305,7 @@ actually has.
 
 ```task
 id: CANP-WP-0002-T05
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "5beec7ba-e6c9-58b1-a065-b06aba015034"
 ```
@@ -316,10 +316,58 @@ manifest surface with no semantics whatsoever in v0.1, and § 9
 
 Decide: what a context dependency declares, how it differs from an input, how
 it relates to `compatibility.capabilities`, and whether capability names are
-free strings in v0.2 (model capability vocabularies stay deferred). T01 is now settled and partly answers this: a derived default is a
-consumer-resolved context requirement expressed through `dependencies.prompts`
-rather than through `dependencies.context`. Decide whether `context` is still a
-distinct concept or collapses into the prompt-dependency mechanism.
+free strings in v0.2 (model capability vocabularies stay deferred). **Decisions (operator, 2026-09-06):**
+
+- *`context` names what CPF cannot package.* `prompts` names artifacts the
+  format resolves by id and version; `context` names what it does not and will
+  not package — a live information space, an API, a corpus, a document the
+  caller supplies. Anything CPF *can* package is a package: a reusable policy
+  or style block belongs in `prompts` as a `type: fragment`.
+- *Capability names are free strings*, lowercase kebab-case, validated for
+  shape and not for membership, exactly as `tags` are. Model capability
+  vocabularies stay deferred.
+- *Terminology, not deduplication, for the capability overlap.* The operator's
+  answer was conditional — keep both fields if they carry the required/observed
+  distinction, and fix the terminology if they do not. **They did not.** § 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"). § 10 then described dependencies as what a prompt
+  "expects". Both fields said *expected*, so the ambiguity was real and the
+  fix was terminology.
+
+Delivered:
+
+1. § 9 rewritten: `compatibility` records **observations, never
+   requirements**, and a consumer MUST NOT refuse to run a package because its
+   environment is absent from those lists. Adds `aliases`, recording the same
+   capability under other names — the operator's point that a capability can
+   be "known by another name".
+2. § 9.1 (new) states the distinction in one word each — `dependencies` means
+   *required*, `compatibility` means *observed* — with what absence implies
+   for each, and notes that the same name may legitimately appear in both.
+3. § 10 opens with the three dependency kinds separated by what CPF can do
+   about them, and § 10.1 (new) specifies context dependencies: `name` rather
+   than `id` because nothing can look them up, a **required** `description`
+   because nothing else can explain an unpackaged dependency, optional `kind`,
+   and `requirement` limited to `required`/`optional`.
+4. § 10.2 (new) specifies capability dependencies: free-form kebab-case, no
+   version and no `requirement: generate`, because a capability is not an
+   artifact and cannot be fetched, pinned or generated.
+5. § 10.1 also draws the input/context line: an input is content passed for one
+   use; a context dependency is a standing fact about the environment.
+6. § 18 gains validation rules 19–20; § 4's manifest surface updated. Former
+   § 10.1/10.2 renumbered to § 10.3/10.4 with all cross-references updated.
+7. `reference/canned_prompts.py`: `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.
+
+**Caught in review of my own change.** I first added a `session-record`
+context dependency to `examples/pqrst-estimate` to demonstrate the feature,
+then removed it: it described the `session_summary` *input*, which § 10.1
+explicitly says a context dependency is not. The example now declares only
+what it genuinely has. Illustrations live in the spec; examples stay honest.
 
 ## Rewrite specification section 23