Итоговый проект по сотрудничеству с ИИ: GitHub, Confluence и Jira
Table of Contents
Вернуться к курсу сотрудничества с ИИ
Выполните PROP-042 дважды, через GitHub-first и через GitHub с Confluence/Jira. Вы вносите изменение, отдельные владельцы его проверяют, а уполномоченные издатели применяют его. После предыдущих уроков используйте изолированные синтетические песочницы. Итоговый проект проверяет всю процедуру, включая отказ, восстановление и независимую передачу, а не качество текста ассистента.
Главные выводы
- Одно общее изменение сравнивает обе модели полномочий.
- Негативные тесты так же важны, как успешная доставка.
- Пакеты доказательств поддерживают независимую проверку.
- Завершение лаборатории не разрешает запуск в production.
Перед началом
Предварительные требования: предыдущие модули курса , одобренный доступ к песочнице и отдельные проверяющие. Плановое время: от восьми до двенадцати часов в нескольких сессиях, плюс независимая проверка. Фактическое время зависит от настройки аккаунта и ремонтных работ. Сложность: высокая.
Обязательные артефакты: устав, карта, политика, адаптеры, базовая линия, манифест, зафиксированное предложение, проверки владельцев, журнал, запись восстановления и handoff. Отсутствующие разрешения, зависящие от плана, блокируют завершение. Не считайте их автоматически пройденными.
Подготовьте отдельный каталог доказательств для каждого трека до тестирования. Проверяющий должен определить исполнителя, ревизии источников, предпринятое действие, наблюдаемый результат и конечное состояние без опоры на резюме чата.
Создайте две базовые линии
- Создайте изолированные запуски с названиями GitHub-first и Mixed. Держите ревизии и проверки раздельно.
- Восстановите семидневную базовую линию по одобренной процедуре каждого трека и зафиксируйте полученные ревизии.
- Проверьте средства отказа с аккаунтами contributor и excluded-user.
- Зафиксируйте текущий контекст и подтвердите согласие адаптера и политики.
- Объявите область: синтетическое хранение экспортов в течение тридцати дней, без реальных данных, резервных копий и юридических удержаний.
PROP-042 является меткой корреляции, а не повторно используемым разрешением. Для каждого запуска нужны собственная замороженная ревизия и доказательства источника. Включайте ID запусков в отчёты.
Выполните GitHub-first
Откройте Issue и кандидатский PR по урокам GitHub. Вместе измените требование, конфигурацию, предложение и runbook. Зафиксируйте защищённую базу, выполните доверенные проверки и получите проверки продукта и операций на финальном коммите.
Run: GitHub-first
Change: synthetic retention 7 -> 30 days
Requirement: REQ-17 revision 2
Configuration: retention_days 30
Runbook: Retention days: 30
Proposal: base revision 1, from 7, to 30
Manifest: protected pre-change source hashes
Review: product and operations at final proposal revision
Publication: merged commit and read-back
Limit: no running deletion service exercised
Заполните реальные ссылки из песочницы. Схема показывает ожидаемое сопоставление, а не готовые доказательства. Мейнтейнер выполняет merge только после проверки, затем независимо читает main. Закройте Issue после добавления ссылок на итоговые записи.
Выполните трек Mixed
Прочитайте версии Confluence и заморозьте предложение Jira. Получите обе проверки владельцев. Опубликуйте требование со статусом доставки pending, выполните merge конфигурации, опубликуйте runbook и прочитайте все системы перед Done.
Записывайте каждую публикацию с версией страницы, коммитом или доказательством перехода. Копии требований в репозитории остаются снимками. Локальный checker не подтверждает текущие полномочия Confluence.
| Сравнение | GitHub-first | Mixed workplace |
|---|---|---|
| Требование | Проверка защищённого репозитория | Публикация, проверенная владельцем Confluence |
| Координация | Issue/PR | Зафиксированное предложение Jira |
| Единица публикации | Merge репозитория | Отдельная запись страниц и merge |
| Актуальность | Защищённый коммит | Версии страниц плюс коммит |
| Восстановление | Проверенный revert/компенсация | Компенсация по журналу |
Выбирайте процесс по потребностям владельцев. GitHub-first уменьшает координацию между системами. Mixed сохраняет рабочие места и добавляет проверки публикации и доступа.
Запустите матрицу сбоев
| Случай | Инъекция | Требуемое наблюдаемое доказательство |
|---|---|---|
| Одобренное изменение | Отправить проверенное предложение на тридцать дней | Согласованный read-back и проверка |
| Устаревший контекст | Изменить источник после захвата | Отказ, согласование, повторное одобрение |
| Неавторизованная запись | Contributor публикует | Отказ и неизменная ревизия |
| Конфликт | Jira говорит шестьдесят, Confluence семь | Блокировка и согласование владельцев |
| Частичная публикация | Прервать после одной записи | Ожидающий журнал и восстановление |
| Отказ в доступе | Удалить доступ задачи на чтение | Нет защищённого текста или публикации |
| Восстановление | Одобренное завершение/backout | Новые проверенные ревизии |
| Handoff | Новая сессия получает только карту/журнал | Свежий read и правильное следующее действие |
Конфликт между системами относится к Mixed. В GitHub-first проверьте описание Issue, противоречащее одобренному файлу. Остальные применимые случаи запускайте в обоих треках. Ошибка локального валидатора не заменяет живое доказательство разрешений.
| Случай и файл доказательств | Запуск GitHub-first | Запуск Mixed |
|---|---|---|
Одобренное изменение 01-approved-change.md |
Проверенный PR и read-back | Проверенные страницы, merge и журнал |
Устаревший контекст 02-stale-context.md |
Изменить защищённую базу после захвата | Изменить страницу-источник полномочий после захвата |
Неавторизованная запись 03-unauthorized-write.md |
Отказ contributor в прямом push | Отказ contributor в изменении страницы и переходе |
Конфликт 04-conflict.md |
Issue расходится с одобренным файлом | Текст Jira расходится с Confluence |
Частичная публикация 05-partial-publication.md |
Остановиться до merge или read-back | Остановиться после одной записи страницы |
Отказ в доступе 06-access-denial.md |
Скрыть защищённый источник репозитория | Исключить пользователя из закрытой страницы |
Восстановление 07-recovery.md |
Проверенный revert или завершение | Компенсация по журналу |
Handoff 08-handoff.md |
Новая сессия читает защищённые файлы | Новая сессия читает сопоставленные страницы и журнал |
Создайте каждый файл до его теста. Запишите ожидаемый результат, наблюдаемый результат, роль исполнителя, начальные и конечные ревизии, ссылку на нативное доказательство и решение проверяющего. Запрос маршрута в браузере не является отказом в прямом push. Держите каталоги двух треков отдельно.
Разделяйте ожидаемые и наблюдаемые результаты. Для каждого случая записывайте ID запуска, роль исполнителя, начальные ревизии, предпринятое действие, ожидание, наблюдение, полученные ревизии и решение проверяющего. Удаляйте из общих отчётов учётные данные и идентификаторы аккаунтов.
Оцените завершение
Для Pass нужны наблюдаемые доказательства каждой применимой строки и независимое принятие. Проверяющие изучают разрешения, актуальность источника, проверку ролей, частичную публикацию, восстановление handoff и журналы согласованности.
Немедленно ставьте Fail при неавторизованной публикации, попадании запрещённого текста к модели или тихой перезаписи изменённой базы. Оставляйте работу Blocked, пока исправленные средства контроля не пройдут повторный тест. Не усредняйте эти сбои в пользу хорошей оценки.
Измеряйте завершённые/заблокированные случаи, отклонённые устаревшие предложения, отклонённые записи, восстановления и время проверяющего. Предполагаемые результаты остаются ожидаемыми до наблюдения. Десять предоставленных unit-тестов покрывают согласованность, а не живую безопасность tenant.
Спланируйте два запуска
Не используйте одно одобрение для обоих треков. Запрошенное значение одинаково, но источники, захваченные ревизии, разрешения и порядок публикации различаются. Дайте каждому запуску отдельный каталог доказательств и пакет проверки.
capstone-evidence/
github-first/
charter-and-map
captured-sources
fixed-proposal
role-reviews
consistency-results
permission-results
publication-readback
recovery-and-handoff
mixed/
same evidence categories, independently captured
Эти имена являются примером организации, а не предоставленными архивными файлами. Храните реальные доказательства в закрытой одобренной песочнице. В общих материалах курса используйте метки ролей и скрытые ссылки, а проверяющие должны сохранять доступ к нативным записям.
Назначьте наблюдателя теста до запуска сбоев. Contributor выполняет предпринятое действие. Наблюдатель записывает исходное состояние, результат и получившееся состояние. Проверяющий позже определяет, подтверждают ли доказательства утверждение. Раскрывайте пересечение ролей вместо намёка на независимое принятие.
Запускайте сбои изолированно
Между случаями возвращайтесь к проверенному состоянию. Одновременная инъекция дрейфа источника, отзыва доступа и несоответствия runbook скрывает, какой контроль отклонил предложение. Один сбой на запуск даёт проверяющему прослеживаемую причину результата.
- Зафиксируйте исходное состояние: ревизии источников, конфигурацию, состояние доставки и роль исполнителя.
- Примените одну синтетическую инъекцию: измените одно условие через авторизованный тестовый маршрут.
- Выполните ограниченное действие: проверку, чтение, публикацию или handoff.
- Запишите наблюдение: фактический вывод и получившееся состояние источника.
- Исправьте через проверку: сохраните доказательства сбоя до восстановления контроля.
- Повторите положительный случай: подтвердите, что исправленный процесс по-прежнему доставляет разрешённую работу.
Плановый сбой всё равно остаётся наблюдением сбоя. Не называйте неавторизованную публикацию успешным тестом только потому, что собирались её исследовать. Тест выявил дефект, но граница публикации не сработала и требует исправления.
Карточка инъекции и сброса для каждого случая: перед следующей строкой используйте новое синтетическое предложение или восстановите проверенную базу. Наблюдатель записывает предусловие и подтверждает сброс. Никогда не удаляйте неудачную попытку из журнала.
| Случай | Инъекция и проверка GitHub-first | Инъекция и проверка Mixed | Сброс перед следующим случаем |
|---|---|---|---|
| Одобренное изменение | Отправить зафиксированный PR, получить обе проверки, выполнить merge и снова открыть main |
Опубликовать REQ-17, выполнить merge проверенного diff, опубликовать RUN-04, затем снова открыть все записи | Зафиксировать итоговые ревизии как следующую базу |
| Устаревший контекст | Захватить манифест, затем изменить защищённую тестовую базу через отдельный проверенный PR до проверки старого предложения | Захватить версии страниц, затем попросить уполномоченного редактора изменить тестовую страницу до чтения перед записью | Остановиться, сравнить версии, захватить свежие источники и проверить новый зафиксированный пакет |
| Неавторизованная запись | Contributor пытается безопасный прямой push в защищённый main и записывает отказ сервера |
Contributor пытается изменить REQ-17 и выполнить переход Approved | Снова открыть защищённый коммит, версию страницы и состояние Jira, которые должны остаться неизменными |
| Конфликт | Поместить шестьдесят дней в черновик Issue, когда одобренный файл говорит семь | Поместить шестьдесят дней в черновик Jira, когда REQ-17 говорит семь | Владелец продукта согласует черновик и записывает решение до проверки |
| Частичная публикация | Остановиться после одобрения, но до merge или финального read-back, оставив Issue открытым | Остановиться после read-back REQ-17, когда конфигурация и RUN-04 всё ещё говорят семь | Оставить доставку ожидающей и получить проверенное решение о завершении или компенсации |
| Отказ в доступе | Использовать тестовую личность, исключённую из закрытого источника, и попытаться прочитать его | Использовать исключённую личность на отдельной ограниченной синтетической странице | Восстановить только одобренный тестовый доступ и проверить, что обычный читатель работает |
| Восстановление | Прервать одобренное тестовое изменение, затем предложить проверенное завершение или revert | Использовать журнал частичной публикации для предложения проверенного завершения или компенсации | Прочитать каждый полученный источник и согласовать журнал |
| Handoff | Отправить MAP-01 и журнал новому проверяющему без старого чата | Отправить ID сопоставленных страниц и журнал новому проверяющему без старого чата | Проверяющий открывает текущие источники и записывает следующий разрешённый шаг |
Для каждого отказанного случая записывайте ответ платформы и второе чтение защищённой записи. Для случая исключённого пользователя также проверяйте возвращённый контекст задачи, чтобы кэшированный фрагмент не выдавал себя за безопасный отказ. Если план не предоставляет контроль или отсутствует одобренная тестовая личность, записывайте Blocked вместо имитации Pass.
Интерпретируйте результат Mixed
Иллюстративный пакет доказательств: локальная согласованность проходит, продукт и операции проверяют зафиксированный пакет, публикация требования успешна, а доступ к редактированию runbook отклонён. Конфигурация ещё не объединена. Jira остаётся Blocked.
| Утверждение | Вердикт | Причина |
|---|---|---|
| Кандидатские записи согласованы | Поддержано локальной проверкой | Предоставленные записи прошли сравнение |
| Владельцы приняли намерение и операции | Требуются нативные зафиксированные проверки | Одних меток ролей недостаточно |
| Тридцатидневная доставка завершена | Не подтверждено | Требуемые шаги публикации остаются ожидающими |
| Граница разрешений работает для каждой роли | Не подтверждено | Один отказ имеет ограниченную область |
| Владелец восстановления должен действовать | Поддержано как следующий шаг | Частичная доставка требует проверенного решения |
Ожидаемое рассуждение: оставьте запуск незавершённым, проверьте текущие источники и запросите решение подходящего владельца. Не завершайте работу ослаблением разрешений или описанием проверки snapshot как живого доказательства публикации.
Заполненный учебный пакет трека Mixed, синтетический и не являющийся доказательством tenant:
Run: MIXED-042-example
Captured base: REQ-17 v4 = 7 days, RUN-04 v2 = 7 days,
GitHub main base-001 config.json = {"retention_days": 7}, Jira PROP-042 r1 = In Review
Fixed proposal: REQ-17 v5 wording says synthetic exports 30 days,
excluding production data, backups, and legal holds.
GitHub config.json changes retention_days from 7 to 30.
RUN-04 v3 wording says 30 days, no deletion service runs in this lab,
and incomplete publication stays pending.
Review: product owner approved the exact requirement wording at PROP-042 r1.
Operations owner approved the exact config diff and runbook wording at r1.
Publication: publisher reopened REQ-17 v5 and read 30 days.
Maintainer reopened main at merge-002 and read retention_days 30.
Publisher reopened RUN-04 v3 and read 30 days.
Denied action: contributor tried an edit to restricted REQ-17 from v5.
Platform denied the edit, the publisher reread v5 unchanged, and the
observer saved the native denial. No edit was applied and v5 stayed unchanged.
Recovery: after a separate simulated failed RUN-04 attempt, Jira stayed
Blocked. Operations approved a retry against the current version.
Publisher reread v3 after the authorized retry before Jira moved to Done.
Handoff: a new reviewer received MAP-01 and the ledger, reopened the three
sources and Jira, and named the current 30-day state and remaining runtime gap.
Limit: source publication is shown. Actual deletion timing is Not run.
Замените каждую иллюстративную версию, роль, отказ и read-back нативными записями до того, как отметить живую строку как Supported. Если план или роль не разрешает тест, отметьте строку Blocked и оставьте курс обоих треков незавершённым.
Проверьте с независимым читателем
Попросите проверяющего восстановить события, а не только прочитать ваш вывод. Без вашей narration он должен найти одобренную базу, зафиксированное предложение, решения владельцев, итоговые ревизии, неудачные попытки, исправление и оставшиеся пробелы.
Reviewer questions:
Which source governs retention intent in this track?
Which exact package did each owner review?
Did any source change after review?
What was published, and what remains pending?
Which denied action was observed under which role?
Did protected text reach an excluded user's context?
Which repair was reviewed and read back?
Does the fresh handoff reconstruct current state independently?
Оценивайте каждое требование отдельно. Используйте Supported, Failed, Blocked или Not run со ссылкой на доказательство. Согласованность, одобрение, разрешения, восстановление и handoff являются отдельными требованиями. Набор зелёных локальных тестов не компенсирует сбой живой границы публикации.
Run ID and track:
Reviewer role and review date:
Case 01 approved change: status ___ evidence ___ gap ___
Case 02 stale context: status ___ evidence ___ gap ___
Case 03 unauthorized write: status ___ evidence ___ gap ___
Case 04 conflict: status ___ evidence ___ gap ___
Case 05 partial publication: status ___ evidence ___ gap ___
Case 06 access denial: status ___ evidence ___ gap ___
Case 07 recovery: status ___ evidence ___ gap ___
Case 08 handoff: status ___ evidence ___ gap ___
Overall decision: Supported / Failed / Blocked / Not run
Next accountable role and action:
Supported означает, что проверяющий нашёл наблюдаемые доказательства для каждого применимого случая. Записывайте Failed при наблюдаемом сбое контроля, Blocked при отсутствии доступа или контроля и Not run для непройденного случая. Храните нативную ссылку каждого случая в его именованном файле доказательств.
Порог прохождения курса: завершите оба трека, GitHub-first и Mixed. В каждом треке все восемь применимых случаев должны иметь доказательства Supported. Неудачная граница или отсутствие нативного read-back блокирует трек. Отсутствие платного плана или тестовой личности даёт Blocked, а не предполагаемый Pass. Один завершённый трек даёт документированный частичный результат, а не завершение курса.
Редактированный модельный пакет, только для иллюстрации:
Track: github-first | Run: G-01 | Reviewer: separate pilot role
Base: protected commit base-001 | Fixed proposal: PROP-042 r1
Approvals: product review ref P-01, operations review ref O-01
Consistency: local check pass, saved output ref C-01
Permission: contributor direct push denied, native event ref D-01
Publication: merged commit merge-002, fresh clone confirms thirty
Exception: backups and legal holds remain excluded
Recovery: interruption case R-01 read back and resolved through review
Handoff: second reader found current base, exception, and next action
Runtime limit: no production deletion or deployment claim
Decision: Supported for synthetic GitHub-first track only
Замените каждую иллюстративную ссылку наблюдаемым артефактом песочницы. Повторите полный пакет для трека Mixed с его собственными версиями источников и проверками. Проверяющий должен отклонить скопированное одобрение GitHub в пакете Mixed.
Сформулируйте ограниченное решение
Полезное итоговое решение называет следующий пилот, а не неограниченный запуск. Например, выберите ещё одну настройку синтетического экспорта с теми же ролями и прямым маршрутом чтения, оставив реальные данные и автоматическую публикацию вне области.
| Элемент решения | Требуемая деталь |
|---|---|
| Область | Одно следующее изменение и его явные исключения |
| Доказательства | Случаи Supported и нерешённые сбои |
| Контроли | Требования платформы и процедурные требования отдельно |
| Владельцы | Ответственная роль за каждый оставшийся пробел |
| Исполнительный пробел | Непроверенное поведение удаления/deployment |
| Условия остановки | Нет доступа, изменились полномочия, неавторизованная публикация |
Проверка завершения: оба пакета запусков проходят независимое восстановление, применимые случаи имеют наблюдаемые доказательства, а нерешённые контроли остаются видимыми. Если завершён только GitHub-трек, сообщите о частичном завершении курса. Не предполагайте, что Mixed будет работать так же.
Устранение проблем и Backout
Есть только доказательства happy-path: повторите тесты отказа и прерывания. Роли пересекаются: раскройте это и повторите с отдельными пользователями. Контроли плана отсутствуют: остановитесь и получите одобренную песочницу.
Backout: восстановите baseline через проверенные PR и правки Confluence, отзовите временные интеграции, архивируйте доказательства Jira и выполните одобренную владельцем синтетическую очистку после удержания доказательств. Сохраните историю восстановления.
Создайте решение о rollout
Decision: another synthetic pilot, blocked, or rejected
Evidence: both run packages and failure matrix
Unenforced requirements: procedural controls listed explicitly
Provider review: input scope and retention handling
Owner coverage: product, operations, policy, repository, delivery
Production gaps: runtime tests, secrets, deployment, access review
Next action: one bounded follow-up with accountable role
Review date: assigned by pilot owners
Ожидаемое рассуждение: синтетический успех поддерживает ещё один ограниченный пилот. Для production нужны отдельные разрешения на реальные данные, deployment, обработку провайдером и поведение во время выполнения. Успешный ответ ассистента не является разрешением на deployment.
Основные ссылки
- Контроли репозитория: Protected branches .
- Доступ к workplace: Confluence permissions .
- Контроли доставки: Jira permission schemes .
Следующие шаги
Вернитесь в центр курса , чтобы проверить отсутствующие контроли. Сравните реализацию со статьёй о framework перед выбором следующего пилота.
