# Capability contract boundary — real-spec source review

2026-09-27. Codex author-model review, documentary evidence only; no application
or runtime execution. Prompted by a non-primary lead
(`history/260927-ComplexWebAppUiComponents_chatgpt.txt`, a pasted AI-chat
transcript with unverifiable, broken citation markers) that is **not** treated
as a source or cited as evidence anywhere below — only the two real specs it
pointed to were actually read. See [SourceCatalog.md](../catalog/SourceCatalog.md).

## Located claims

| Claim | Located text | Interpretation / limit |
| --- | --- | --- |
| CC01 — Custom Elements lifecycle contract | [MDN, Using custom elements](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements): a custom element class declares `static observedAttributes`, and the platform calls `connectedCallback()`, `disconnectedCallback()`, `adoptedCallback()` and `attributeChangedCallback(name, oldValue, newValue)` at defined lifecycle points. | This is a real, browser-native lifecycle/attribute-change notification mechanism. It is narrower than a full "capability contract": this specific page documents attributes and lifecycle callbacks, not a standardized way to declare *semantic* events, commands or slots for a component's public interface — those are separate platform features (custom events, `<slot>`) that this page does not cover in the sections read. |
| CC02 — Module Federation's expose/consume contract | [webpack, Module Federation](https://webpack.js.org/concepts/module-federation/): a build acts as a "container" that exposes modules through a two-step contract (async load, then sync evaluate); other builds consume it as a "remote module." Shared modules are negotiated through a "share scope" with a `packageName`/`requiredVersion`, not bundled per build. | This is a real, documented mechanism for *code loading and dependency sharing* across independently built bundles. It says nothing about the shape of a UI component's semantic interface (props/events/commands) — Module Federation operates at the module-resolution layer, one layer below any UI-facing contract. |
| CC03 — the two mechanisms are complementary, not equivalent | Neither CC01 nor CC02 defines a semantic "capability contract" (inputs/events/commands/slots/lifecycle as a declared, versioned interface) as a first-class platform or tool concept. | A semantic capability contract, if adopted, would need to be authored *on top of* one or both of these mechanisms (e.g., attributes/custom-events on a Custom Element, or an exposed module's function signature in Module Federation) — it is not something either spec hands you directly. This is the gap the reviewed lead's "Interface Capability" idea was pointing at, but the lead itself is not evidence that anyone has actually built or standardized it. |

## Disposition

Draft [Capability Contract Boundary](../candidates/CapabilityContractBoundary.md)
(CAND-0018) as a new hypothesis, distinct from [Independent Feature Boundary](../candidates/IndependentFeatureBoundary.md)
(release/activation cadence) and [Vertical Feature Slice](../candidates/VerticalFeatureSlice.md)
(source-code grouping): this pattern concerns the *shape* of a UI capability's
public semantic surface, independent of which runtime-isolation mechanism
(package, Web Component, Module Federation remote, micro-frontend, iframe)
implements it. Two documentary sources, one family each (Web Components,
webpack); no independent known use of a capability contract itself is claimed —
only that its two candidate substrates are real and independently documented.
No canonical admission, no application/runtime evidence, no M1/M2 status change.