coulomb/canned-prompts
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

CANP-WP-0006 T05: HTTP registries, and one finding

Browse source 
--registry now accepts an http(s):// URL as well as a path, implemented with
urllib so reference/ keeps PyYAML as its only dependency.

This was the first real test of INTENT principle 10's claim that a hosted
registry layers on without changing package semantics. Verified against the
running service, almost everything survived the transport unaltered: identity
and its ambiguity rules (a bare id in two registries returns 409 over HTTP just
as it does locally), immutability of a published id@version (identical content
accepted, changed content refused, version bump accepted), strict packaging,
validation, and the index. A package published and then installed over HTTP was
byte-identical to its source — diff -r clean — and its canonical-fidelity eval
still passed after the round trip.

One thing did not survive: a URL is not a registry. A filesystem registry IS
one registry and section 20.1 names it from its directory; an HTTP service
HOSTS SEVERAL behind one base URL. The address therefore cannot name the
registry, so it must be named separately — --as when publishing, a qualified
reference when installing.

Recorded as section 20.4 rather than worked around silently in the client,
because the gap is in the specification's list of registry kinds, not in the
CLI. Publishing to an HTTP registry without --as fails with that explanation
rather than guessing a registry name.

Registry responses are treated as untrusted input (section 19): decode_files
refuses path traversal, with a test. The wire shape round-trips binary content
through base64, also tested.

Reference tests 99 -> 105.

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
This commit is contained in:
tegwick 2026-09-06 20:39:04 +02:00
parent 56b1708b58
commit c076d8395e
6 changed files with 263 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

23
workplans/CANP-WP-0006-hosted-registry-service.md
View file

@ -206,7 +206,7 @@ check` now reports no drift.
```task
id: CANP-WP-0006-T05
status: todo
status: done
priority: medium
state_hub_task_id: "8dacbb68-aaa2-5f91-942d-a0667f1f1fc7"
```
@ -220,6 +220,27 @@ claims.
If they do not survive it, that is a finding about the format, not a bug to
paper over in the client.
**Done, and it produced exactly one finding.**
*What survived unaltered*, verified against the running service: identity and
its ambiguity rules (a bare id in two registries came back 409 over HTTP just as
it does locally), immutability of a published `<id>@<version>` (identical
content accepted, changed content refused, a version bump accepted), strict
packaging, validation, and the index. A package published and installed over
HTTP was **byte-identical** to its source — `diff -r` clean — and its
`canonical-fidelity` eval still passed after the round trip.
*What did not*: **a URL is not a registry.** A filesystem registry *is* one
registry and § 20.1 names it from its directory; an HTTP service *hosts
several* behind one base URL. So the address cannot name the registry, and it
has to be named separately — `--as` when publishing, a qualified reference when
installing. Recorded as § 20.4 rather than papered over in the client, because
the gap is in the specification's list of registry kinds, not in the CLI.
Implemented with `urllib` rather than a library, so `reference/` keeps PyYAML as
its only dependency. Registry responses are treated as untrusted input (§ 19):
`decode_files` refuses path traversal, with a test.
## Image and smoke contract
```task