···166166 respondentLanguageOptions:
167167 visitor: Use visitor's language
168168 showProgress: Show form progress
169169+ showProgressHelp: Show respondents where they are in the form.
170170+ allowBackNavigation: Allow going back to previous steps
171171+ allowBackNavigationHelp: Let respondents return to earlier visited steps in the public form runner.
169172 copyLink: Copy link
170173 openRunner: Open runner
171174 deleteForm: Delete form
+3
locales/ru.yml
···166166 respondentLanguageOptions:
167167 visitor: Использовать язык посетителя
168168 showProgress: Показывать прогресс формы
169169+ showProgressHelp: Показывать респондентам, на каком шаге формы они находятся.
170170+ allowBackNavigation: Разрешить возврат к предыдущим шагам
171171+ allowBackNavigationHelp: Разрешить респондентам возвращаться к уже пройденным шагам в публичном раннере формы.
169172 copyLink: Скопировать ссылку
170173 openRunner: Открыть раннер
171174 deleteForm: Удалить форму
···11+## Context
22+33+The public form runner currently models navigation as a visited-route history plus a cursor. That supports branching, respondent backtracking, and resumed sessions, but it assumes every published form allows backward movement. Form settings already persist respondent-facing runner options such as progress visibility and interface locale, so a new navigation-control setting fits the same metadata path. Because this change touches persisted form data, creator settings UI, public runner behavior, and draft restore semantics, a short design is useful before implementation.
44+55+## Goals / Non-Goals
66+77+**Goals:**
88+- Let creators decide per form whether respondents may navigate back to earlier visited steps.
99+- Preserve the existing experience for all current forms by defaulting to back navigation enabled.
1010+- Enforce the setting consistently in the live runner and after saved-progress restoration.
1111+- Keep the implementation aligned with existing form metadata storage, validation, and serialization patterns.
1212+1313+**Non-Goals:**
1414+- Introducing per-block or conditional navigation locks.
1515+- Preventing browser-level page refresh/close/navigation outside the runner UI itself.
1616+- Reworking branching, submission validation, or progress calculations beyond the changes needed to respect the new setting.
1717+- Adding new respondent roles, authentication, or anti-tampering guarantees beyond existing public runner behavior.
1818+1919+## Decisions
2020+2121+### 1. Store back-navigation control as a persisted form-level boolean
2222+The system will add a boolean form field such as `allowBackNavigation` with a default of `true`, and include it in builder/public form payloads plus form metadata validation.
2323+2424+**Why:** This setting is authored form behavior, similar to `showProgress` and `respondentLocale`, and must survive draft saves, publication, and later edits.
2525+2626+**Alternatives considered:**
2727+- Keep the value only in client state: rejected because respondent behavior must follow the saved form, not the current creator session.
2828+- Encode the behavior indirectly from branching rules or block settings: rejected because the request is a simple form-wide navigation policy.
2929+3030+### 2. Expose the control in form settings next to other respondent-experience options
3131+The builder will surface the option in the form settings panel alongside respondent language and progress visibility, using clear copy that explains the setting applies to respondents in the public runner.
3232+3333+**Why:** Creators already manage runner-wide presentation and behavior in this panel, so adding one more runner-level control keeps discovery and mental model simple.
3434+3535+**Alternatives considered:**
3636+- Add a separate advanced settings area: rejected because the feature is straightforward and would be harder to find.
3737+- Put the option on each block: rejected because the requested behavior is form-wide, not per-step.
3838+3939+### 3. Enforce the rule at the runner action layer, not only in the UI
4040+When `allowBackNavigation` is false, the public runner will not render the back action and will also guard any back-navigation code paths so route state cannot move backward through helper calls or keyboard handling.
4141+4242+**Why:** UI hiding alone is fragile. Central action-level enforcement keeps behavior correct if the component grows more navigation triggers later.
4343+4444+**Alternatives considered:**
4545+- Hide only the back button: rejected because future shortcuts or internal calls could accidentally bypass the setting.
4646+- Rebuild the route model without a cursor/history concept: rejected because the current route model still works for forward progression and restore validation.
4747+4848+### 4. Keep saved-progress restoration compatible and honor the current form setting on resume
4949+Stored drafts do not need to persist a separate copy of the back-navigation flag. On restore, the runner can continue restoring answers/history/cursor as it does today, but resumed interaction must use the current form setting to decide whether backward movement is available.
5050+5151+**Why:** The restored state describes where the respondent is, while the form setting describes what navigation actions are currently allowed. This avoids invalidating saved progress just because the creator toggled the setting.
5252+5353+**Alternatives considered:**
5454+- Include the flag in the draft fingerprint and invalidate drafts whenever it changes: rejected because restoring current position is still safe and less disruptive.
5555+- Force-collapsing restored history when back navigation is disabled: rejected because forward flow and progress calculations still benefit from the visited route.
5656+5757+## Risks / Trade-offs
5858+5959+- [Creators may expect the setting to prevent all browser back behavior] → Mitigation: scope copy and specs to runner back navigation within the form UI, not global browser history control.
6060+- [Hidden UI without logic guards could regress later] → Mitigation: centralize enforcement in the runner navigation handler/helper path and cover it with tests.
6161+- [Existing forms could change behavior unexpectedly] → Mitigation: default the stored field to `true` and treat missing legacy values as enabled.
6262+- [Restored sessions might feel inconsistent if creators change the setting mid-response] → Mitigation: honor the latest saved form behavior while still restoring the respondent's current step and answers.
6363+6464+## Migration Plan
6565+6666+- Add a new boolean column on `Form` with default `true`.
6767+- Thread the field through form loading, builder serialization, and metadata validation.
6868+- Update the builder settings save flow to persist the value.
6969+- Update public runner rendering and tests to respect the flag.
7070+- Rollback is low risk: the code can ignore the field and default behavior remains equivalent to enabled back navigation.
7171+7272+## Open Questions
7373+7474+- None currently. The requested behavior is clear enough to implement as a form-level boolean with a default-enabled migration.
···11+## Why
22+33+The public form runner currently always lets respondents move backward through their visited path. That works for editable interview-style flows, but some forms need creators to lock answers once a respondent advances so later questions cannot be influenced by revisiting earlier steps.
44+55+## What Changes
66+77+- Add a per-form setting that lets creators choose whether respondents can navigate backward in the public form runner.
88+- Preserve the current behavior as the default so existing forms continue allowing back navigation.
99+- Update the public runner to hide or disable backward navigation when the setting is off while keeping forward progress, validation, branching, and submission intact.
1010+- Ensure saved draft progress and resumed sessions honor the form's configured back-navigation mode.
1111+1212+## Capabilities
1313+1414+### New Capabilities
1515+- None.
1616+1717+### Modified Capabilities
1818+- `conversational-form-builder`: add a form-level setting for whether respondents may go back to earlier steps in the public runner.
1919+- `anonymous-form-runner`: allow forms to disable respondent back navigation and enforce that behavior consistently during active and restored sessions.
2020+2121+## Impact
2222+2323+- Affected code: Prisma form model, form settings validation and serialization, creator builder settings UI, public form runner navigation logic, runner draft restore behavior, and related tests/spec coverage.
2424+- No new external dependencies are expected.
2525+- Existing forms should remain backward-compatible by defaulting to back navigation enabled.
···11+## MODIFIED Requirements
22+33+### Requirement: Runner presents blocks in a linear one-at-a-time flow
44+The system SHALL present form blocks one at a time starting from the first saved block and SHALL resolve each next block by evaluating the current block's saved branch rules against the respondent's current answer. If no branch rule matches, the system SHALL continue to the block's configured default next target when present, or otherwise continue to the next block in saved order. Text blocks SHALL remain part of the flow but SHALL NOT collect an answer. When the form allows respondent back navigation, the system SHALL allow backward navigation across the respondent's visited path and SHALL recalculate future visited steps when a prior answer changes. When the form disables respondent back navigation, the system SHALL keep the respondent moving forward only and SHALL NOT expose runner controls that return to earlier visited steps.
55+66+#### Scenario: Respondent sees a conditional follow-up question
77+- **WHEN** a respondent answers a question with a value that matches a saved branch rule pointing to a later follow-up block
88+- **THEN** the system shows that follow-up block as the next step in the runner
99+1010+#### Scenario: Respondent skips a branch-only follow-up
1111+- **WHEN** a respondent answers a question with a value that does not match any saved branch rule
1212+- **THEN** the system continues to the next block in saved order instead of showing the branched follow-up block
1313+1414+#### Scenario: Respondent changes an earlier branching answer when back navigation is enabled
1515+- **WHEN** a respondent navigates backward on a form that allows back navigation, changes an answer that controls branching, and continues again
1616+- **THEN** the system recalculates the subsequent route from that changed answer and replaces the no-longer-valid future steps
1717+1818+#### Scenario: Respondent uses a form with back navigation disabled
1919+- **WHEN** a respondent advances past a step on a form that disables back navigation
2020+- **THEN** the system does not provide runner navigation that returns them to an earlier visited step
2121+2222+## ADDED Requirements
2323+2424+### Requirement: Restored public runner sessions honor the form's back-navigation mode
2525+The system SHALL restore saved public-runner progress only when the saved route remains valid for the current form, and resumed interaction SHALL honor the form's currently configured back-navigation mode.
2626+2727+#### Scenario: Respondent resumes a form with back navigation disabled
2828+- **WHEN** a respondent restores saved progress for a form whose current settings disable back navigation
2929+- **THEN** the system restores the saved current step and answers without exposing runner navigation that goes back to earlier visited steps
3030+3131+#### Scenario: Respondent resumes a form with back navigation enabled
3232+- **WHEN** a respondent restores saved progress for a form whose current settings allow back navigation
3333+- **THEN** the system restores the saved current step and continues allowing backward navigation across the restored visited path
···11+## ADDED Requirements
22+33+### Requirement: Creator can configure respondent back navigation per form
44+The system SHALL allow an authenticated creator to configure whether respondents may navigate backward to earlier visited steps in the public form runner for any accessible form. The setting SHALL default to enabled for existing and newly created forms unless the creator explicitly disables it.
55+66+#### Scenario: Creator leaves back navigation enabled
77+- **WHEN** an authenticated creator keeps the respondent back-navigation setting enabled and saves form settings
88+- **THEN** the system persists the form with respondent back navigation allowed
99+1010+#### Scenario: Creator disables back navigation
1111+- **WHEN** an authenticated creator disables respondent back navigation in form settings and saves
1212+- **THEN** the system persists the form so respondents can continue forward but cannot return to earlier visited steps in the public runner
1313+1414+#### Scenario: Creator reopens form settings with back navigation disabled
1515+- **WHEN** an authenticated creator opens settings for a form that already has respondent back navigation disabled
1616+- **THEN** the system shows the saved disabled state as the current value
···11+## 1. Persist form-level back-navigation settings
22+33+- [x] 1.1 Add a persisted `allowBackNavigation` form field with a default-enabled migration for existing and new forms
44+- [x] 1.2 Thread `allowBackNavigation` through form metadata validation, form serialization, and builder/public form TypeScript types
55+- [x] 1.3 Add or update validation tests to confirm the setting defaults to `true` and preserves explicit disabled values
66+77+## 2. Expose the setting in creator form settings
88+99+- [x] 2.1 Extend the form settings draft/save flow so creators can edit and persist the respondent back-navigation option
1010+- [x] 2.2 Update the form settings panel UI and localized copy to explain the option alongside other respondent-experience controls
1111+- [x] 2.3 Add builder UI tests covering default enabled behavior, disabling the setting, and reopening settings with a saved disabled value
1212+1313+## 3. Enforce the setting in the public form runner
1414+1515+- [x] 3.1 Update public runner navigation logic to block backward route movement when `allowBackNavigation` is false while preserving forward progression, validation, and branching
1616+- [x] 3.2 Update the runner UI so back navigation controls are only shown when the form allows them
1717+- [x] 3.3 Add runner state/component tests covering enabled back navigation, disabled back navigation, and branching after forward-only progression
1818+1919+## 4. Honor the setting during saved-progress restore
2020+2121+- [x] 4.1 Ensure restored runner sessions continue from the saved step while honoring the form's current `allowBackNavigation` mode
2222+- [x] 4.2 Add restore-focused tests proving resumed sessions do not expose backward navigation when the setting is disabled and still allow it when enabled
+18-3
openspec/specs/anonymous-form-runner/spec.md
···1212- **THEN** the system does not allow public response collection for that form
13131414### Requirement: Runner presents blocks in a linear one-at-a-time flow
1515-The system SHALL present form blocks one at a time starting from the first saved block and SHALL resolve each next block by evaluating the current block's saved branch rules against the respondent's current answer. If no branch rule matches, the system SHALL continue to the block's configured default next target when present, or otherwise continue to the next block in saved order. Text blocks SHALL remain part of the flow but SHALL NOT collect an answer. The system SHALL allow backward navigation across the respondent's visited path and SHALL recalculate future visited steps when a prior answer changes.
1515+The system SHALL present form blocks one at a time starting from the first saved block and SHALL resolve each next block by evaluating the current block's saved branch rules against the respondent's current answer. If no branch rule matches, the system SHALL continue to the block's configured default next target when present, or otherwise continue to the next block in saved order. Text blocks SHALL remain part of the flow but SHALL NOT collect an answer. When the form allows respondent back navigation, the system SHALL allow backward navigation across the respondent's visited path and SHALL recalculate future visited steps when a prior answer changes. When the form disables respondent back navigation, the system SHALL keep the respondent moving forward only and SHALL NOT expose runner controls that return to earlier visited steps.
16161717#### Scenario: Respondent sees a conditional follow-up question
1818- **WHEN** a respondent answers a question with a value that matches a saved branch rule pointing to a later follow-up block
···2222- **WHEN** a respondent answers a question with a value that does not match any saved branch rule
2323- **THEN** the system continues to the next block in saved order instead of showing the branched follow-up block
24242525-#### Scenario: Respondent changes an earlier branching answer
2626-- **WHEN** a respondent navigates backward, changes an answer that controls branching, and continues again
2525+#### Scenario: Respondent changes an earlier branching answer when back navigation is enabled
2626+- **WHEN** a respondent navigates backward on a form that allows back navigation, changes an answer that controls branching, and continues again
2727- **THEN** the system recalculates the subsequent route from that changed answer and replaces the no-longer-valid future steps
2828+2929+#### Scenario: Respondent uses a form with back navigation disabled
3030+- **WHEN** a respondent advances past a step on a form that disables back navigation
3131+- **THEN** the system does not provide runner navigation that returns them to an earlier visited step
3232+3333+### Requirement: Restored public runner sessions honor the form's back-navigation mode
3434+The system SHALL restore saved public-runner progress only when the saved route remains valid for the current form, and resumed interaction SHALL honor the form's currently configured back-navigation mode.
3535+3636+#### Scenario: Respondent resumes a form with back navigation disabled
3737+- **WHEN** a respondent restores saved progress for a form whose current settings disable back navigation
3838+- **THEN** the system restores the saved current step and answers without exposing runner navigation that goes back to earlier visited steps
3939+4040+#### Scenario: Respondent resumes a form with back navigation enabled
4141+- **WHEN** a respondent restores saved progress for a form whose current settings allow back navigation
4242+- **THEN** the system restores the saved current step and continues allowing backward navigation across the restored visited path
28432944### Requirement: Runner shows progress across the full flow
3045The system SHALL display progress based on the respondent's current visited route rather than assuming every saved block will appear, and SHALL update the visible step indicator when branching or backtracking changes that route.
···144144- **WHEN** an authenticated creator opens settings for a form that already has a saved respondent interface locale override
145145- **THEN** the system shows the saved override as the current selected value
146146147147+### Requirement: Creator can configure respondent back navigation per form
148148+The system SHALL allow an authenticated creator to configure whether respondents may navigate backward to earlier visited steps in the public form runner for any accessible form. The setting SHALL default to enabled for existing and newly created forms unless the creator explicitly disables it.
149149+150150+#### Scenario: Creator leaves back navigation enabled
151151+- **WHEN** an authenticated creator keeps the respondent back-navigation setting enabled and saves form settings
152152+- **THEN** the system persists the form with respondent back navigation allowed
153153+154154+#### Scenario: Creator disables back navigation
155155+- **WHEN** an authenticated creator disables respondent back navigation in form settings and saves
156156+- **THEN** the system persists the form so respondents can continue forward but cannot return to earlier visited steps in the public runner
157157+158158+#### Scenario: Creator reopens form settings with back navigation disabled
159159+- **WHEN** an authenticated creator opens settings for a form that already has respondent back navigation disabled
160160+- **THEN** the system shows the saved disabled state as the current value
161161+147162### Requirement: Builder reflects the active workspace context
148163The system SHALL show the active workspace context when a creator creates or edits a form so they can tell whether the form belongs to their personal workspace or an organization.
149164