Документация

Происхождение

Откуда взялась каждая задача, кто её запросил, кто принимал решения и по каким причинам, а также что было доставлено.

Происхождение — это запись об одной единице работы: задаче, плане, задаче плана или рабочем пакете. Она отвечает на вопросы, которые необходимо задать о изменении спустя долгое время после его слияния: откуда оно взялось, кто его запросил, кто им владеет, кто принимал решения и по каким причинам, а также что было доставлено.

Coroid формирует эту запись на основе того, что уже происходит в процессе работы внутри Factory: разговора или запроса, ставшего отправной точкой, документов, которые утвердили заинтересованные лица, принятых ими решений, а также пул-реквестов и коммитов, обеспечивших доставку результата. Вы можете увидеть ту же самую запись в портале, в пул-реквестах и коммитах; её также читают агенты, выполняющие задачу.

На какие вопросы отвечает происхождение

  • Источник. Что стало началом выполнения задачи — со ссылкой на соответствующий элемент: обсуждение в Чате, Рецензирование подготовки работы, запрос на Новая работа, импортированный или полученный через вебхук инцидент, хук, расписание, клиент MCP, API, обнаруженная проблема или отчет, а также родительский План или Задача.
  • Запросивший и Владелец. Человек, запросивший работу и отвечающий за неё сейчас. Если работа поступает через служебную учётную запись или от человека за пределами вашей организации, например от автора задачи GitHub, в разделе «происхождение» указывается эта учётная запись или этот человек. Coroid никогда не указывает участника, которого пришлось бы угадывать.
  • Решения. Согласования, запросы на изменения, запуски, остановки, повторные попытки, слияния, переопределения и изменения владельца — каждое действие с указанием исполнителя, времени и причины, если она была указана.
  • Обсуждение. Сообщения участников, повлиявшие на ход выполнения задачи: краткие выдержки из исходного диалога и отзывов о документах, с указанием автора и ссылкой.
  • Доставка. Pull-запросы, коммиты, вердикты QA, решения по рецензированию и подтверждающие данные.

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

Сначала — краткое описание

Каждый раздел с происхождением начинается с краткого описания: сразу видно, для чего предназначена работа и кто за неё отвечает:

  • Намерение: краткое описание назначения и цели работы. Оно берется из утвержденного намерения, затем из утвержденных Спецификаций, затем из исходного запроса, а в конце — из описания Задачи или Плана. Под этим текстом указывается источник информации.
  • Запросил:: лицо, сервисная учетная запись или внешний контрагент, который инициировал выполнение работы.
  • Владелец: лицо, ответственное за выполнение работы в данный момент. Это тот, кому задача была передана последним, затем — лицо, которому назначена Задача, затем — Владелец исходного Чата, а в конце — инициатор запроса.
  • Согласовано:: лица, утвердившие цели, Спецификации и план реализации, а также сам план, с указанием их ролей при утверждении.
  • Ключевые решения: до пяти последних принятых решений с указанием причин их принятия.

В списке утверждающих всегда указаны люди. Автоматически зафиксированные Coroid утверждения опущены; подробнее — в разделе Автоматические решения.

Где это отображается

В портале

Откройте задачу или план в разделе Factory и разверните раздел «происхождение». Под кратким описанием вы найдёте следующие элементы:

  • Источник: место возникновения задачи с ссылкой на соответствующий чат, запрос, задачу или отчет.
  • Линия наследования: план и рабочий пакет, к которым относится задача, если она входит в состав плана.
  • Решения: от самых старых к новым, каждое с указанием причины. В списке отображаются последние восемь записей, а для просмотра остальных достаточно одного клика.
  • Обсуждение: сообщения, повлиявшие на ход выполнения задачи, отображаются в порядке убывания даты.
  • Доставка: pull requests и данные о том, кто их объединил, коммиты, вердикты QA, рецензирование и доказательства.
ЗадачаПланСохранённые поисковые запросы с уведомлениями по электронной почте
Уведомления по электронной почте для сохранённых поисковых запросов
ПроисхождениеИсточник, заказчик, владелец, решения и реализация
MarkdownJSON

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

Из утверждённой цели

Запрошено заказчиком
Майя Линдквист
Владелец
Майя Линдквист
Одобрено ответственным лицом
  • Сэм ОкафорВладелец продукта
  • Прия ШахТехнический ответственный
Источник
Подготовка работЗапрошено через чат
Открытый диалог
Решения
  1. УтвержденоСэм ОкафорВладелец продукта

    Это то, что запросили клиенты. Отложить push-уведомления можно.

  2. НачатоМайя Линдквист

    Необходимо выпустить продукт до весенней кампании.

  3. УтвержденоМайя ЛиндквистАвтоматически

    Договор на поставку автоматически подтверждён на основе утверждённого плана.

  4. Вердикт QAПройденоАгент QA

    Все 6 критериев приемки подтверждены.

  5. СлиятоСэм Окафор
