Repository navigation
Publish the decentralized UI contract and compatibility kit #6
Description
🤖 Generated by the Agentic Engineer
User story
As a data-product publisher, I want my product UI to work in any compatible catalog so that I can own its interaction model without coupling releases to one central application.
Acceptance criteria
- A versioned manifest defines the product UI entrypoint, capabilities, origins, and message contract.
- The reference host runs third-party UI in a restrictive sandbox with explicit capability grants and origin validation.
- A compatibility test kit can validate a product UI independently of the central registry.
- Two independently built host examples load the same demo product.
- Accessibility, responsive behavior, loading, error, and unavailable-product states are covered.
Rough size: L.
Metadata
Metadata
Assignees
Labels
No labels
Type
Fields
Priority
None yet
Start date
None yet
Target date
None yet
Effort
None yet
Projects
- Status
Activity
chore: agent-claim #6 nonce=83ee569ff1f555e99ada3363a4df577d
devantler commentedon Sep 30, 2026
All five implementation criteria are delivered by merged PR #121 (
4e5227185181706682cdcf6b2a6e3bcccf9fa3e8) and its v1.6.0 release, retained in current v1.7.0. The versioned manifest, restrictive reference host, independent compatibility kit, two hosts using the same demo, and accessibility/responsive/error-recovery paths are covered by the exact-head browser and Kubernetes acceptance recorded on that PR.Closing the completed implementation explicitly because this issue remained open after merge. Production activation and release-flag retirement remain separately tracked in #120.