Проверки и сохранение в явно выбранном worktree

Назначение

Оператор работает в собственной ветке внешнего Git worktree. Создание документов уже поддерживает явный корень, но последующие команды ищут их в primary checkout. Нужен последовательный способ проверить, финализировать и сохранить документы без копирования в primary и без ослабления защиты ветвей.

Пользовательские сценарии

Сценарий 1: Проверка документов, P1

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

Сценарий 2: Финализация, P1

Дано: в выбранном worktree подготовлен корректный комплект документов. Когда оператор запускает предварительную проверку. Тогда проверяются реальные входные файлы без записи. Когда оператор запускает обычную финализацию. Тогда документы, статусы и commits остаются на разрешённой поверхности выбранной работы; primary и соседний worktree не изменяются.

Сценарий 3: Сохранение, P1

Дано: изменён один разрешённый документ в выбранном worktree. Когда оператор явно сохраняет его командой. Тогда commit содержит только разрешённые файлы, сообщает правильную ветку и SHA. Повторный вызов без изменений не создаёт лишний commit.

Сценарий 4: Отказ от чужого корня, P1

Дано: передан другой репозиторий, вложенный каталог или повреждённый Git pointer. Когда запущена любая из трёх команд. Тогда получен структурированный отказ до чтения документов чужой работы и до записи. Отсутствие нового параметра сохраняет прежнее поведение, но не признаёт владение worktree по одному лишь текущему каталогу.

Требования

Функциональные требования

IDНазваниеТребованиеПриоритетСтатус
FR-001Явный кореньТри команды принимают параметр --owned-checkout и проверяют принадлежность репозиторию штатным классификатором.ВысокийОткрыто
FR-002Проверкаagent mission check-prerequisites читает документы из проверенного корня, включая поиск по точному идентификатору.ВысокийОткрыто
FR-003Финализацияagent mission finalize-tasks использует проверенный корень на этапах чтения, размещения, создания статусов и commits.ВысокийОткрыто
FR-004Сохранениеspec-commit разрешает пути и назначение commit относительно проверенного корня.ВысокийОткрыто
FR-005СовместимостьБез нового параметра сохраняется прежний контракт; не вводятся эвристики владения по cwd и выдуманные поля старых метаданных.ВысокийОткрыто
FR-006Ограниченный режимЯвный корень в первом патче поддерживает только single_branch; другие topology и сочетание с --resume-probe отклоняются до побочных эффектов.ВысокийОткрыто
FR-007Ветка и файлыДо записи проверяется совпадение текущей и целевой ветки, отсутствие detached HEAD и protected destination; вся пачка файлов принадлежит выбранной работе и корню.ВысокийОткрыто

Нефункциональные требования

IDНазваниеТребованиеКатегорияПриоритетСтатус
NFR-001ИзоляцияВ положительных и отрицательных тестах неизменны HEAD, index, tracked и untracked содержимое primary и соседнего worktree.БезопасностьВысокийОткрыто
NFR-002Проверка без записиПредварительная финализация не меняет документы, статусы, index и refs ни одного checkout.НадёжностьВысокийОткрыто

Ограничения

IDНазваниеОграничениеКатегорияПриоритетСтатус
C-001Одна модель владенияИспользовать существующие resolve_ownership_claim и структурированные отказы; не переносить неявную модель из закрытых локальных патчей.АрхитектураВысокийОткрыто
C-002Локальная проверкаНе менять глобальный launcher, установленные навыки и primary checkout. Не публиковать upstream и не выполнять release.ДоставкаВысокийОткрыто
C-003Границы ремонтаНе переписывать все команды жизненного цикла, не менять формат метаданных и не обходить protection policy.ОбъёмВысокийОткрыто

Критерии результата

  • SC-001: все три сценария проверены через реальные CLI entrypoints на синтетическом репозитории с двумя внешними worktree.
  • SC-002: доказаны отказы для чужого, вложенного и повреждённого корня; нет изменений primary.
  • SC-003: исходное воспроизведение падает до патча и проходит после него; parser error сам по себе не считается доказательством исправленного поведения.
  • SC-004: после тестов повторены read-only проверки исходных документов cli-opportunity; успешный результат не означает разрешения на создание или установку навыка.
  • SC-005: одинаковый slug в primary и worktree не смешивает документы; отсутствие работы в выбранном корне не запускает fallback в primary.
  • SC-006: чужие staged/unstaged файлы сохраняются, смешанная допустимая и недопустимая пачка отклоняется до staging; ссылки наружу не обходят ограничение путей.

