···127127 unpublish: Unpublish
128128 blocks: Blocks
129129 newBlock: New block
130130+ openGraphMode: Open branching graph
131131+ graphModeEyebrow: Branching view
132132+ graphModeTitle: Branching graph
133133+ graphModeDescription: See the full route structure, select a block, and edit how respondents move through the form.
134134+ exitGraphMode: Back to editor
135135+ graphCanvasAria: Branching graph canvas
136136+ graphNodeIndex: "Block {number}"
137137+ graphNodeRoutes: "{count} route(s)"
138138+ graphNodeNoRoutes: No outgoing routes
139139+ graphEmptyTitle: No blocks to map yet
140140+ graphEmptyDescription: Add blocks to start laying out the form flow.
141141+ graphSelectionEyebrow: Routing
142142+ graphSelectionTitle: Select a block to edit its routes
143143+ graphSelectionDescription: Click a node or route in the graph to inspect its branching settings.
144144+ graphTextBlockDescription: Text blocks appear in the flow, but only question blocks can define branching routes.
145145+ graphSelectedRoute: "Selected route: {route} → {target}"
146146+ graphEditDescription: Review the selected block's default path and branch rules.
147147+ graphLinearRoute: Next
148148+ graphDefaultRoute: Default
130149 settingsTitle: Settings
131150 titleField: Title
132151 shareSlug: Public URL address
···180199 branchNoValueNeeded: No value needed for this operator.
181200 branchingHelp: 'Leave a rule unmatched to use the default path. Example value: "{value}".'
182201 branchingNoTargets: Add a later block before creating branch rules from this question.
202202+ endFormAfterBlock: End form after this block
203203+ endFormAfterBlockDescription: Submit the response immediately after this block instead of continuing to another block.
204204+ endFormDisablesBranching: While this is enabled, this block ignores its saved branch rules and default path.
183205 dragBranchRuleAria: "Drag branch rule {number}"
184206 removeBranchRuleAria: "Remove branch rule {number}"
185207 branchMissingTarget: Missing target block
+22
locales/ru.yml
···127127 unpublish: Снять с публикации
128128 blocks: Блоки
129129 newBlock: Новый блок
130130+ openGraphMode: Открыть граф ветвления
131131+ graphModeEyebrow: Ветвление
132132+ graphModeTitle: Граф ветвления
133133+ graphModeDescription: Просматривайте всю структуру переходов, выбирайте блок и редактируйте маршруты, по которым респонденты проходят форму.
134134+ exitGraphMode: Назад к редактору
135135+ graphCanvasAria: Холст графа ветвления
136136+ graphNodeIndex: "Блок {number}"
137137+ graphNodeRoutes: "Маршрутов: {count}"
138138+ graphNodeNoRoutes: Нет исходящих маршрутов
139139+ graphEmptyTitle: Пока нечего раскладывать на графе
140140+ graphEmptyDescription: Добавьте блоки, чтобы построить маршрут формы.
141141+ graphSelectionEyebrow: Маршрутизация
142142+ graphSelectionTitle: Выберите блок, чтобы редактировать его маршруты
143143+ graphSelectionDescription: Нажмите на блок или маршрут на графе, чтобы посмотреть и изменить настройки ветвления.
144144+ graphTextBlockDescription: Текстовые блоки показываются в потоке, но задавать маршруты могут только блоки с ответом.
145145+ graphSelectedRoute: "Выбранный маршрут: {route} → {target}"
146146+ graphEditDescription: Проверьте маршрут по умолчанию и правила ветвления для выбранного блока.
147147+ graphLinearRoute: Дальше
148148+ graphDefaultRoute: По умолчанию
130149 settingsTitle: Настройки
131150 titleField: Название
132151 shareSlug: Адрес публичного URL
···180199 branchNoValueNeeded: Для этого оператора значение не требуется.
181200 branchingHelp: 'Если ни одно правило не совпало, форма использует маршрут по умолчанию. Пример значения: "{value}".'
182201 branchingNoTargets: Добавьте более поздний блок, прежде чем создавать правила ветвления для этого вопроса.
202202+ endFormAfterBlock: Завершить форму после этого блока
203203+ endFormAfterBlockDescription: Сразу отправить ответ после этого блока вместо перехода к следующему.
204204+ endFormDisablesBranching: Пока эта опция включена, блок игнорирует сохранённые правила ветвления и маршрут по умолчанию.
183205 dragBranchRuleAria: "Перетащить правило ветвления {number}"
184206 removeBranchRuleAria: "Удалить правило ветвления {number}"
185207 branchMissingTarget: Целевой блок отсутствует
···11+## Context
22+33+Branching is already supported in the conversational form builder, but configuration is centered on the currently selected block and its inspector controls. That works for isolated edits, yet it becomes difficult to reason about the overall route structure when a form has multiple branch paths, shared targets, or unreachable sections.
44+55+The requested change adds a graph-first branching workspace that creators can open from the builder chrome. The graph view must use the full available page width, temporarily hide the usual sidebar-based builder layout, and keep the form readable even when the form is still purely linear.
66+77+The existing branching model, save APIs, publish validation, and block ordering rules already define the source of truth. The graph view should therefore be a new interaction layer over existing block and branch data rather than a parallel persistence model.
88+99+## Goals / Non-Goals
1010+1111+**Goals:**
1212+- Give creators a graph-based view of the form's branching structure.
1313+- Add a clear entry point next to the existing create-block action.
1414+- Use a full-width workspace that prioritizes graph readability over the normal sidebar layout.
1515+- Lay out nodes from left to right according to saved block order so linear and branched forms are both understandable.
1616+- Allow creators to inspect and edit branching relationships without introducing a second branching system.
1717+- Reuse existing branch validation and save semantics.
1818+1919+**Non-Goals:**
2020+- Replacing the standard block editor as the default builder mode.
2121+- Introducing freeform graph editing with arbitrary node placement persistence.
2222+- Changing the meaning of existing branch rules, default-next behavior, or publish validation.
2323+- Adding respondent-facing graph visualizations.
2424+- Redesigning unrelated builder settings outside the branching workflow.
2525+2626+## Decisions
2727+2828+### 1. Add a dedicated graph mode toggle in the builder toolbar
2929+The builder will expose a compact branching button beside the existing create-block action. Activating it switches the builder into a graph-focused mode; exiting returns the creator to the standard builder layout.
3030+3131+**Why:** This keeps branching discoverable without making graph mode the default experience for simple forms.
3232+3333+**Alternatives considered:**
3434+- Put graph mode inside each block's branching editor: rejected because it hides a form-level workflow inside a block-level surface.
3535+- Replace the default builder with a graph view: rejected because most day-to-day edits are still block-content edits.
3636+3737+### 2. Build the graph from existing ordered block and branching data
3838+Each node will correspond to a saved block in form order. Edges will be derived from the saved default-next target and each saved branch rule target. The horizontal flow will follow block order from left to right, while branching paths can create vertical separation as needed.
3939+4040+**Why:** This preserves one source of truth and ensures the graph reflects the same routing model used for saving, validation, and respondent execution.
4141+4242+**Alternatives considered:**
4343+- Store separate graph nodes and edges: rejected because it would duplicate routing state and create sync risk.
4444+- Use free-drag placement as the canonical layout: rejected because the request is about understanding flow, not maintaining manual diagrams.
4545+4646+### 3. Use deterministic auto-layout instead of user-saved node positions
4747+The graph should compute positions from block order and branching relationships each time it renders. Linear forms will therefore appear as a simple left-to-right chain, while branched forms will fan outward only where routing requires it.
4848+4949+**Why:** Deterministic layout avoids persistence complexity and keeps the graph stable across sessions.
5050+5151+**Alternatives considered:**
5252+- Persist custom coordinates per block: rejected as unnecessary complexity for the first version.
5353+- Render a simple list with connectors: rejected because it would not provide enough spatial clarity for richer branch graphs.
5454+5555+### 4. Keep editing bound to existing branch rule operations
5656+Graph interactions should map back to the current branching model: selecting a node or edge opens graph-mode controls for editing branch rules or default-next behavior using the same rule schema already enforced elsewhere. Saving from graph mode should use the existing block save flows.
5757+5858+**Why:** This avoids creating different rule semantics between the inspector view and graph view.
5959+6060+**Alternatives considered:**
6161+- Make graph mode read-only in the first version: rejected because the request is for a branching settings interface, not only visualization.
6262+- Create graph-specific mutation APIs: rejected because existing block update APIs already own branching persistence.
6363+6464+### 5. Graph mode temporarily replaces the sidebar layout
6565+When graph mode is active, the normal left block list and standard editor sidebar will be hidden so the graph can take the full page width. Graph-specific actions and context will live in the graph workspace itself.
6666+6767+**Why:** The graph needs the width that the normal two-pane layout would otherwise consume, and the request explicitly calls for the sidebar to be hidden.
6868+6969+**Alternatives considered:**
7070+- Keep the sidebar visible beside the graph: rejected because it reduces graph readability and conflicts with the requested layout.
7171+- Open the graph in a modal: rejected because large branching structures need a persistent full-screen workspace.
7272+7373+## Risks / Trade-offs
7474+7575+- **Dense graphs may still become visually busy** → Use deterministic spacing, directional edges, and focus/selection states to keep active paths readable.
7676+- **Dual editing surfaces can drift behaviorally** → Reuse the same branch-rule data model, validation, and save pipeline in both standard and graph modes.
7777+- **Full-width graph mode may hide useful navigation context** → Provide an obvious exit back to the standard builder and preserve the last selected block when returning.
7878+- **Auto-layout may not match every creator's mental model** → Favor stable order-based positioning so the graph stays predictable, even if it is less customizable.
7979+8080+## Migration Plan
8181+8282+- No data migration is required because the graph is derived from existing form blocks and branch configuration.
8383+- Rollback is low risk: disabling graph mode leaves the current builder and saved branching data unchanged.
8484+8585+## Open Questions
8686+8787+- Whether graph mode should support creating new branch rules directly from edge handles, or start with selection-driven editing only.
8888+- Whether graph mode needs viewport controls such as zoom-to-fit and minimap in the first implementation, or whether panning plus fit-on-open is sufficient.
···11+## Why
22+33+Branching is currently configured through per-block settings, which makes it hard to understand the overall flow of a form once multiple paths are involved. A dedicated graph view would let creators see the full branching structure at once and move between routing relationships more confidently.
44+55+## What Changes
66+77+- Add a branching graph entry point next to the existing create-block action in the builder toolbar.
88+- Add a full-width graph view for branching configuration that temporarily replaces the normal sidebar-based builder layout.
99+- Represent each block as a node laid out from left to right, with edges for saved default-next and branch-rule targets.
1010+- Keep linear forms readable in the graph view by laying blocks out left to right even when no branching is configured.
1111+- Allow creators to inspect and manage branching relationships from the graph-focused interface while preserving existing branching rules and validation behavior.
1212+1313+## Capabilities
1414+1515+### New Capabilities
1616+- None.
1717+1818+### Modified Capabilities
1919+- `conversational-form-builder`: extend builder behavior to include a graph-based branching view and graph-specific navigation for configuring routing relationships.
2020+2121+## Impact
2222+2323+- Affected code: builder layout, branching settings UI, graph rendering components, builder navigation controls, and related interaction tests.
2424+- APIs: no new external API is expected; the feature should continue using the existing block and branching save flows.
2525+- Dependencies/systems: likely frontend-only unless a graph-specific serialization need is discovered during implementation.
···11+## ADDED Requirements
22+33+### Requirement: Builder provides a full-page branching graph workspace
44+The system SHALL allow an authenticated creator to open a graph-based branching workspace from the form builder. The graph workspace SHALL temporarily replace the standard sidebar-based builder layout and use the full available page width to visualize block-to-block routing.
55+66+#### Scenario: Creator opens graph mode from the builder toolbar
77+- **WHEN** an authenticated creator clicks the branching graph action beside the create-block action in the builder toolbar
88+- **THEN** the system opens the branching graph workspace for the current form
99+1010+#### Scenario: Graph mode replaces the sidebar layout
1111+- **WHEN** an authenticated creator opens the branching graph workspace
1212+- **THEN** the system hides the normal block-list sidebar and standard editor panel while the graph workspace is active
1313+1414+#### Scenario: Creator exits graph mode
1515+- **WHEN** an authenticated creator leaves the branching graph workspace
1616+- **THEN** the system returns to the standard builder layout for the same form
1717+1818+### Requirement: Branching graph workspace visualizes routing from left to right
1919+The system SHALL render each saved form block as a graph node and SHALL derive graph edges from the saved default-next target and saved branch-rule targets for each block. The graph SHALL lay blocks out from left to right in saved block order and SHALL keep linear forms readable even when no branching is configured.
2020+2121+#### Scenario: Creator views a linear form in graph mode
2222+- **WHEN** an authenticated creator opens graph mode for a form with no branching rules or default-next overrides
2323+- **THEN** the system displays the blocks as a left-to-right sequence of nodes
2424+2525+#### Scenario: Creator views a branched form in graph mode
2626+- **WHEN** an authenticated creator opens graph mode for a form with saved branch rules or default-next targets
2727+- **THEN** the system displays node connections that represent those possible next-block routes
2828+2929+#### Scenario: Graph nodes follow saved block order
3030+- **WHEN** an authenticated creator views the branching graph workspace
3131+- **THEN** the system positions nodes so the primary horizontal reading order follows the saved form block order from left to right
3232+3333+### Requirement: Creator can manage branching relationships from graph mode
3434+The system SHALL allow an authenticated creator to inspect and update a block's branching relationships from the graph workspace using the same branching rule model and validation rules as the standard builder.
3535+3636+#### Scenario: Creator inspects a block's routing from graph mode
3737+- **WHEN** an authenticated creator selects a block node in the branching graph workspace
3838+- **THEN** the system shows that block's current default-next target and branch-rule relationships for editing
3939+4040+#### Scenario: Creator saves branching changes from graph mode
4141+- **WHEN** an authenticated creator updates a block's branching relationships in graph mode and saves
4242+- **THEN** the system persists those changes through the existing block branching save flow
4343+4444+#### Scenario: Graph mode preserves existing branching validation
4545+- **WHEN** an authenticated creator saves branching changes from graph mode that would violate existing branching validation rules
4646+- **THEN** the system rejects publishing or saving in the same way as the standard branching workflow requires
···11+## 1. Graph mode entry and layout shell
22+33+- [x] 1.1 Add a graph-mode toggle button with branching icon next to the create-block action in the builder toolbar.
44+- [x] 1.2 Add builder state for entering and leaving graph mode while preserving the current form and selection context.
55+- [x] 1.3 Render a full-width graph workspace that hides the standard sidebar and editor layout while graph mode is active.
66+77+## 2. Graph data and visualization
88+99+- [x] 2.1 Add a graph data helper that converts saved blocks, default-next targets, and branch rules into graph nodes and edges.
1010+- [x] 2.2 Implement deterministic left-to-right layout so linear forms render as a simple sequence and branched forms fan out from saved block order.
1111+- [x] 2.3 Render graph nodes and edges with readable labels and selection states for blocks and routing relationships.
1212+1313+## 3. Graph-mode branching editing
1414+1515+- [x] 3.1 Add graph-mode controls for inspecting the selected block's default-next target and branch rules.
1616+- [x] 3.2 Reuse the existing block branching save flow so graph-mode edits persist through current APIs and draft handling.
1717+- [x] 3.3 Ensure graph-mode editing preserves existing branching validation and surfaces blocking/advisory issues consistently.
1818+1919+## 4. Verification
2020+2121+- [x] 4.1 Add unit coverage for graph data and layout derivation from linear and branched forms.
2222+- [x] 4.2 Add interaction coverage for entering graph mode, leaving graph mode, and editing branching relationships from the graph workspace.
2323+- [x] 4.3 Manually verify graph mode on linear and branched forms, including full-width layout behavior and save/validation flows.
···191191#### Scenario: Creator introduces a fragile but still valid branch setup
192192- **WHEN** an authenticated creator creates a branch setup that is structurally valid but likely fragile or overlapping
193193- **THEN** the system surfaces an advisory warning without preventing the draft from being saved
194194+195195+### Requirement: Builder provides a full-page branching graph workspace
196196+The system SHALL allow an authenticated creator to open a graph-based branching workspace from the form builder. The graph workspace SHALL temporarily replace the standard sidebar-based builder layout and use the full available page width to visualize block-to-block routing.
197197+198198+#### Scenario: Creator opens graph mode from the builder toolbar
199199+- **WHEN** an authenticated creator clicks the branching graph action beside the create-block action in the builder toolbar
200200+- **THEN** the system opens the branching graph workspace for the current form
201201+202202+#### Scenario: Graph mode replaces the sidebar layout
203203+- **WHEN** an authenticated creator opens the branching graph workspace
204204+- **THEN** the system hides the normal block-list sidebar and standard editor panel while the graph workspace is active
205205+206206+#### Scenario: Creator exits graph mode
207207+- **WHEN** an authenticated creator leaves the branching graph workspace
208208+- **THEN** the system returns to the standard builder layout for the same form
209209+210210+### Requirement: Branching graph workspace visualizes routing from left to right
211211+The system SHALL render each saved form block as a graph node and SHALL derive graph edges from the saved default-next target and saved branch-rule targets for each block. The graph SHALL lay blocks out from left to right in saved block order and SHALL keep linear forms readable even when no branching is configured.
212212+213213+#### Scenario: Creator views a linear form in graph mode
214214+- **WHEN** an authenticated creator opens graph mode for a form with no branching rules or default-next overrides
215215+- **THEN** the system displays the blocks as a left-to-right sequence of nodes
216216+217217+#### Scenario: Creator views a branched form in graph mode
218218+- **WHEN** an authenticated creator opens graph mode for a form with saved branch rules or default-next targets
219219+- **THEN** the system displays node connections that represent those possible next-block routes
220220+221221+#### Scenario: Graph nodes follow saved block order
222222+- **WHEN** an authenticated creator views the branching graph workspace
223223+- **THEN** the system positions nodes so the primary horizontal reading order follows the saved form block order from left to right
224224+225225+### Requirement: Creator can manage branching relationships from graph mode
226226+The system SHALL allow an authenticated creator to inspect and update a block's branching relationships from the graph workspace using the same branching rule model and validation rules as the standard builder.
227227+228228+#### Scenario: Creator inspects a block's routing from graph mode
229229+- **WHEN** an authenticated creator selects a block node in the branching graph workspace
230230+- **THEN** the system shows that block's current default-next target and branch-rule relationships for editing
231231+232232+#### Scenario: Creator saves branching changes from graph mode
233233+- **WHEN** an authenticated creator updates a block's branching relationships in graph mode and saves
234234+- **THEN** the system persists those changes through the existing block branching save flow
235235+236236+#### Scenario: Graph mode preserves existing branching validation
237237+- **WHEN** an authenticated creator saves branching changes from graph mode that would violate existing branching validation rules
238238+- **THEN** the system rejects publishing or saving in the same way as the standard branching workflow requires