Add named batch-processing presets

[LostOne1000]

Priority

Medium

Summary

Add named batch-processing presets that capture reusable combinations of batch settings.

The current batch dialog remembers only the most recently used values. Users need multiple saved configurations for workflows such as:

• Generate all metadata.
• Keywords only.
• Title and caption only.
• Skip already processed photos.
• Reprocess existing Llama metadata.
• Stock metadata.
• Editorial metadata.

A preset may reference a saved user prompt template and a saved system prompt, but those remain independent records managed by the prompt-library feature.

Current behavior

The batch dialog persists individual values such as:

prefs.batchPrompt
prefs.batchUseCurrentData
prefs.batchUseSystemPrompt
prefs.batchSkipExisting
prefs.batchGenerateTitle
prefs.batchGenerateCaption
prefs.batchGenerateKeywords
prefs.batchSelectedModel

This restores the previous configuration but does not support named alternatives.

Proposed preset model

{
    schemaVersion = 1,
    presets = {
        {
            id = "keywords-only",
            name = "Keywords Only",
            userPromptTemplateId = "default-user-prompt",
            userPromptSnapshot = "Generate accurate metadata for this image.",
            systemPromptId = "default-metadata-system",
            useSystemPrompt = true,
            useCurrentData = false,
            skipExisting = true,
            generateTitle = false,
            generateCaption = false,
            generateKeywords = true,
            selectedModel = "gemma4:latest"
        }
    }
}

A preset may contain:

• Stable ID.
• Display name.
• User prompt-template ID.
• User-prompt fallback snapshot.
• System-prompt ID.
• Whether the system prompt is enabled.
• Use-current-data setting.
• Skip-existing setting.
• Generate-title setting.
• Generate-caption setting.
• Generate-keywords setting.
• Optional selected model.

The user prompt and system prompt must be referenced separately.

Excluded preset data

A preset must not contain:

• Ollama server address.
• Connection status.
• Available-model list.
• Selected photos.
• Progress state.
• Processing results.
• Temporary image paths.

The server must always come from the centralized Plug-in Manager preference introduced by the server-settings issue.

Proposed implementation

1. Add BatchPresetService.lua

Create a pure-Lua service responsible for:

• Returning built-in presets.
• Loading user presets.
• Validating presets.
• Creating stable IDs.
• Creating presets.
• Updating presets.
• Duplicating presets.
• Renaming presets.
• Deleting user presets.
• Protecting built-in presets.
• Serializing presets with JSON.lua.
• Recovering from corrupt preference data.
• Migrating schema versions.
• Applying a preset to a plain state table.
• Detecting whether live settings differ from the selected preset.

Store presets under dedicated preferences such as:

prefs.batchPresetsJson
prefs.lastBatchPresetId

2. Add built-in presets

Provide a small set of read-only defaults.

All metadata

Title: enabled
Caption: enabled
Keywords: enabled
Skip existing: enabled

Keywords only

Title: disabled
Caption: disabled
Keywords: enabled

Title and caption

Title: enabled
Caption: enabled
Keywords: disabled

Users may duplicate built-in presets to create editable copies.

3. Integrate user prompt templates

A preset may store:

• The stable ID of a user prompt template.
• A fallback snapshot of the user prompt text.

The snapshot allows the preset to remain usable when the referenced template has been deleted.

When a referenced template is missing:

• Use the stored snapshot.
• Display a non-blocking warning.
• Do not recreate the deleted template.
• Do not silently rewrite the preset.

The preset’s generation checkboxes remain independent from the selected user prompt template.

4. Integrate system prompts separately

A preset may independently store:

• The selected system-prompt ID.
• Whether Use System Prompt is enabled.

The selected system prompt must not be embedded inside the user prompt template.

When the referenced system prompt is missing:

• Fall back to the documented built-in system prompt.
• Display a non-blocking warning.
• Preserve the stored preset until the user explicitly updates it.

