Перейти к содержимому

Самопроверка полноты

Workflow, который создаёт результат по явным требованиям, должен проверить готовый артефакт перед выдачей. Проверкой владеет тот же предметный workflow: он читает зафиксированные требования, исследует реальную реализацию, записывает долговечный отчёт и одним проверяемым по схеме ответом возвращает путь и счётчики.

Правила

  1. Источник истины — зафиксированные требования. Не подменяйте их текущим планом или памятью агента.
  2. Проверяйте реальный артефакт. Для каждого требования приводите конкретный код, файл, вывод теста или другое воспроизводимое наблюдение.
  3. Записывайте один долговечный отчёт. Добавляйте по одному упорядоченному пункту на требование и ставьте COVERED, только когда evidence его доказывает; иначе ставьте GAP.
  4. Возвращайте полную сводку атомарно. То же действие возвращает coverage_report_path, total_requirements и requirements_gaps_count. JSON Schema проверяет их форму; второй агент или пересчёт графом не повторяет предметное решение.
  5. Маршрутизируйте пробелы обратно в реализацию. Ноль пробелов ведёт к выдаче. Ненулевое значение входит в ветку исправления или перепланирования.

Todo List — универсальный последовательный checklist с пустым терминальным результатом. Не используйте его как транспорт для классификаций покрытия, outcomes или счётчиков.

Реестр переменных

Объявляйте значения покрытия без defaults, чтобы исполнение без завершённой проверки не могло выдать искусственный нулевой результат:

{
"coverage_report_path": {
"type": "string",
"minLength": 1,
"maxLength": 1000
},
"total_requirements": {
"type": "integer",
"minimum": 1,
"maximum": 100
},
"requirements_gaps_count": {
"type": "integer",
"minimum": 0,
"maximum": 100
}
}

Действие проверки покрытия

Производящая agent-directive записывает версионированный отчёт вроде requirements-coverage-report-v{attempt}.md и вместе возвращает все три глобальные переменные:

{
"type": "object",
"additionalProperties": false,
"properties": {},
"required": ["coverage_report_path", "total_requirements", "requirements_gaps_count"],
"globalInputs": ["coverage_report_path", "total_requirements", "requirements_gaps_count"]
}

В отчёте допустимы предметные термины COVERED и GAP; эти классификации остаются внутри владеющего workflow. JSON Schema доказывает только типы и границы возвращённых значений. Агент по-прежнему отвечает за чтение каждого требования и классификацию на основе evidence.

Фиксируйте завершённый проход сразу после этого ответа, до проверки пробелов или любой видимой агенту паузы. Тогда поздние ветки остановки и перепланирования однозначно различают состояния «coverage не запускался» и «полный предыдущий отчёт существует».

Проверка пробелов

{
"type": "condition",
"id": "check-requirements-gaps",
"condition": {
"operator": "eq",
"left": { "contextPath": "requirements_gaps_count" },
"right": 0
},
"connections": {
"true": "deliver",
"false": "fix-gaps"
}
}

Нулевой default не доказывает, что проверка выполнялась. Не создавайте outputs проверки до полного корректного по схеме ответа coverage action.

Связанные паттерны