Template server variables and presets

[t1]

Parent: #13 (Multi-server support)

Depends on: #39 (Global server selector panel)

Add support for OpenAPI server template variables ({variable} placeholders in server URLs) with named presets for quick switching between variable combinations.

Scope

Template detection:

• Identify servers with {variable} placeholders in URLs
• Read variable definitions: name, default value, enum values, description

Default preset:

• If all variables have defaults, auto-generate a preset with default values (labeled with resolved URL)
• Default preset cannot be deleted

"+ Add preset" form:

• Per-template button opens an inline form
• Input field per variable (dropdown/select for enum-constrained variables, text input otherwise)
• Save creates a new radio entry labeled with the resolved URL
• Cancel dismisses the form

Preset management:

• User-created presets can be deleted (delete button per preset)
• Multiple template servers supported — each has its own presets
• Presets persisted in localStorage

JS:

• Template variable resolution (substitute variables into URL template)
• Preset CRUD (create, delete)
• On preset selection, update data-base-url and header display
• Persistence of presets in localStorage

Design spec

See docs/superpowers/specs/2026-04-11-issue-13-multi-server-support-design.md

[t1]

Agent: starting work

Type: Feature
Summary: Extends the global server selector (#39) to support OpenAPI server template variables. Template servers will display their URL pattern with nested presets (radio buttons) for quick switching between variable combinations. Auto-generates a default preset when all variables have defaults, plus "+ Add preset" form for user-defined combinations.

Design decisions:

• Template servers display URL pattern with nested indented presets below
• Preset radio buttons labeled with resolved URL (not custom names)
• Default preset auto-generated when all variables have defaults (cannot be deleted)
• User-created presets deletable via delete button
• Variables with enum constraints use dropdown/select, others use text input
• Presets stored in localStorage as JSON per template server
• Template substitution happens in JS when preset is selected

Acceptance criteria:

• Template servers detected and variables extracted from spec
• Default preset auto-generated when possible
• "+ Add preset" button opens inline form with variable inputs
• Preset selection updates data-base-url with resolved URL
• Presets persist across page reloads
• User-created presets can be deleted
• Multiple template servers supported independently

Files:

• core/src/main/java/com/github/t1/openapi/ui/generator/OpenApiUiGenerator.java (extend serverSelector() method)
• core/src/main/resources/com/github/t1/openapi/ui/generator/app.js (template resolution, preset CRUD, persistence)
• New test fixture: core/src/test/resources/template-servers.yaml
• core/src/test/java/com/github/t1/openapi/ui/BrowserTest.java (add template variable tests)

[t1]

Question from agent

Context: Phase 4 (Implement), mid-way through TDD cycles

Question: This feature requires significant structural changes to both Java HTML generation and JavaScript runtime code:

1. Java side (~3-4 TDD cycles):

   • Detect template servers via server.getVariables()
   • Change HTML structure: template URL as heading + nested preset radios (not flat radios)
   • Auto-generate default preset when all variables have defaults
   • Generate variable metadata (name, default, enum, description) in data attributes

2. JavaScript side (~2-3 TDD cycles):

   • Template variable resolution (substitute {var} → value)
   • Preset CRUD (create form, save/delete presets)
   • Update data-base-url on preset selection
   • LocalStorage persistence for presets

Should I:

1. Complete the full implementation in this session (estimated 60-80k tokens, 3-4 hours)
2. Implement Java side only (HTML generation) and defer JS to next issue
3. Create sub-issues for Java generation vs JS runtime vs persistence

Impact: Option 1 completes #40 but risks running out of tokens mid-implementation. Option 2 delivers partial functionality. Option 3 breaks the work into committable chunks.

[t1]

Use Option 3

[t1]

Agent: resuming work

Found answer from owner. Continuing from where the previous agent left off.