Согласованное расширение приёмки

2026-08-31 оператор разрешил локальную доработку четвёртой команды, accept, и регрессионные тесты. Первоначальные три команды остаются без изменения контракта.

single_branch; диагностика читает документы, статусы и матрицу только этой работы.

только в выбранном checkout. Неполные доказательства продолжают блокировать приёмку.

исправлением кодировки отклоняется до эффектов. Перед пишущим режимом отклоняется непустой index; без явного корня прежний контракт сохраняется.

работы при совпадающем имени в primary; снимки primary и соседней работы неизменны.

остаточных изменений, отрицательный пример не превращает незавершённую работу в принятую.

  • FR-008: accept --owned-checkout проверяет тот же явный корень, ветку и
  • FR-009: обычная приёмка сохраняет матрицу, метаданные и служебное завершение
  • FR-010: диагностика не пишет; сочетание явного корня с диагностикой и
  • SC-007: повторяемый CLI-тест проверяет правильный путь и содержимое выбранной
  • SC-008: положительный пишущий тест проверяет фактический commit и отсутствие

Установка runtime, публикация, ремонт глобальных навыков и ручное изменение статусов реальных работ этим расширением не разрешены.

Проект расширения смены статуса

Оператор разрешил подготовить узкий ремонт agent tasks move-task. Этот раздел задаёт дополнение для согласования до изменения кода. Аудитория: разработчик CLI и оператор, работающий в отдельной Git-ветке. Исходная база: 3c9845044.

Сценарии

1. Документы и статус существуют только в явно выбранной рабочей копии. Оператор выполняет допустимый переход с --owned-checkout и --mission; команда читает именно этот статус, сохраняет актёра и фиксирует изменения на целевой ветке этой работы. Корневой checkout репозитория и соседняя рабочая копия неизменны. 2. Работа передаётся на ревью и затем одобряется с настоящими доказательствами. Проверяются изменения относительно отдельной достоверной базы сравнения, завершённость подзадач, чистота рабочей копии и штатные ограничения ревью. Отсутствующая или непригодная база даёт отказ, а не пустой успешный diff. 3. Ревью отклоняет работу с конкретной обратной связью. Результат ревью, переход in_review -> planned и снятие назначения остаются в выбранной рабочей копии; feedback сохраняется, прежние agent и shell_pid освобождаются. Нельзя потерять выбранный корень в служебной или компенсирующей записи. 4. Чужой корень, совпадающее имя другой работы, неподдерживаемый режим или повреждённые доказательства не приводят к чтению/изменению другой работы или ослаблению проверок. Вызов без флага сохраняет прежний контракт.

Дополнительные требования

IDНазваниеТребованиеПриоритетСтатус
FR-011Явная рабочая копияmove-task --owned-checkout использует существующую проверку владения, точный идентификатор, single_branch, совпадение текущей и целевой ветки, защиту обеих копий и пустой index до любых записей.ВысокийПроект
FR-012Единый контекст операцииДокументы, статус, подзадачи, база и доказательства ревью разрешаются из выбранной работы; при отсутствии данных нет fallback в корневой checkout репозитория.ВысокийПроект
FR-013Честная проверка измененийНазначение commit и база сравнения различаются. Для code_change сохраняются штатные проверки реализации и ревью; нельзя сравнить HEAD с ним самим, выдать рабочую копию за repo_root или изменить её метаданные ради пропуска проверки.ВысокийПроект
FR-014Локальная записьСобытия статуса, результаты ревью, метаданные и компенсация идут через существующие владельцы записи только в выбранную работу. Успех оставляет её Git-дерево чистым и сообщает фактический результат.ВысокийПроект
FR-015Ограничения и совместимостьНовый режим поддерживает обычные переходы между planned, claimed, in_progress, for_review, in_review, approved, включая doing и мотивированный возврат из ревью. done, другие topology, принудительные/skip/arbiter/self-review-fallback режимы и отключённый auto-commit отвергаются до эффектов. Без флага прежние режимы сохраняются.ВысокийПроект

