Зависимости задач Asana

A ждет B: A нельзя закончить до B. Это зависимость A→B; обратное отображение «B держит A» не требует второго ребра. Связанность и происхождение работ (related в asana-project) зависимостью не являются. Этот навык не переносит сроки, не закрывает задачи и не меняет комментарии.

Выбор режима

Необязательное поле mode задается у доски; --mode переопределяет его для вызова. Возможности относятся к выбранному workspace и операции. Успешный GET не доказывает право записи. Не создавать пробные связи ради проверки тарифа. Только 402 означает тарифное ограничение; 401/403, 429, timeout и 5xx не разрешают fallback. Даже после 402 описания не меняются автоматически: пользователь согласует новый текстовый план.

Предпросмотр и разрешение

1. Выбери аккаунт, workspace и доску. При нескольких аккаунтах передавай --auth явно во всех командах; порядок получения PAT такой же, как в asana-comments. Токены не включать в конфиг, журнал или вывод.
2. Выполни dry-run. Проверь имена, направление, точные добавления, снятия и очистку текста. Неоднозначные/отсутствующие имена и неверный scope блокируют доску.
3. Покажи конкретный результат пользователю и получи разрешение на этот набор. Digest связывает байты плана, но сам разрешением не является.
4. Для native --send нужны сохраненный план и --expect-plan. Инструмент заново проверяет снимок; drift требует нового предпросмотра и оценки разрешения. После частичной ошибки сохраняй journal и результат, не повторяй запись со случайным новым digest.

Конфигурация и команды

{
  "board": {
    "project": "12345",
    "mode": "native",
    "chains": {"A": ["B", "C"]}
  }
}

chains читается как «A ждет B и C». Пустой chains: {} в native позволяет спланировать снятие ранее управляемых связей. Ручные связи не присваиваются инструменту. Имена сверяются после нормализации пробелов/Unicode; дубли и self-edge отвергаются.

python3 scripts/asana-blockers.py --board board
python3 scripts/asana-blockers.py --board board --send

# Родитель внешнего служебного каталога заранее выбран и проверен.
python3 scripts/asana-blockers.py --board board --mode native   --state /service/task/asana-state.json --plan /service/task/asana-plan.json
python3 scripts/asana-blockers.py --board board --mode native   --state /service/task/asana-state.json --plan /service/task/asana-plan.json   --send --expect-plan <digest-из-предпросмотра>

Native/auto поддержаны только на Linux и работают с одной явно выбранной --board. Пути --state и --plan абсолютные, устойчивые, вне sync/vault и корня конфигурации. До запуска агент проверяет реальные границы синка по docs-maintenance; наличие абсолютного пути само по себе их не доказывает. Не использовать symlink-пути, чужие файлы или один путь для state/plan/lock. Родитель должен уже существовать. План и journal записываются приватно, без сырого HTML, подписанных URL и токенов. Конкретный scope должен всегда использовать один и тот же journal, включая следующие сессии; новый пустой файл не восстанавливает владение.

Журнал и безопасный повтор

Журнал различает account/workspace/project, хранит только управляемые ребра и метаданные применения. Перед POST записывается intent, после успеха и проверки обеих сторон — подтверждение. До успешной записи intent API не меняется. Старое ручное ребро остается ручным даже при совпадении с конфигом.

При timeout после отправки неизвестно, применен ли запрос. Сохрани неопределенный статус и сделай новый dry-run; наличие ребра по GET не превращает его в owned. Подтвержденные предыдущие шаги остаются в журнале. Ошибка сохранения после API также дает ненулевой результат, не PASS. При ошибке после atomic replace на диске может уже быть подтвержденная запись; следующая сессия перечитывает фактический файл, а не предполагает откат. Автоматической компенсации и слепого retry мутаций нет.

Stable lock рядом с journal сериализует один state-файл на Linux, не разные файлы для одной доски. Lock не удаляется после освобождения. Запись атомарная с fsync файла/каталога; это не доказательство поведения при физическом отключении питания. Журнал не заменяет пользовательское разрешение на конкретный план.

Миграция текстовых блоков

