Запутался по строками 31-40 в классе ConciseApi
Не работают описанные в ревью конструкции и если честно потерял нить почему нам нужно сделать так.
/*
    таки да, запутался)
    сейчас распутаемся

    сначала - твой код прокомментирую
    ниже - приведу конечный вариант и тоже прокомментирую
*/
    public static WebElement $(ExpectedCondition<WebElement> conditionToWaitElement) {
        return $(assertThat(elementLocator));
    }
    /*
        у метода - параметр = кондишен, который обеспечивает умное ожидание
        именно его и надо использовать для ожидания- conditionToWaitElement

        изначально - у нас был метод $ реализован с использованием
        assertThat(visibilityOfElementLocated(elementLocator));
        дождались видимости, и затем вернули этот веб элемент

        т е - самый универсальный из методов $ - БЫЛ WebElement $(By elementLocator)
        вот в нем = мы вызывали assertThat(visibilityOfElementLocated(elementLocator)); =
        реализовывали сам алгоритм методов $
        а в остальных методах $ (например WebElement $(String cssSelector) ) - мы бы переиспользовали
        самый универсальный, ранее разработанный метод WebElement $(By elementLocator)

        ТЕПЕРЬ самый универсальный -
            не WebElement $(By elementLocator)
            а  WebElement $(ExpectedCondition<WebElement> conditionToWaitElement)
        и именно он будет реализован по сути
        остальные методы $ - будут его переиспользовать (тоже в 2 приема это сделаем)

        по реализации метода WebElement $(ExpectedCondition<WebElement> conditionToWaitElement)
            разбираем код
                return $(assertThat(elementLocator));
            elementLocator - у нас нет такого параметра вообще
            выражение assertThat(elementLocator) - не имеет смысла
            а нам ведь передали - кондишен, который нужно использовать для ожидания
            assertThat(conditionToWaitElement) - как раз и вернет нам нужный веб элемент
            передавать этот веб элемент как параметр какому-то еще методу $ - уже не нужно
            т е - код этого метода =
                 return assertThat(conditionToWaitElement);
    */


    public static WebElement $(By conditionToWaitElement) {
    /*
        если параметр типа By - то почему он называется conditionToWaitElement?
        логичнее было бы назвать этот параметр - By elementLocator
    */
        return $(visibilityOfElementLocated(elementLocator));
        /*
            по сути реализации
            давай пока забудем про переиспользование ранее азработанных методов $

            что нам надо сделать
            нам надо дождаться видимости элемента по локатору
            как это сделать
            assertThat(visibilityOfElementLocated(elementLocator))

            а если учесть ранее реализованный $(ExpectedCondition<WebElement> conditionToWaitElement)
            то код этого метода, верно, такой, как ты и написал
             return $(visibilityOfElementLocated(elementLocator));
            НО - он будет ОК - если у метода параметром будет By elementLocator
            иначе - естественно, тебе Идея сообщает об ошибках
            т к оперируешь в методе тем, чего нету
        */
    }

    public static WebElement $(String elementLocator) {
    /*
        если параметр типа String - то это точно не локатор
        я писала - что хорошо бы реализовать метод
        принимающий как параметр  - цсс селектор
        вот такой вариант
        WebElement $(String cssSelector)
    */
        return assertThat(visibilityOfElementLocated(elementLocator));
        /*
            Снова разбираемся, что нам нужно сделать
            нам по селектору - нужно получить локатор By
            это = byCss(cssSelector)

            Далее - как в предыдущем методе - мы можем полученный локатор передать в visibilityOfElementLocated
            и для такого кондишена - выполнить ждущую проверку

            получим
            return assertThat(visibilityOfElementLocated(byCss(cssSelector)));

            а если вспомнить про реализованный предыдущий метод - WebElement $(By elementLocator)
            то
            return $(byCss(cssSelector));

            такая замена assertThat-ов вызовами нужного варианта метода $ - призвана упростить код
            сделать его проще и лаконичнее, убрать повторения = сделать код более DRY

            если тебе в таком коде тяжело ориентироваться
            то для начала - откажись от идеи переиспользования методов $ в других методах $

            ниже - я приведу вариант без переиспользования
            затем - с переиспользованием

            ты кстати можешь так себя проверять
            зажав ctrl кликай на вызов метода - разбирайся, какой будет вызван
            это на первых порах облегчит тебе жизнь
        */
    }
//вариант  без переиспользования методов $
    publc static WebElement $(ExpectedCondition<WebElement> conditionToWaitElement) {
        return assertThat(conditionToWaitElement);
    }

    public static WebElement $(By elementLocator) {
       return assertThat(visibilityOfElementLocated(elementLocator));
    }

    public static WebElement $(String cssSelector) {
        return assertThat(visibilityOfElementLocated(byCss(cssSelector)));
    }
//а теперь - то же самое, только когда каждый следующий метод $ - переиспользует ранее разработанный
    public static WebElement $(ExpectedCondition<WebElement> conditionToWaitElement) {
        return assertThat(conditionToWaitElement);
    }

    public static WebElement $(By elementLocator) {
       return $(visibilityOfElementLocated(elementLocator));
    }

    public static WebElement $(String cssSelector) {
        return $(byCss(cssSelector));
    }
/*
    оба варианта кода - делают одно и то же
    только второй вариант - более DRY
*/
**********************************************************************************************************
в Todo MVC сложность со строкой 47, вроде бы все согласно логике, которая реализована с помощью Selenide, однако не получается разобраться со строкой.

    $(ExpectedCondition<WebElement> conditionToWaitParentElement, By innerElementLocator){
        return assertThat(elementWithText(tasks, text),innerElementLocator);
    }

    $(ExpectedCondition<WebElement> conditionToWaitParentElement, String innerElementLocator){
        return assertThat(elementWithText(tasks, text), innerElementLocator);
    }
