kami
894969d62b
The JSON-schema artifact validator enforced `required` keys but not array
contents, so a model could emit `"requirements": []` (or `"steps": []`,
`"components": []`) and pass — a misread brief sailing through as a valid
artifact. That empty-list gap is the hole under role-reliability §3's
keystone ("force the analyst to define done; verifiability propagates
downstream").
- JsonSchemaProperty gains `minItems` and `items` (recursive), letting a
schema declare a required-non-empty / element-typed array.
- JsonSchemaValidator checks array length >= minItems and each element's
declared item type (with index in the message). Pure + deterministic;
single-return to stay within the detekt ReturnCount budget.
- Role-pipeline schemas tightened: analysis.requirements, design.components,
impl_plan.steps → minItems 1 + items string. Prompt-free — these arrays
were already `required`; this only forbids them being empty.
§4 (force a non-empty `alternativesConsidered` on the architect) is
deliberately NOT taken: it contradicts the standing "don't raise
alternatives unnecessarily" preference the architect prompt already encodes.
22 lines
517 B
JSON
22 lines
517 B
JSON
{
|
|
"type": "object",
|
|
"properties": {
|
|
"approach": {
|
|
"type": "string",
|
|
"description": "the chosen approach and why"
|
|
},
|
|
"components": {
|
|
"type": "array",
|
|
"description": "components/files to add or change, one per item",
|
|
"minItems": 1,
|
|
"items": { "type": "string" }
|
|
},
|
|
"risks": {
|
|
"type": "array",
|
|
"description": "risks, trade-offs, or open questions, one per item"
|
|
}
|
|
},
|
|
"required": ["approach", "components"],
|
|
"additionalProperties": true
|
|
}
|