Left open by #13. Issue #9 supplied no answer.
specifications/component/v1/spec.md §5.3 is only this TODO:
TODO — Key grammar, the precedence order between literal, config-reference, and contract-supplied values, and the handling of sensitive values.
Why it matters
Precedence is the sharp one. contract.inputs carries a target.envVarKey, so an input can land on the same key an envVars entry declares literally. Nothing says which wins. Two implementations can each be defensible and disagree, and the disagreement surfaces as a wrong value inside a running workload — not as a validation error.
That is the same failure blueprint §5.2 refused to accept for input merging, and it was refused there with an explicit diagnostic (ERR_CONFLICTING_INPUT_SCHEMA) rather than a silent winner. The same argument applies here.
Sensitivity is the second. §6.1 requires a generated input to declare schema.isSensitive: true, on the grounds that an unmarked minted secret "is echoed back into logs and interfaces". An envVars entry has no equivalent, so the same secret written literally carries no marking at all.
The concrete questions
- Key grammar —
^[A-Z_][A-Z0-9_]*$ is the POSIX shape; is it required, or merely conventional?
- Precedence between a literal
envVars entry, a config reference, and a target.envVarKey collision. Or: is a collision an error, per §5.2's precedent?
- Whether an
envVars value can be marked sensitive, and what marking obliges an implementation to do.
What deciding it costs
A key grammar is narrowing and therefore free only before the first tag (#1/#2/#3 are open). Precedence-as-an-error needs a new diagnostic code and a conformance case. Sensitivity is additive.
Refs #9
Left open by #13. Issue #9 supplied no answer.
specifications/component/v1/spec.md§5.3 is only this TODO:Why it matters
Precedence is the sharp one.
contract.inputscarries atarget.envVarKey, so an input can land on the same key anenvVarsentry declares literally. Nothing says which wins. Two implementations can each be defensible and disagree, and the disagreement surfaces as a wrong value inside a running workload — not as a validation error.That is the same failure blueprint §5.2 refused to accept for input merging, and it was refused there with an explicit diagnostic (
ERR_CONFLICTING_INPUT_SCHEMA) rather than a silent winner. The same argument applies here.Sensitivity is the second. §6.1 requires a generated input to declare
schema.isSensitive: true, on the grounds that an unmarked minted secret "is echoed back into logs and interfaces". AnenvVarsentry has no equivalent, so the same secret written literally carries no marking at all.The concrete questions
^[A-Z_][A-Z0-9_]*$is the POSIX shape; is it required, or merely conventional?envVarsentry, a config reference, and atarget.envVarKeycollision. Or: is a collision an error, per §5.2's precedent?envVarsvalue can be marked sensitive, and what marking obliges an implementation to do.What deciding it costs
A key grammar is narrowing and therefore free only before the first tag (#1/#2/#3 are open). Precedence-as-an-error needs a new diagnostic code and a conformance case. Sensitivity is additive.
Refs #9