DesignCorp Docs

Appearance

Landing Operating Standard ​

Обновлено: 2026-03-17

Назначение ​

Это канонический документ по продуктовой и технической модели landing.

Он фиксирует:

  • public vs workspace границу;
  • definition vs instance модель;
  • publish/runtime contract;
  • shell canon;
  • access model;
  • i18n model;
  • owner operating rules.

Документ синхронизирован с текущим кодом в репозитории landing.

Scope ​

  • Репозиторий: /home/admin/workspace/landing
  • Prod: https://landing.designcorp.eu
  • Dev: https://dev.landing.designcorp.eu
  • GitHub board: Project #10

Runtime Layout ​

  • Dev runtime runs from /home/admin/workspace/landing via landing-dev.service.
  • Prod runtime runs only from /opt/designcorp/landing/prod/current via landing-prod.service.
  • Prod releases are created under /opt/designcorp/landing/prod/releases/<timestamp>-<sha>.
  • GitHub main deploy must create a temporary main worktree from /home/admin/workspace/landing and remove it after deploy.
  • Permanent extra checkouts such as /home/admin/workspace/landing-main are not part of the canonical steady-state layout.

1. Product Model ​

landing — это не просто builder-страница, а полный контур:

  1. Section Builder
  • definition-driven authoring;
  • draft -> publish to library;
  • section defaults, bindings, settings, variants.
  1. Landing Builder
  • instance-driven page editing;
  • block-level overrides;
  • draft -> publish snapshot.
  1. Templates
  • immutable page snapshots;
  • стартовая точка для create-project.
  1. Runtime
  • published pages rendered from snapshots;
  • canonical URL strategy;
  • lead capture and project-level webhook/email delivery.
  1. Owner Workspace
  • admin / builder / section-builder / templates / leads / integrations / domains / media.

2. Public vs Workspace Model ​

Это две разные entry-модели.

Public ​

  • /{locale}
  • /{locale}/{projectSlug}
  • /{locale}/{projectSlug}/{pageSlug}
  • canonical host resolution:
    1. verified custom domain
    2. verified managed project subdomain
    3. fallback root-host route

Workspace ​

  • /{locale}/admin
  • /{locale}/builder/{pageId}
  • /{locale}/section-builder
  • /{locale}/templates
  • /{locale}/workspace

Правило:

  • public routes индексируются и ведут в продукт;
  • workspace routes — owner-only operational surfaces.

3. Definition vs Instance Contract ​

Это главный контракт всей системы.

Section Definition ​

  • живёт в library;
  • имеет version lifecycle;
  • редактируется в Section Builder;
  • publish создаёт новую published definition version.

Section Instance ​

  • живёт внутри проекта/страницы;
  • редактируется в Landing Builder;
  • может иметь block-level overrides;
  • pinned to definitionVersionId.

Жёсткое правило:

  • instance override не меняет library;
  • новая published definition version не переписывает старые page instances автоматически.

4. Publish / Runtime Model ​

Project Draft ​

  • changes happen in draft;
  • autosave / ops + CAS;
  • preview route reads current draft snapshot model.

Publish ​

  • publish creates immutable page snapshot;
  • snapshot becomes active runtime source;
  • rollback activates previous snapshot version.

Runtime ​

  • public runtime renders only from published snapshot;
  • template preview and draft preview should stay as close as possible to runtime output;
  • SEO and canonical metadata derive from the same public URL contract.

5. Workspace Shell Canon ​

Все owner surfaces должны идти через один WorkspaceShell contract.

Shell parts ​

  1. Topbar
  • route context
  • actions
  • environment/status
  1. Left Rail
  • navigation, library, outline, selected-node summary
  1. Canvas / Content
  • primary work surface
  1. Right Inspector
  • relevant editor controls only

Canonical rule ​

admin, builder, section-builder, templates, leads, domains, media должны ощущаться как один продукт, а не набор разных интерфейсов.

6. Section Builder Model ​

Section Builder — это definition-driven component tree editor.

Он не должен становиться:

  • Figma-like free canvas;
  • arbitrary CSS editor;
  • pixel-perfect freeform tool.

Он должен оставаться:

  • primitive-driven;
  • schema-driven;
  • token-driven.

Текущий authoring lifecycle:

  1. New Section
  2. Empty или Preset
  3. Draft definition
  4. Node editing
  5. Autosave draft
  6. Publish to Library

7. Landing Builder Model ​

Landing Builder редактирует page instances.

Current contract:

  • section-level and block-level selection;
  • instance overrides for mapped blocks;
  • publish affects only page snapshot, not library definitions.

Target rule:

  • любой поддержанный runtime block выбирается и редактируется как instance object;
  • inspector behaves predictably for Content / Media, Layout, Style.

8. Access Model ​

Owner access is a product rule, not a visual rule.

Protected surfaces ​

  • /{locale}/admin
  • /{locale}/builder/{pageId}
  • /{locale}/section-builder
  • /{locale}/templates
  • /{locale}/workspace
  • owner APIs:
    • /api/admin/**
    • /api/pages/**
    • /api/section-definitions/**
    • /api/templates/**
    • /api/constructor/bootstrap
    • /api/media/** except public media content

Current session contract ​

  • cookie: landing_admin_session
  • roles:
    • owner
    • manager
  • fallback integration access:
    • x-admin-token

Login path:

  • /{locale}/admin/login

Workspace entry:

  • /{locale}/workspace

9. I18n Model ​

Public/runtime ​

Supported locales:

  • ru
  • en
  • pl
  • ua

Workspace ​

Current shipping scope:

  • ru
  • en

Rule:

  • workspace strings must be dictionary-driven;
  • no critical owner flow may depend on hardcoded English copy.

10. Owner Operating Rules ​

Daily product path ​

  1. login
  2. choose template / create project
  3. open builder
  4. edit page instance blocks
  5. publish
  6. open live URL
  7. inspect leads / integrations / domains

Section authoring path ​

  1. open section-builder
  2. create or select definition
  3. edit defaults/settings/bindings
  4. publish to library
  5. use new section in landing builder

11. Dev Baseline Rules ​

stitch-prototype/home is the canonical clean baseline for:

  • builder regression
  • preview/runtime parity checks
  • owner manual walkthroughs

12. Release Gate ​

Canonical release gate:

bash
cd /home/admin/workspace/landing
set -a && . ./.env.local && set +a
BASE_URL=https://dev.landing.designcorp.eu LOCALE=ru pnpm test:smoke:release-gate

Gate is go only if:

  • lint = pass
  • build = pass
  • editor-stability = pass
  • template-lifecycle = pass
  • integrations = pass
  • outbox = pass
  • runtime-parity = pass
  • launch = pass
  • owner-access = pass

If dev is polluted by smoke data, use baseline reset instead of manual database cleanup.

12. Related Docs ​