Связанные Mesh сохраняют отдельные права

Три вопроса за одной группой

Первый: что это за репозиторий? Разные checkout могут указывать на один remote; имя папки не является identity. Второй: какой Mesh владеет Task, правилами, памятью и участниками? Третий: какую связь подтвердил Weavatrix? Ответы могут различаться.

Например, Mesh связывает внутреннее приложение и публичный сайт. Это не выдаёт каждому участнику доступ к обоим репозиториям. Кодовая зависимость подтверждается только при наличии свидетельства и ревизии источника.

Что должна показывать группа

Обзор показывает Mesh, связанные репозитории, компьютеры, недавние Tasks и причины связей. Подпись отличает привязку от подтверждённой Weavatrix зависимости. Отсутствие отчёта означает неизвестность, а не отсутствие связи.

Mesh может связывать несколько репозиториев, но вид участника зависит от явных разрешений аккаунта и Project. Телефон владельца проверяет их до пересылки защищённых данных или действий Project.

Имена для человека, ID для маршрута

Два Mesh с именем general-codex могут иметь разные права; две папки granttap могут быть рабочими копиями одного репозитория. Имена помогают ориентироваться, но не служат основанием для маршрутизации и выдачи доступа.

Начните с области координации

Project — место координации людей и работы, а не команда объединить все репозитории и сессии провайдеров. Мобильное приложение, сайт и локальный helper могут входить в один продукт, сохраняя отдельные checkout и процессы выпуска. Вид Project связывает их, чтобы человек понимал, почему две Task относятся друг к другу. У связи должна быть явная причина: общий продуктовый контекст, объявленная зависимость или отчёт с evidence. Эти причины имеют разную силу.

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

Привязка, декларация и evidence

Привязка репозитория сообщает, какой checkout Project наблюдает через подключённый компьютер. Объявленная связь означает, что кто-то записал отношение между компонентами или репозиториями. Подтверждённая архитектура требует большего: отчёт должен вести к проанализированному исходнику и revision. Смешение категорий создаёт ложную уверенность. Даже яркое ребро может быть лишь декларацией, а подтверждённое ребро — относиться к более старому commit, чем текущая Task.

Прежде чем действовать по связи, изучите подпись. Кто её добавил, какие исходники она покрывает, когда получена и применима ли к этому checkout? Если отчёта нет, оставьте декларацию декларацией. Если отчёт устарел, он может направить исследование, но не должен автоматически оправдывать правку. Так архитектурное представление остаётся полезным и не притворяется знанием всего кода.

Права относятся к человеку и действию

Представим коллегу, которому разрешён review Task сайта, но запрещён запуск локальной команды на компьютере выпуска. Связанный Project всё равно может показать, что сайт и helper относятся к одному продукту. Из этого нельзя выводить право на команду. Нужно проверить, можно ли именно этому участнику получить конкретные данные или запросить действие на выбранной машине. Проверка телефона владельца и enforcement на host выполняют разные части этой цепочки.

То же верно для конфигурации возможностей. На одном компьютере MCP-сервер доступен, на другом настроен иначе или не имеет credential. Общая метка Project не делает hosts одинаковыми. При передаче Task целевая сторона должна сообщить, что она действительно способна инициализировать. Карта помогает выбрать маршрут, но самому маршруту нужны собственные проверки capability и policy.

Не путайте имя с identity

Имена удобны человеку, но плохо работают как уникальные идентификаторы. Два репозитория могут иметь одинаковое короткое имя; один репозиторий бывает в папках с разными именами на двух компьютерах. Project можно переименовать, не изменив его identity. Устойчивые связи поэтому опираются на стабильные идентификаторы и revision, а интерфейс показывает понятные названия как контекст. Ошибочное совпадение может отправить работу в чужой checkout или показать не связанную Task.

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

Как карта помогает принять решение

Допустим, изменение iOS зависит от контракта relay. Карта Project ведёт от репозитория приложения к репозиторию протокола, показывает, объявлена связь или наблюдалась, и помогает найти текущие Task с обеих сторон. Следующий разумный шаг — проверить контракт на нужной revision и согласовать работу владельцев. Карта не доказывает, что обе сборки проходят, публикация состоялась или разрешение одного репозитория покрывает другой.

Первая сгенерированная картинка подчёркивает отдельные границы, вторая — разные основания связей. Скриншот GrantTap ниже получен из детерминированной демонстрации, а не из свежего анализа закрытых репозиториев. Все три изображения объясняют, как читать продукт. В своей работе проверьте детали привязки и evidence до того, как положиться на связь. Так коллекция репозиториев становится понятным Project, не стирая решения, которые сохраняют узкий доступ.

Если отчёты расходятся

У разных компьютеров могут быть разные checkout одного репозитория. Один report ещё описывает старую revision, другой построен после изменения контракта, а участник видит только разрешённую ему часть Project. Это не повод выбирать самый красивый граф. Сначала установите, какой компьютер и commit относятся к текущей Task, затем сравните область и время отчётов. Устаревший отчёт остаётся историческим evidence, но не получает статус актуального только потому, что пришёл из знакомого host.

При расхождении полезно сформулировать узкий вопрос: какой файл подтверждает связь сейчас? Если ответа нет, отметьте отношение как непроверенное и откройте исходник на целевом checkout. Отсутствие анализа нельзя автоматически толковать как отсутствие зависимости. Равным образом наличие ребра не подтверждает доступ к ресурсу. Карта показывает, где искать; policy определяет, что разрешено; host сообщает, что реально применено. У этих слоёв могут быть разные времена обновления, поэтому единый зелёный индикатор скрывал бы важную разницу.

Перед общей работой

Когда два участника открывают связанные Tasks, договоритесь о владельце изменения и порядке проверки контрактов. Если один агент меняет приложение, а другой одновременно правит протокол, связь на карте не заменяет согласования версии. Запишите в Task используемые revisions, ожидаемый результат и способ проверки каждой стороны. При необходимости работайте в отдельных ветках или worktrees. Это сохраняет возможность увидеть конфликт до объединения кода, не выдавая участникам лишний доступ к машинам друг друга.

После завершения проверьте не только список связанных репозиториев, но и доказательства результата: соответствующие тесты, сборки и review. Успех в одном checkout не доказывает успех во втором. Если deploy или выпуск ещё не выполнялись, так и запишите. Проектная карта полезна как маршрут к этим проверкам. Она становится опасной только тогда, когда её визуальную близость принимают за общую identity, общие права или автоматически подтверждённое поведение всех частей продукта.