Left open by #13. Issue #9 supplied no answer.
specifications/blueprint/v1/spec.md §5.2:
TODO — How an authored parameter binds to the component inputs it satisfies. Derivation makes that correspondence by key; an override is used verbatim, which does not say what happens to a parameter key matching no input, or to a USER input no parameter covers.
Why it matters
§5 settled that a non-empty parameters mapping is "an authored override, used in place of derivation rather than merged with it". §5.1 and §5.2 then specify derivation in full — which inputs are derived, in what order, and what happens when two nodes disagree.
The override path has none of that. It is the path an author takes deliberately, and §5.2's own closing line recommends it: "An author who wants one shared value across two components says so by writing spec.parameters outright, which is what an authored override is for." The specification recommends a path it does not define.
The concrete questions
- A parameter matching no input. Dead configuration — the install form asks for something nothing consumes. Error, or permitted?
- A
USER input no parameter covers. The sharper one. The component requires a value, the install form never asks for it, and the workload starts without it. If overrides are used verbatim, this is silent by construction.
- Does binding stay by key? Derivation binds by key. If overrides do too, then (1) and (2) are both decidable statically and both deserve diagnostics. If they do not, something else has to say how a parameter reaches an input.
Question 2 has the same shape as the conflict §5.2 already refused to leave silent: nothing fails at validation time, and it fails at deploy time inside the consuming workload with nothing pointing back.
What deciding it costs
semantic, needs the referenced component documents, therefore a case tree — ADR 0002 makes this expressible now. conformance/blueprint/v1/semantic/009-conflicting-input-schema/ is the fixture to copy.
Probably two new codes. Adding them rejects blueprints that validate today.
Refs #9
Left open by #13. Issue #9 supplied no answer.
specifications/blueprint/v1/spec.md§5.2:Why it matters
§5 settled that a non-empty
parametersmapping is "an authored override, used in place of derivation rather than merged with it". §5.1 and §5.2 then specify derivation in full — which inputs are derived, in what order, and what happens when two nodes disagree.The override path has none of that. It is the path an author takes deliberately, and §5.2's own closing line recommends it: "An author who wants one shared value across two components says so by writing
spec.parametersoutright, which is what an authored override is for." The specification recommends a path it does not define.The concrete questions
USERinput no parameter covers. The sharper one. The component requires a value, the install form never asks for it, and the workload starts without it. If overrides are used verbatim, this is silent by construction.Question 2 has the same shape as the conflict §5.2 already refused to leave silent: nothing fails at validation time, and it fails at deploy time inside the consuming workload with nothing pointing back.
What deciding it costs
semantic, needs the referenced component documents, therefore a case tree — ADR 0002 makes this expressible now.conformance/blueprint/v1/semantic/009-conflicting-input-schema/is the fixture to copy.Probably two new codes. Adding them rejects blueprints that validate today.
Refs #9