Редактирование Workflows

Способы редактирования

Через MCP Tools

Используйте инструмент manage с действием edit:

mcp__moira__manage({
  action: "edit",
  workflowId: "my-workflow",
  changes: {
    // изменения здесь
  },
});

Через workflow-management-flow

Запустите управляющий workflow:

mcp__moira__start({
  action: "prepare",
  workflowId: "workflow-management-flow",
  parentExecutionId: "none",
});
mcp__moira__start({ action: "execute", startAttemptId: "<ID попытки запуска из prepare>" });

Выберите “edit” при запросе действия.

Используйте workflow-management-flow для сложных правок. Он проверяет дизайн до изменения, валидирует получившийся граф и независимо проверяет готовый workflow.

Через CLI для workflows

Авторы репозитория могут использовать официальный CLI moira-workflow для файловых правок. Сначала проверьте, из какой рабочей копии запускается глобально связанная команда, особенно если локально существует несколько worktree Moira:

moira-workflow --version

Команда выводит версию пакета и точный путь к исходнику. Длинное описание и полную схему переменной можно прочитать из файла, не полагаясь на хрупкое экранирование shell:

moira-workflow ./workflow.json set-description --file ./description.txt
moira-workflow ./workflow.json set-system-reminder --file ./reminder.txt
moira-workflow ./workflow.json set-tags research,verification
moira-workflow ./workflow.json set-variable-schema result --file ./result-schema.json

Вид процесса использует тот же файловый authoring surface. Задайте полный список блоков из JSON командой set-progress (или наращивайте его через add-block / edit-block), затем назначьте каждой ноде её блок командой set-block — включая маршрутизирующие ноды: вывод процесса отклоняет ноду без блока. Вложение прогресса доступно для user-notification и устаревшей telegram-notification; значения none и false удаляют соответствующие опциональные поля.

moira-workflow ./workflow.json set-progress --file ./progress.json
moira-workflow ./workflow.json update implement --progress-node-id implementation
moira-workflow ./workflow.json update implement --progress-active-label "Implement {{unit}}/{{total}}"
moira-workflow ./workflow.json update notify --progress-node-id review --attach-progress-image true

У контракта блоков есть собственные команды: привязать ноду к блоку, добавить или изменить блок с его описанием, подписать связь, выходящую из блока, и объяснить возврат причиной цикла и условием его завершения. Каждая запись сообщает, сколько диагностик контракта блоков осталось, поэтому flow размечается итеративно, пока derive не покажет ни одной; --no-version-bump сохраняет версию во время итераций.

moira-workflow ./workflow.json set-block route-plan-approval plan
moira-workflow ./workflow.json add-block deliver "Deliver" "Hand the result over" --after execute
moira-workflow ./workflow.json edit-block deliver --summary "Present the result"
moira-workflow ./workflow.json set-label check-plan-approved true "plan approved"
moira-workflow ./workflow.json set-label route-review false "review found defects" \
  --cause "The independent review reported blocking findings." --exit "The review passes."
moira-workflow ./workflow.json derive

Команды сохраняют schema fields, но не выводят процесс и не судят о его смысле; они не заменяют итоговые validate, derive, schema, поведенческие scenarios и независимое semantic review.

Для полной спланированной замены sync сохраняет идентичность целевого workflow и его catalog migration aliases в previousSlugs. Catalog reader проверяет aliases отдельно, а в engine validator передаётся только executable graph. Aliases всегда берутся из реальной цели, а не из workspace-копии. При ошибке metadata или graph validation целевой файл не меняется. Отдельная команда validate завершается с ненулевым кодом для обоих классов ошибок, поэтому агент или CI может использовать её как настоящий гейт без ослабления runtime/upload graph validation.

moira-workflow ./workspace/workflow.json sync ./workflows/production/flows/<flow>.json
moira-workflow ./workflows/production/flows/<flow>.json validate

Перед проверкой или изменением большого графа выведите его полную детерминированную схему потока:

moira-workflow ./workflows/production/flows/<flow>.json schema

Схема показывает каждую реальную ноду и именованный переход, условия, циклы, объявленные выходы и маппинги, ссылки на контекст, обычные пути от start, отдельные области, доступные только через teleport, и несвязанные компоненты. Если workflow определяет вид процесса, та же проекция включает все упорядоченные блоки, сохранённые на них устаревшие отрисовочные связи и принадлежность каждой ноды блоку. Это структурная проекция только для чтения и анализа агентом или человеком: команда не запускает workflow, не интерпретирует его предметный смысл и не утверждает семантическую корректность видимого маршрута.

