Files
correx/docs/schemas/analysis.json
T
kami 894969d62b feat(validation): enforce array minItems/items in artifact schemas (role-reliability §3)
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.
2026-06-13 15:47:54 +04:00

22 lines
569 B
JSON

{
"type": "object",
"properties": {
"summary": {
"type": "string",
"description": "what the request is asking for, in your own words"
},
"requirements": {
"type": "array",
"description": "concrete requirements / acceptance criteria, one per item",
"minItems": 1,
"items": { "type": "string" }
},
"affected_areas": {
"type": "array",
"description": "files, modules, or subsystems likely involved, one per item"
}
},
"required": ["summary", "requirements"],
"additionalProperties": true
}