/*
    нам нужны такие методы - не на уровне пейджа, а на уровне ConciseAPI
    а для этого - такие методы должны быть универсальными

    ты верно заметил
    что за основу - берем код assertThat(elementWithText(tasks, text)).findElement(...)
    собственно - это и будем реализовывать
    но - перейдем к универсальным терминам

    цель - реализовать метод
    WebElement $(ExpectedCondition<WebElement> conditionToWaitParentElement, By innerElementLocator)

    который
        получит родительскй вебэлемент, использовав ждущую проверку  conditionToWaitParentElement
            WebElement parentElement = assertThat(conditionToWaitParentElement);
        затем - у родительского єлемента получит его внутренний єлемент по локатору innerElementLocator
            return parentElement.findElement(innerElementLocator)
    т е
*/
 public static WebElement $(ExpectedCondition<WebElement> conditionToWaitParentElement, By innerElementLocator) {
    WebElement parentElement = assertThat(conditionToWaitParentElement);
    return parentElement.findElement(innerElementLocator);
 }
 //или - короче, в одну строку
  public static WebElement $(ExpectedCondition<WebElement> conditionToWaitParentElement, By innerElementLocator) {
     return assertThat(conditionToWaitParentElement).findElement(innerElementLocator);
  }
 /*
    дальше - как реализовать WebElement $(ExpectedCondition<WebElement> conditionToWaitParentElement, String innerElementСssSelector)

    по большому счету - разница  - только в способе получения снутреннего элемента
    раньше у нас уже был локатор
    а теперь - его надо получить по css selector-у

    если ничего не переиспользовать то получим
 */
  public static WebElement $(ExpectedCondition<WebElement> conditionToWaitParentElement, String innerElementСssSelector) {
     return assertThat(conditionToWaitParentElement).findElement(byCss(innerElementСssSelector));
  }
//а если переиспользовать ранее разработанный   WebElement $(ExpectedCondition<WebElement> conditionToWaitParentElement, By innerElementLocator)
  public static WebElement $(ExpectedCondition<WebElement> conditionToWaitParentElement, String innerElementСssSelector) {
     return $(conditionToWaitParentElement, byCss(innerElementСssSelector));
  }
/*
    заметь - внутри этих методов мы вообще не оперируем ничем конкретным из пейджа
    все - универсально
    мы пережли от терминов пейджа к универсальным терминам
    универсальное - располагай в ConciseAPI

    а в пейдже - будешь использовать это
    к примеру
    вместо $(elementWithText(tasks, taskText)).findElement(byCss(".toggle")).click();
    будет  $(elementWithText(tasks, taskText), ".toggle").click();
*/
***************************************************
Я так понимаю, что с методом StartEdit получиться разобраться, когда будут готовы методы
$(ExpectedCondition<WebElement> conditionToWaitParentElement и т.д.
Тогда бы мне не помешала подсказка по поводу их реализации)

//давай вернемся к селенидовской версии этого метода и ее разберем
    private SelenideElement startEdit(String oldTaskText, String newTaskText) {
        tasks.find(exactText(oldTaskText)).doubleClick();
        return tasks.findBy(cssClass("editing")).$(".edit").setValue(newTaskText);
    }
/*
    мы возвращали - SelenideElement = элемент $(".edit") внутри редактируемой таски
    после ввода нового значения в этот элемент

    теперь мы будем возвращать все тот же элемент и после тех же действий
    только тип будем использовать не SelenideElement
    а WebElement

    т е сигнатура метода будет
    private WebElement startEdit(String oldTaskText, String newTaskText)

    теперь разбираем первую строку
    нам нужен даблклик на таске с такми-то текстом

        как мы теперь получаем таску с таким-то текстом
        $(elementWithText(tasks, taskText))
        и на ней нужно - даблкликнуть
        doubleClick($(elementWithText(tasks, taskText)))

        если такой код не будет работать - то таску нужно уточнить до label
        как мы делали в задании по Downgrade Selenide to 2.17
        doubleClick($(elementWithText(tasks, taskText), "label"))

    по второй строке
        нам нудно получить таску в режиме редактирования
        т е - таску с классом editing

        ты для этого писал специальный кондишен elementWithCssClass
        его и применим
        $(elementWithCssClass(tasks, "editing")) - как раз такая таска
        далее - нам нужно уточниться до ее внутреннего элемента  $(".edit")
        $(elementWithCssClass(tasks, "editing"), ".edit")

        и вот для этого элемента - нужно ввести новый текст
        и его - этот элемент  - нужно вернуть
*/

     private WebElement startEdit(String oldTaskText, String newTaskText)
        doubleClick($(elementWithText(tasks, taskText), "label"));
        WebElement inputEdit = $(elementWithCssClass(tasks, "editing"), ".edit");
        setValue(inputEdit, newTaskText);
        return inputEdit;
    }

// а если setValue чуть доработать
   public static WebElement setValue(WebElement element, String task) {
        element.clear();
        element.sendKeys(task);
        return element
   }
// то и   startEdit можно переписать лаконичнее
     private WebElement startEdit(String oldTaskText, String newTaskText)
        doubleClick($(elementWithText(tasks, taskText), "label"));
        return setValue($(elementWithCssClass(tasks, "editing"), ".edit"), newTaskText);
    }
//тогда уже разумно и другие методы для работы с веб элементом - подправить как подправили setValue
//пусть возвращают WebElement