Left open by #13, and stated twice — this is one question cross-referenced from both ends, so it gets one issue.
specifications/component/v1/spec.md §6.2:
TODO — Type compatibility between an output and the input it feeds. schema.semanticType is the tag a composition layer matches on, but the matching rule is not yet stated. It belongs with blueprint §4.2, which resolves the connection.
specifications/blueprint/v1/spec.md §4.2:
TODO — Type compatibility between the output and the input it feeds. schema.semanticType is the tag a composition layer matches on, but the matching rule is not stated, and neither is what happens when a STRING output feeds an INTEGER input.
Why it matters
Blueprint §4.2 already resolves both ends of a connection and rejects each half independently — ERR_UNKNOWN_ROLE when fromRole names no node, ERR_UNKNOWN_OUTPUT when fromOutput names no output of the component that node deploys. Both now have conformance cases.
What it does not check is whether the two ends fit. A STRING output wired into an INTEGER input satisfies every rule the specification currently states, and fails at deploy time inside the consuming workload — the exact failure shape §5.2 rejected for input merging, and rejected on the grounds that "it fails at deploy time, inside the consuming workload, a long way from the two documents that disagreed and with nothing pointing back at them."
The argument that produced ERR_CONFLICTING_INPUT_SCHEMA applies here unchanged. This is the last place a composition can be internally inconsistent and still validate.
The concrete questions
- Is
type compatibility exact, or is widening permitted (INTEGER output into a STRING input)?
- What is
semanticType for, given type exists? Is a semanticType mismatch an error, a warning, or advisory metadata a storefront uses?
- Does a mismatch need its own code, or is
ERR_INCOMPATIBLE_CONNECTION one code covering both axes?
- What about an output whose
schema is absent or permissive — does an unconstrained producer satisfy a constrained consumer?
What deciding it costs
semantic, needs the referenced component document, therefore a case tree — which ADR 0002 now makes expressible. conformance/blueprint/v1/semantic/008-connection-names-unknown-output/ is the fixture to copy.
Adding the rule rejects compositions that validate today, so it is breaking after the first tag. Release PRs #1/#2/#3 are open.
Refs #9
Left open by #13, and stated twice — this is one question cross-referenced from both ends, so it gets one issue.
specifications/component/v1/spec.md§6.2:specifications/blueprint/v1/spec.md§4.2:Why it matters
Blueprint §4.2 already resolves both ends of a connection and rejects each half independently —
ERR_UNKNOWN_ROLEwhenfromRolenames no node,ERR_UNKNOWN_OUTPUTwhenfromOutputnames no output of the component that node deploys. Both now have conformance cases.What it does not check is whether the two ends fit. A
STRINGoutput wired into anINTEGERinput satisfies every rule the specification currently states, and fails at deploy time inside the consuming workload — the exact failure shape §5.2 rejected for input merging, and rejected on the grounds that "it fails at deploy time, inside the consuming workload, a long way from the two documents that disagreed and with nothing pointing back at them."The argument that produced
ERR_CONFLICTING_INPUT_SCHEMAapplies here unchanged. This is the last place a composition can be internally inconsistent and still validate.The concrete questions
typecompatibility exact, or is widening permitted (INTEGERoutput into aSTRINGinput)?semanticTypefor, giventypeexists? Is asemanticTypemismatch an error, a warning, or advisory metadata a storefront uses?ERR_INCOMPATIBLE_CONNECTIONone code covering both axes?schemais absent or permissive — does an unconstrained producer satisfy a constrained consumer?What deciding it costs
semantic, needs the referenced component document, therefore a case tree — which ADR 0002 now makes expressible.conformance/blueprint/v1/semantic/008-connection-names-unknown-output/is the fixture to copy.Adding the rule rejects compositions that validate today, so it is breaking after the first tag. Release PRs #1/#2/#3 are open.
Refs #9