Проверяемый результат

корневом checkout; parser error нового флага не заменяет это доказательство.

Git-рабочей копии с отдельной базой; проверены точные события, evidence, actor, commit target, чистое дерево и неизменность соседних копий, включая их index.

корень/ветку, чужой index, отсутствующую базу, незавершённые подзадачи, некорректное ревью и отказ записи; ошибочный статус не становится одобренным. Сбой перехода после записи verdict проверяется отдельно от отказа ревью: после штатной компенсации проверяются status, review bytes, assignment и Git. При сбое самой компенсации команда явно сообщает частичное выполнение, ненулевой код и фактическое остаточное состояние, а не чистый успех.

изменение одного ожидаемого статуса в примере также вызывает содержательный отказ.

  • SC-009: до патча реальный entrypoint воспроизводит ошибочный поиск работы в
  • SC-010: реальная цепочка реализации и независимого ревью проходит в синтетической
  • SC-011: отрицательные случаи охватывают одинаковые имена работ, неверный
  • SC-012: смысловая мутация выбранного корня или базы ломает наблюдаемый тест;

Пригодная база обязательна там, где штатный переход проверяет реализацию или актуальность ревью. Начальное назначение и обычный мотивированный возврат не получают нового требования базы. Декларация должна разрешаться в commit и merge-base того же репозитория; отсутствие, конфликт, неразрешимая ссылка или сравнение с HEAD дают отказ. Одна зафиксированная ревизия служит diff и проверке implementation commit в пределах одного запуска; target записи остаётся отдельным.

Новый пакет не устанавливает runtime или навыки, не публикует изменения, не переносит реальные работы, не меняет next, самостоятельный status emit, контракт приёмки или требуемые каталоги src/ и contracts/.

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

Формальная приёмка выявила последний локальный разрыв: mark-status не имеет --owned-checkout, поэтому канонизирует mission в primary до чтения и записи. Расширение остаётся внутри WP01 и добавляет только явный режим для этой команды.

Дополнительные требования

IDНазваниеТребованиеПриоритетСтатус
FR-016Явная рабочая копияmark-status --owned-checkout требует явный --mission, использует resolve_owned_mission, поддерживает только single_branch и до чтения проверяет точный корень, ветку, protection policy и пустой index.ВысокийПроект
FR-017Единая поверхностьtasks.md, authored roster, status lock, status.events.jsonl и status.json разрешаются из одного MissionHandle с проверенным effective_root; fallback в primary запрещён.ВысокийПроект
FR-018Локальная фиксацияOwned-вызов требует auto-commit и использует transactional annotation writer с effective_root, который атомарно фиксирует event и snapshot на проверенной task-ветке. Для нескольких WP транзакции идут последовательно; поздняя ошибка сообщает ненулевым кодом применённые WP, event IDs, destination и фактическое dirty-state. Чистый успех оставляет selected checkout чистым.ВысокийПроект
FR-019Изоляция и совместимостьПри активном sync owned-режим отказывается до записи; ambient history, error-log и dossier hooks в нём не вызываются. Без флага поведение, JSON и patch seams остаются прежними.ВысокийПроект

Проверяемый результат

primary и не может завершить подзадачу, существующую только в selected checkout; parser error нового флага не считается красным доказательством.

InnerStateChanged, материализуют snapshot и commit только в selected checkout. Проверяются фактический путь, ветка, SHA, чистое дерево и неизменность байтов, index, HEAD и refs primary и sibling.

staged index, active sync, --no-auto-commit, неизвестный task и ошибка transaction/materialization/readback отвергаются с проверяемым состоянием; stale status.json не считается успехом. Смысловая мутация effective_root или ожидаемого event/snapshot path ломает тест.

  • SC-013: реальный tasks.app до исправления принимает mission только из
  • SC-014: пакет done и обратный pending создают правильный
  • SC-015: чужой, вложенный, detached, protected и branch-mismatched checkout,

Расширение не меняет reducer, формат событий, sync emitters, move-task, обычный режим mark-status или acceptance matrix. Оно не разрешает установку, push, PR, merge и публикацию.