Как workflow-management-flow выполняет правку

При редактировании управляющий workflow загружает полное актуальное определение и сохраняет требования, анализ, план и отчёты ревью в рабочем каталоге. Содержимое остаётся в файлах; через граф передаются только небольшие значения, действительно влияющие на маршрутизацию.

При начальном выборе также фиксируется, разрешён ли доступ к серверу. Явное указание local-only или offline используется без повторного вопроса и запрещает edit-ветке скачивать либо сравнивать серверное определение.

На том же первом шаге фиксируется режим работы. В режиме interactive все согласования остаются как сейчас: дизайн, план и результат подтверждает пользователь. В режиме autonomous workflow обходит эти три согласования и вместо них выдаёт один финальный отчёт в конце. Агент использует режим, который пользователь уже назвал, выводит однозначный сам — в том числе когда запуск является дочерним для уже автономного процесса, — и спрашивает один раз только тогда, когда режим не назван и не выводится.

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

Перед планированием workflow решает, нужно ли проверить весь исходный workflow по известному каталогу антипаттернов. В интерактивном режиме он спрашивает, показывает конкретные существующие проблемы и уточняет, какие из них включить в scope правки. В автономном режиме агент принимает оба решения сам — по запрошенному изменению и доступным доказательствам, — а невзятые находки остаются в отчёте аудита. При отказе от аудита анализ ограничивается запрошенным изменением и его необходимыми зависимостями.

План описывает результаты, затронутые контракты, инварианты, критерии приёмки, способы получения свидетельств и риски. Перед добавлением механизма проверки или доказательства он должен назвать требуемое состояние, внешне похожее неправильное состояние и наблюдение, которое надёжно их различает. Недоказуемый производный критерий пересматривается, а не заменяется суррогатным сигналом. План не навязывает исчерпывающий список файлов, точные команды, псевдокод или фиксированный порядок локальных правок, если этого не требует внешний контракт.

Создание и редактирование используют одно независимое ревью дизайна до изменения workflow. Подробные findings остаются в стабильном файле workspace, а через граф передаётся только один из исходов: pass, repair или replan. repair допустим только для подтверждённого дефекта самого проверяемого артефакта; ошибочный критерий, модель доказательства, интерпретация требования, план или процесс возвращаются к владельцу самого раннего ошибочного контракта. После реального исправления reviewer получает ограниченное описание класса причины и изменившегося знания. Повтор того же класса без более сильного свидетельства и циклы, меняющие только validation-инфраструктуру, ведут к перепланированию, а не к следующему слою проверки. Структурную валидацию штатным валидатором Moira по-прежнему выполняет нода, создающая или изменяющая workflow.

Типы изменений

Обновление метаданных

mcp__moira__manage({
  action: "edit",
  workflowId: "my-workflow",
  changes: {
    metadata: {
      version: "2.0.0",
      description: "Updated description",
    },
  },
});

Обновление содержимого узла

mcp__moira__manage({
  action: "edit",
  workflowId: "my-workflow",
  changes: {
    updateNodes: [
      {
        nodeId: "task-node",
        changes: {
          directive: "New directive text",
          completionCondition: "New condition",
        },
      },
    ],
  },
});

Добавление узлов

mcp__moira__manage({
  action: "edit",
  workflowId: "my-workflow",
  changes: {
    addNodes: [
      {
        type: "agent-directive",
        id: "new-node",
        directive: "New task",
        completionCondition: "Task complete",
        connections: { success: "existing-node" },
      },
    ],
  },
});

Удаление узлов

mcp__moira__manage({
  action: "edit",
  workflowId: "my-workflow",
  changes: {
    removeNodes: ["node-to-remove"],
  },
});

При удалении узлов обновите соединения в других узлах, которые ссылались на удалённый узел.

Безопасный процесс редактирования

Получите текущую структуру

mcp__moira__manage({
  action: "get-structure",
  workflowId: "my-workflow",
});

Найдите узлы для редактирования

mcp__moira__manage({
  action: "search-nodes",
  workflowId: "my-workflow",
  query: "search term",
});

Получите детали узла

mcp__moira__manage({
  action: "get-node",
  workflowId: "my-workflow",
  nodeId: "node-id",
});

