frontend-patterns/research/candidates/CapabilityContractBoundary.md
tegwick eaa1608771 Draft CAND-0018 Capability Contract Boundary from a screened AI-chat lead
history/260927-ComplexWebAppUiComponents_chatgpt.txt is a pasted AI-chat
transcript on UI-integration architecture. It fails this repo's primary-source
bar (unauthored, unverifiable broken citation markers), so it is screened as
a leads-only document, not cataloged as a source, and never cited as evidence.

Instead read the two real specs it pointed to: MDN Custom Elements (SRC-0046)
and webpack Module Federation (SRC-0047). Neither defines a semantic UI
capability contract (inputs/events/commands/slots) as a first-class concept;
that gap motivates the new draft hypothesis, distinct from the existing
Independent Feature Boundary (release cadence) and Vertical Feature Slice
(source grouping) candidates.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: sonnet
Assistant-Process: 290719@bnt-lap001
Assistant-Session: 55cbe504-1bfe-4932-b761-29016523c87b
2026-09-27 23:29:10 +02:00

53 lines
3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
title: Capability Contract Boundary
status: draft
maturity: hypothesis
families: [composition, execution]
scales: [L4]
admission: research-candidate-only
---
# Capability Contract Boundary
Context: a UI capability (e.g. a customer editor, a document viewer) is consumed by
one or more independently evolving host applications, possibly across frameworks or
teams. The host needs a stable way to configure, observe and command the capability
without depending on its internal framework, state library or rendering technology.
Proposed solution: declare the capability's public surface as an explicit, versioned
semantic contract — inputs/configuration, emitted events, invokable commands, and
host-provided presentation slots — separately from whichever runtime-isolation
mechanism (a plain package, a Custom Element, a Module Federation remote, a
micro-frontend, an iframe) carries it. The contract is the thing consumers depend on
and version against; the isolation mechanism is an implementation detail that can
change without necessarily breaking the contract.
Result: hosts can swap or upgrade a capability's implementation without renegotiating
its interface, and the interface can be reasoned about independently of deployment
topology. Declaring a contract does not by itself provide runtime isolation, dependency
negotiation or compatibility checking — those still come from whatever mechanism
implements it (see Evidence). A contract with no enforcement is only documentation.
Evidence: [source review](../reviews/CapabilityContractSources.md) CC01–CC03 locates
two real, independently documented substrate mechanisms — Custom Elements'
attribute/lifecycle callbacks (CC01) and Module Federation's expose/consume module
contract (CC02) — and establishes that neither defines a semantic capability contract
itself (CC03); one would be authored on top of either. No known use of an explicit
capability contract, as distinct from its substrate mechanisms, has been located.
Prompted by a non-primary AI-chat lead that is explicitly not cited as evidence; see
[SourceCatalog.md](../catalog/SourceCatalog.md).
Alternative: an ad hoc, framework-typed component API (e.g. React props/callbacks)
when every consumer already shares the same framework and version, making a
framework-neutral contract layer unnecessary overhead.
Proposed relations: [Independent Feature Boundary](IndependentFeatureBoundary.md)
governs release/activation cadence and may carry a capability contract without being
one; [Vertical Feature Slice](VerticalFeatureSlice.md) governs source-code grouping,
a different concern. Neither entails this pattern nor is entailed by it.
Next test: pin one real Custom Element library and one real Module Federation
example; compare what each actually enforces about a component's declared
inputs/events/commands versus what a hand-authored capability-contract layer would
need to add on top. All relations are research proposals; no canonical identity or
admitted graph edges. The next test is planned, not executed.