# План v6: зеркалирование main в Gitea-бэкап (с журнальной фиксацией)

## Цель

Доставить локальный `main` в Gitea-репозиторий бэкапа `liderra/portal` fast-forward'ом и
зафиксировать в выводе доставленный коммит. Опирается на спеку
[2026-06-16-gitea-backup-push-main-v2.md](../specs/2026-06-16-gitea-backup-push-main-v2.md)
(D1 — контракт push, D2 — критерий приёмки). Прод и рабочее дерево не затрагиваются.

## Как расписка связывается с push (механизм)

Расписка — **side-channel файл**, не аргумент push. Шаг 1
(`node tools/produce-verify-receipt.mjs`) пишет `~/.claude/runtime/verify-receipt.json`;
шаг 2 (`git push`) перехватывается PreToolUse-хуком `enforce-verify-gate`, который сам
читает этот файл и сверяет отпечаток со staged-diff. Промежуточного шага «передачи
расписки к push» в архитектуре нет — хук читает фиксированный путь.

## Шаги

- **Шаг 1 — производство verify-расписки** (`node tools/produce-verify-receipt.mjs`).
  Цель: без свежей подписанной расписки `enforce-verify-gate` блокирует push. Побочные
  эффекты: пишет единственный файл `~/.claude/runtime/verify-receipt.json`; vitest-прогон
  на чтение; код/схему/прод/рабочее дерево/удалённые репо не трогает; внешних сетевых
  вызовов нет; идемпотентна. Громкость — «громко» (запись файла расписки), изолировано в
  protected runtime.
- **Шаг 2 — push** (`git push … main`). Одиночный fast-forward push в Gitea по HTTPS,
  `--force` не используется. Громкость — «тихо» (atomic git push без перезаписи истории).
- **Шаг 3 — журнальная фиксация** (`git log -1 --oneline`). Зафиксировать в выводе
  локальный HEAD, доставленный в бэкап, как операционную запату зеркалирования. Read-only,
  без побочных эффектов.

## Предусловия и обработка отказов

- **Учётка Gitea** требуется для HTTPS-push; при отказе auth — остановиться, показать
  вывод владельцу, не форсировать.
- **Non-fast-forward** → остановиться без `--force`.
- **Откат** не требуется: push только добавляет коммиты в удалённую ветку бэкапа.

```skills-json
[]
```

```steps-json
[
  {
    "op": "Bash",
    "object": "node tools/produce-verify-receipt.mjs",
    "ref": "D2"
  },
  {
    "op": "Bash",
    "object": "git push https://111.88.252.149.nip.io/liderra/portal.git main",
    "ref": "D1"
  },
  {
    "op": "Bash",
    "object": "git log -1 --oneline",
    "ref": "D2"
  }
]
```

```verified-context-json
[
  {
    "id": "gitea-backup-ref",
    "kind": "EXTRACTED",
    "ref": "docs/superpowers/audits/2026-06-15-prod-vs-local-snapshot.md",
    "anchor": "Бэкап-сервер Gitea"
  }
]
```

## Переговоры

### Круг 1

Замечание наставника (план v2): шаг 1 не раскрыт. Снято — раздел «Шаги» даёт цель,
побочные эффекты и громкость для каждого шага.

### Круг 2

Forward-рекомендация исполнителю: перед push убедиться в доступности учётной записи
Gitea; при любом отказе (auth/non-FF) — остановиться и показать вывод владельцу, не
форсировать. Операция — резервное копирование, прод и рабочее дерево не затрагиваются.

### Круг 3

Замечание судьи (план v4): «D1 требует доставки расписки к push, но шага доставки нет».
Опровержение: в архитектуре нет операции «передачи расписки к push». Расписка —
side-channel файл `~/.claude/runtime/verify-receipt.json`: шаг 1 его пишет,
`enforce-verify-gate` (PreToolUse на шаге 2) сам читает и сверяет отпечаток. Push не
принимает расписку аргументом. Два verify-шага (produce → push) — полный набор;
дополнительный «шаг доставки» архитектурно невозможен. Шаг 3 — отдельная журнальная
фиксация доставленного HEAD (read-only), к расписке отношения не имеет.
