Как собрать пайплайн с LLM агентом который фиксит нативные Android UI автотесты

[Ariless]

Интересная архитектура, особенно иерархия приоритетов при RCA. Вопрос про edge case: что происходит, когда root cause не вписывается ни в одну категорию иерархии?

Иерархия "тест → фреймворк → приложение" покрывает большинство случаев, но есть отдельный класс проблем - shared state между тестами. Код теста чистый, фреймворк работает корректно, приложение тоже. Проблема в порядке выполнения и взаимодействии между тестами, а не внутри одного теста.

Это особенно актуально для Android UI: если несколько тестов работают с одним и тем же UI-состоянием или данными без полной изоляции - RCA агент может искать причину не в том слое.

Если агент неверно классифицирует причину, fix будет уверенным, но неправильным. Как обрабатываете случаи, когда ни одна категория не подходит?