DeployMate Handoff

Updated: 2026-04-11

Web Terminal Pointer

Sidecar operator workspace name: Web Terminal
Local/server reference doc: WEB-TERMINAL.md
Live host today: https://lab.deploymatecloud.ru
Source project today: products/codex-mobile-terminal

Current Product Goal

Главная цель сейчас: не просто наращивать deploy/control функции, а сделать путь понятным с первого прохода.
Долгоживущий стратегический source of truth теперь отдельно зафиксирован в PRODUCT-STRATEGY.md.
Ближайший продуктовый ориентир:
- подключить сервер
- увидеть, жив ли сервис
- понять, что делать дальше без длинного скролла и лишнего жаргона
Для быстрой ресинхронизации Codex теперь использовать короткие команды из CODEX-PROTOCOL.md.

Current Security Boundary

Новый жёсткий проектный принцип: runtime-данные не могут быть "по умолчанию общими" просто потому, что пользователь уже вошёл в систему.
Базовая безопасная модель на текущем этапе:
- admin видит весь продуктовый runtime и admin depth
- member видит только свои deployments/templates/activity/notifications
- remote server inventory и remote server execution остаются admin-only, пока у проекта нет явной sharing/ownership модели для серверов
Дополнительные жёсткие guardrails теперь тоже часть текущей boundary:
- auth throttling должен жить в shared state, а не в памяти одного процесса
- bootstrap admin/admin не допускается без явного local-only override
- SSH host trust по умолчанию должен быть strict/pinned, а не accept-new
Production/release boundary теперь тоже зафиксирована как часть security contract:
- DEPLOYMATE_ADMIN_PASSWORD должен быть реальным секретом
- DEPLOYMATE_AUTH_RATE_LIMIT_BACKEND должен быть shared, а не memory
- DEPLOYMATE_SSH_HOST_KEY_CHECKING=yes и DEPLOYMATE_SSH_KNOWN_HOSTS_FILE обязательны для remote runtime
- post-deploy smoke должен проверять реальный runtime path, а не только /api/health
Любой новый runtime surface дальше нужно оценивать не только по clarity, но и по ownership boundary: кто именно может это видеть, экспортировать и менять.

Current Build Reality

/app сейчас работает как обзорный входной экран.
/app/server-review сейчас главный экран для подключения и review серверов.
/app/deployment-workflow сейчас главный runtime/deploy workspace.
deployment detail стал более decision-first, чем раньше.
Week 1 now has a clearer first-pass story across the four main surfaces:
- /app chooses the obvious next path instead of surfacing too many competing actions
- /app/server-review now reads as save -> verify -> deploy
- /app/deployment-workflow now behaves like one active lane at a time: live, create, or templates
- deployment detail now answers state, risk, and next action more directly
продукт стал заметно понятнее с первого прохода, но живой walkthrough на проде показал более глубокую проблему: новичок всё ещё не понимает, что делает продукт и какой у него первый шаг
Одновременно infra/release слой теперь тоже сильно жёстче:
- production env audit и contract gate уже часть нормального release path
- post-deploy smoke теперь умеет явный host resolve
- если локальный runner не видит staging по DNS/TLS, smoke можно и нужно запускать прямо на deploy host через SSH
Week 2 beginner story теперь уже началась в реальном UI:
- /app объясняет three-step path и даёт plain-language meaning для server, what to run, и healthy
- /app теперь начинается как простой product-entry экран: large product statement, one next action, short signal strip, then the three-step path
- /app/server-review теперь жёстко framed как один job: save one server target, run one check, then leave for Step 2
- /app/deployment-workflow теперь явно framed как Step 2 with one-lane-at-a-time guidance instead of operator-first scanning
Task-first framing уже усилился ещё на один шаг:
- /app now shows one explicit Do this now task card before the rest of the three-step map
- opening a saved server now shows what to do with this server before edit/delete surfaces
- server edit/delete are now secondary details instead of competing with the main path
- login can now hide demo access by default unless a dedicated demo user is explicitly configured
- member blocked flow in /app/deployment-workflow is being simplified so it stops showing dead create/template surfaces before admin Step 1 is done
- after a live walkthrough, overview primary CTA was corrected so member users waiting on admin Step 1 no longer see a false start deployment main action

Current Release Reality

2026-04-10 живой staging walkthrough завершён end-to-end успешно на хосте deploymate.
Проверенный release path теперь реально включает:
- remote audits
- compose rebuild
- login/auth smoke
- backup bundle + restore dry-run
- runtime smoke deploy with health/diagnostics/logs/activity/delete
В процессе walkthrough были пойманы и закрыты три настоящих release-path дефекта:
- локальный smoke runner зависел от внешнего DNS/TLS
- post_deploy_smoke.sh не умел curl --resolve
- в post_deploy_smoke.sh отсутствовал json_query() helper
Важный operational вывод: release path нельзя считать здоровым, пока он не прогнан на реальном staging host, даже если локальные тесты зелёные.

Next Recommended Package

Проверить новый beginner story не только глазами автора, а живым walkthrough:
- first-time admin path: /app -> /app/server-review -> /app/deployment-workflow
- member path under admin-managed server inventory
- confirm that the next click is still obvious after login, after saving a server, and after the first deploy
Для следующего прохода уже есть явный артефакт и guardrail:
- manual checklist: docs/beginner-walkthrough.md
- local smoke: npm --prefix frontend run smoke:beginner
После walkthrough уже добивать remaining clarity gaps instead of blindly rewriting copy.
Параллельно не ослаблять новый release contract и не превращать его во временный workaround.
Следующий стратегический слой после beginner clarity уже зафиксирован:
- first deploy in 10 minutes
- production-useful runtime
- team and agency fit
- deployment passport как главный продуктовый differentiator

Week 1 Result

The main product story is now more explicit: server -> deploy -> observe.
The first pass should stay inside four surfaces only:
- Overview
- Servers
- Deployments
- Templates
Admin, recovery, import, audit-heavy, and queue-heavy flows remain valid, but should stay secondary until the main path is already clear.
The current UI standard is no longer “show everything important”.
The new standard is “show the next obvious action first”.

Week 2 Focus

Make the product understandable to a full novice without author explanation.
Turn /app into a simple what this is / what to do first / what happens next screen.
Reframe /app/server-review as Step 1 instead of an operator review console.
Reframe /app/deployment-workflow as Step 2 with plain language about image, deploy, and next action.
Remove or demote text that sounds like internal ops jargon on the first pass.

Week 2 Progress

