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

id	type	title	domain	repo	status	owner	topic_slug	created	updated
CANP-WP-0002	workplan	Resolve CPF v0.1 open questions promoted for v0.2	agents	canned-prompts	ready	codex	practice	2026-09-06	2026-09-06

Resolve CPF v0.1 open questions promoted for v0.2

CannedPromptFormat-v0.1.md § 23 currently lists twelve items as "experience should determine". A review of the seed on 2026-09-06 (spec + reference CLI + examples/pqrst-estimate; 3/3 tests pass, full local lifecycle smokes clean) plus an operator interview promoted five of them from "wait and see" to "decide, with a stated leaning". This workplan carries those decisions.

Unpromoted § 23 items stay deferred and unchanged: content macros, cryptographic integrity/signing, model capability vocabularies, run manifests and evidence formats, deterministic compilation manifests, trust/reputation signals, federated discovery, richer template syntax.

Guardrail for every task below: INTENT.md § Deliberate boundary. The format may declare a requirement; it must not specify the resolver, runtime, or execution engine that satisfies it.

Optional inputs need defaults

id: CANP-WP-0002-T01
status: todo
priority: high

Gap found in review. Rendering rule § 5.1(4) makes any unresolved placeholder an error, and § 6 gives inputs no default field. An input declared required: false and referenced from the template therefore makes render fail unless a value is supplied — optional inputs are effectively unusable. The spec's own § 4 manifest example hits this with repository_context. reference/canned_prompts.py is conformant here; the defect is in the spec.

Decision (operator, 2026-09-06): add a default field to inputs, and allow that default to be either

• a static value, or
• a derived default — a prompt that produces the value from available context.

Unresolved-with-no-default remains an error.

Work:

1. Extend § 6 with default, and state the two default kinds.
2. Specify the derived-default declaration form so it stays inert data: the package declares what to derive and the prompt to derive it with; it never names or requires a specific resolver, model, or runtime. A consumer that cannot derive must report the input as unresolved rather than guess.
3. Reconcile § 5.1: rules 1–2 gain input defaults; rule 4 keeps unresolved as an error; § 5.1's "no conditionals, loops, filters, or functions" and § 19's "MUST NOT execute code merely because it appears in a package" must survive the change — a derived default is a request to a consumer, not template-embedded execution. Say so explicitly.
4. Extend § 18 validation accordingly.
5. Implement static defaults in reference/canned_prompts.py resolve_values and add tests. Derived defaults: validate and surface them; the reference CLI never calls a model, so it reports them as unresolved-by-design.

Registry namespaces and ownership

id: CANP-WP-0002-T02
status: todo
priority: high

An id like practice/pqrst-estimate has a namespace prefix with no owner. Two authors publishing practice/… into one registry collide today; add and publish only refuse an exact id@version that already exists.

Decide, for § 3.2 and § 20: what a namespace means, who may claim one, how a filesystem registry records the claim, and what a consumer does on conflict. Leaning: keep v0.1's local-first stance — namespace ownership is a registry policy, declared by the registry rather than by the package — so package semantics do not change when a hosted registry appears later. Signing and trust scoring stay out of scope (§ 23, INTENT non-goals).

Prompt composition and inheritance

id: CANP-WP-0002-T03
status: todo
priority: high

Largest gap between INTENT.md and the spec. Principle 9 ("composition without capture") and the dependencies.prompts field both promise composition, but v0.1 defines no mechanism — dependencies is a declared field with no semantics.

Decide what composition means at the artifact level: how one package references another, whether references are includes, extends, or plain declared prerequisites, and how versions are pinned. Leaning: declaration only — a package states what it needs, and resolution stays with the consumer, per the INTENT boundary. Do not introduce range resolution (INTENT non-goal).

Canonical eval schemas

id: CANP-WP-0002-T04
status: todo
priority: medium

Cheapest item to pin down. evals/ is a reserved path and evals: is a manifest list, but § 12 defines no schema, so an eval file is an unvalidated blob that no tool can act on.

Define a minimal eval-spec schema: identity, what is being asserted, the fixture it runs against, and how a result is reported. Keep it declarative and engine-neutral — "universal prompt evaluation" is an explicit INTENT non-goal, so this specifies the file, not an evaluation engine. Extend § 18 to validate eval files that declare the schema, and add one eval to examples/pqrst-estimate as a worked case.

Typed context and dependency contracts

id: CANP-WP-0002-T05
status: todo
priority: medium

dependencies.context and dependencies.capabilities appear in the § 4 manifest surface with no semantics whatsoever in v0.1, and § 9 compatibility.capabilities overlaps them without a stated relationship.

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). Coordinate with T01 — a derived default is a consumer-resolved context requirement, and the two mechanisms must not describe the same thing twice.

Rewrite specification section 23

id: CANP-WP-0002-T06
status: todo
priority: medium

After T01–T05 land, replace § 23's flat twelve-item list with two sections: questions being decided for v0.2 (each with its scoped question and stated leaning, referencing this workplan) and questions still deferred (the eight unpromoted items listed at the top of this file). Bump the spec status line if the format revision warrants it.

Reference implementation conformance fixes

id: CANP-WP-0002-T07
status: todo
priority: low

Two defects found in the same review, independent of the format questions:

1. Prerelease versions sort as newest. parse_semver in reference/canned_prompts.py returns (major, minor, patch, raw_string), so 1.0.0-rc1 and 1.0.0 tie on the numeric fields and then compare as strings — "1.0.0-rc1" > "1.0.0". resolve_installed with no --version therefore selects a prerelease over its own release. Order prerelease below release, or state in § 17 that v0.1 ignores prerelease ordering.
2. copy_immutable copies everything. add/publish use shutil.copytree over the whole source directory, so a stray .git, .venv, or scratch file lands in the catalog and registry. § 2 says tools MUST ignore unknown non-reserved files unless a manifest field references them. Decide whether packaging is reserved-paths-only or an explicit ignore list, then align the implementation and § 2.