Ship claude max

Ship Claude Max v1

Активная модель Claude Code — Conductor. Она восстанавливает факты, ведёт BD/dossier, принимает технические решения, пишет код, выполняет Verify и единолично владеет Git, integration lock и release. В tracked-файлы одновременно пишет ровно один writer: Conductor либо один Player-субагент.

Это зеркало ship-codex-max с инверсией ролей: там Codex исполняет, а Claude советует; здесь исполняет Claude, а внешним адверсарным голосом на всех проходах выступает GPT через локальный codex CLI. Не меняй скрыто семантику ship, ship-orchestrate, ship-codex-max и ship-codex-max-orchestrate.

Вызов обслуживает один BD epic, но реализация и release выполняются короткими release slices.

Неизменяемые роли и модели

Этап	Trusted transport/profile	Модель	Effort
Conductor (writer)	Claude Code	активная модель	текущий
Cross-family design partner	codex-stage-review.mjs --profile design-partner	gpt-5.6-sol	medium
Phase plan review	--profile phase	gpt-5.5	medium
Simple Coach	--profile coach-simple	gpt-5.5	medium
Complex Coach	--profile coach-complex	gpt-5.6-sol	medium
Consolidated code review	--profile phase	gpt-5.5	medium

Все внешние профили работают read-only и не пишут файлы. Произвольный model/effort и high запрещены. При review_impasse effort не повышается.

GPT — primary cross-family adversarial partner на каждом semantic проходе. Поскольку writer всегда Claude, а reviewer всегда GPT, wrapper вычисляет cross_family — reviewer получает полный scope-aware мандат. Не подменяй внешний проход собственным рассуждением и не называй свой self-review внешним.

Окружение codex CLI

• Бинарник: /opt/homebrew/bin/codex (не в дефолтном PATH — всегда полный путь; wrapper использует его сам).
• Auth: OAuth ChatGPT в ~/.codex/auth.json.
• Recovery при «command not found» / битом симлинке: /opt/homebrew/bin/brew reinstall --cask codex (auth сохраняется), при протухшем OAuth — codex login.

Autonomy contract

Единственная штатная остановка владельца — утверждение завершённого design. До неё Conductor самостоятельно собирает Value Contract, product/UX/money/ legal/auth/release решения, Visual Design Pack и disclosure внешних advisor calls. Design approval одним пакетом подтверждает выбранный design и informed consent: точные destination/назначения, data scope, purpose/цель и risk/риск.

После утверждения design автономно выполняй plan, review, реализацию, Verify, push, production release и smoke без новых согласований, разрешений или вопросов. Не спрашивай отдельное или повторное согласие перед advisor, reviewer или Coach, если destination и scope уже раскрыты в утверждённом design. Технические failures, review findings и обратимые defaults решай сам.

Остановиться повторно можно только из-за новой материальной развилки вне design, расширения data scope, нового destination, необратимого действия или нового существенного money/legal/security риска. Сначала исчерпай безопасные варианты в утверждённой границе и задай владельцу один пакетный вопрос.

Каждое сообщение, после которого workflow реально ждёт владельца, заканчивай отдельным заметным блоком:

ЧТО НУЖНО ОТ ВАС ПРЯМО СЕЙЧАС
Действие: <одно конкретное действие: утвердить, разрешить, выбрать или предоставить>
Ответьте: <точный формат короткого ответа>
После ответа: <что Conductor немедленно продолжит>

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

ЧТО НУЖНО ОТ ВАС ПРЯМО СЕЙЧАС
Ничего — работа продолжается автономно.

Весь видимый владельцу текст — нарратив, промежуточные находки и релей ответов GPT — по-русски, а не только итоговое сообщение.

Phase -1: history, BD и memory

Сначала восстанови историю и не создавай дубликат. На этом этапе разрешено создать или найти только BD intake/epic; coordinator slot ещё не занимай:

bd search "ключевые слова задачи"
bd list --status open
bd list --status closed
bd show "UXI LM-похожая-задача"

Выполни quick pass по /Users/alexbut/.claude/projects/-Users-alexbut-Documents-GitHub-nosync-UXI-LM/memory/MEMORY.md; открой только прямо релевантные rollout/skill files. Memory — гипотеза, текущие Git/BD/runtime факты проверь заново.

Phase -0.5: Value Contract

