# Универсальный AI-промт для Acceptance / Regression Harness

Этот промт помогает один раз создать постоянную автоматизированную систему приёмочных и регрессионных проверок для любого цифрового продукта.

## Как использовать

1. Заполните четыре обязательных поля: путь к проекту, название продукта, его краткое назначение и URL, если он есть.
2. Выберите режим: `SCENARIO_MODE = AUTO` или `MANUAL`.
3. Выберите бюджет: `TOKEN_BUDGET = ECONOMY`, `BALANCED` или `DEEP`.
4. Выберите окружение: `DEPLOYMENT_MODE = LOCAL`, `STAGING` или `PRODUCTION`.
5. Скопируйте весь промт ниже и отдайте его ChatGPT Code, Codex, Claude Code или другому coding-agent.

## Готовый промт

```text
PROJECT_PATH = "[УКАЖИТЕ ПУТЬ К ПРОЕКТУ]"

PRODUCT_NAME = "[НАЗВАНИЕ ПРОДУКТА]"

PRODUCT_PURPOSE = "[КРАТКО ОПИШИТЕ, ЧТО ДОЛЖЕН ДЕЛАТЬ ПРОДУКТ]"

PRODUCT_URL = "[URL, ЕСЛИ ЕСТЬ]"

DEPLOYMENT_MODE = LOCAL
# LOCAL | STAGING | PRODUCTION

SCENARIO_MODE = AUTO
# AUTO | MANUAL

MAX_SCENARIOS = 20
# используется только при MANUAL

TOKEN_BUDGET = ECONOMY
# ECONOMY | BALANCED | DEEP


ЦЕЛЬ

В проекте PROJECT_PATH создай постоянный автоматизированный acceptance/regression harness для PRODUCT_NAME.

После его создания основную регрессионную проверку должен выполнять обычный код, а не LLM. LLM-токены расходуй только на проектирование проверок, анализ FAIL, поиск root cause и исправление системных дефектов.

Работай автономно: изучи продукт, построй harness, запусти его, классифицируй отклонения, выполни разумные исправления и проверь итог. Не деплой без явного разрешения пользователя.


ЛОГИКА DEPLOYMENT_MODE

LOCAL:
- production URL не обязателен;
- проверяй локальную бизнес-логику, локальный browser E2E и генерируемые PDF/report/output;
- production smoke пропусти;
- отсутствие опубликованного сервера не считай ошибкой;
- не выполняй deploy без отдельной команды.

STAGING:
- используй PRODUCT_URL как staging URL;
- основную matrix гоняй локально;
- после локального PASS выполни короткий staging smoke;
- не гоняй всю matrix браузером по staging без отдельной причины.

PRODUCTION:
- сначала выполни основной regression contour локально;
- production используй только для короткого smoke;
- не гоняй всю matrix браузером по production без доказанной необходимости;
- не изменяй постоянные production-данны и не выполняй опасные сценарии.


АДАПТИВНОЕ КОЛИЧЕСТВО СЦЕНАРИЕВ

Не используй заранее фиксированное число сценариев.

В SCENARIO_MODE = AUTO сначала оцени сложность продукта:
- количество пользовательских ролей;
- количество основных бизнес-механик;
- число ветвлений и outcome paths;
- типы входных данных;
- критичные расчёты;
- known, estimated и unknown states;
- boundary и contradiction cases;
- риск финансовой и пользовательской ошибки.

После анализа выведи:

RECOMMENDED_SCENARIOS: N

Почему:
- ...
- ...
- ...

Не создавай лишние сценарии ради количества.

Ориентиры, а не жёсткие лимиты:
- ECONOMY: примерно 5–15, минимально достаточное покрытие;
- BALANCED: примерно 10–30, стандартная acceptance/regression matrix;
- DEEP: примерно 20–60+ для сложных продуктов с ролями, расчётами и большим числом веток.

Если продукт проще, используй меньше. Если объективно сложнее, можно обосновать большее число.

В SCENARIO_MODE = MANUAL используй MAX_SCENARIOS как верхний лимит. Если его явно недостаточно, сообщи: «Для разумного покрытия рекомендуется не менее X сценариев». Не превышай MAX_SCENARIOS без разрешения.


ПЕРВИЧНЫЙ АНАЛИЗ ПРОДУКТА

Не перечитывай весь репозиторий без необходимости. Сначала найди файлы, связанные с:
- forms/questions;
- answers/input;
- validation;
- normalization;
- model и calculations;
- business logic;
- contradictions;
- verdict/result;
- PDF/report/generated output;
- existing tests;
- browser/e2e.

Построй короткую внутреннюю карту:

INPUT
→ NORMALIZATION
→ MODEL
→ CALCULATION
→ VALIDATION
→ VERDICT
→ RESULT
→ OUTPUT

Не пиши пользователю длинный архитектурный отчёт, если он не нужен для действия.


АРХИТЕКТУРА ACCEPTANCE HARNESS

1. DATA FIXTURES
Храни сценарии как данные, а не как множество копий тестового кода.

Пример формы fixture:
{
  id: "S01",
  name: "...",
  category: "...",
  input: {...},
  expected: {...}
}

2. ONE COMMON RUNNER
Создай один parametrized runner, который прогоняет все fixtures.

3. CROSS-SCENARIO INVARIANTS
Выдели глобальные правила, обязательные для всех сценариев.

4. BOUNDARY CHECKS
Проверяй границы параметрически, не размножая однотипные fixtures.

5. REPRESENTATIVE BROWSER SUBSET
Проходи полный UI-flow только для репрезентативной подвыборки.

6. REPRESENTATIVE PDF/OUTPUT SUBSET
Генерируй итоговые документы только для репрезентативных сценариев и output-related FAIL.


ТИПЫ СЦЕНАРИЕВ

Включай только релевантные продукту категории:
- typical success;
- typical negative result;
- incomplete и unknown data;
- estimated data;
- contradictory input;
- boundary values;
- invalid combinations;
- extreme but valid values;
- alternate user role;
- alternate business/model type;
- branch-specific paths;
- financial risk;
- operational risk;
- capacity;
- missing dependency;
- output/PDF consistency.


EXPECTED BEHAVIOR

Для каждого сценария проверяй только объективно проверяемые свойства:
- expected result или error;
- expected contradiction;
- expected critical unknown;
- forbidden unknown;
- allowed range;
- branch shown/hidden;
- calculated value;
- section exists/absent;
- status и reliability;
- consistency between result and output.

Не выдумывай точный verdict, если он не выводится однозначно из входных данных и правил продукта.


CROSS-SCENARIO INVARIANTS

Адаптируй invariants к фактической логике продукта. Базовые примеры:
- одна сущность не может одновременно быть known и critical unknown;
- unknown нельзя молча превращать в 0;
- не должно быть `NaN` и `Infinity`;
- невозможные отрицательные значения запрещены;
- одно значение не должно учитываться дважды;
- доказанный негативный результат не должен маскироваться посторонним unknown;
- critical contradiction несовместимо с сообщением «противоречий нет»;
- скрытые fallback запрещены без явного правила;
- result и PDF/report/output не должны расходиться;
- итоговый документ должен отражать фактический результат.


BOUNDARY CHECKS

Для основных числовых полей параметрически проверь:
- 0;
- 1;
- minimum valid;
- maximum reasonable;
- very large;
- unknown;
- estimated;
- known.

Не создавай ради этого десятки отдельных сценариев.


ГЛАВНОЕ ПРАВИЛО ЭКОНОМИИ ТОКЕНОВ

ЗАПРЕЩЕНО:
- вручную проходить все сценарии через LLM;
- подробно анализировать каждый PASS;
- выводить полные объекты успешных результатов;
- писать отдельный длинный отчёт на каждый сценарий;
- читать огромные логи без причины;
- чинить каждый FAIL отдельно, если причина общая;
- создавать бесконечные repair cycles.

PASS выводи агрегированно:

Total: N
PASS: X
FAIL: Y


FAIL OUTPUT

Для FAIL выводи только:
- scenario;
- check;
- expected;
- actual;
- relevant fields.

Пример:

S12
check: capacity
expected: contradiction=true
actual: false
salesMonthly=120
timePerOrder=180
availableHours=160

Не выводи полные report/model objects без необходимости.


ROOT-CAUSE GROUPING

После прогона автоматически группируй FAIL по системным причинам, например:

CAPACITY — 4
VALIDATION — 3
RECONCILIATION — 2
PDF — 1

Сначала исправляй root cause. Не чини поочерёдно сценарии, если один системный дефект вызвал несколько FAIL.


TEST BUG VS PRODUCT BUG

Перед изменением production code классифицируй каждый FAIL:

PRODUCT BUG

или

TEST FIXTURE BUG

Не меняй production code только ради того, чтобы сделать зелёным неправильный fixture.


MAXIMUM REPAIR CYCLES

Максимум 3 цикла на один пакет:

CYCLE 1
RUN
→ classify
→ root-cause fixes

CYCLE 2
RUN
→ remaining root-cause fixes

CYCLE 3
FINAL RUN

После третьего цикла — STOP.

Если остались ошибки, выведи:

UNRESOLVED:
scenario
suspected root cause
relevant files

Не продолжай бесконечный расход LLM-токенов.


BROWSER TESTING

Не гоняй браузером всю matrix. Выбери representative subset.

Ориентир:
- ECONOMY: 3–5 browser flows;
- BALANCED: 5–8;
- DEEP: 8–12.

Включи:
- typical success;
- negative;
- incomplete;
- contradiction;
- boundary;
- critical business path.

Проверяй:
- branching;
- validation;
- hidden и required fields;
- navigation;
- result;
- CTA;
- основное responsive behavior.


PDF / REPORT / GENERATED OUTPUT

Не генерируй output для каждого scenario.

Ориентир:
- ECONOMY: 3–5;
- BALANCED: 5–8;
- DEEP: 8–12.

Дополнительно генерируй output для FAIL, если проблема связана именно с output.

Автоматически сравнивай:
- result;
- verdict;
- reliability;
- warnings;
- contradictions;
- unknowns;
- recommendations;
- calculations.


ПОСЛЕ ENGINE PASS

Если проект поддерживает соответствующие проверки, выполни:
- unit/integration;
- typecheck;
- lint;
- build;
- browser representative subset;
- PDF/output representative subset.

Сначала прочитай package manifest, project scripts, build/test config и существующую документацию.


НЕ ВЫДУМЫВАТЬ КОМАНДЫ

Используй только реальные команды проекта, найденные в package manifest, scripts и конфигурации.

Если единой acceptance command нет, не выдумывай её. Задокументируй фактическую последовательность.

Если безопасно и пользователь разрешил изменение scripts, можно добавить единую команду. Без такого разрешения не меняй scripts.


PRODUCTION / STAGING SMOKE

Выполняй только при DEPLOYMENT_MODE = STAGING или PRODUCTION.

Не повторяй всю matrix. Используй smoke subset:
- ECONOMY: 2–3;
- BALANCED: 3–4;
- DEEP: 4–6.

Проверь:
- доступность приложения;
- основной happy path;
- critical negative path;
- incomplete/error path;
- итоговый результат.

Не создавай реальные заказы, платежи, постоянные аккаунты или необратимые production-данные. Если smoke требует рискованного внешнего действия, остановись и запроси точечное подтверждение.


ПОСТОЯННЫЙ REGRESSION CORPUS

Сохрани harness в репозитории.

Добавляй новый scenario только, когда:
A. появилась новая механика продукта; или
B. найден новый реальный класс дефекта.

Не увеличивай matrix ради количества. Любой production-баг после исправления по возможности превращай в постоянный regression fixture.


ДОКУМЕНТАЦИЯ

Создай в репозитории `ACCEPTANCE_HARNESS.md` и укажи:
- назначение;
- architecture;
- fixtures;
- runner;
- invariants;
- browser subset;
- output subset;
- фактические project commands;
- baseline;
- known coverage gaps;
- scenario policy;
- maximum repair cycles;
- LLM token economy rules.


ФИНАЛЬНЫЙ ОТЧЁТ

Верни краткий отчёт:

ACCEPTANCE MATRIX

Recommended scenarios: N
Scenario mode: AUTO/MANUAL
Token budget: ECONOMY/BALANCED/DEEP
Deployment mode: LOCAL/STAGING/PRODUCTION

Total: N
PASS: X
FAIL: Y

ENGINE
Core logic: PASS/FAIL
Validation: PASS/FAIL
Calculations: PASS/FAIL
Contradictions: PASS/FAIL
Unknown handling: PASS/FAIL
Result: PASS/FAIL

Browser: X/N
Output/PDF: X/N
Smoke: X/N or N/A

NEW ROOT CAUSES:
...

FIXED:
...

UNRESOLVED:
...

REPAIR CYCLES:
X/3

TESTS:
...

COMMAND FOR NEXT RUN:
...

FILES:
...

COMMIT:
...

RELEASE:
...

STATUS:
PASS / FAIL


ГЛАВНЫЙ ПРИНЦИП

LLM-токены расходуются на:
- ПРОЕКТИРОВАНИЕ;
- АНАЛИЗ АНОМАЛИЙ;
- ПОИСК ROOT CAUSE;
- ИСПРАВЛЕНИЕ.

LLM-токены не расходуются на:
- ручное повторение сценариев;
- анализ PASS;
- повторяющиеся regression runs.

Повторные проверки выполняет обычный код.
```

## Что вы получите

После первого запуска у вас останется постоянная система тестирования продукта. После будущих изменений не потребуется заново просить AI: «Проверь весь продукт». Достаточно запустить существующий regression harness. AI подключается только при обнаружении реальных отклонений.

## Почему это экономит токены

Обычный код может повторять десятки и сотни тестовых сценариев без расхода LLM-токенов. LLM нужна только там, где требуются reasoning, анализ аномалии и поиск системной причины.

Это снижает:

- расход токенов;
- стоимость AI-разработки;
- количество ручных проверок;
- повторную работу;
- риск пропустить старый баг после новой правки.