Добавь --cleanup-text и в dry-run, и в согласованный send только для явно запрошенной миграции. Код распознает прежний технический блок, проверяет ЖДЕТ как A→B, ДЕРЖИТ как X→A и снимает только целиком подтвержденную собственную секцию. Несоответствующий конфигу или ручной текст сохраняется с диагностикой. related, ручной хвост, HTML и вложения сохраняются; пустой каркас снимается. Закрытые задачи не открываются, даты и сроки не меняются.

Текст убирается после read-back штатных зависимостей и обратной стороны. Перед PUT описание перечитывается; после PUT проверяется сохранность результата. Ошибка PUT/read-back или конфликт оставляют честный partial в журнале, без автоматического восстановления поверх чужой правки.

Временные URL вложений могут обновляться. Допускается изменение значений только X-Amz-Algorithm, X-Amz-Credential, X-Amz-Date, X-Amz-Expires, X-Amz-SignedHeaders, X-Amz-Signature, X-Amz-Security-Token у URL, подтвержденного attachment gid через API. Host/path, остальные параметры и их порядок, набор signing keys, ID и остальные атрибуты неизменны. Неизвестная подпись, дубли ключей, fragment или неподтвержденная ссылка сравниваются строго. У внешнего вложения download_url может отсутствовать или быть null: тогда URL сравнивается строго без нормализации. Пишется свежее описание; сырые URL и HTML в диагностику не попадают. Если URL неизвестного signer меняется при каждом чтении, строгая проверка может постоянно возвращать drift; такую доску нужно разбирать отдельно. Строгий post-readback может остановиться на непредусмотренной нормализации Asana; это не объявляется успешной миграцией.

Ограничения API и конкурентных изменений

План проверяет циклы в доступном графе, включая пути вне конфига, и предел 30 dependencies+dependents с сохранением ручных ребер. Обход ограничен 1000 задач, 100 вложений на задачу и бюджетом 10000 чтений на построение/применение; неполнота или отказ чтения блокируют следующий шаг. Общий бюджет apply может остановить большой план после части подтвержденных шагов: журнал сохраняется, остаток требует нового согласованного dry-run. Сначала выполняются снятия, затем добавления; каждый шаг учитывает ранее подтвержденные изменения и проверяет внешний drift. Снятие и миграция текста у задачи в нескольких проектах блокируются: несколько конфигов досок не считаются скоординированными.

Asana не дает CAS. Между GET и POST/PUT остается окно гонки: ручная правка описания может быть перезаписана; конкурентное ручное создание того же ребра может получить ошибочную owned-атрибуцию после идемпотентного POST. Перед send согласуй окно без параллельных редакторов. Не обещай полную изоляцию, rollback или глобальное определение владельца.

Текстовый режим и общий каркас

Прежний text-режим сохраняется: один блок СВЯЗИ ЗАДАЧИ / - - - в начале описания; секции ЖДЕТ/ДЕРЖИТ принадлежат asana-blockers, СВЯЗАННЫЕ ЗАДАЧИ — asana-project. Общий реестр заголовков и слияние находятся в asana-blockers.py; не заводи второй экземпляр. Каждый скрипт сохраняет чужие известные секции. Перенесенный вниз блок автоматически не ищется: нужен ручной разбор, иначе возможен дубль. Текст, буквально повторяющий машинную грамматику, может быть распознан как машинный — ручные пояснения туда не помещать.

Text пишет html_notes, сохраняет оформление и перечитывает задачу перед записью; повторный прогон идемпотентен, убранная цепочка снимает текстовый блок. Статус блокера и смена исполнителя требуют нового прогона; сами имена подставляются Asana из упоминаний. Частичная ошибка не транзакционна, постоянные отказы и удаленные задачи требуют разбора. Сроки/закрытие относятся к asana-project и отдельному разрешению. Старый формат блока распознается; asana-project может потребовать сначала прогнать текстовый преобразователь. Сохраняются проверки имен, доски и неполных ответов; dry-run не заменяет согласование.

Связанные источники

• scripts/asana-blockers.py — text/native движок; .asana-blockers.json — конфиг.
• skills/asana-project — создание/сроки/закрытие и независимая секция related; skills/asana-comments — комментарии и авторизация.
• rules/tasks-tracking.md и rules/tracker-addressing.md — требования к человеческим задачам.

Модель и текущие назначения

Перед новым заданием и запуском применяй маршрутизацию моделей: свежий MODELS выше канонического дефолта. Границы данных и полномочий этого навыка сохраняются.