До полного design зафиксируй в BD и dossier проверяемый Value Contract:

beneficiary:
evidence_source:
counterfactual_if_not_done:
success_signal:
review_at:
investment_cap:
value_lane:
decision:

beneficiary называет конкретного клиента, роль, внутреннего оператора либо систему. evidence_source содержит ссылки на тикеты, разговоры, измерения, incident/policy evidence или явно сформулированную стратегическую гипотезу. Расплывчатое «нужно пользователям» не является evidence. counterfactual_if_not_done описывает наблюдаемую цену бездействия, success_signal — проверяемый outcome, review_at — дату или slice milestone, а investment_cap — максимум slices и/или active wall-clock.

Допустимые value_lane:

• customer_demand;
• measured_problem;
• mandatory_risk;
• strategic_bet.

Выбери одно решение:

• PROCEED — named evidence оправдывает полный epic/design;
• EXPERIMENT — разрешён один минимальный проверяемый release slice, после которого работа останавливается до outcome evidence;
• DEFER — сохрани intake в BD, но не запускай coordinator или design;
• MANDATORY — только для mandatory_risk с конкретным security, compliance, reliability, incident либо data-integrity evidence.

Если evidence отсутствует, это не разрешает PROCEED: выбери EXPERIMENT с малой ставкой либо DEFER. Отсутствие конкретного клиента само по себе не блокирует mandatory_risk или проверяемый strategic_bet.

Если исходное требование уже содержит beneficiary, evidence и ожидаемый outcome, Conductor фиксирует их без повторного интервью. Иначе Conductor выбирает EXPERIMENT/DEFER либо включает обоснование PROCEED|MANDATORY в единый design owner gate. Value Contract не создаёт отдельную остановку.

Пометь BD intake/slice labels ship-slice, value-lane:<lane> и value-decision:<decision>, чтобы outcome и process calibration можно было связать с исходной ставкой.

Phase -0.25: coordinator

Только после PROCEED|MANDATORY либо для ограниченного EXPERIMENT создай отдельную BD child task на каждый release slice. Запускай slice через coordinator:

node scripts/ship/ship-coordinator.mjs start \
  --bd-id "UXI LM-abc.1" --slug "short-slice-slug" \
  --conductor claude --json

