The Variable Management System implements a three-tier variable architecture that enables template-based prompt construction with configurable placeholders. The system manages three distinct layers of variables—predefined (system-built-in), global (user-defined), and temporary (session-scoped)—with automatic priority resolution and mode-specific persistence strategies. This document covers variable storage, priority rules, session isolation, and integration with the template processor. For template structure and variable substitution syntax, see Template System. For session state persistence, see Session Management with Pinia.
The system organizes variables into three hierarchical tiers, each with distinct lifecycle and scope characteristics.
Sources:
| Tier | Storage | Lifecycle | Scope | Use Case |
|---|---|---|---|---|
| Temporary | Session store (Pro/Image) Memory (Basic) | Until mode switch or reset | Mode-specific | Per-session test inputs, temporary overrides |
| Global | VariableManager → PreferenceService | Persistent across sessions | Application-wide | User-defined reusable values |
| Predefined | PREDEFINED_VARIABLES constant | Immutable | Application-wide | System-provided contextual values |
Sources:
Predefined variables are system-built-in placeholders that reference runtime state. These variables are read-only and automatically populated by the application.
Predefined Variable Descriptions (from i18n):
| Variable Name | Description | Usage Context |
|---|---|---|
originalPrompt | Current original prompt content | All optimization modes |
lastOptimizedPrompt | Last optimized prompt result | Iteration operations |
iterateInput | Input content for iteration optimization | Iteration templates |
currentPrompt | Current prompt in use (optimized or original) | Testing phase |
userQuestion | User question or input | Pro Variable mode |
conversationContext | Current conversation context information | Pro Multi mode |
toolsContext | Available tools information (auto-injected) | Tool-enabled modes |
Sources:
Predefined variables are resolved dynamically at runtime from the variableManager.allVariables computed property, which aggregates contextual state from multiple sources (optimizer, context editor, etc.). If a predefined variable is not available in the current context, it defaults to an empty string.
Sources:
Global variables are user-defined key-value pairs that persist across sessions and are accessible application-wide. They are managed through useVariableManager() and stored via PreferenceService.
Sources:
Global variables must pass validation before being added:
| Validation Rule | Implementation |
|---|---|
| Name pattern | isValidVariableName(name) - Checks alphanumeric + underscore, no spaces |
| Reserved names | Cannot override predefined variable names |
| Sanitization | sanitizeVariableRecord() filters invalid entries before persistence |
Sources:
isValidVariableName, sanitizeVariableRecord)Temporary variables are mode-scoped variables with dynamic persistence behavior. Unlike global variables, temporary variables are isolated per operational mode and have different storage strategies depending on the function mode.
Sources:
Basic Mode:
useTemporaryVariablesStore (Pinia global store)Pro/Image Modes:
useProVariableSession, etc.)PreferenceService with mode-specific keysSources:
All operations route through useTemporaryVariables(), which dispatches to the appropriate session store:
Implementation Dispatch:
| Method | Basic Mode | Pro/Image Modes |
|---|---|---|
setVariable(name, value) | globalStore.setVariable() | sessionStore.setTemporaryVariable() |
getVariable(name) | globalStore.getVariable() | sessionStore.getTemporaryVariable() |
hasVariable(name) | globalStore.hasVariable() | sessionStore.hasTemporaryVariable() |
deleteVariable(name) | globalStore.deleteVariable() | sessionStore.deleteTemporaryVariable() |
clearAll() | globalStore.clearAll() | sessionStore.clearTemporaryVariables() |
Event-Driven Updates:
@variable-change events from test panelsuseTestVariableManager composableSources:
The useAggregatedVariables() composable merges all three variable tiers into a single unified view, applying strict priority rules.
Sources:
Given:
{ originalPrompt: "Hello", lastOptimizedPrompt: "" }{ userName: "Alice", originalPrompt: "Overridden" }{ userName: "Bob", testValue: "123" }Result (after aggregation):
Priority Application:
originalPrompt: Global overrides PredefineduserName: Temporary overrides GlobaltestValue: Only in TemporarylastOptimizedPrompt: Only in Predefined (no override)Sources:
useAggregatedVariables() provides getVariableSource(name) to determine which tier a variable originates from:
Sources:
Temporary variables in Pro and Image modes are persisted as part of the session state snapshot. Each session store includes a temporaryVariables field that is serialized to PreferenceService.
Sources:
Before saving temporary variables to session stores, the sanitizeVariableRecord() function filters out invalid entries:
Sanitization Rules:
isValidVariableName)Sources:
sanitizeVariableRecord)The system supports automatic variable extraction from prompts and smart value generation using LLMs.
The system provides two methods for variable extraction:
{{variableName}} patternsSources:
The extraction system uses the LLM's reasoning capabilities to identify implicit variables in prompts:
Extraction Request Structure:
Extraction Logic:
IPromptService.extractVariablesFromPrompt()VariableExtractionResultDialogSources:
The system can generate contextually appropriate default values for variables using AI analysis:
Generation Context:
Generation Output:
Implementation Details:
Sources:
The system enforces strict validation rules to prevent invalid variable names and ensure data integrity.
The system enforces strict naming rules via isValidVariableName():
Validation Logic:
/^[a-zA-Z_][a-zA-Z0-9_]*$/Predefined Name Protection:
isPredefinedVariable(name) before allowing creationvariables.errors.predefinedName in i18nSources:
isValidVariableName function)All session stores sanitize temporary variables before persistence and after restoration:
On Save:
On Restore:
Sources:
Variables are consumed by the template processor during prompt construction. The aggregated variable map is passed to template context for placeholder substitution.
Sources:
Variables are passed to multiple execution contexts depending on the operation:
Optimization Requests:
Test Execution:
Template Preview:
Variable Resolution Order in Execution:
useAggregatedVariables{{userName}} are replaced with actual values{{missingVar}} literals (triggering warnings)Sources:
The system detects variables referenced in templates or prompts that are not defined in any tier.
Detection Implementation:
/\{\{(\w+)\}\}/g extracts variable names from contentaggregatedVariables.hasVariable(name)User Resolution Flow:
VariableAwareInputadd-missing-variable event with variable name pre-filledContext-Aware Detection:
Sources:
Storage Keys:
| Data Type | Storage Key | Provider |
|---|---|---|
| Global Variables | variables/custom (inferred) | PreferenceService |
| Pro Variable Session | session/v1/pro-variable | PreferenceService |
| Pro Multi Session | session/v1/pro-multi | PreferenceService |
| Image Text2Image Session | session/v1/image/text2image | PreferenceService |
| Image Image2Image Session | session/v1/image/image2image | PreferenceService |
| Basic Temp Variables | (not persisted) | Memory-only |
Sources:
Refresh this wiki