Примените изменения

mcp__moira__manage({
  action: "edit",
  workflowId: "my-workflow",
  changes: {/* ... */},
});

Валидация

mcp__moira__manage({
  action: "validate",
  workflowId: "my-workflow",
});

Редактирование без лишней машинерии

Вносите изменение официальными MCP-действиями или CLI workflow и валидируйте реальный артефакт до завершения. Одноразовый генератор, скрипт миграции или промежуточный формат, написанный ради одной правки, становится необъявленной зависимостью: workflow корректно проходит цикл правки только там, где этот инструмент есть, и в определении об этом ничего не сказано. Артефакт записи — сам JSON workflow.

Сверка копий в репозитории и на сервере

Встроенный workflow существует дважды: как файл в репозитории и как запись каталога на инстансе, который его отдаёт. Перед правкой определите, какие идентичности указывают на один и тот же workflow — публичный owner/slug, внутренний UUID и локальный путь, — и сравните определения, а не считайте их совпадающими.

# Получить отдаваемое определение по одноразовому download-токену
mcp__moira__token({ action: "download", workflowId: "moira/quick-task" })

Если они различаются, выберите базу осознанно: какое определение затрагивает запрошенное изменение, какое новее по metadata.version и что потеряет каждая сторона. Механическое объединение двух JSON даёт граф, который никто не проверял.

Смена slug встроенного workflow меняет его идентичность в каталоге. Чтобы при обновлении старый workflow не остался активным рядом с новым, добавьте прежний slug в служебный массив каталога previousSlugs. Загрузчик перенесёт существующую запись в рамках того же владельца и сохранит её внутренний ID; если найдётся больше одной объявленной прежней идентичности, загрузка завершится ошибкой вместо догадки или создания дубля. Не используйте previousSlugs для объединения разных workflow.

Обновление соединений

Обновление одного соединения

{
  updateNodes: [
    {
      nodeId: "source-node",
      changes: {
        connections: {
          success: "new-target-node",
        },
      },
    },
  ];
}

Соединения узла-условия

{
  updateNodes: [
    {
      nodeId: "condition-node",
      changes: {
        connections: {
          true: "when-true-node",
          false: "when-false-node",
        },
      },
    },
  ];
}

Контроль версий

Инкремент версии

Всегда обновляйте версию при внесении изменений:

{
  metadata: {
    version: "1.1.0"; // было 1.0.0
  }
}

Семантика версий:

Major (2.0.0): Ломающие изменения, перестроенный поток
Minor (1.1.0): Новые функции, новые узлы
Patch (1.0.1): Исправления ошибок, правки текста

Сравнение версий

mcp__moira__manage({
  action: "diff",
  workflowId: "my-workflow",
  compareWorkflowId: "my-workflow-old",
});

Типичные правки

Исправление опечатки в директиве

{
  updateNodes: [
    {
      nodeId: "task-node",
      changes: {
        directive: "Corrected directive text",
      },
    },
  ];
}

Добавление обязательного поля в InputSchema

{
  updateNodes: [
    {
      nodeId: "input-node",
      changes: {
        inputSchema: {
          type: "object",
          properties: {
            existing_field: { type: "string" },
            new_field: { type: "string" }, // добавлено
          },
          required: ["existing_field", "new_field"], // обновлено
        },
      },
    },
  ];
}

Вставка узла в поток

{
  addNodes: [
    {
      type: "agent-directive",
      id: "inserted-node",
      directive: "New step",
      connections: { success: "original-target" }
    }
  ],
  updateNodes: [
    {
      nodeId: "original-source",
      changes: {
        connections: { success: "inserted-node" }
      }
    }
  ]
}

Ошибки валидации

Отсутствует цель соединения

Error: Node 'task-1' connection target 'missing-node' not found

Решение: обновите соединение на валидный ID узла.

Изолированный узел

Warning: Node 'orphan-node' is not reachable from start

Решение: добавьте соединение от другого узла или удалите изолированный узел.

Неверный тип узла

Error: Unknown node type 'custom-type'

Решение: выберите встроенный тип из справочника узлов. Для типа расширения с пространством имён убедитесь, что расширение установлено. Валидатор без достоверных live-данных реестра сообщает, что тип не удалось разрешить; live-реестр без этого типа сообщает об ошибке.

Смотрите также

Создание Workflows - Создание новых workflows
MCP Tools - Справочник инструментов