--conductor claude обязателен: он создаёт branch claude/ship/* от свежего origin/main, returned worktree и занимает один из семи slots. Все чтения, edits, tests, commits и review выполняй только в returned worktree. Проверь:

git rev-parse --show-toplevel
git branch --show-current
git status --short --branch
node scripts/ship/ship-coordinator.mjs status --json

Review wrapper принимает только coordinator namespaces claude/ship/* и codex/ship/*; ветка вне coordinator session блокирует любое внешнее ревью.

При resume прочитай BD, contract.md, state.md, decision-log.md и последний reviews/review-N.md. Dossier защищает workflow от компрессии контекста. Полный lifecycle и recovery: docs/runbooks/parallel-ship.md.

При resume повторно проверь Value Contract. Если investment cap исчерпан или review_at наступил без ожидаемого evidence, не продолжай следующий slice: вернись к value decision.

Phase 0: GPT co-design

Используй standalone brainstorming, но вторым пилотом запускай GPT-5.6-sol через tracked wrapper. GPT здесь не ревьюер, а равный со-конструктор: цель — через спор родить дизайн лучше, чем в одиночку.

До owner gate подготовь task-scoped informed consent для точных destination OpenAI Codex gpt-5.6-sol (design partner и complex Coach) и OpenAI Codex gpt-5.5 (plan/code review и simple Coach), data scope, purpose и risk disclosure. Включи его в единый design approval; после утверждения plan/code review и Coach в раскрытых границах стартуют автоматически. Передавай только committed tracked содержимое; secrets, PII и untracked files не передавай.

Consent-файл создавай с mode 0600:

umask 077 && cat > "$CONSENT" <<'JSON'
{
  "version": 1,
  "ownerApproved": true,
  "bdId": "UXI LM-abc.1",
  "destination": "OpenAI Codex gpt-5.6-sol",
  "dataScope": "Committed tracked repository code and project documents, excluding secrets and PII",
  "purpose": "Adversarial co-design of the approved slice",
  "riskDisclosure": "Private repository content is processed by an external OpenAI service",
  "approvedAt": "<ISO-8601 момента фактического approval>"
}
JSON

1. Ground: проверь execution path, tests, defaults, BD и прошлые решения. Дебат должен быть предметным, а не абстрактным.
2. Подготовь варианты, trade-offs, risks и проверяемые assumptions. В промпте первого раунда дай 2-3 конкретных предложения и явную инструкцию «спорь, дави на слабые места, предлагай альтернативы, которые я упустил; не соглашайся из вежливости».
3. Раунд 1 (stage=design, fresh SID) запрашивает adversarial counter-design.
4. Проверь каждое фактическое утверждение GPT по репозиторию. Прими бесспорное без спора, но пушбэкни там, где не согласен, приведя факт из кода.
5. Раунд 2 получает принятые/отклонённые аргументы и evidence, затем сводит варианты к consensus.

node scripts/ship/codex-stage-review.mjs \
  --stage design \
  --profile design-partner \
  --bd-id "UXI LM-abc.1" \
  --prompt-file "$PROMPT" \
  --consent-file "$CONSENT" \
  --output-file "$OUTPUT" \
  --decision-file "$DECISION" \
  --schema-file scripts/ship/codex-stage-review.schema.json \
  --worktree "$WORKTREE" \
  --writer-model "$ACTUAL_CONDUCTOR_MODEL" \
  --writer-reasoning "$ACTUAL_CONDUCTOR_REASONING"

--writer-model/--writer-reasoning — фактическая активная модель Claude и её текущий effort, не «желаемые» значения. Продолжение того же semantic дебата — --session-id "$SID" из предыдущего decision.json; GPT помнит весь тред и позже ревьюит план и код в контексте замысла.

Budget: design — два содержательных round. Третий допустим только при новом evidence, новой P0/P1 или материальной альтернативе. Смена request/SID не сбрасывает budget.

Деградация в self-design

Если GPT-партнёра физически не получить (отсутствующий или битый бинарник, launcher error, протухший OAuth, provider outage), сначала выполни один recovery-проход по разделу «Окружение codex CLI». Если он не помог, не останавливай workflow: перейди в self-design и зафиксируй:

requested_partner: gpt-5.6-sol
effective_partner: none (self-design)
design_independence: self_review
degradation_reason: <точная техническая причина и вывод команды>
recovery_attempted: <что именно попробовал>

Деградация разрешена только по валидированной технической причине. Неудобная критика, semantic disagreement, BLOCKED и завершённый semantic outcome техническим failure не являются — не превращай их в предлог остаться одному. В self-design мандат урезан: собственные возражения блокируют только contract violation, proven regression, security и data integrity с проверяемым evidence; maintainability и теория не блокируют. Раскрой деградацию владельцу в design gate и в финальном сообщении. При восстановлении codex до следующего внешнего прохода вернись на штатный путь.

Canonical design

После consensus запиши canonical design, включая:

chosen_design:
rejected_alternatives:
assumptions_and_evidence:
risks_and_mitigations:
test_strategy:
release_slices:
owner_decisions:
gpt_rounds:
degradation_rounds:
visual_design_pack:
visual_coverage_matrix:

Visual Design Pack

После consensus и до owner gate, до перехода к implementation plan, подготовь Visual Design Pack — один или несколько согласованных визуальных артефактов, которые раскрывают весь выбранный design:

• архитектурная карта компонентов, контекстов, external systems, data/control flow и trust boundary — всегда, с подробностью по scope;
• пользовательский flow; при async/queue/roles/transitions также sequence diagram и state/состояния;
• при любом user-facing изменении — UI before/after или wireframe, визуальная иерархия и применимые interaction states (default/loading/empty/error/ success/disabled/permission); для разных экранов — несколько кадров или storyboard;
• при data/security/integration risk — ownership boundaries, side effects, fail-closed, rollback и observability.

Для простой структуры используй Mermaid. Для UI, сложных пересекающихся связей, слоёв или интерактивности используй инлайн-визуализацию Claude (mcp__visualize__show_widget) либо опубликованный Artifact. Один pack может сочетать Mermaid, блок-схему и отдельный инлайн UI-макет. Подбирай артефакты по scope и не создавай нерелевантные визуалы ради количества.

Качество и язык обязательны:

• русский язык — по умолчанию для заголовков, узлов, стрелок, условий, действий и легенды; технический термин давай вторым в скобках, например Проверка перед публикацией (preflight);
• расшифровывай каждый статус, сокращение и аббревиатуру при первом появлении; внутренние функции/поля оставляй только когда они влияют на owner decision;
• основной пользовательский путь сделай визуально главным и пронумеруй шаги; побочные ветки привязывай к конкретной развилке;
• добавь компактную легенду; успех, ошибка/блокировка и нейтральный переход различай также подписью и формой/линией — цвет не единственный носитель смысла;
• используй иерархию и группировку, минимизируй пересечения линий и не смешивай служебные статусы с пользовательскими действиями;
• под или сразу после схемы дай краткое пояснение: основной сценарий, точка решения и видимый пользователю результат;
• проверь понятность: нетехнический читатель без знания кода должен суметь пересказать основной сценарий, каждую развилку и итог.

Обязателен результат, а не тип, формат или шаблон: Visual Design Pack должен полно, понятно и честно передать canonical design. Conductor свободно выбирает и комбинирует формы представления под конкретный design. Допустимы новые, другие и нестандартные визуальные формы, если они объясняют решение лучше.

Следующий список — не исчерпывающие примеры и эвристики, а не обязательное соответствие «вопрос → формат»:

• пороги, режимы, уровни и trade-offs — интерактивный исследователь с ползунком/переключателем либо напрямую подписанное сравнение;
• жизненный цикл сущности — машина состояний (state machine), включая тупики, retry и условия освобождения ресурсов;
• ветвление «если X, то Y» — дерево решений (decision tree) с видимыми исходами и действиями;
• UI/интерфейс — реалистичный макет (mockup), before/after или storyboard со всеми применимыми состояниями;
• хронология, роли, async и очереди — sequence diagram или временная шкала (timeline) с ожиданиями и ответственностью.

Интерактивность используй, только когда она помогает исследовать параметры, сравнивать сценарии или меняет понимание решения. Первый кадр должен быть полезным и понятным без взаимодействия. Все числа и значения бери из canonical design, evidence или проверенных доказательств; не выдумывай их ради демонстрации. Визуализация — тест на завершённость design: если состояния, переходы или исходы нельзя показать без догадок, вернись к design и закрой пробел до owner gate.

Закрой visual coverage matrix:

material_aspect -> visual_artifact -> states/boundaries_shown -> owner_decision

Все материальные части или аспекты design должны быть покрыты либо отмечены text-only с причиной. При недоступном renderer используй Mermaid, ASCII wireframe или статический HTML/SVG; renderer failure не разрешает пропустить pack.

Текстовый design остаётся canonical source of truth. Visual Design Pack не добавляет скрытых решений и не заменяет evidence, risks, tests или owner decisions. Не превращай его в implementation plan, release batches, task list или status.

Покажи владельцу текстовый design, Visual Design Pack, coverage matrix и все решения одним пакетом. Не начинай реализацию до явного утверждения.

Project skills gate

Skill-контуры обоих семейств проверяются тестами. До implementation/resume и повторно перед local-only release выполни:

node --test scripts/ship/__tests__/project-codex-skills.test.mjs
node --test scripts/ship/__tests__/ship-skills-contract.test.mjs

scripts/ship/project-codex-skills.json — точный source of truth для проектных Codex skills: физический набор .agents/skills/* должен совпадать с manifest, каждый skill — быть tracked и не ignored, а claude-mirror — байт-в-байт совпадать с источником. Missing skill, лишний каталог, ignore/untracked drift, небезопасный artifact или mirror drift блокируют Ship. Тесты обязаны пройти в fresh worktree от committed HEAD.

Phase 1: release map и slice contract

Epic — architecture roadmap, а не единица release. Разрежь реализацию на deployable, dark-deployable или явно local-only slices. Один slice включает не больше трёх G3 batches:

slice_id:
included_bd_tasks:
depends_on_slices:
value_contract_ref:
runtime_mode: active | canary | compat | dark | local-only
tier:
tier_triggers:
coach_profile_reason:
migration_strategy:
feature_flag:
acceptance_criteria:
rollback:
production_smoke:
max_g3_batches: 3

Граница выбирается по deployability и зависимостям, а не механически по каждой BD child. Если во время работы появился четвёртый batch, доведи текущий slice до ближайшего безопасного deployable/dark-deployable состояния и сделай re-slice: остаток получает новую BD child и новый worktree от обновлённого main.

Tier выбирай по правилу минимально достаточный Tier (lowest sufficient Tier). В contract обязательно запиши tier_triggers и coach_profile_reason; одного субъективного «задача сложная» недостаточно. Неясный scope не повышает Tier автоматически: создай bounded discovery slice, получи evidence и только затем классифицируй implementation slice. Полная матрица triggers находится в ship-claude-max-orchestrate.

Phase 2: входной baseline

До первого feature commit на exact base SHA отдельно запиши:

• targeted tests;
• full Vitest;
• tsc --noEmit;
• Next build;
• ESLint.

Green build не означает green TypeScript. Non-trivial Tier 1/2 не начинается при неожиданно красном baseline. Если известный baseline пока не погашен, сначала получи полный machine-readable capture без pipe/tail:

node scripts/ship/tsc-baseline-capture.mjs \
  --worktree "$WORKTREE" --project frontend/tsconfig.json \
  --base-sha "$BASE_SHA" --generated-policy reject \
  --output "$CAPTURE"

--generated-policy reject fail-closed останавливает capture при diagnostics из .next. include допустим только как явное решение после детерминированной регенерации Next types; режима exclude нет, generated diagnostics нельзя молча терять. Capture сам запускает direct tsc --noEmit --pretty false, требует clean tracked worktree, фиксирует exact SHA, версию TypeScript и отдельные source/generated counts.

Известный долг разрешён только через versioned set-based manifest, проверяемый scripts/ship/baseline-diff.mjs: сравниваются fingerprint sets, не counts. Каждый allowance содержит BD bug id, expiry и captured base SHA. Gate сам выполняет live bd show <id> --json, требует matching issue со status open и не доверяет сохранённому в manifest bd_status. unexpected = current - allowed блокирует; resolved = allowed - current требует очистки manifest. Build failure и security P0 нельзя waive.

Phase 3: plan и GPT-5.5/medium review

Используй writing-plans. Plan содержит paths, TDD steps, AC, gates, migration, rollback, monitoring и release slice mapping. Зафиксируй design/plan targeted commit без push.

Перед внешним ревью быстро заземли ключевые допущения плана против реального кода (существуют ли функции/поля/экспорты, nullable-семантика, точки вставки) — это ловит явные мисматчи до траты токенов reviewer.

Plan review запускай через codex-stage-review.mjs:

node scripts/ship/codex-stage-review.mjs \
  --stage plan --profile phase \
  --writer-model "$ACTUAL_WRITER_MODEL" \
  --writer-reasoning "$ACTUAL_WRITER_REASONING" \
  --bd-id "$BD_ID" --prompt-file "$PROMPT" \
  --consent-file "$CONSENT" --output-file "$OUTPUT" \
  --decision-file "$DECISION" \
  --schema-file scripts/ship/codex-stage-review.schema.json \
  --worktree "$WORKTREE"

Используй task-scoped informed consent из утверждённого design для точного destination OpenAI Codex gpt-5.5, data scope, purpose и risk disclosure; не запрашивай его повторно. Private files имеют mode 0600. Wrapper проверяет coordinator BD/worktree match, пишет consentSha256, actual writer/reviewer metadata и вычисленный independence.

Plan budget: два обычных round плюс один evidence-only round. Новый SID, writer, re-ground или compaction budget не сбрасывает. Если APPROVE не получен, вернись к design/re-slice; не продолжай бесконечно.

Token-эконом главного контекста: не затаскивай полный план или design-doc в главный контекст — reviewer читает файл по пути сам. Рутинное заземление (широкий grep «есть ли X», «где вызывается Y») отдавай Explore-субагенту. В главном контексте держи только глубокое чтение: money-path, тонкая логика, разбор бага.

Scope-aware findings и independence

Finding обязана иметь severity, origin, impact, disposition и blocking_evidence. Правила:

• introduced|exposed P0/P1 → fix_now;
• pre_existing|out_of_scope → bd_followup, если diff не ухудшает дефект;
• старый security/data-integrity P0 может блокировать release;
• maintainability без доказанного failure path — максимум P2;
• APPROVE с P2/P3 или pre-existing P1 follow-up допустим;
• REQUEST_CHANGES требует evidence-backed blocking fix_now.

Wrapper вычисляет independence, reviewer не объявляет её сам:

cross_family
cross_model
same_model_different_effort
self_review

При штатном пути Claude-writer и GPT-reviewer дают cross_family — полный scope-aware мандат. self_review возникает только в деградации из Phase 0 и блокирует лишь contract violation, proven regression, security или data integrity с проверяемым evidence. Если wrapper вернул независимость слабее cross_family, не выдавай проход за внешний: запиши фактический уровень.

Route proof: независимость доказывается, а не заявляется

Independence считается от МОДЕЛИ, которая реально вела ход, а не от той, что запрошена флагом. Wrapper наблюдает её в rollout-записи сессии codex (turn_context: model, effort, sandbox, cwd) и пишет в decision:

routeProof.status: verified | route_mismatch | unverified
independenceEvidence: observed | requested
routeAssurance: verified | waived

Читай это как факт, а не как формальность:

• verified — заявка и наблюдение совпали, уровень независимости доказан;
• route_mismatch — ревьюила другая модель или другое усилие. Independence уже понижена до фактической; терминальное одобрение на таком маршруте не принимается никогда;
• unverified — телеметрии нет. Терминальное одобрение блокируется, пока причина не устранена.

Наблюдённый sandbox не read-only или cwd вне coordinator worktree — жёсткий отказ: ревью шло не там, где заявлено.

Когда rollout действительно недоступен (другой CODEX_HOME, смена формата в новой версии CLI), одобрение можно провести под явным waiver:

--allow-unproven-route "codex rollout telemetry unavailable: <причина>"

Waiver попадает в decision (routeAssurance: waived, routeWaiverReason) и обязан быть раскрыт владельцу в статусе того же слайса. route_mismatch waiver не покрывает. Молча оформлять waiver, чтобы не чинить телеметрию, нельзя.

INCONCLUSIVE: несостоявшееся ревью не равно пройденному

Если прогон ревью сорвался — CLI упал, ответ не разобран, контракт finding нарушен, маршрут не доказан — wrapper всё равно оставляет артефакт:

terminal: INCONCLUSIVE
inconclusiveReason: <точная причина>

Это не APPROVE и не «ревью не нашло проблем». Допустимо: повторить раунд с новым SID в пределах бюджета стадии либо остановиться и показать владельцу причину. Недопустимо: идти дальше, пересказав падение как чистое ревью, или не упомянуть его в статусе. INCONCLUSIVE-раунды тратят тот же бюджет, что и обычные. Инварианты ДО запуска (consent, coordinator session, приватность файлов) остаются жёстким отказом без артефакта — их не «повторяют», а чинят.

Попутно найденные баги

Не расширяй scope молча. Любой подтверждённый или предполагаемый дефект, найденный помимо основной задачи, сразу внеси в Review Ledger и показывай в каждом существенном status/final сообщении отдельным блоком:

ДОПОЛНИТЕЛЬНО НАЙДЕННЫЕ БАГИ
- <краткое название>
  связь с основной задачей: introduced | exposed | pre_existing | out_of_scope
  evidence/доказательство:
  severity:
  disposition: fix_now_same_slice | bd_followup | release_blocker | not_a_bug
  BD ID: <id или n/a с причиной>
  исправлено: yes | no
  блокирует текущий release: yes | no

Disposition выбирай детерминированно:

• fix_now_same_slice — только introduced регрессия текущего diff либо небольшой exposed дефект, без исправления которого не выполняются acceptance criteria/AC или безопасный release. Исправляй в той же сессии, проходи RED-GREEN и включай в общий review.
• bd_followup — pre_existing или out_of_scope дефект, который текущий diff не ухудшает. Немедленно создай отдельную BD-задачу с evidence, severity, затронутыми путями и связью с текущим epic; текущий release не расширяй.
• release_blocker — доказанный P0/P1 security, data-integrity, destructive migration либо baseline failure, из-за которого текущий diff нельзя безопасно выпустить. Останови release, но сначала зафиксируй BD ID и конкретное действие в блоке владельца.
• not_a_bug — гипотеза не воспроизвелась или это ожидаемое поведение. Зафиксируй проверенное evidence; BD-задачу не создавай.

Если найденный дефект требует новой продуктовой логики, нового UI или существенно увеличивает release slice, это bd_followup, а не повод незаметно дописать фичу. Владелец не обязан выбирать disposition: Conductor делает это по evidence. Отдельное решение владельца нужно только если дефект стал release_blocker и безопасные варианты требуют материальной развилки.

Если реестр пуст, явно напиши:

ДОПОЛНИТЕЛЬНО НАЙДЕННЫЕ БАГИ
Багов дополнительно не найдено.

Review Ledger

Каждый fresh reviewer получает compact Review Ledger, а не самоотчёт Player:

accepted_invariants:
rejected_arguments:
resolved_findings:
deferred_findings:
evidence_already_checked:
current_slice_boundaries:
review_counts:
  consecutive_self_review_batches:
timing:
  active_wall_clock_ms:
  external_idle_ms:
  external_idle_reasons:
    machine_sleep_ms:
    owner_approval_ms:
    rate_limit_ms:
    provider_outage_ms:

Ledger не даёт заново открыть решённую finding без нового evidence и хранит счётчики независимо от SID/re-ground. Если начинается третий подряд batch с self_review, закрой текущий slice на ближайшем безопасном deployable состоянии и вернись в top-level для re-slice; продолжать третий self-review batch нельзя. active_wall_clock_ms не включает external_idle_ms; сумма external reasons обязана совпадать с external idle total.

Phase 4: G3 implementation

Используй .claude/skills/ship-claude-max-orchestrate. Он выполняет Strategy -> Player -> Verify -> Coach, TDD, build leases, hard batch/review budgets и committed dossier. Он не интегрирует и не deploy-ит.

Phase 5: consolidated code review

После локальных gates запусти stage=code --profile phase на полном committed base..target diff. Передай design, plan, AC, Review Ledger и verification evidence; reviewer сам выполняет git diff в read-only worktree — не затаскивай изменённые файлы целиком в главный контекст ради ревью. REQUEST_CHANGES исправляй через RED-GREEN-REFACTOR и повторный Verify. Code budget общий с batch: максимум три REQUEST_CHANGES. Четвёртый создаёт review_impasse: STOP edits, сохранить evidence и re-slice либо вернуться в design. high не включать.

Reviewer в read-only sandbox может не запустить vitest (fnm symlink permission). Тесты гоняешь ты независимо в Verify; reviewer только читает дифф.

Phase 6: serialized exact-SHA release

Входи только при scope-aware APPROVE, green expected gates, committed target и отсутствии новой owner decision.

APPROVE относится к конкретному дереву, а не к ветке вообще. Перед входом сверь дерево из code-review решения с текущим:

git rev-parse HEAD^{tree}   # обязано совпасть с decision.candidate.tree

Расхождение — stale review: дифф изменился после ревью. Тогда сначала повторный consolidated code review на актуальном дереве, и только потом release. Integration lock покрывает:

rebase -> fresh verify -> bd sync -> push -> deploy/smoke or no-deploy

node scripts/ship/ship-coordinator.mjs lock acquire \
  --bd-id "UXI LM-abc.1" --json

Обязательно:

• heartbeat rebasing до rebase и зафиксировать integration base;
• full build только с build resource lease, bd sync — с его lease;
• targeted git add, secret scan, никогда git add ./git add -A; не трогать docs/hermes-prompts/;
• git push origin HEAD:main, без force;
• runtime: ./vps_atomic_deploy.sh --expected-sha "<sha>", health, site smoke, затронутые endpoints, production HEAD, затем smoke --sha;
• только для verified local workflow: no-deploy --sha --reason;
• post-push uncertainty → recovery-required, затем lock resume;
• fresh origin/main, pushed SHA и production HEAD должны совпадать.

Миграции БД выполняй вручную на проде до кода, при race-риске — второй backfill. Тяжёлые прод-проверки (дамп БД, объёмный лог-греп) отдавай субагенту, а не тащи сырой дамп в главный контекст.

no-deploy не является ручным обходом deploy: coordinator сам проверяет все изменения сессии от зафиксированного integration base до exact pushed SHA. Разрешённые local workflow пути: .agents/, .codex/, .claude/skills/, docs/, scripts/ship/, scripts/claude-review/, точно .github/workflows/claude-ship-review.yml, .github/workflows/claude-ship-review-intake.yml, .gitignore, AGENTS.md, CLAUDE.md. Любой смешанный/runtime diff отклоняется, --reason обязателен.

Recovery

Если owner-чат потерян, новая сессия сначала запускает status и doctor, проверяет тот же BD id и перевыпускает приватный token без смены phase:

node scripts/ship/ship-coordinator.mjs lock resume \
  --bd-id "UXI LM-abc.1" --json

lock resume не может забрать lock другой BD-задачи. Для recovery-required до первого heartbeat обязательно проверить production. Потерянный build/BD-sync token восстанавливается через:

node scripts/ship/ship-coordinator.mjs resource resume \
  --name build --bd-id "UXI LM-abc.1" --json

doctor показывает leases и pending starts без token. Повторный start восстанавливает прерванный start только при мёртвом записанном PID и точном совпадении BD/branch/worktree; вручную такой worktree не удалять. finish --bd-id запрещено форсировать: dirty/unmerged/unverified worktree сохраняется.

До закрытия исходного BD child выполни scheduling-часть Phase 7: создай положенный Value review и при необходимости process-calibration task. Затем обнови/закрой BD child, синхронизируй и выполни:

node scripts/ship/ship-coordinator.mjs finish \
  --bd-id "UXI LM-abc.1" --delete-remote --json

Следующий slice запускается новым coordinator session от обновлённого main. Задача не завершена до exact-SHA release evidence и coordinator finish.

Финальное сообщение начинается с одного недвусмысленного статуса:

ГОТОВО И ВЫЛОЖЕНО НА PRODUCTION
production_sha:
production_smoke_status:
owner_action_required: none

Для local-only/no-deploy либо незавершённого релиза используй:

НЕ ВЫЛОЖЕНО НА PRODUCTION
reason:
pushed_sha:
production_sha: n/a
production_smoke_status: not_run
owner_action_required:

Не пиши расплывчатое «готово», если push, deploy, exact production SHA или smoke не подтверждены. После заголовка кратко перечисли, что изменилось, какие gates прошли и требуется ли действие владельца. Затем повтори человеческим языком блок ЧТО НУЖНО ОТ ВАС ПРЯМО СЕЙЧАС: одно конкретное действие и формат ответа либо Ничего — работа продолжается автономно. / Ничего — задача завершена.. Перед owner-action обязательно покажи актуальный блок ДОПОЛНИТЕЛЬНО НАЙДЕННЫЕ БАГИ, включая созданные BD ID и отметку, что уже исправлено в текущем slice. Если design проходил в деградации, повтори это в финальном сообщении.

Phase 7: outcome и process feedback loops

Release evidence отвечает «доставлено ли», но не «дало ли ценность». Для active|canary|dark product release после successful coordinator evidence создай под исходным epic BD child Value review YYYY-MM-DD с датой через 30 дней, priority P2/P3 и labels value-review, not-before:YYYY-MM-DD. Перенеси в него beneficiary, исходный success_signal, release SHA и нужные telemetry/interview evidence.

В дату review прочитай фактический сигнал и закрой задачу ровно одним outcome:

EXPAND | KEEP | REVISE | RETIRE

EXPAND разрешает следующую инвестицию, KEEP сохраняет текущий scope, REVISE требует нового Value Contract, RETIRE останавливает дальнейшую работу и при необходимости создаёт rollback/cleanup slice. Не закрывай review описанием «метрики собраны» без decision.

Process-метрики также имеют петлю. После каждых пяти завершённых ship-slice после последней calibration создай BD task Ship process calibration. Агрегируй минимум:

active_wall_clock_ms
external_idle_ms
review rounds
re-slices
value outcomes
degradation rounds

Сравни медианы и распределение по Tier/value lane. Меняй budgets, routing или Tier defaults по серии slices, а не по одному выбросу. Local-only workflow slice без продуктового outcome всё равно входит в process calibration, но не создаёт искусственный customer Value review.

Memory Curator

После release передай только повторяемые или архитектурные lessons. Не редактируй MEMORY.md напрямую без matching evidence и явного owner request на обновление памяти; не сохраняй эфемерные SHA/logs/secrets/PII.

Guardrails

• Advisor/Coach не пишет файлы и не управляет Git/BD/release.
• Не выдавай собственное рассуждение за внешний cross-family проход.
• BLOCKED и REQUEST_CHANGES не являются approval.
• Не держи integration lock во время review, edits или ожидания owner.
• Не обновляй baseline allowlist автоматически.
• Не закрывай synthetic external-provider canary без реального второго клиентского аккаунта.
• Не запускай этот skill в основном worktree main.