CANP-WP-0002 T01: input defaults, static and derived

Closes the gap that made optional inputs unusable: rendering rule 5.1(4)
made any unresolved placeholder an error while inputs had no `default`, so
an input marked `required: false` and referenced from the template failed
every render in which the caller omitted it — including the spec's own
section 4 example.

Section 10 already carried the derivation mechanism (`requirement: generate`,
resolution deliberately undefined), so a derived default needed a binding
rather than a new concept: the input's default names a declared prompt
dependency.

Spec:
- 5.1 rewritten as "Resolution and rendering". Resolution may be
  non-deterministic and must report what it derived; rendering is
  deterministic and must not derive. A tool that handles only supplied
  values and static defaults is stated to be conforming.
- 6.1 (new) covers both declaration forms. Reference form is preferred, with
  the reason stated — an inline prompt is anonymous, so unversioned,
  unprovenanced and un-evaluable — and validators should warn when a
  published package derives inline.
- A derived default may declare a static fallback `value`. Without one the
  input stays unresolved, which is an error; derivation never silently
  yields empty content.
- 4, 10, 18 (rules 11-13), 19 (two new MUST NOTs), 21 updated accordingly.

Reference CLI:
- New `resolve` verb reporting the origin of every value.
- `Resolution` dataclass and `resolve_inputs`; `resolve_values` kept as a
  wrapper so existing callers are unaffected.
- `render` refuses with a specific error naming underivable inputs rather
  than substituting empty text.
- Tests 3 -> 11. Example package lifecycle re-verified end to end.

INTENT.md is unchanged: splitting resolve from render preserves success
criterion 4 (deterministic rendering) as written.

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

@@ -24,6 +24,10 @@ python canned_prompts.py add ../examples/pqrst-estimate
 python canned_prompts.py search pqrst
 python canned_prompts.py show practice/pqrst-estimate
 
+# see how each input and parameter resolves, and where the value came from
+python canned_prompts.py resolve practice/pqrst-estimate \
+  --set session_summary="Implemented feature X, read unfamiliar code, added tests."
+
 # render it
 python canned_prompts.py render practice/pqrst-estimate \
   --set session_summary="Implemented feature X, read unfamiliar code, added tests."
@@ -50,6 +54,19 @@ CANNED_PROMPTS_HOME=/some/path
 
 or command-level `--catalog` / `--registry` options.
 
+## Resolution vs rendering
+
+The format separates the two steps (`CannedPromptFormat-v0.1.md` § 5.1).
+Resolution decides a value for every input and parameter and may be
+non-deterministic; rendering substitutes those values and always is. An input
+may declare a default that is either a static value or a *derived* one — a
+prompt that a capable consumer may run to produce the value, declared without
+naming any resolver or model.
+
+This reference tool never calls a model, so it resolves supplied values and
+static defaults only, and reports anything it cannot derive instead of
+rendering a prompt with a silent hole in it.
+
 ## Deliberate limitations
 
 This seed has no hosted registry, model execution, authentication, network access, dependency resolver, or social features. `publish` and `install` operate on a filesystem registry so that the package semantics can be tested before infrastructure is built around them.