The Server Review -> Deployment Workflow bridge is now partially real, not just conceptual.
When a reviewed server is ready, server-review now opens deployment-workflow with that target preselected.
The create form now says more clearly when the target already came from Server Review, so the user knows the next move is simply setting the image.
After the first successful deploy, the success state now points straight to runtime detail instead of leaving the user in a vague success-only state.
The first-pass copy is now much closer to a real novice path:
- /app now explains the product in a three-step story instead of only reflecting workspace state
- /app also now starts with one explicit Do this now action instead of making the user choose from the whole page
- server-review now reads as one job: save one server target, check it, then move on
- opening a saved server now shows ordered tasks first, while edit/delete moved behind a secondary disclosure
- deployment-workflow now explains Step 2 with one-lane-at-a-time guidance and simpler language around image, template, and health
The blocked member path is now more internally consistent:
- /app no longer presents Step 2 and Step 3 as if they were already open before admin Step 1 is complete
- /app/server-review no longer shows a false remote-only CTA into Deployment Workflow
- /app/deployment-workflow now opens the live lane directly when a blocked member already has deployments to review
The first-time admin overview is now stricter too:
- when no server is connected yet, /app no longer renders Step 2 as if app choice were already open
- /app also no longer renders Step 3 as if live runtime review already existed before the first deploy
- the new smoke:beginner guardrail now checks those blocked-step states directly
server-review is now stricter in the first saved-but-unconfirmed state too:
- once one server already exists, the live check queue now appears before the add another server form
- the page now stops competing with its own main action when the right next move is run one check
- smoke:servers now includes a pending-server fixture pass to hold that ordering in place
deployment-workflow is now stricter in the first-deploy-after-server-review state too:
- when Step 1 is already done and no deployment exists yet, the main CTA stays Create deployment
- an empty first draft no longer gets mislabeled as the primary blocker just because Image is still blank
- smoke:beginner now includes a server-ready first-deploy fixture so templates do not hijack the main lane again
The first manual walkthrough pass found one remaining Step 2 hesitation:
- screen: /app/deployment-workflow after coming from Server Review
- issue: the empty first draft still showed Image is required. before the user typed anything
- fix: preflight errors now wait until the user has actually started a rollout draft
- guardrail: the first-deploy beginner smoke now fails if that premature error comes back
The first Step 3 runtime walkthrough pass found one remaining healthy-detail hesitation:
- screen: /deployments/smoke-deployment with a running and healthy runtime
- issue: the primary action still pushed Prepare rollout change even though the safer next step was to open the running app and verify it
- fix: healthy runtimes with a live endpoint now make Open running app primary and keep rollout changes secondary
- guardrail: smoke:runtime now fails if a healthy runtime detail makes Prepare rollout change the main next-step action again
The failed-runtime walkthrough path is now review-first too:
- screen: /app/deployment-workflow -> /deployments/review-worker
- issue: the workflow queue exposed delete before the failed runtime had been reviewed, and smoke detail did not represent the failed deployment
- fix: failed cards now point to detail review before delete, and smoke detail resolves review-worker as a failed runtime
- guardrail: smoke:runtime now fails if the failed queue exposes early delete or if failed detail stops making Review runtime issues primary
The failed-runtime focus card now makes the review action explicit:
- screen: failed primary card on /app/deployment-workflow
- issue: the card no longer exposed delete first, but its main CTA still said View details, which left the safest next step too vague during a failed rollout
- fix: failed focus cards now make Review runtime issues the primary action and keep the inline warning aligned with that same review-first wording
- guardrail: smoke:runtime now fails if the failed focus card loses its primary Review runtime issues CTA
The live queue now uses one action hierarchy across focus and secondary cards:
- screen: /app/deployment-workflow
- issue: focus cards had started using review-first/open-first actions, but secondary cards still collapsed everything into low-emphasis View details and Open app links
- fix: runtime cards now follow one status-based matrix everywhere in the queue: failed cards make Review runtime issues primary, healthy cards with a URL make Open app primary, and detail review stays visibly secondary when the app is already reachable
- guardrail: smoke:runtime now checks healthy secondary cards, healthy focus cards, and a failed-secondary smoke scenario so queue action hierarchy stays aligned
The internal-only runtime path now follows the same review-first story:
- screen: /app/deployment-workflow and /deployments/internal-runtime
- issue: healthy runtimes without a public URL still fell back to vague View details language in the queue, while detail copy said the runtime was stable without making the review step explicit enough
- fix: no-public-URL runtime cards now make detail review the primary action, running internal-only cards use Review stable runtime, and internal-only detail now explains that overview/ports/health/activity review comes before rollout changes
- guardrail: smoke:runtime now checks an internal-only detail fixture plus focus/secondary workflow cards so private-runtime review cannot regress back into ambiguous queue copy
The blocked member overview CTA now says what the click actually does:
- screen: member remote-only /app before admin Step 1 is complete
- issue: the primary CTA still said See what opens next, which was directionally correct but too vague for a first-time user trying to understand why rollout is blocked
- fix: the blocked member overview now uses Review rollout status, matching the fact that the click opens the blocked deployment workflow state instead of a hidden next-step surprise
- guardrail: smoke:beginner now fails if the member waiting overview loses that explicit rollout-status action
The ready server-review state now points forward instead of backward:
- screen: ready server task panel on /app/server-review
- issue: once a server was already ready, the open task grid still kept Check server readiness as a primary action, so the page visually competed with the actual next move into app setup
- fix: ready server cards now make Choose what to run the primary CTA, while readiness check is demoted to an explicit recheck-only action
- guardrail: smoke:servers now runs a ready-server fixture and fails if the continue action stops being primary or the recheck action regains primary weight
The first-deploy workflow tabs now stop competing with the blank create path:
- screen: /app/deployment-workflow right after Step 1 is done and no deployment exists yet
- issue: the page still showed Check live apps and a neutral template tab before the first deploy existed, which made Step 2 read like several equal paths instead of one obvious first click
- fix: the live-review tab now stays hidden until at least one deployment exists, and the template path is explicitly framed as Use saved setup instead with a first-deploy fallback note
- guardrail: smoke:beginner now fails if the first-deploy fixture brings back the live tab or loses the explicit template-fallback framing
Template deploy success now lands on the same next step as manual create:
- screen: template deploy success banner on /app/deployment-workflow
- issue: manual create already made Open runtime detail the obvious next click, but template deploy success still fell back to low-emphasis View details copy without a secondary route back into the live queue
- fix: template deploy success now uses the same review-first wording as manual create, with Open runtime detail as the primary action and Review live queue as the secondary follow-up
- guardrail: smoke:runtime now runs a template-success workflow fixture and fails if runtime detail stops being the primary success action
The first runtime-detail screen now preserves the verify-first story after success:
- screen: /app/deployment-workflow -> /deployments/* after a fresh create/template success click
- issue: the success banner pointed to runtime detail correctly, but the detail page still immediately offered Prepare rollout change as the secondary path even when the rollout had just been created and still needed first verification
- fix: workflow success links now carry explicit workflow-success context, and healthy runtime detail uses that context to show a fresh-rollout review banner plus Review runtime overview instead of early change-prep
- guardrail: smoke:runtime now loads healthy runtime detail with ?source=workflow-success and fails if the fresh-rollout bridge banner or review-first secondary action disappears
The fresh-rollout detail path now closes the verification loop more explicitly:
- screen: healthy /deployments/*?source=workflow-success and success banners on /app/deployment-workflow
- issue: even after the first bridge, a fresh rollout still landed on a fairly generic overview, and smoke did not yet prove that create/template success links were preserving the workflow-success context
- fix: fresh rollout detail now shows a dedicated verify app / health / activity checklist in overview, create success got its own smoke fixture, and both create/template success links are now held to the workflow-success href contract
- guardrail: smoke:runtime now fails if the fresh-rollout checklist disappears or if either success path stops linking into detail with ?source=workflow-success
The member-safe pass found one blocked-path leak:
- screen: member /app/deployment-workflow and member runtime detail in remote-only mode
- issue: blocked create/template lanes and runtime mutation controls were hidden but still rendered in HTML
- fix: member remote-only workflow no longer renders blocked create/templates lanes, and admin-managed runtime detail no longer renders redeploy/delete controls
- guardrail: smoke:beginner now checks that member workflow/detail HTML stays free of those controls while preserving Open running app and Review runtime issues
The next member-safe pass closed one remaining identity leak:
- screen: member live queue on /app/deployment-workflow and member /deployments/* detail for admin-managed remote runtimes
- issue: the blocked/member-safe path still rendered admin-managed server labels like Ops Batch and Smoke VPS in review UI even after mutation controls were hidden
- fix: member-safe runtime review now falls back to generic admin-managed target labels instead of server inventory names/host labels
- guardrail: smoke:beginner now fails if the member workflow/detail fixtures expose those admin-managed server identities again
The member export/handoff pass closed the same boundary at generated-payload level:
- screen: member runtime detail utility/handoff layer
- issue: the visual UI was generic, but downloadable incident JSON/markdown and copy/export payloads could still be built from raw deployment/diagnostics/activity objects
- fix: member export payloads now strip server inventory fields, replace admin-managed targets with generic labels, redact matching activity/attention text, and omit remote suggested ports
- guardrail: smoke:beginner now imports the payload sanitizer directly and fails if member exports contain raw server inventory keys, server names, SSH targets, server ids, or suggested ports
The backend now enforces the same member boundary instead of relying on frontend sanitizers:
- issue: owned legacy/admin-managed remote deployments and templates could still expose server_id, server_name, server_host, or SSH target text through API reads/exports/activity, and member API calls could still reach remote runtime live actions
- fix: non-admin API reads/exports redact admin-managed server inventory fields, activity/notifications redact matching server identity text, and remote runtime diagnostics/logs/health/redeploy/delete now return admin-only 403
- guardrail: tests.test_member_ownership_isolation now covers owned remote deployment/template reads, ops exports, notifications/activity redaction, and blocked remote live/mutation actions
The frontend now understands backend-redacted admin-managed runtimes:
- issue: once the backend hid server_id, member runtime detail could mistake an admin-managed remote runtime for a local target and show dead mutation/template controls
- fix: API responses include a non-sensitive server_managed_by_admin marker, and runtime detail uses it to hide redeploy/delete/local-template save, skip live diagnostics/logs/health calls, and show clear admin-managed live-check/template notices
- guardrail: smoke:beginner now renders a redacted admin-managed-runtime detail fixture and fails if mutation controls, local template save, local-runtime copy, or server identity returns
The member deployment workflow now separates two remote-only states:
- if member already has deployments, /app/deployment-workflow frames the page as live review with admin-managed targets instead of saying Step 2 is still waiting
- member live-search no longer matches hidden admin-managed server names/hosts
- if member has no deployments, the page still stays blocked on admin Step 1 and keeps create/templates/live cards out of the HTML
- guardrail: smoke:beginner now checks both the live-review member path and the waiting-for-admin member path
The member overview now follows the same split:
- if member already has deployments, /app makes live review the main path and keeps new remote deployment gated behind admin target control
- the smoke fixture for that path uses redacted admin-managed deployments so the overview does not reintroduce server identity leaks
- guardrail: smoke:beginner now checks the member overview live-review path separately from the waiting path
The admin overview now has an explicit server-ready/no-deployments guardrail:
- if one server is already connected and no deployments exist, /app points to first deployment instead of server setup
- guardrail: smoke:beginner now checks that the hero CTA is Launch first deployment, Step 2 is active, and Add first server target does not return as the primary action
The admin first-deploy bridge now keeps target context from overview into workflow:
- if overview knows exactly one ready server and no deployments exist, /app links into deployment-workflow with that target already selected
- deployment-workflow now explains when the first-deploy target came from Overview, not only from Server Review
- guardrail: smoke:beginner now follows the overview link, checks the preserved server query, and fails if Step 2 loses the selected target or shows a premature image error
The overview first screen now has a stronger product-entry hierarchy:
- screen: /app
- issue: the overview story was behaviorally clearer, but still felt too much like an admin/status dashboard with several similarly weighted cards
- fix: /app now opens with a large product statement, one focused next-step panel, a compact signal strip, and then the three-step path; ops/admin depth stays below the first-pass path
- guardrail: smoke:beginner now requires the product hero/signal strip and checks that hero -> next task -> three-step path render before operations depth
The overview first screen now reduces scroll friction:
- screen: /app
- issue: after the product-entry pass, the user still had to scroll down to understand the three-step usage model
- fix: the hero now includes a top quick-action rail for Connect server, Deploy app, and Review health, using the same real enabled/blocked state as the beginner path
- fix: the longer three-step explanation and plain-language copy are now collapsed details, so the first screen stays action-first instead of reading-first
- guardrail: smoke:beginner now requires the quick-action rail and checks it renders before the deeper path/ops sections
The overview quick-action layer now reads more like one premium step grid than a button strip:
- screen: /app
- issue: the first quick-action pass reduced scrolling, but the dark active middle button still looked like an extra primary CTA and made the top row feel visually uneven
- fix: the top layer is now a three-card glass grid with equal step cards, soft state tints, clearer Start here / Ready / Locked status labels, and a lighter current-step action treatment instead of a black active slab
- fix: the top surfaces now use a restrained glass treatment with soft neutral/ice/sage tones, while the rest of the page stays quiet and readable
- guardrail: the existing beginner smoke still holds the quick-action layer above the deeper overview/ops sections, and live browser smoke now validates the desktop grid/collapsed-detail shape before handoff
The product shell is now moving out of the page body and into a shared top bar:
- screen: /app, /app/server-review, /app/deployment-workflow, /deployments/*, /change-password
- issue: /app kept turning into a giant hero with secondary explanation blocks, while account/help controls were not anchored as one shared product shell
- fix: workspace routes now use one fixed top bar with a centered DeployMate badge, right-side Help, Profile, and Logout, while /login stays clean and separate
- fix: /app itself now starts as one full-width action board for Step 1 / Step 2 / Step 3 instead of hero + signal strip + next panel; deeper ops/admin sections stay below the fold
- guardrail: smoke:beginner now checks the new action-surface structure and no longer depends on the old hero/next-panel markup
The healthy runtime happy path is now reinforced in workflow as well as detail:
- on the primary healthy runtime card in deployment-workflow, Open app now comes first and uses the primary action styling
- smoke:runtime now runs a healthy-only workflow fixture so the safe verify path is checked in live queue before detail review
- the existing detail guardrail still holds Open running app as the main next step on healthy runtime detail
Local frontend smoke for the beginner path passed after this slice:
- scripts/frontend_beginner_smoke.sh
- scripts/frontend_servers_smoke.sh
- scripts/frontend_runtime_smoke.sh
The remaining question is no longer "do we have the right frame?" but "does a real beginner now follow it without hesitation?"

Current State

Local working branch for current product work: deploymate/product-wip
Latest published develop commit: 0384fa3
Staging host deploymate:
- /opt/deploymate branch develop currently points to 0384fa3
- remote origin/develop also points to 0384fa3
- pre-cleanup dirty remote state was preserved in backup branch codex/remote-host-backup-20260410-023502
Latest validated package now includes:
- member/admin runtime ownership isolation
- shared auth throttling, explicit bootstrap admin password, strict SSH trust with persistent known_hosts
- production env audit and production contract gate
- remote release smoke that can run on the deploy host and can pin host resolution explicitly
- successful end-to-end staging walkthrough with runtime smoke create/health/diagnostics/logs/activity/delete
- first-pass beginner story rewrite across overview, server step, and deployment step
- blocked member first-pass alignment across overview, server step, and deployment step
- local frontend smoke confirmation for /app, /app/server-review, /app/deployment-workflow, and deployment detail
Host-specific note:
- saved runtime smoke server prod-runtime-smoke currently points to 103.88.241.103
- do not switch it back to deploymatecloud.ru until backend-container DNS resolution is explicitly re-verified

Product Rule

интерфейс DeployMate должен становиться не просто функциональным, а интуитивно понятным
для любого важного сценария пользователю должно быть очевидно, куда нажать, чтобы пойти по основному пути
главный следующий шаг на экране должен читаться сразу, без чтения документации и без догадок
если на экране есть много действий, главный путь не должен теряться среди второстепенных controls
если логика уже работает, но пользователь всё ещё не понимает, что делать дальше, такой экран считать незаконченным

Практический вывод из текущего состояния проекта:

сейчас проект уже сильнее как operator/review console, чем как интуитивный продуктовый интерфейс
главная UX-проблема не в отсутствии функций, а в том, что основной путь местами тонет среди exports, filters, refresh и второстепенных tools
ближайшие продуктовые пакеты нужно оценивать не только по safety и полноте логики, но и по тому, стал ли следующий шаг очевиднее для клиента

Short Version

Если совсем по-человечески:

scaffold уже не просто “улучшали”
его реально прогнали на живой продуктовой задаче
результат этой проверки: появился новый surface server-review/page.js
это теперь полноценное место для работы с серверами

Что это значит:

серверы больше не должны жить в двух местах сразу
/app теперь обзорный экран
/app/deployment-workflow теперь основной экран для rollout creation, template reuse и live deployment review
/app/server-review теперь основной экран для серверной работы
deployment detail теперь лучше объясняет текущее runtime-состояние и даёт готовый handoff-артефакт, а не только raw diagnostics
backend activity теперь лучше объясняет не только результат mutation, но и сам старт runtime-операции
restore dry-run теперь понятнее отвечает на вопрос “готов ли этот bundle хотя бы к import preparation”
restore dry-run теперь ещё и заранее ловит битые связи между секциями bundle
restore workspace теперь проще отфильтровать под конкретный риск, а не глазами читать всё подряд
restore workspace теперь ещё и явно показывает, что можно готовить к import дальше, что держать на merge review, а что оставлять только в dry-run
удаление deployment теперь требует явного review и typed confirmation вместо одного случайного confirm popup

What Was Actually Done

1. Scaffold был проверен на реальной фиче

Через scaffold был создан и затем доведён до реального состояния новый surface:

server-review/page.js

Это уже не scaffold-demo и не mock page.

Это живая страница поверх настоящего server API.

2. Server review стал полноценным контуром

Сейчас в server-review есть:

просмотр серверов
поиск и review filters
table view
saved views
export
локальный audit trail на странице
create server
edit server
test connection
diagnostics
suggested ports
delete server

Простой вывод:

серверный workflow теперь собран в одном месте
для работы с серверами не нужно прыгать обратно на /app

3. Старый дублирующий server flow на `/app` был упрощён

На page.js:

серверный блок больше не тащит на себе полный CRUD + diagnostics flow
там теперь короткий обзор и вход в Server review
в верхних actions тоже добавлена ссылка на Server review

Простой вывод:

/app снова стал обзорной панелью
server-review стал рабочим экраном по серверам

4. Лишний backend starter-мусор был удалён

Scaffold сначала нагенерил отдельный fake backend под server_review, но после перевода страницы на реальные /servers endpoints этот слой стал лишним.

Он был убран.

Что осталось правильным:

реальный backend /servers
реальный frontend server-review

Что это значит:

нет дублирующего API только ради шаблона
меньше лишней поддержки

5. Реальный update flow серверов добавлен в backend

На backend добавлен настоящий update путь для серверов:

db update:
- db.py
route update:
- servers.py
schema update:
- schemas.py
test update:
- test_server_api_flow.py

Простой вывод:

сервер теперь можно не только создать и удалить, но и нормально редактировать

6. Runtime detail стал нормальным handoff surface

На page.js:

добавлен plain-language runtime summary для людей без технического контекста
добавлен downloadable incident snapshot в JSON
добавлен downloadable handoff в Markdown
activity лента получила search / level filter / sort
текущий activity view теперь можно экспортировать в CSV

На project_automation_smoke_checks.sh:

runtime smoke теперь проверяет новый handoff/export слой deployment detail

Простой вывод:

deployment detail теперь годится не только для диагностики, но и для нормальной передачи состояния дальше
оператору больше не нужно вручную собирать картину из health, logs, diagnostics и activity

7. Backend activity стал полезнее для runtime review

На deployment_mutations.py:

create/redeploy/delete теперь пишут явные started activity events
стартовые activity messages теперь содержат более человеческое описание target, image, ports и env-shape
failure activity messages теперь лучше объясняют, на каком шаге и в каком target произошёл сбой

На test_deployment_routes.py и test_deployment_api_flow.py:

добавлены проверки на эти новые mutation-start events и richer activity messages

Простой вывод:

runtime detail activity теперь показывает более полезную историю
при create/redeploy/delete оператору легче понять не только чем всё закончилось, но и что именно система пыталась сделать

8. Restore dry-run стал явным import-preparation decision surface

На backend:

Что добавлено:

restore summary теперь возвращает readiness_status
summary теперь возвращает human-readable plain_language_summary
summary теперь возвращает явный next_step
summary теперь возвращает highest_risk_sections

На frontend:

Что добавлено:

import readiness card
next-step card
plain-language import-preparation summary
markdown export для restore preparation handoff
restore smoke теперь проверяет новый preparation слой

Простой вывод:

оператору теперь проще понять, можно ли вообще двигаться к import preparation
даже человеку без технического бэкграунда стало проще объяснить, почему bundle safe, review или blocked

9. Restore dry-run теперь ловит cross-section reference risks

На backend:

Что добавлено:

upgrade requests теперь предупреждают о ссылках на отсутствующих пользователей
templates теперь предупреждают о ссылках на отсутствующие серверы
deployments теперь блокируются, если ссылаются на отсутствующий сервер
deployments теперь предупреждают о ссылках на отсутствующий template

Простой вывод:

bundle теперь раньше сообщает, что в нём сломано между секциями
оператору не нужно догадываться, почему import preparation нельзя считать безопасным

10. Restore workspace стал полезнее для ручного review

На frontend:

Что добавлено:

search по restore sections
highest-risk-only filter
summary по текущей видимой выборке sections
CSV export именно текущего видимого restore view
per-section issue summary прямо в карточках sections

Простой вывод:

теперь проще быстро сузить restore review до реальных проблемных зон
и проще отдать кому-то именно текущую отфильтрованную картину, а не весь отчёт целиком

11. Delete deployment получил нормальные destructive guardrails

На frontend:

page.js

На smoke checks:

project_automation_smoke_checks.sh

Что изменилось:

вместо простого window.confirm теперь открывается delete review panel
пользователь видит impact summary перед удалением
для удаления нужно руками ввести имя deployment
smoke checks теперь проверяют новый delete-review слой и новые restore preparation controls

Простой вывод:

случайно удалить deployment стало заметно сложнее
runtime detail теперь лучше подходит для осторожной операторской работы, а не только для быстрых кликов

12. Restore import preparation стал более структурированным рабочим слоем

На backend:

Что добавлено:

каждый restore section теперь возвращает preparation_mode
каждый restore section теперь возвращает recommended_action
общий restore summary теперь возвращает preparation_summary
summary теперь считает секции по четырём режимам: prepare_import, merge_review, validate_only, dry_run_only

На frontend:

Что добавлено:

новая Preparation mix card в restore overview
новый preparation summary внутри import-preparation card
per-section preparation mode и recommended action прямо в restore section cards
markdown/CSV export теперь тоже тащит structured preparation guidance
restore smoke anchors теперь проверяют новый planning слой

Простой вывод:

restore dry-run теперь объясняет не только риск, но и следующий безопасный способ работы с каждой секцией bundle
оператору проще отделить реальные import candidates от merge-review и dry-run-only зон

13. Появился узкий DeployMate vertical feature scaffold

На repo tooling:

Что добавлено:

новый make scaffold-deploymate-feature
wrapper поверх scaffold_deploymate_surface.sh для текущих DeployMate-паттернов
три узких режима: review-workflow, recovery-workflow, guardrail-workflow
кроме базового surface scaffold теперь сразу создаются:
- frontend feature-pack helper stub
- generated smoke checks file
- dedicated frontend smoke runner script

Что это значит practically:

следующая review/recovery/admin-heavy фича теперь стартует не только со страницы и backend route
она сразу получает ещё и project-specific pack для summary/export/smoke слоя
это должно уменьшить повторную ручную сборку на ближайших пакетах, а не когда-нибудь потом

14. Import review стал отдельным recovery workspace

На backend:

Что добавлено:

новый GET /import-review
backend собирает current backup bundle, restore dry-run и controlled import plan в один workspace response
import-review больше не starter queue, а recovery-specific review surface

На frontend:

Что добавлено:

отдельная страница /app/import-review
bundle card, dry-run readiness card и plan-status card
controlled import boundary card с scope summary, reviewer guidance и typed confirmation phrase
фильтрация import-plan sections по plan_state и search
JSON / Markdown / visible-sections CSV export для текущего import review
ссылка обратно в /app/users для полного restore workspace

Что это делает:

controlled import/apply boundary теперь видна как отдельный экран, а не только как кусок внутри users/restore workspace
оператору проще быстро увидеть текущий backup, readiness и import scope без лишнего admin шума

15. Restore и import-review теперь связаны в один recovery маршрут

На frontend:

Что добавлено:

из restore import plan card теперь можно открыть dedicated import-review именно с тем bundle, dry-run и import plan, которые оператор только что собрал
handoff идёт через browser session storage, без отдельного backend session-layer
import-review теперь явно показывает source workspace: restore handoff или live backup
на import-review можно принудительно сбросить handoff и вернуться к current live backup baseline
smoke anchors теперь покрывают и restore-side handoff кнопку, и import-review source card

Что это значит practically:

recovery flow больше не выглядит как два несвязанных экрана
review теперь можно продолжать на отдельной странице без потери именно того bundle-контекста, который только что проверяли
при этом всё ещё остаётся явная возможность вернуться к live backup и не перепутать источники данных

16. Import review получил готовый approval trail для handoff

На backend:

Что добавлено:

import plan summary теперь отдаёт approval_packet_title
import plan summary теперь отдаёт approval_subject_line
import plan summary теперь отдаёт approval_share_summary
import plan summary теперь отдаёт approval_next_step

На frontend:

Что добавлено:

approval card теперь показывает packet title, subject line, share summary и next step
можно скачать не только markdown approval packet, но и structured approval trail JSON
можно скопировать короткий handoff summary без ручной сборки текста

Что это значит practically:

import-review теперь не только объясняет решение, но и сразу собирает короткий пакет для передачи дальше
оператору не нужно руками пересказывать bundle name, plan status, decision question и следующий шаг
approval handoff стал больше похож на законченный workflow-артефакт, а не на один markdown-файл

17. Import review теперь доводит review до controlled preparation handoff

На backend:

Что добавлено:

import plan summary теперь отдаёт preparation_status
import plan summary теперь отдаёт preparation_packet_title
import plan summary теперь отдаёт preparation_share_summary
import plan summary теперь отдаёт preparation_summary
import plan summary теперь отдаёт preparation_checklist
import plan summary теперь отдаёт preparation_handoff_note
import plan summary теперь отдаёт preparation_next_step

На frontend:

Что добавлено:

новый Controlled preparation handoff card внутри import-review
markdown export для preparation packet
structured preparation trail JSON
copy action для короткой preparation summary

Что это значит practically:

recovery flow теперь не обрывается на approval handoff
следующий безопасный шаг тоже упакован: можно передать дальше scope, checklist и next step для preparation работы
это всё ещё не apply-path и не скрытый destructive flow, а отдельный handoff на следующую безопасную стадию

18. Началась UX-пересборка вокруг явного главного действия

На frontend:

Что добавлено:

AdminPageHeader теперь умеет принимать явный primaryAction, а Refresh больше не считается главным действием по умолчанию
Users header теперь ведёт прямо к Create user
Server Review header теперь ведёт прямо к Add server target
Import Review header теперь ведёт прямо к Download preparation packet
внутри import-review появился отдельный Main next step card, который явно говорит, что делать дальше после review

Что это значит practically:

проект начал переход от “мощной панели инструментов” к более понятному продукту с читаемым главным путём
на ключевых admin/recovery поверхностях теперь заметнее, что является главным действием, а что просто вспомогательным инструментом
это ещё не полный UX-рефактор всего продукта, но правильный системный сдвиг уже начался

19. `/app` начал превращаться в сценарный вход в продукт

На frontend:

Что добавлено:

на верхнем уровне /app появился отдельный сценарный блок с понятными путями
теперь сверху страницы виднее основные сценарии: deployment, runtime review, server review и recovery/admin path
этот блок не заменяет deeper workspace sections ниже, а помогает сначала выбрать очевидный основной путь

Что это значит practically:

/app стал меньше похож на просто обзорный dashboard и больше на продуктовый входной экран
новый пользователь быстрее понимает не только текущее состояние системы, но и с какого сценария начать работу
это продолжает тот же UX-сдвиг: сначала очевидный next step, потом уже детали и второстепенные инструменты

20. Recovery path получил явную последовательность шагов

На backend:

Что добавлено:

import plan summary теперь отдаёт workflow_focus
import plan summary теперь отдаёт workflow_summary
import plan summary теперь отдаёт workflow_steps

На frontend:

Что добавлено:

в import-review появился отдельный Recovery sequence card
экран теперь явно показывает текущий фокус и порядок безопасных следующих шагов
markdown export теперь тоже тащит sequencing summary

Что это значит practically:

recovery flow теперь легче воспринимается как последовательность действий, а не как набор отдельных packet/export блоков
пользователю проще понять, где он находится сейчас: на review, blocked cleanup или preparation handoff
это усиливает продуктовую понятность без открытия скрытого apply-path

21. Upgrade inbox начал переходить в guided review path

На frontend:

Что добавлено:

Upgrade Requests header теперь ведёт не просто в refresh/export pattern, а даёт явный вход в inbox review
наверху страницы появился отдельный Main next step card
экран теперь сразу показывает, на чём фокус: new, in-review или approved requests

Что это значит practically:

upgrade-requests стал меньше похож на технический inbox с bulk-tools наверху
пользователю теперь проще понять, что сначала нужно пройти текущий queue slice, а уже потом идти в bulk, saved views и audit
это продолжает общий UX-сдвиг проекта: сначала очевидный review path, потом supporting tools

22. Users разделился на team-access path и recovery path

На frontend:

Что добавлено:

Users header теперь ведёт в Review team access, а не в создание пользователя как главный путь
наверху страницы появился Main next step card для обычного team-access review
recovery получил отдельный верхний Recovery path card
recovery path теперь виден как отдельный маршрут, а не только как часть большого Advanced audit and recovery disclosure

Что это значит practically:

один из самых смешанных экранов проекта стал понятнее по структуре
пользователь теперь быстрее видит, идёт ли он в обычный доступ/команду или в recovery workflow
это уменьшает путаницу между ежедневным access review и редким, более опасным recovery path

23. Deployment/runtime/templates ушли в отдельный workflow screen

На frontend:

Что добавлено:

появился отдельный deployment-workflow screen
туда переехали live deployments, create deployment и deployment templates
/app остался обзорным scenario-entry экраном и перестал быть смешанным toolbox-экраном для rollout path
smoke checks теперь тоже считают deployment/template path отдельной поверхностью, а не частью обзорного /app

Что это значит practically:

основной путь деплоя теперь не тонет среди ops overview, admin и recovery surfaces
пользователю проще понять, куда идти для следующего rollout: в один отдельный deployment workspace
проект стал ближе к intent-first структуре: обзор отдельно, rollout workflow отдельно, server review отдельно, recovery отдельно

24. Deployment detail стал более intent-first runtime workspace

На frontend:

Что добавлено:

у deployment detail появился отдельный верхний Main next step слой
back path теперь ведёт в deployment-workflow, а не в общий обзорный /app
runtime detail теперь явнее разделяет: сначала review/decision, потом redeploy, потом handoff/delete/tools
handoff, delete review и deeper runtime history теперь меньше конкурируют с главным действием страницы

Что это значит practically:

deployment detail стал не просто страницей с большим количеством мощных блоков, а более понятным рабочим экраном
пользователю теперь проще увидеть, нужно ли сначала стабилизировать rollout, подготовить change, отдать handoff или идти в delete review
это продолжает тот же продуктовый сдвиг: сначала очевидный safe next step, потом supporting diagnostics/history/tools

25. Template lifecycle стал связнее между deployment detail и deployment workflow

На frontend:

Что добавлено:

после сохранения шаблона на deployment detail появился явный переход в deployment-workflow
deployment-workflow теперь умеет открываться сразу на нужном template context из detail-страницы
template review/reuse/edit теперь меньше ощущается как два несвязанных места

Что это значит practically:

пользователь теперь не теряет шаблон сразу после сохранения на runtime detail
стало понятнее, что detail умеет сохранить текущую реальность как template, а основной lifecycle шаблона продолжается уже в deployment workflow
это делает template path ближе к человеческому сценарию: сохранить -> открыть -> проверить -> переиспользовать

26. Create и redeploy стали ближе по guardrails и объясняющему слою

На frontend:

Что добавлено:

redeploy теперь тоже делает preflight-проверку на image, парность портов и ошибки в env rows
у redeploy появился такой же draft summary, как у guided create
create и redeploy теперь лучше ощущаются как один rollout language, а не как два слегка разных технических flows

Что это значит practically:

пользователю теперь проще доверять экрану изменения rollout: он заранее видит очевидные проблемы в форме, а не только backend error после submit
переход между “создать новый deploy” и “изменить существующий deploy” стал понятнее по языку и поведению
это уменьшает ощущение, что workflow и detail живут по разным правилам

27. Redeploy стал review-first, а не submit-first

На frontend:

Что добавлено:

кнопка Redeploy превратилась в Review redeploy
перед реальным redeploy теперь открывается review panel с impact summary
для redeploy теперь тоже нужен typed confirmation, как и для delete

Что это значит practically:

risky runtime change теперь сложнее сделать случайно
пользователь сначала видит, что именно изменится или что redeploy просто заново прогонит тот же rollout
delete и redeploy теперь выглядят как два осознанных review-действия, а не как две кнопки с разным уровнем осторожности

28. Delete и redeploy получили более единый человеческий review language

На frontend:

Что добавлено:

delete и redeploy теперь используют одинаковый confirmation phrase pattern
review panels у risky действий теперь объясняют подтверждение в одном и том же тоне
wording стал меньше зависеть от разных случайных формулировок на каждой кнопке

Что это значит practically:

пользователю легче понять логику опасных действий, потому что они больше не разговаривают на разных языках
review layer на runtime detail стал восприниматься как один цельный safety pattern, а не как набор отдельных решений
это делает risky actions более предсказуемыми даже без чтения документации

29. Reviewer-facing rollout copy стал общим слоем между overview, workflow и detail

На frontend:

Что добавлено:

общий reviewer-facing copy layer для трёх основных runtime экранов
overview, deployment workflow и deployment detail теперь объясняют основной путь более одинаковым языком
меньше дрейфа между “obvious path”, “main next step”, “review first” и похожими product формулировками

Что это значит practically:

человеку проще читать продукт как один связный маршрут, а не как три экрана, написанные разным тоном
главный путь деплоя и review теперь ощущается стабильнее даже при переходе между разными surface
это уменьшает риск, что пользователь поймёт overview, но потеряется на workflow или detail из-за смены языка

Important Practical Meaning

Если коротко:

server-review теперь можно считать законченным отдельным экраном
это уже не “заготовка”
это уже не “нужно ещё чуть-чуть, чтобы стало usable”
это уже рабочее место для серверов
deployment detail теперь тоже стал сильнее как рабочее место для runtime review и incident handoff
restore layer теперь уже не просто report, а более структурированный preparation handoff
у проекта теперь есть ещё и более узкий ускоритель именно под текущие DeployMate feature slices, а не абстрактный scaffold “на будущее”
recovery layer теперь ещё и получил отдельный import-review экран для controlled import boundary
restore и import-review теперь уже связаны в один маршрут, а не живут как две параллельные поверхности без handoff
import-review теперь ещё и умеет выдавать короткий approval trail, который проще отправить дальше без пересказа руками
import-review теперь доводит review ещё и до preparation handoff, то есть следующий безопасный шаг тоже оформлен как рабочий артефакт
поверх этого началась явная UX-пересборка: главный следующий шаг стали выводить вперёд, а не прятать среди второстепенных действий
/app поверх этого тоже начал меняться в сторону сценарного входа, а не просто обзорной панели
теперь это касается не только CTA-слоя, но и самого deploy/runtime/templates workflow: он вынесен в отдельный deployment-workflow
recovery path поверх этого теперь ещё и показывает последовательность шагов, а не только отдельные handoff-артефакты
upgrade-requests поверх этого тоже начал смещаться от inbox-toolbox к guided review path
users поверх этого теперь тоже начал разделяться на отдельные intent-first маршруты вместо одного смешанного admin/recovery экрана
deployment detail поверх этого теперь тоже начал смещаться от dense runtime toolbox к более явному decision-first экрану
поверх этого template path между detail и workflow теперь тоже стал более непрерывным, а не разорванным между двумя страницами
поверх этого create и redeploy теперь ещё и говорят с пользователем более одинаковым языком и одинаково рано показывают draft-проблемы
поверх этого redeploy теперь ещё и получил свой review boundary, а не оставался прямым submit-действием
поверх этого delete и redeploy теперь ещё и подтверждаются более одинаковым человеческим языком
поверх этого overview, workflow и detail теперь ещё и объясняют основной rollout path более одинаковым reviewer-facing языком

What Was Verified

Проверено локально:

bash -n scripts/scaffold_deploymate_surface.sh -> ok
cd backend && venv/bin/python -m unittest tests.test_server_api_flow -> ok
npm --prefix frontend run build -> ok
FRONTEND_SMOKE_PORT=3006 npm --prefix frontend run smoke:runtime -> ok
cd backend && venv/bin/python -m unittest tests.test_deployment_routes tests.test_deployment_api_flow -> ok
cd backend && venv/bin/python -m unittest tests.test_restore_dry_run -> ok
FRONTEND_SMOKE_PORT=3007 npm --prefix frontend run smoke:restore -> ok
FRONTEND_SMOKE_PORT=3006 npm --prefix frontend run smoke:runtime -> ok
повторный cd backend && venv/bin/python -m unittest tests.test_restore_dry_run после structured preparation plan -> ok
повторный npm --prefix frontend run build после restore UI/export updates -> ok
bash -n scripts/scaffold_deploymate_feature.sh -> ok
dry run scaffold_deploymate_feature.sh на временном target repo -> ok
cd backend && venv/bin/python -m unittest tests.test_import_review_api_flow tests.test_restore_dry_run -> ok
npm --prefix frontend run build после import-review surface -> ok
git diff --check -> ok
повторный cd backend && venv/bin/python -m unittest tests.test_import_review_api_flow tests.test_restore_dry_run после restore -> import-review handoff -> ok
повторный npm --prefix frontend run build после handoff/source-layer updates -> ok
повторный cd backend && venv/bin/python -m unittest tests.test_import_review_api_flow tests.test_restore_dry_run после approval trail layer -> ok
повторный npm --prefix frontend run build после approval trail updates -> ok
повторный cd backend && venv/bin/python -m unittest tests.test_import_review_api_flow tests.test_restore_dry_run после preparation handoff layer -> ok
повторный npm --prefix frontend run build после preparation handoff updates -> ok
npm --prefix frontend run build после primary-action / main-next-step UX package -> ok
git diff --check после primary-action / main-next-step UX package -> ok
npm --prefix frontend run build после /app scenario-entry UX package -> ok
git diff --check после /app scenario-entry UX package -> ok
cd backend && venv/bin/python -m unittest tests.test_import_review_api_flow tests.test_restore_dry_run после recovery sequencing layer -> ok
npm --prefix frontend run build после recovery sequencing layer -> ok
git diff --check после recovery sequencing layer -> ok
npm --prefix frontend run build после upgrade inbox UX package -> ok
git diff --check после upgrade inbox UX package -> ok
npm --prefix frontend run build после users dual-path UX package -> ok
git diff --check после users dual-path UX package -> ok
npm --prefix frontend run build после deployment workflow split -> ok
FRONTEND_SMOKE_PORT=3006 npm --prefix frontend run smoke:runtime после deployment workflow split -> ok
FRONTEND_SMOKE_PORT=3008 npm --prefix frontend run smoke:templates после deployment workflow split -> ok
git diff --check после deployment workflow split -> ok
npm --prefix frontend run build после deployment detail intent-first layer -> ok
FRONTEND_SMOKE_PORT=3006 npm --prefix frontend run smoke:runtime после deployment detail intent-first layer -> ok
git diff --check после deployment detail intent-first layer -> ok
npm --prefix frontend run build после template lifecycle bridge -> ok
git diff --check после template lifecycle bridge -> ok
npm --prefix frontend run build после create/redeploy consistency layer -> ok
FRONTEND_SMOKE_PORT=3006 npm --prefix frontend run smoke:runtime после create/redeploy consistency layer -> ok
git diff --check после create/redeploy consistency layer -> ok
npm --prefix frontend run build после redeploy review-first guardrails -> ok
FRONTEND_SMOKE_PORT=3006 npm --prefix frontend run smoke:runtime после redeploy review-first guardrails -> ok
git diff --check после redeploy review-first guardrails -> ok
npm --prefix frontend run build после shared risky-action language layer -> ok
FRONTEND_SMOKE_PORT=3006 npm --prefix frontend run smoke:runtime после shared risky-action language layer -> ok
git diff --check после shared risky-action language layer -> ok
npm --prefix frontend run build после shared reviewer-facing rollout copy layer -> ok
FRONTEND_SMOKE_PORT=3006 npm --prefix frontend run smoke:runtime после shared reviewer-facing rollout copy layer -> ok
git diff --check после shared reviewer-facing rollout copy layer -> ok
npm --prefix frontend run build после member live/waiting deployment workflow split -> ok
npm --prefix frontend run smoke:beginner после member live/waiting deployment workflow split -> ok
npm --prefix frontend run build после member overview live-review split -> ok
npm --prefix frontend run smoke:beginner после member overview live-review split -> ok
npm --prefix frontend run build после admin server-ready overview guardrail -> ok
npm --prefix frontend run smoke:beginner после admin server-ready overview guardrail -> ok
npm --prefix frontend run build после overview-to-workflow first-deploy bridge -> ok
npm --prefix frontend run smoke:beginner после overview-to-workflow first-deploy bridge -> ok
npm --prefix frontend run build после healthy workflow open-app priority slice -> ok
npm --prefix frontend run smoke:runtime после healthy workflow open-app priority slice -> ok
npm --prefix frontend run build после failed workflow review-first CTA slice -> ok
npm --prefix frontend run smoke:runtime после failed workflow review-first CTA slice -> ok
npm --prefix frontend run build после deployment workflow runtime queue consistency package -> ok
npm --prefix frontend run smoke:runtime после deployment workflow runtime queue consistency package -> ok
npm --prefix frontend run build после internal-only runtime review path package -> ok
npm --prefix frontend run smoke:runtime после internal-only runtime review path package -> ok
npm --prefix frontend run build после blocked member overview CTA wording slice -> ok
npm --prefix frontend run smoke:beginner после blocked member overview CTA wording slice -> ok
npm --prefix frontend run build после ready server-review CTA hierarchy slice -> ok
npm --prefix frontend run smoke:servers после ready server-review CTA hierarchy slice -> ok
npm --prefix frontend run build после first-deploy workflow tab hierarchy slice -> ok
npm --prefix frontend run smoke:beginner после first-deploy workflow tab hierarchy slice -> ok
npm --prefix frontend run build после template deploy success consistency slice -> ok
npm --prefix frontend run smoke:runtime после template deploy success consistency slice -> ok
npm --prefix frontend run build после fresh rollout detail verify-first bridge slice -> ok
npm --prefix frontend run smoke:runtime после fresh rollout detail verify-first bridge slice -> ok
npm --prefix frontend run build после fresh rollout detail verification checklist slice -> ok
npm --prefix frontend run smoke:runtime после fresh rollout detail verification checklist slice -> ok
npm --prefix frontend run build после overview product-entry hierarchy slice -> ok
npm --prefix frontend run smoke:beginner после overview product-entry hierarchy slice -> ok
npm --prefix frontend run build после overview quick-action rail slice -> ok
npm --prefix frontend run smoke:beginner после overview quick-action rail slice -> ok
npm --prefix frontend run build после overview glass step-grid slice -> ok
npm --prefix frontend run smoke:beginner после overview glass step-grid slice -> ok
npm --prefix frontend run build после workspace shell + action-board slice -> ok
npm --prefix frontend run smoke:beginner после workspace shell + action-board slice -> ok
README.md / RUNBOOK.md обновлены под server-review как основной server workspace

Простой вывод:

текущий пакет по scaffold + server-review + runtime detail handoff + richer backend mutation trace + stronger restore preparation guardrails + structured restore preparation guidance + DeployMate-specific feature scaffold + import-review workspace + restore/import-review handoff + approval trail layer + preparation handoff layer + primary-action UX package + /app scenario-entry layer + recovery sequencing layer + upgrade inbox UX package + users dual-path UX package + dedicated deployment workflow split + deployment detail intent-first layer + template lifecycle bridge + create/redeploy consistency layer + redeploy-review guardrails + shared risky-action language layer + shared reviewer-facing rollout copy layer + overview product-entry hierarchy + overview quick-action rail + overview glass step-grid polish + workspace shell + action-board slice находится в рабочем состоянии

Best Next Step

Самый разумный следующий шаг сейчас:

Считать restore/runtime review layer уже достаточно сильным на уровне review/preparation и не раздувать его бесконечной полировкой.
Если делать ускоритель разработки, то только такой, который окупится прямо на следующих пакетах DeployMate, а не абстрактный framework “на будущее”.
Узкий DeployMate-specific vertical feature scaffold теперь уже есть, значит дальше его надо проверять только на реальной ближайшей фиче.
import-review уже проверил scaffold на реальной recovery фиче, значит дальше можно использовать тот же путь только там, где он реально экономит ручную сборку.
Следующий продуктовый пакет теперь логичнее брать уже после entry/CTA/sequencing/inbox-review/users-split/deployment-workflow/deployment-detail/template-bridge/create-redeploy-consistency/redeploy-review-first слоя: не возвращаться к смешанному rollout toolbox, а идти дальше в reviewer-facing rollout copy и delete/redeploy shared confirmation language.

Что из ускорения реально стоит делать сейчас:

только то, что ускорит следующие реальные DeployMate фичи уже в ближайших пакетах
vertical feature scaffold под текущие review/recovery/admin patterns проекта
повторно используемые примитивы именно для review/export/guardrail flows, если они сразу войдут в следующую работу

Что из ускорения сейчас делать НЕ надо:

ещё один общий automation framework ради красоты
слишком абстрактный scaffold “для любых будущих проектов”
крупный refactor, который не сокращает время до следующей законченной фичи в самом DeployMate

Что сейчас уже НЕ является хорошим следующим шагом:

ещё один абстрактный раунд улучшения scaffold
возврат полного server CRUD обратно на /app
создание второго server screen рядом с server-review

Git Cadence

Чтобы GitHub выглядел презентабельно, правило должно быть простое:

коммитить не по каждой мелочи, а по каждому законченному логическому куску
пушить не после каждого коммита, а после осмысленного checkpoint

Практически это значит:

хороший коммит:
- одна понятная тема
- проходит релевантную локальную проверку
- имеет внятное сообщение
плохой коммит:
- смесь scaffold, backend, docs и UI без общей идеи
- “fix”, “wip”, “tmp”, если этого можно избежать
- промежуточное сломанное состояние без причины

Нормальная частота:

коммит: когда завершён один смысловой кусок работы
push: когда собран 1 хороший коммит или маленькая серия из 2-3 связанных коммитов
для длинной сессии: лучше несколько чистых коммитов и один push серии, чем 12 мелких push подряд

Простой ориентир:

если изменение уже можно объяснить одной короткой фразой, это кандидат на коммит
если локально уже не стыдно открыть diff в PR, это кандидат на push

Для этого репо хороший стиль такой:

1 коммит на платформенный/infra кусок
1 коммит на конкретную продуктовую фичу
push после того, как оба куска собираются в аккуратную историю

Fast Resume

Открой HANDOFF.md.
Проверь текущее состояние:
- git status --short
- git rev-parse --short HEAD
Если продолжаешь server-review track:
- открой server-review/page.js
- открой starter-api.js
- открой servers.py
- открой test_server_api_flow.py
Если продолжаешь runtime detail track:
- открой page.js
- открой project_automation_smoke_checks.sh
Если продолжаешь backend runtime trace track:
- открой deployment_mutations.py
- открой test_deployment_routes.py
- открой test_deployment_api_flow.py
Если продолжаешь restore preparation track:
- открой users/page.js
- открой root.py
- открой test_restore_dry_run.py
Если продолжаешь runtime destructive-guardrails track:
- открой page.js
- открой project_automation_smoke_checks.sh
Быстрые проверки:
- cd backend && venv/bin/python -m unittest tests.test_server_api_flow
- cd backend && venv/bin/python -m unittest tests.test_deployment_routes tests.test_deployment_api_flow
- cd backend && venv/bin/python -m unittest tests.test_restore_dry_run
- npm --prefix frontend run build
- FRONTEND_SMOKE_PORT=3006 npm --prefix frontend run smoke:runtime
- FRONTEND_SMOKE_PORT=3007 npm --prefix frontend run smoke:restore
Если цель — завершить этот пакет:
- проверить docs/handoff diff
- собрать commit

FilesExpand file tree

HANDOFF.md

Latest commit

History

HANDOFF.md

File metadata and controls

DeployMate Handoff

Web Terminal Pointer

Current Product Goal

Current Security Boundary

Current Build Reality

Current Release Reality

Next Recommended Package

Week 1 Result

Week 2 Focus

Week 2 Progress

Current State

Product Rule

Short Version

What Was Actually Done

1. Scaffold был проверен на реальной фиче

2. Server review стал полноценным контуром

3. Старый дублирующий server flow на /app был упрощён

4. Лишний backend starter-мусор был удалён

5. Реальный update flow серверов добавлен в backend

6. Runtime detail стал нормальным handoff surface

7. Backend activity стал полезнее для runtime review

8. Restore dry-run стал явным import-preparation decision surface

9. Restore dry-run теперь ловит cross-section reference risks

10. Restore workspace стал полезнее для ручного review

11. Delete deployment получил нормальные destructive guardrails

12. Restore import preparation стал более структурированным рабочим слоем

13. Появился узкий DeployMate vertical feature scaffold

14. Import review стал отдельным recovery workspace

15. Restore и import-review теперь связаны в один recovery маршрут

16. Import review получил готовый approval trail для handoff

17. Import review теперь доводит review до controlled preparation handoff

18. Началась UX-пересборка вокруг явного главного действия

19. /app начал превращаться в сценарный вход в продукт

20. Recovery path получил явную последовательность шагов

21. Upgrade inbox начал переходить в guided review path

22. Users разделился на team-access path и recovery path

23. Deployment/runtime/templates ушли в отдельный workflow screen

24. Deployment detail стал более intent-first runtime workspace

25. Template lifecycle стал связнее между deployment detail и deployment workflow

26. Create и redeploy стали ближе по guardrails и объясняющему слою

27. Redeploy стал review-first, а не submit-first

28. Delete и redeploy получили более единый человеческий review language

29. Reviewer-facing rollout copy стал общим слоем между overview, workflow и detail

Important Practical Meaning

What Was Verified

Best Next Step

Git Cadence

Fast Resume

3. Старый дублирующий server flow на `/app` был упрощён

19. `/app` начал превращаться в сценарный вход в продукт