public class SmartFilteredByConditionCollection extends AbstractSmartCollection {

  ...

    @Override
    public List<WebElement> getWrappedEntity() {
        List<WebElement> unfilteredCollection = collection.getWrappedEntity();
        List<WebElement> filteredCollection = new ArrayList<>();

/*
    тут переделал
    это ок

    а аналогичное место - SmartCollectionFoundByConditionElement?
*/
***********************
    @Override
    public boolean is(Condition<WebElement> condition) {
        try {
            condition.apply(this);
        } catch (WebDriverException e) {
            return false;
        }
        return true;
    }
/*
    с матчером - все ок получилось
    теперь учти это и здесь

    используй метод кондишена check
    try-catch - не убирай
    мы по-прежнему должны вылавливать все исключения-наследники WebDriverException

    подумай - как использоватьграмотно то, что вернет check

    с check более правильно - т к тут метод - лишь для определения - да/нет для кондишена
    и у кондишена метод check - про то же
    результат apply - нам по большому счету и не нужен
*/
*************************************
public class SmartInnerElementCollectionByLocator extends AbstractSmartCollection {
/*
    чтоб и это имя класса оставалось в той же схеме, что и остальные
    SmartElementInnerCollection - вот так будет лучше

    для полей класса - лучше явно пропиши модификатор доступа (access modifier)
*/
...

    @Override
    public List<WebElement> getWrappedEntity() {
        return element.findElements(innerlocator);
    }
/*
    в element.findElements - уже сидит внутри ожидание видимости

    а все getWrappedEntity() - не должны в себе содержать ожиданий
    они же сами используются в ждущей проверке

    сначала - у родителького элемента получи вебэлемент и затем у него уже вызывай findElements
*/

    @Override
    public String toString() {
        return "Inner collection from parentElement = " + element + ", by locator " + innerlocator;
    }
/*
    лаконичность тут не помешает)
    element.toString() + " findAll(" + innerLocator + ")"

    кстати
    не innerlocator
    а  innerLocator

*/
*********************************
public class SmartFilteredByConditionCollection extends AbstractSmartCollection
/*
    где toString()?
*/
**********************************
SmartCollectionFoundByConditionElement
/*
    toString - перепиши лаконичнее (понятно, без потери точности, но слов многовато сейчас)
    parentCollection.toString() + " find(" + condition.getClass().getSimpleName() + ")"

    как-то бессистемно пока у тебя
    про родительские сущности - ты то уточняешься - parent
    то не уточняешься

    лучше - везде уточняйся
*/
*********************************
SmartCollectionIndexElement
/*
    название класса - SmartCollectionNthElement  ?
    мне кажется - так лучше
    или SmartCollectionFoundByIndexElement - наверное так даже лучше

    toString - parentCollection.toString() + "[" + index + "]"
*/
**************************
SmartElementInnerElement
/*
    toString - parentElement.toString() + " find(" + innerLocator + ")";
*/
****************************
public interface SmartEntity<V> extends DescribesEntity {

    V getWrappedEntity();
}
...
public abstract class AbstractCondition<V>  implements Condition<V>, DescribesResult
...
public <V> V run(Command<V> command)
...
public class WaitFor<V>
/*
    <V> vs <T> ?

    конвеншенсы )
*/
***************************
public abstract class CollectionCondition extends AbstractCondition<List<WebElement>> {

}
/*
    от ElementCondition - избавился
    а от этого класса чего не избавился? )
*/
*********************************
$$(byCss("[role=main] .zA"));
vs
$$("[role=main] .zA");
**********************************
$(byCss("#Email"))
vs
$("#Email")
***********************
clearComplited
vs
clearCompleted
***********************
(JavascriptExecutor) getDriver()).executeScript("localStorage.clear()")
/*
  в ConciseAPI реализуй метод executeJavaScript
*/
************************
    public void delete(String text) {
        tasks.find(exactText(text)).hover();
        tasks.find(exactText(text)).find(By.cssSelector(".destroy")).click();
    }
/*
    можно переписать в одну строчку
    tasks.find(exactText(text)).hover().find(".destroy").click()

    дореализуй
    SmartElement find(String innerCssSelector);

    насчет лаконичных вызовов - $ $$ find - пройдись по коду
*/
*****************************
 public void addTask(String text) {
 public void delete(String text)
/*
    в именах методов - не надо про Task писать - т к все действия делаем над тасками
    а вот в именах параметров - стоит уточнить до taskText

    во всех методах пейджа пройдись
*/
*********************************
public void checkTodoCount(int count)
/*
    https://docs.google.com/document/d/13dNyFGbI7mV22UUhH8E0LJ7SzabAmX7Bw7VCHScYfiU/edit#bookmark=id.sswzyp7qkm9o
*/
**********************************
page.tasks.shouldHave(exactTexts("task 1", "task 2", "task 3", "task 4"));
page.tasks.shouldBe(empty());

page.tasks.filter(visible()).shouldHave(exactTexts("task 1"));
page.tasks.filter(visible()).shouldHave(exactTexts("task 1", "task 4"));
/*
    реализуй в пейдже

    assertTasks
    assertNoTasks

    assertVisibleTasks
    assertNoVisibleTasks

    и их используй в тестах

    также уже вдогонку
    посмотри видео Якова про это - https://drive.google.com/file/d/0B8hgIBw8-V-AdGxxU1R3enl1RzQ/view?ts=567ab8d7

    поясняю)
    мы можем быть максимально точными и держать 4 проверки
        2 -
            в списке = такси с такими-то текстами
            в списке = пусто
        и еще 2 -
            в отфильтрованном по visible списке = таски с такими-то текстами
            в отфильтрованном по visible списке = пусто
        И за точность будем платить  тем - что надо думать - когда какую проверку вызвать правильнее
        и если это делать бездумно - то при небольших изменениях сценариев - могут тесты падать на проверках,
        или второй вариант - не будем нормально пользоваться полученной точностью...

        мы можем исходить из того, что ошибку, когда невидимые таски копятся в списке - мы тестим на более низком уровне,
        и на UI уровне - нам не нужно до этого уточняться. Поэтому - мы будем держать всего 2 проверки
              в отфильтрованном по visible списке = таски с такими-то текстами
              в отфильтрованном по visible списке = пусто
        В таком случае - каждый раз понятно - какую проверку вызывать - получаем более KISS картину
        правда, платим за это точностью) Но - возможно - если мы уже отдельно это в тестах покрыли -
        что у нас не копятся невидимые таски - так мы и не платим ) И - тогда - все проще в написании тестов,
        и в их сопровождении.
        Тогда - поскольку обе проверки реализованы одинаково и других нету - можно из имен проверок скрыть этот нюанс
        и назвать их assertTasks и assertNoTasks (хотя в них работаем с отфильтрованным по visible списком тасок)
*/