Поставка
Pull-запросы
Запрос на включение изменений #142Слиято пользователемСэм Окафор9c1e4a7f02
Коммиты
  • 3f2b7d1a9cКоммит агентаcoroid/saved-search-alerts
  • 9c1e4a7f02Коммит слияния

Происхождение задачи в Фабрике: сначала — краткое описание, затем — исходный диалог, решения с их обоснованиями, одно из которых фиксируется автоматически, а также pull request и коммиты, реализовавшие её. Примерные данные.

Сжатая версия отображается на вкладке «Детали» задачи и при рецензировании плана, со ссылкой на полное происхождение.

Доступ к происхождению зависит от самой задачи. Для просмотра происхождения задачи требуется права на чтение проекта, а происхождение плана видно во всей организации, как и сам план.

В pull requests

Каждый pull request, открываемый в Coroid, содержит раздел «происхождение», будь то задача, план или релиз. Раздел начинается с краткого описания: цель, суть работы, кто её запросил, кто отвечает за неё, кто её согласовал и какие решения были приняты. Далее указаны источник и ссылки на него, история работы, решения, результат и ссылка, открывающая работу в Coroid.

Coroid формирует остальные разделы документа: краткое описание изменения, ссылку на Задачу и подтверждающие данные для Рецензирования, критерии приемки, а также статус этапов тестирования и Рецензирования.

Coroid владеет только теми разделами, которые он помечает скрытыми комментариями в описании. При обновлении pull request, например после доработки, система заменяет именно эти разделы, сохраняя в неизменном виде весь остальной текст, написанный вами или вашими рецензентами. Если длинная история изменений не помещается в одном месте, самые старые решения удаляются первыми, а в соответствующем разделе указывается, что дополнительные сведения доступны в Coroid.

В pull request релиза перечислены все связанные с ним элементы pull request: то, что он поставляет, кто запросил его создание и кто дал на него Согласования, в порядке их объединения в основную ветку.

В коммитах

Каждый коммит, созданный Coroid, завершается трайлерами, указывающими на соответствующую задачу:

Coroid-Task: 3f6e2b1c-7d4a-4c1e-9b2f-0a8d5e6c7b91
Coroid-Plan: 8a41b7c3-25d0-4f6b-a1e9-6c3d2b7f4e05
Coroid-Requested-By: Maya Lindqvist
Coroid-Origin: prepare_work

В зависимости от типа задачи в коммите также указываются ее плановая задача, рабочий пакет, запуск агента, патч или релиз. Трайлер с информацией о заказчике содержит имя, а не адрес электронной почты.

Coroid является автором каждого созданного им коммита. Если коммит оформлен от имени учетной записи конкретного пользователя, Coroid также добавляет себя в список соавторов.

Co-authored-by: Coroid <ai@coroid.ai>

Coroid также ведет собственную карту, связывающую каждый коммит с соответствующей задачей или планом. Когда открытый Coroid pull-запрос объединяется в GitHub или GitLab, Coroid фиксирует соответствующий merge- или squash-коммит, чтобы при squash-merge не потерялась связь.

Для агентов

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

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

Что никогда не отправляется на ваш хост Git

Текст диалога никогда не сохраняется в pull request или коммите. В pull request указываются имена, роли, решения, причины и ссылки. Сама дискуссия отображается лишь в виде количества сообщений и списка авторов с ссылкой на соответствующий чат в Coroid. Электронные адреса не записываются; вместо них указываются имена пользователей.

По умолчанию в разделе «происхождение» pull request содержатся абзац с описанием намерений, ключевые решения и объяснения, которые дали люди. Организация может выбрать вариант, в котором остаются только ссылки. Тогда в разделе сохраняются сведения о том, кто запросил работу, кто за неё отвечает, кто её согласовал, принятые решения и ссылки на Coroid, но не включаются абзац с описанием намерений, ключевые решения и объяснения.

Выбирайте ссылки только в том случае, если доступ к вашему репозиторию имеют пользователи, которым не следует видеть обоснование продукта — например, при его публичном доступе. Данный параметр применяется к запросам на объединение, которые открывает или обновляет Coroid после вашего выбора. Пока что для него нет отдельного экрана настроек. Свяжитесь с нами чтобы перевести вашу организацию на режим использования только ссылок.

Решения и их обоснование

Coroid фиксирует, кто принимал решения в процессе выполнения задач: согласования намерений, Спецификации и Планы, этапы квалификации, ручной запуск, остановка, повторная попытка и завершение работы, обычные и принудительные слияния, отмена ограничений шлюзов, утверждения релизов, изменения в составе Владельца или участников чата, а также вердикты агентов по проверке качества, Рецензированию и координатор.

