Формализация телесного знания: IWE и FPF в Brazilian Zouk

Когда-то я собирал знания о Brazilian Zouk в Coda.io — элементы, механики, шаги. Типичная база «для себя»: понятно мне, но не воспроизводимо другим. На днях начал переносить это в IWE и прогонять через FPF и самого агента. За пару часов работы стало понятно, почему «база в таблице» и «Pack» — принципиально разные вещи.

Хочу поделиться тем, что показал FPF-review, и одним нетривиальным открытием про верификацию описаний.


Иерархия

Первый вопрос — как декомпозировать движение?

Выбрали пять уровней:

Уровень Что содержит Пример
L1 Физические примитивы тела Plie, Push off, Weight transfer
L2 Механики — сборки из L1 Step CWT, Turn on spot
L3 Сольные элементы Ginga, Lateral (solo), Viradinha
L4 Движения в паре Lateral (couple), Corredor
L5 Связки Комбинации

Плюс отдельный файл для позиций и принципов пары. Итого 8 файлов, ~200 узлов с ID и полями «Состоит из».


Что FPF увидел на L1

Начали проходить по первым уровням через три критерия FPF: дисциплина уровня, точность состава, однородность вида.

На L1 нашли три проблемы.

Принцип среди примитивов. L1.012 (Preparation/Pre-movement) был помечен «принцип» прямо в списке физических действий. FPF называет это смешением видов: правило и физическое действие — разные kinds. Preparation разобрали: это фаза, которая входит внутрь L2-механик, а не самостоятельный примитив.

Состояние среди действий. L1.008 (Balance/Eixo) — вертикальная ось тела. На первый взгляд — действие. Но при проверке оказалось: это состояние, которое удерживаешь непрерывно, а не делаешь однократно. Вошёл в отдельный вид — ZK.S.001-body-states.md со своей схемой узла:

Достигается через: [действия]
Удерживается через: [мышечная работа]
Присутствует в: [L2/L3 где ты в нём находишься]

Механика, притворяющаяся примитивом. Wave active/passive — последовательная активация сегментов тела. Это составной процесс, не атомарное действие. Перенесли в L2.


Критерий верификации

Структура готова — но как проверить, что описание достаточно точное?

Мы сформулировали критерий: человек должен воспроизвести движение по описанию без единого исправления.

Проверяли на Lateral — базовом элементе пары. Я спрашивал агента «расскажи, как делать латерал» после каждого раунда правок. Понадобилось семь итераций до стабильного ответа. Агент выступал одновременно как строитель структуры и как тест — если он воспроизводил движение неверно, значит описание ещё неполное.

Каждая итерация выявляла конкретный зазор:

Зазор 1 — нет ориентации тела. Написали «лидер шагает влево», но не написали, что лидер стоит лицом поперёк линии движения. Без этого «влево» звучит как обычный боковой шаг. Добавили поле Ориентация тела: вдоль / поперёк линии движения.

Зазор 2 — один фрейм вместо двух. Шаг описан как «вперёд» (с точки зрения тела) — но в абсолютных координатах это «вдоль линии» или «поперёк линии». Добавили два столбца в таблицу шагов: Своё тело и Абсолютное.

Зазор 3 — нет механики соединения. Описали ноги обоих партнёров, но не объяснили почему фолловер разворачивается. Это происходит из натяжения в соединении рук — не из команды, а из относительного положения тел. Добавили секцию Парная динамика.

Зазор 4 — терминология другого домена. Написали «лидер тянет фолловера» — язык хастла. В Zouk ведение «на кончиках пальцев»: натяжение создаётся положением тела, не усилием рук. Зафиксировали как принцип пары с пояснением для преподавателей.


Итоговая схема узла

Финальная схема L4-узла — четыре секции:

  1. Исходное положение — описание как состояние пары, не от лица одного партнёра

  2. Соло паттерны — таблица с колонками Своё тело + Абсолютное для каждого партнёра

  3. Парная динамикаШаг | Лидер | Фолловер | Соединение

  4. Ключевое ощущение — что должно чувствоваться при правильном исполнении


Зачем это IWE

Pack с такой структурой позволяет агенту отвечать на вопрос «как делать X» точно и воспроизводимо — а не «по мотивам». Знание хранится в git, проходит FPF-review, версионируется. Каждое исправление — коммит с объяснением, почему прежнее описание было неточным.

Мне кажется, это хороший ответ на вопрос «зачем Pack, а не просто заметки»: Pack — это знание, которое можно верифицировать.

1 лайк

Восторг! Есть с кем теперь такое обсуждать. Напомню, что первые эксперименты на тему стилистической инженерии в танце с FPF у меня были вот тут месяц назад – lytdybr: ailev — ЖЖ

Для удобства вынесу текст сюда:

