canned-prompts/workplans/CANP-WP-0004-prompt-index.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
CANP-WP-0004	workplan	Catalog index: where a package came from and when	agents	canned-prompts	finished	codex	practice	2026-09-06	2026-09-06	4fc1883c-8103-5ef6-9b25-5eaad2aee0a8

Catalog index: where a package came from and when

Driven by packaging a real collection (helix-forge HF-WP-0005). The operator asked for canned-prompts to "build a database of versioned prompts", recording the source a prompt came from and the date it was included — the first step toward a platform for collaborative prompting.

The format had no place for this. provenance (§ 13) records who wrote a prompt and where the idea came from, but nothing recorded how a copy arrived in a particular store.

Fix practice/pqrst-estimate to be the canonical prompt

id: CANP-WP-0004-T01
status: done
priority: high
state_hub_task_id: "0fb4602a-f561-5ecb-acb2-1888c24f9710"

Found while researching helix-forge. examples/pqrst-estimate was not the canonical PQRST prompt. The canonical one is ~/pqrst-practice/PqrstPrompt.md, normatively specified in spec/PqrstEstimationPractice.md, and hall-of-helix/CLOSING.md requires pasting it unmodified. Ours was a paraphrase with a different output shape — no Confidence, no Signature, no Dominant factors — and CANP-WP-0002-T03 had made it worse by prepending a house_style inclusion to a prompt whose governing document says do not modify it.

A copied prompt that silently forked its source, sitting in the examples directory of the repo whose INTENT.md opens by naming that exact failure.

Fixed: the template is the canonical block extracted programmatically rather than retyped, and the default render is byte-identical at 2886 bytes. evals/canonical-fidelity.yaml guards it with sixteen render checks, including not_contains checks naming the paraphrase it used to be. Version 0.2.1 → 1.0.0, the § 17 MAJOR case.

The source documents two optional add-ons appended after the block. CPF has no conditionals, so add_ons is an input defaulting to the empty string and each add-on is an example fixture. Adequate, but a workaround — recorded as evidence about § 23's deferred "richer template syntax".

Add the index

id: CANP-WP-0004-T02
status: done
priority: high
state_hub_task_id: "4ceb7e8b-3ed7-5019-918c-59d5bcdb9b91"

A store may keep an index.yaml recording which package versions entered it, from where, and when. Specified in § 20.3, deliberately as store metadata rather than package data: how a copy arrived differs for every consumer, and recording an arrival must never rewrite the package that arrived (§ 17).

add, install and publish record an entry carrying registry, id, version, name, source, method, included_at, the package's declared author and source, and its licence — the last two copied so a listing is readable without opening every package. A new index verb lists it.

included_at is first arrival and is never overwritten; a re-run updates last_seen_at instead. When a package first entered a collection is a fact about history, not about the last time someone ran a command.

reference/canned_prompts.py: read_index, record_inclusion, index_entry_key, cmd_index. Tests 84 → 90.

Record the inclusion-deduplication gap

id: CANP-WP-0004-T03
status: done
priority: medium
state_hub_task_id: "fdab9028-3cee-5425-8f78-165ef03b39fe"

Found by using the format. helix/repo-advance composed helix/commit-sync, which composes helix/custodian-conventions, while also composing the conventions itself. The rendered prompt contained the conventions block twice: CPF inclusion has no deduplication, so a diamond dependency renders shared content once per path.

Not fixed in the format. Deduplicating would mean deciding which occurrence survives and what happens when the two paths resolve different versions — that is resolver behaviour, and § 10.4 keeps composition declarative on purpose. Nothing in § 10.4 currently warns an author, which is the actual defect.

Downstream this was fixed by factoring (HF-WP-0005-T03), which is the right answer for a collection and may be the right general advice.

Handed to CANP-WP-0005: document the diamond behaviour in § 10.4 and decide whether a validator should warn when one package reaches the same dependency by two paths.