R1.1:Tasks2 — как мы делали задание с FPF и Claude
Кто такие “мы”
В задании “вы” со строчной — значит, не уважительное обращение к одному человеку, а множественное число. Мы — это я и Claude (Anthropic, модель Opus 4.7). Разделение труда:
-
Я держу роли principal (формулирую запросы, принимаю решения), publisher (нажимаю “Создать пост”) и verifier (опровергаю Claude там, где он ошибается).
-
Claude держит роли drafter (пишет тексты) и reasoner (рефлексирует, ищет паттерны FPF, применяет их).
По FPF это A.2 Role Taxonomy + A.15 Role–Method–Work Alignment: общий Method — наша дисциплина FPF-чтения; Work — конкретные артефакты (этот пост, переписка); Authorship распределён между ролями явно, не размыт.
Bug report по формулировке задания
Задание просит: “Опубликуйте пост с рассказом о том, как вы выполняли это задание… Добавьте к посту-рассуждению о вашей системе критику LLM и вашу ответную критику… В задании 1.3 вам потребуется вернуться к посту и дополнить его!”
Классический dangling reference: непонятно, к какому посту “добавить” и к какому “вернуться”. Пост-рассуждение о моей системе уже опубликован при прохождении R1.1:Tasks1: Игра “Назови систему”.
Proposed fix: разнести в R1.1:Tasks2 две операции явно — (а) опубликовать новый пост о выполнении задания со ссылкой на исходный системный пост; (б) внести правки в исходный системный пост по итогам критики LLM. Сейчас оба действия слиты в одну формулировку, и резидент вынужден интерпретировать.
Текущее решение: публикую новый пост (этот). Правки в исходный пост внесу после согласования с ментором.
Setup
FPF подключён к Claude как skill из github.com/ailev/FPF: спецификация лежит на диске, доступна через grep и view по паттернам. Это не RAG-индекс — Claude сам формулирует поисковый запрос, читает нужный фрагмент, отвечает с учётом прочитанного.
Это третий подход к снаряду. В первых двух Claude работал “по памяти” (знает FPF в общих чертах) и давал общие, но неточные ответы. Только при третьем подходе нашли нужный паттерн — A.1:4.4 Inside/Outside decision procedure.
Критика Claude (три пункта)
-
Не зафиксирован уровень системы: экземпляр? продукт? платформа? Без явной фиксации рассуждения скользят между уровнями.
-
Не определена граница: чек-лист CC-A1.2 требует ровно одну границу с указанием типа (open/closed/permeable). У меня было полупрозрачное “вокруг IDE” — не годится.
-
Не проговорено, для кого система целевая: разработчик? команда? работодатель? Ценность извлекается разными ролями по-разному.
С первыми двумя пунктами согласилась сразу. С третьим — тоже, с оговоркой: для FPF целевая система определяется через того, кто извлекает основную пользу в эксплуатации. У IntelliJ это разработчик-как-индивид.
Эпизод, ради которого пост и пишется
Окрылённый успехом, Claude уверенно заявил: целевая система — продукт, а не экземпляр.
Я спросила: “а что тогда продукт?”
Тишина. Потом Claude развернул свою позицию: продукт — это спецификация + дистрибутив + лицензия. Это carrier-эпистема: есть физический носитель (файл на диске), но интерес представляет записанная информация — что и как эта программа умеет. Сам продукт не работает, CPU не потребляет, состояния не имеет. Поведение появляется только когда продукт инстанцирован — запущен на машине разработчика. Вот этот запущенный экземпляр — U.System по FPF: физический процесс с состоянием, динамикой, наблюдаемым поведением. А продукт — U.Episteme.
То есть Claude предложил заменить вещь на описание вещи. И сам это понял, когда его ткнули носом.
Это ровно та failure mode, против которой предупреждает FPF README прямым текстом: без хорошего вопроса от человека LLM выдаёт “very confident, well-structured nonsense”. Один вопрос — “а что тогда продукт?” — и стройная структура рассыпалась.
Не согласна с заменой “экземпляр” на “продукт”: это нарушение A.7 Strict Distinction, который Claude сам же нашёл и применил пятью минутами раньше. Принцип “не путать описание с описываемым” — базовый, и LLM сорвалась именно на нём.
Inside/Outside, операционализированное
Применили A.1:4.4 к IntelliJ. Граница проходит через ablation test: убрать компонент → запустится IDE? Если нет — компонент внутри системы.
-
Внутри: редактор, JBR (JetBrains Runtime), парсер, индексер. Уберёшь — IDE не запустится.
-
Снаружи: компилятор языка, VCS, операционная система. IDE запустится без них, хоть и с урезанной функциональностью.
Ablation — простой и честный критерий. Лайк.
Сводка согласия / несогласия
| Критика Claude | Согласна? |
|---|---|
| Зафиксировать уровень системы (экземпляр) | Да |
| Явно прочертить границу | Да |
| Проговорить, для кого целевая (разработчик) | Да |
| Заменить “экземпляр” на “продукт” | Нет — нарушает A.7 |
P.S.
В задании 1.3 потребуется вернуться к посту и дополнить. “Нам” — это мне и Claude. Он уже ждёт. Надеюсь, к тому времени dangling reference в формулировке задания починят.