Files
selfpost/docs/progress.md
T
mix c8abec376a docs: document /data/setup-token and close phase 14
14.C needed no code: the setup link is already mirrored to /data/setup-token
at 0600 and removed once setup completes. What was missing is the reason to
prefer it — a deployment whose container logs ship to a central aggregator
otherwise leaves a live bearer token in that pipeline for ten minutes, and in
whatever retains it afterwards.

The reverse-proxy section gains the one requirement 14.A introduces: pass the
original Host header through. Everything else about security stays the
proxy's non-problem, which is the point of emitting the headers from the
panel.

Phase 14 leaves the plan (the file describes only unfinished work), but its
section A keeps what was deliberately left open: the accepted risk for clients
sending neither Sec-Fetch-Site nor Origin, the decision not to add
session-bound CSRF tokens and what would justify revisiting it, and the fact
that XSS inside the panel's own origin is answered by html/template and the
CSP rather than by either of those.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 23:02:26 +03:00

5.9 KiB
Raw Blame History

Прогресс реализации SelfPost

Живой трекер состояния. Переживает /clear — читается первым при возобновлении работы. План (открытые вопросы + опциональные фазы): implementation-plan.md. ТЗ: specification.md. История релизов: CHANGELOG.md. История сделанного по фазам (0→13, все закрыты) — в git log и в CHANGELOG, здесь не дублируется.

Как возобновить после сброса контекста

  1. Прочитать этот файл (текущее состояние, что дальше).
  2. Открыть implementation-plan.md — там нерешённые вопросы, принятые риски и опциональная линия 2.x.x (Фаза O1+).
  3. При необходимости — детали в specification.md.
  4. Продолжить с пункта «Следующий шаг».

Модель по типу работы

Правило: безопасность / инфра / риск-критичное → Opus; UI / документация / бойлерплейт → Sonnet; тривиальная механика → Haiku.

Коммиты

Коммит на каждом осмысленном шаге (не каждое сохранение файла, но и не только конец фазы): рабочий под-функционал, зелёная сборка, конец фазы. Минимум — один коммит на закрытую фазу + промежуточные на связные под-шаги. Ветка main (если пользователь не попросит отдельную). Push/PR — только по явной команде. Сообщение коммита завершается трейлером Co-Authored-By: Claude <модель> <noreply@anthropic.com> — с той моделью, которая этот шаг делала (на момент Фазы 14 — Claude Opus 5).

На каждом таком шаге — запись в CHANGELOG.md под [Unreleased] (формат Keep a Changelog). При явном решении зарезать версию — секция [Unreleased] переименовывается в [X.Y.Z] - дата, заводится новая пустая [Unreleased]. Тег/пуш образа — только по явному запросу (см. workflow release.yml).

Протокол закрытия фазы/крупного шага

Перед /clear в конце каждого законченного шага Claude:

  1. Обновляет этот файл: «Текущее состояние» → что изменилось, что дальше.
  2. Проверяет применимые критерии «Готово, когда…».
  3. Дописывает CHANGELOG.md под [Unreleased].
  4. Делает финальный коммит шага.

Текущее состояние

  • Выполнено и принято: базовый линейный план 0→11 (v1.0; аудит безопасности ТЗ 7.6 — полное соответствие), Фаза 12 (UI/UX), Фаза 13 (страница /status, DNS-проверки домена) и Фаза 14 (security-заголовки, проверка origin, cookie __Host- + обнаружение дублей, документация про /data/setup-token). Что именно сделано — в git log и CHANGELOG.md, здесь не дублируется.
  • Дальше — то, что перечислено в implementation-plan.md: открытые вопросы разделов B–D (надёжность и эксплуатация, e2e в CI, указатель на объём 2.x) и принятые риски раздела A (POST без Sec-Fetch-Site/Origin пропускается, токенов нет); опциональная Фаза O1+ (входящий релей, линия 2.x.x, требует согласования).
  • Прод: selfpost.mixfed.ru, реальный Let's Encrypt сертификат, живой e2e (DKIM/SPF pass). Контейнер там всё ещё на образе v1.0 — Фаза 14 в него не выкатывалась. При апгрейде: админа один раз разлогинит (сменилось имя cookie), а от reverse-proxy требуется передача исходного Host (Apache-фрагмент из deploy/ это делает).

Рабочая петля (dev loop) — ВАЖНО

Локально (Windows, D:\Local\Git\selfpost) нет Go и Docker — только редактирование и git. Вся сборка/тесты идут на dev-сервере selfpost.mixfed.ru (Debian 12 bookworm, тот же, что базовый образ; провижён под разработку). Цикл: править локально → залить дерево на сервер → go build/go vet/docker build/тесты там. rsync в локальном git-bash нет, поэтому дерево едет tar'ом по ssh: tar -czf - --exclude=.git . | ssh root@selfpost.mixfed.ru 'rm -rf /root/selfpost-src && mkdir -p /root/selfpost-src && tar -xzf - -C /root/selfpost-src'; Go на сервере — в /usr/local/go/bin (не в PATH по умолчанию); образ — docker build -f build/Dockerfile -t selfpost:dev --build-arg VERSION=dev .. Источник истины и git-история — локальный репозиторий; сервер — только исполнитель сборки/тестов. Подключение: ssh root@selfpost.mixfed.ru (по ключу).