5. Integrate model selection

A preset may optionally identify a model.

Model availability and fallback behavior should use the model-resolution behavior implemented by issue #8.

When the saved model is unavailable:

• Keep the preset selected.
• Fall back through the model rules from Persist model selection and improve vision-model handling #8.
• Display a warning.
• Do not silently modify the preset.

This issue should not independently implement model-persistence rules.

6. Add batch-dialog controls

At the top of the batch dialog, add:

• Preset popup.
• New.
• Save As.
• Update.
• Duplicate.
• Rename.
• Delete.

Suggested behavior:

• Selecting a preset applies it to the live batch state.
• Editing any preset-controlled field marks the configuration as modified.
• The UI displays Preset Name (modified) or switches to Custom.
• Updating requires an explicit action.
• Delete requires confirmation.
• Built-in presets cannot be updated or deleted.

7. Preserve Custom configuration

Maintain a separate Custom configuration representing the last manually entered batch values.

When switching from Custom to a preset and back:

• Restore the previous Custom values.
• Do not overwrite Custom merely by selecting a preset.
• Starting a batch may update the saved Custom state only when the current configuration is Custom.

8. Migrate existing batch preferences

On first use after upgrade:

• Build the Custom configuration from the existing prefs.batch* values.
• Preserve the previous prompt and checkbox choices.
• Preserve the previous batch-model preference.
• Do not automatically create a named preset from the old values.
• Do not delete the legacy values until migration behavior is tested and stable.

9. Keep preset logic out of BatchLrLlama.lua

Do not implement preset validation, persistence, comparison, and migration directly inside the batch entry-point file.

At minimum:

• Put business logic in BatchPresetService.lua.
• Keep dialog callbacks thin.
• Add an extracted batch controller or state service if needed for testability.

Dependencies

Recommended implementation order:

1. Move the Ollama server to the Plug-in Manager settings pane.
2. Complete issue Persist model selection and improve vision-model handling #8 for model persistence and model fallback.
3. Implement separate user prompt templates and system prompts.
4. Implement batch-processing presets.

The preset feature may be developed earlier with dependency injection and placeholder IDs, but final integration depends on those stable services.

Testing

Add tests covering:

• Built-in presets.
• Creating presets.
• Updating presets.
• Duplication.
• Renaming.
• Deletion.
• Protection of built-in presets.
• Duplicate-name handling.
• Serialization and deserialization.
• Corrupt preference recovery.
• Schema-version handling.
• Applying a preset.
• Modified-state detection.
• Preserving Custom values.
• Migration from existing prefs.batch* values.
• Missing user-template fallback.
• Missing system-prompt fallback.
• Missing-model fallback.
• Independent title, caption, and keyword checkboxes.
• Exclusion of the Ollama server from preset data.
• Last-selected preset restoration.
• Production wiring into the batch dialog.

Out of scope

• Per-preset Ollama servers.
• Scheduling batches.
• Selecting collections or photos through a preset.
• Online preset sharing.
• Preset import and export.
• Conditional rules based on rating, folder, camera, or metadata.
• Automatic model installation.
• Embedding system prompts inside user prompt templates.

Acceptance criteria

• Users can select named presets in the batch dialog.
• Users can create, update, duplicate, rename, and delete user presets.
• Built-in presets are read-only.
• Presets persist across Lightroom sessions.
• Presets store title, caption, and keyword checkbox values independently.
• Presets may reference a user prompt template.
• Presets may separately reference a system prompt.
• User prompt templates do not determine output-checkbox values.
• Presets never store the Ollama server address.
• Applying a preset updates the live batch state.
• Live edits do not modify the stored preset without an explicit action.
• The dialog indicates when a preset has been modified.
• Custom values survive switching between presets.
• Existing batch preferences migrate without data loss.
• Missing prompts and models fall back predictably.
• Preset logic is unit tested outside Lightroom.
• Preset business logic is not implemented directly in the batch entry-point file.