Finding (reported from the live listings)
wasm.directory indexes components under the registry namespace but interfaces under the WIT package namespace. Ours disagree:
|
namespace |
| WIT packages |
falcon — falcon:cascade@0.7.0, falcon:flight@1.26.0 |
| OCI registry / registered entry |
pulseengine — registry/pulseengine.toml |
So https://wasm.directory/pulseengine/falcon-iekf/1.131.1 links its exports/imports to https://wasm.directory/falcon/cascade/0.7.0/interface/ekf — a different namespace, which is orphaned: /falcon reports "0 packages", "No packages found under this namespace", no owner, no registry.
Contrast https://wasm.directory/wasi/io/0.2.9/interface/poll — coherent, because the wasi package namespace is owned and registered.
Net: the interfaces are reachable by direct URL but not discoverable from our namespace, and the namespace they do live in belongs to nobody.
Options
- Publish + register the WIT package (
falcon:cascade) as its own artifact and claim the falcon namespace via a kind: interface registry entry. Keeps the WIT identity, makes the interface independently consumable (component install falcon:cascade), and closes the ownership gap. Needs a new publish step — wkg can push a WIT package.
- Register
falcon as a second namespace pointing at ghcr.io/pulseengine. Cheapest, claims the namespace — but the split remains, and it is slightly dishonest since nothing is actually published under a falcon registry path.
- Rename the WIT packages
falcon:* → pulseengine:*. Fully coherent, and breaking: it changes every import/export string, the wac composition, the meld fusion, and jess's integration. Not worth it for a listing.
Recommendation: (1). It is the only option that makes the namespace genuinely ours and makes the interface reusable, which is the point of publishing components in the first place. falcon as a product namespace alongside pulseengine as the org is legitimate — the problem is that it is unclaimed, not that it exists.
Second, separate finding on the same pages
falcon-iekf:1.131.1 and falcon-attitude:1.131.1 each import 14 wasi:* interfaces (measured on the published blobs). Only falcon-rate is clean (0). Expected — only rate has been converted — and already tracked as SWREQ-FALCON-OCI-P02 (v1.133). Worth noting it is now publicly visible: a component described as formally-verified and embedded-targeted, listing 14 WASI imports, reads badly to anyone browsing. That raises the priority of finishing the conversion, though it does not change its scope.
Refs: #306 (OCI rollout), OCI-P02 (v1.133 no_std conversion), docs/OCI-DISTRIBUTION.md.
🤖 Generated with Claude Code
Finding (reported from the live listings)
wasm.directory indexes components under the registry namespace but interfaces under the WIT package namespace. Ours disagree:
falcon—falcon:cascade@0.7.0,falcon:flight@1.26.0pulseengine—registry/pulseengine.tomlSo
https://wasm.directory/pulseengine/falcon-iekf/1.131.1links its exports/imports tohttps://wasm.directory/falcon/cascade/0.7.0/interface/ekf— a different namespace, which is orphaned:/falconreports "0 packages", "No packages found under this namespace", no owner, no registry.Contrast
https://wasm.directory/wasi/io/0.2.9/interface/poll— coherent, because thewasipackage namespace is owned and registered.Net: the interfaces are reachable by direct URL but not discoverable from our namespace, and the namespace they do live in belongs to nobody.
Options
falcon:cascade) as its own artifact and claim thefalconnamespace via akind: interfaceregistry entry. Keeps the WIT identity, makes the interface independently consumable (component install falcon:cascade), and closes the ownership gap. Needs a new publish step —wkgcan push a WIT package.falconas a second namespace pointing atghcr.io/pulseengine. Cheapest, claims the namespace — but the split remains, and it is slightly dishonest since nothing is actually published under afalconregistry path.falcon:*→pulseengine:*. Fully coherent, and breaking: it changes every import/export string, the wac composition, the meld fusion, and jess's integration. Not worth it for a listing.Recommendation: (1). It is the only option that makes the namespace genuinely ours and makes the interface reusable, which is the point of publishing components in the first place.
falconas a product namespace alongsidepulseengineas the org is legitimate — the problem is that it is unclaimed, not that it exists.Second, separate finding on the same pages
falcon-iekf:1.131.1andfalcon-attitude:1.131.1each import 14wasi:*interfaces (measured on the published blobs). Onlyfalcon-rateis clean (0). Expected — onlyratehas been converted — and already tracked as SWREQ-FALCON-OCI-P02 (v1.133). Worth noting it is now publicly visible: a component described as formally-verified and embedded-targeted, listing 14 WASI imports, reads badly to anyone browsing. That raises the priority of finishing the conversion, though it does not change its scope.Refs: #306 (OCI rollout), OCI-P02 (v1.133 no_std conversion), docs/OCI-DISTRIBUTION.md.
🤖 Generated with Claude Code