Ship codex max

Ship Codex Max v2.1

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

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

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

Этап	Trusted transport/profile	Модель	Effort
Conductor	Codex App	активная модель	текущий
Cross-family design partner	scripts/claude-review/run-stage-review.mjs	exact claude-opus-4-8	provider-managed
Design technical fallback	codex-stage-review.mjs --profile design-fallback	gpt-5.5	medium
Phase plan review	codex-stage-review.mjs --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

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

Claude Code — primary cross-family adversarial design partner. Не называй внутренний Sol заменой Claude. Только валидированный технический Claude BLOCKED (helper exit 5 и decision verified_technical_blocked) разрешает перейти на bounded design-fallback через GPT-5.5 внутри Codex. Этот fallback не является Claude co-design и не получает cross-family мандат автоматически.

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 не остановлен, явно напиши:

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

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 по memory_summary.md и /Users/alexbut/.codex/memories/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 codex --json

Coordinator создаёт branch codex/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

При 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: Claude co-design

Используй standalone brainstorming, но вторым пилотом запускай Claude Code через trusted GitHub helper из docs/claude-github-reviewer-protocol.md. Standing owner consent этого протокола покрывает committed read-only snapshot; secrets, PII и untracked files не передавай.

До owner gate подготовь task-scoped informed consent для точного destination OpenAI Codex gpt-5.5, data scope, design-review purpose и risk disclosure. Включи его в единый design approval; после утверждения разрешённый fallback, plan/code review и Coach в раскрытых границах стартуют автоматически.

1. Ground: проверь execution path, tests, defaults, BD и прошлые решения.
2. Подготовь варианты, trade-offs, risks и проверяемые assumptions.
3. Claude round 1 (kind=design) запрашивает adversarial counter-design.
4. Проверь каждое фактическое утверждение Claude по репозиторию.
5. Claude round 2 получает принятые/отклонённые аргументы и evidence, затем сводит варианты к consensus.

Для каждого semantic round сначала вызывай Claude. Fallback запускается только когда tracked helper фактически вернул exit 5, а его decision подтверждает verified_technical_blocked и review_status=skipped_technical. Тогда:

1. сохрани Claude decision/attestation в Review Ledger;
2. собери design prompt с теми же grounded facts, номером semantic round и проверенным evidence;
3. вызови новый Codex request без --session-id, то есть с fresh SID:

node scripts/ship/codex-stage-review.mjs \
  --stage design \
  --profile design-fallback \
  --bd-id "UXI LM-abc" \
  --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"

policy-block запрещает fallback и любой transport hopping. integrity failure, unknown exit/model mismatch и semantic disagreement или завершённый semantic outcome также не запускают fallback. Не превращай неудобную критику в transport failure.

Запиши фактический переход:

requested_partner: claude-opus-4-8
effective_partner: gpt-5.5
effective_profile: design-fallback
claude_review_status: skipped_technical
claude_decision_evidence:
fallback_reason: verified_technical_blocked
fallback_sid:
independence:

independence вычисляет wrapper из actual writer/reviewer metadata. GPT-5.5 не называй Claude или cross-family: фактический уровень может быть cross_model, same_model_different_effort либо self_review. Если GPT-5.5 fallback завершился техническим failure/сбоем, зафиксируй обе причины и останови design; не повышай effort и не запускай скрытую третью модель.

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

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

chosen_design:
rejected_alternatives:
assumptions_and_evidence:
risks_and_mitigations:
test_strategy:
release_slices:
owner_decisions:
claude_rounds:
fallback_rounds:
visual_design_pack:
visual_coverage_matrix:

После 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, сложных пересекающихся связей, слоёв или интерактивности используй bundled visualize с inline artifact через ::codex-inline-vis. Один pack может сочетать Mermaid, блок-схему и отдельный inline 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 с причиной. При недоступном inline 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

scripts/ship/project-codex-skills.json — точный source of truth для проектных Codex skills. До implementation/resume и повторно перед local-only release выполни:

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

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

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-codex-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.

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; не продолжай бесконечно.

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.

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

Не расширяй 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 и безопасные варианты требуют материальной развилки.

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

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

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

cross_family
cross_model
same_model_different_effort
self_review

cross_family|cross_model имеют полный scope-aware мандат. same_model_different_effort не блокирует по maintainability/теории. self_review блокирует только contract violation, proven regression, security или data integrity с проверяемым evidence.

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

Уровень независимости считается от МОДЕЛИ, которая реально вела ход, а не от запрошенной флагом. 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 действительно недоступен, одобрение проводится под явным waiver --allow-unproven-route "<причина>". Он попадает в decision (routeAssurance: waived, routeWaiverReason) и обязан быть раскрыт владельцу в статусе того же слайса; route_mismatch waiver не покрывает.

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

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

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

Используй .agents/skills/ship-codex-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. REQUEST_CHANGES исправляй через RED-GREEN-REFACTOR и повторный Verify. Code budget общий с batch: максимум три REQUEST_CHANGES. Четвёртый создаёт review_impasse: STOP edits, сохранить evidence и re-slice либо вернуться в design. high не включать.

Phase 6: serialized exact-SHA release

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

APPROVE относится к конкретному дереву, а не к ветке вообще. Перед входом сверь git rev-parse HEAD^{tree} с decision.candidate.tree из code-review решения. Расхождение — stale review: дифф изменился после ревью, нужен повторный consolidated code review на актуальном дереве, а не release. Integration lock покрывает:

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

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

• heartbeat rebasing до rebase и зафиксировать integration base;
• full build только с build resource lease, bd sync — с его lease;
• targeted git add, secret scan, никогда git add ./git add -A;
• 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 должны совпадать.

До закрытия исходного 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.

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

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

Memory Curator

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

Guardrails

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