Параллельно я начал эксперименты с SPF (second principles framework):

  • я поговорил немного про эволюцию музыкального стиля прог-рока (когда-то сильно этим увлекался! я ж вполне застал 70-е, был председателем университетского музыкального клуба как раз в конце 70-х – а расцвет прог-рока был ровно в начале 70-х) в пост-прог. Потыкал палочкой в онтологию стилистики.
  • затем я развернул дискуссию о стиле в сторону обсуждения стилевой эволюции в рамках eco-evo-devo, а также в сторону роста эволюционной сложности и многоуровневой эволюционной оптимизации по статьям Ванчурина-Кацнельсона-Кунина-Вольфа. И добавил до кучи эволюцию танцевальных стилей. Попросил суммаризовать дискуссию в файл (Pro-версия в ChatGPT перестала терять файлы, счастье! И в файл она легко пишет больше 40К знаков, и они явно получаются интересней, чем при работе xhigh-версии в Codex). Получил эссе-1 (evolutionary_stylistics_music_dance_ru.md — Яндекс Диск), и там уже были и уровни, и межуровневые конфликты.
  • дальше дал FPF и указал на OEE, получил эссе-2 (evolutionary_stylistics_music_dance_fpf_ru.md — Яндекс Диск). Вот полный промпт: “У тебя в файле спецификация FPF, содержащая паттерны, которые позволяют описывать open-ended evolution и поведение на фронтире, а также даёт понимание, как характеризовать какие-то эволюционирующие сущности с вниманием не к лексике, а к онтологии (kinds). Ещё у тебя текст про эволюцию музыки и танцев, который использует схожие идеи, усиленные идеями eco-evo-devo и идеями Ванчурина-Кацнельсона о многоуровневости эволюции и росте сложности. Сделай новую редакцию текста про эволюционную стилистику в файле Markdown, уточнив и усилив её идеями из FPF.”
  • и вот тут я дал промпт, который разворачивает это всё в DRR по SPF, получил DRR с нарезкой предметной области на 14 паттернов (DRR-ES-SPF-002_style_engineering_second_principles_framework_ru.md — Яндекс Диск). Вот этот промпт: “Если рассматривать FPF как паттерны “нулевых и первых принципов”, можем ли мы как-то представить эту новую редакцию эволюционной стилистики как набор паттернов “вторых (предметных) принципов”, опирающихся на FPF, но связанных с конкретной предметной областью? Чем-то подобным в FPF должна была заниматься часть G, но она осталась недоработанной. Как бы выглядел набор паттернов эволюционной стилистики, оформленный как second principles framework? Ориентация тут, конечно, должна быть на “инженеров стиля” и “менеджеров стилевой разработки”, а не чисто “аналитическая” и “исследовательская”. Переформулируй написанный тобой текст в формате DRR на написание такого набора паттернов (по E.9, в Markdown).”
  • это чистый эксперимент, поэтому в этих текстах не делал обычных проверок, но они получились на удивление разумными (впрочем, тексты промптов не такие уж случайные, они явно предотвращают некоторые известные проблемы использования FPF). Что дальше? Например, можно пройти дальше по тому же маршруту реализации паттернов согласно DRR, что и в любой обычной кампании, но вместо landing в монолит FPF иметь просто набор паттернов рядом как SPF. В любом случае, я считаю эксперимент вполне удачным. Разработка SPF тем самым сводится к обычному workstream (архитектура и несколько кампаний для DRR по реализации общих архитектурных решений) или campaign (intake, а по нему сразу DRR – и паттерны, вот как с этой “стилевой инженерией”).

И ещё про SPF я писал вот тут, как его проще делать: Организация кастомизации без падения масштабирования (пример SPF): ailev — ЖЖ

Ещё у нас ведь есть работы по моделированию соматомеханики (соматостатики и соматодинамики): как перейти от “внешнего” языка описания движений (что видит глаз зрителя) к “изнутри тела” (ибо танцор управляет телом по ощущениям, иногда ведь даже глаза закрыты – и нужно описание-для-управления с учётом ощущения инерции и баланса, а не просто описание движений в их физической форме).

В любом случае – хорошее начало!

1 лайк

Спасибо за ссылки и за детальный разбор workflow! Читаю оба эссе и DRR.

Про соматомеханику — это прямо в точку для зука. Работа головой у фолловера вся на проприоцепции: не видишь траекторию, управляешь через ощущение веса головы, натяжение шеи, сигнал от лидера через плечевой пояс. Внешнее описание («голова идёт назад по дуге») как инструкция не работает совсем.

Про SPF — у меня сейчас как раз формируется материал для МК по работе головой (июль), буду пробовать этот маршрут. Хорошая точка входа для зук-специфичного фреймворка.

В принципе, у меня есть сообщество (я уже говорил о нём несколько лет назад), где публикую разные эксперименты по моделированию танцев – хотя про зук там немного, разве что есть тексты про ламбазук.

Я думаю, что там можно ещё много интересного найти (и, замечу, там публиковаться с этой теорией): https://vk.com/buffdance

Отходы производства – из моего текущего поста, где я написал ещё несколько слов про проблемы моделирования танцев: lytdybr: ailev — ЖЖ