При утверждении и запуске плана, остановке задачи или повторной попытке выполнения задачи в окне подтверждения будет предложено указать необязательную причину объемом до 2 000 символов. Эта информация сохраняется вместе с вашим именем в разделе происхождение данной работы, а в открытых запросах на включение изменений она отображается, если в вашей организации не используются только ссылки. Достаточно одного предложения: фраза «Клиенты запрашивали это еще до весенней кампании» даст следующему читателю больше информации, чем само лишь подтверждение. Для принудительного объединения изменений требуется письменная причина, которая также сохраняется аналогичным образом.

Автоматические решения

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

Решения, принятые агентами — например, вердикты QA и рецензирования, а также решения координатора — отображаются под именем соответствующего агента с указанием данного резюме.

Добавить контекст к текущей задаче

Вы можете передать агентам информацию во время выполнения задачи, не прерывая её процесс. Откройте вкладку «Активность» задачи и выберите опцию «Добавить контекст» рядом с текущей активностью. Укажите сведения, которые должны знать агенты, объёмом до 2 000 символов, и подтвердите действие.

  • Когда агент выполняет задачу, он прочитает ваше сообщение при следующем шаге обработки. Координатор, ожидающий завершения другого агента, проснётся и также ознакомится с ним.
  • Если ни один агент не выполняет задачу, следующий запущенный агент прочитает это сообщение.

Сообщение сохраняется в разделе происхождение данной задачи в виде записи о решении «Добавлен контекст» с указанием вашего имени. При этом это не влияет на то, что должна поставлять данная задача: если ваше сообщение противоречит Спецификациям, агент укажет на это противоречие, а не примет решение самостоятельно. Чтобы изменить итог выполнения задачи, необходимо либо скорректировать Спецификации, либо отправить задачу на доработку.

Для добавления контекста требуется права на запись в проект задачи. Для завершённых и отменённых задач такие права недоступны.

Отследите код до соответствующей задачи

Вы можете начать с строки кода и найти соответствующую ей задачу. Портал, агенты, клиенты MCP и Git помогут вам в этом.

Почему это здесь?

В процессе рецензирования задачи на каждом фрагменте кода, затрагивающем существующие строки, имеется соответствующая кнопка. Она определяет коммиты, которые последними изменили эти строки в целевой ветке, и отображает источник каждого из них:

  • Создано с помощью Coroid: задача или план, их назначение, сведения о том, кто их запросил и согласовал, ключевые решения и ссылка на полный раздел «происхождение».
  • Создано вне Coroid: отсутствуют записи о задаче или плане, объясняющие причину изменения; поэтому отображаются автор и дата.

В файле, который добавляется в результате изменения, нет предыдущих строк, поэтому кнопка отсутствует.

Через агента или клиент MCP

Агенты и клиенты MCP задают один и тот же вопрос с помощью инструмента. Он принимает файл и, при необходимости, диапазон строк, а также ветку, тег или коммит. В ответ он возвращает каждый диапазон строк с указанием коммита, в котором эти строки были изменены последний раз. Для коммита, созданного Coroid, он также возвращает соответствующую задачу или план и кратко описывает его происхождение. Этот инструмент называется explain_code.

  • АгентыАгенты: агенты-разработчики, рецензенты и координатор от Coroid используют эту информацию перед тем, как изменять или удалять код с неясной целью.
  • Клиенты MCPКлиенты MCP: это инструмент для чтения, поэтому требуется роль рецензента и следующий диапазон доступа: mcp.readОн работает только в проектах, до которых достигает подключение, и позволяет выполнять 30 вызовов в минуту.

С помощью Git

Каждый коммит, созданный Coroid, указывает на соответствующую задачу в своих заголовках, поэтому через Git вы тоже можете к нему получить доступ:

git blame -L 120,120 src/search/alerts.ts   # the commit that last changed line 120
git log -1 <sha>                            # its Coroid-Task or Coroid-Plan trailer

Затем откройте соответствующую задачу или план в портале, чтобы ознакомиться с её происхождением:

  • Задача: https://client.coroid.ai/factory/task:<task id>?panel=provenance
  • План: https://client.coroid.ai/factory/<plan id>#provenance

Для коммита слияния или сквош-коммита откройте исходный pull request. В разделе «происхождение» есть ссылка на Coroid.

Экспортировать происхождение

В верхней части панели расположены две кнопки скачивания. Кнопка Markdown скачивает происхождение в виде документа, в котором сначала приводится краткое описание. По структуре он соответствует разделу pull request: в нём указаны причины, но нет текста переписки. Кнопка JSON скачивает полную запись, включая выдержки из обсуждения, для ваших архивов или инструментов. Храните файл JSON так же конфиденциально, как и переписку, цитируемую в нём.

Происхождение не зафиксировано

Coroid фиксирует происхождение для задач, созданных после внедрения данной функции. Для ранее выполненных задач вместо информации об источнике отображается это сообщение:

Источник не зафиксирован. Эта работа была создана до того, как Coroid начал учитывать происхождение.

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

Происхождение с меткой «Derived» было восстановлено на основе предыдущих записей, а не зафиксировано в момент создания задачи.