How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

wow-viewer CLI GUI Surface Plan - Prompt

Name: wow-viewer CLI GUI Surface Plan
Author: akspa0

Prompt file imported from akspa0/parp-tools (.codex/prompts/wow-viewer-cli-gui-surface-plan.md). Copyright stays with the author.

Design the dual-surface tool plan for wow-viewer so the reformed tool suite can expose both CLI commands and GUI panels without duplicating format logic or workflow code.

Read First

gillijimproject_refactor/memory-bank/activeContext.md
gillijimproject_refactor/memory-bank/progress.md
gillijimproject_refactor/src/MdxViewer/memory-bank/activeContext.md
AGENTS.md
gillijimproject_refactor/plans/v0_5_0_wow_viewer_bootstrap_and_migration_draft_2026-03-25.md

Goal

Define how the new tool suite exposes the same shared capability through both CLI and GUI surfaces, using one service layer instead of separate implementations for panels, commands, and one-off executables.

Existing GUI/Interactive Inputs To Account For

MdxViewer sidebars, inspectors, exporters, previewers, and conversion panels
asset-catalog and screenshot workflows
PM4 and WDL utilities
terrain import/export and related panel-driven workflows
dataset explorer and supervision or curation workflows
training-review or launch workflows that need local-only reproducibility without bundled proprietary outputs

Existing CLI/Headless Inputs To Account For

WoWMapConverter.Cli
AlphaWdtAnalyzer.Cli
Pm4Research.Cli
WlAnalyzer
any old console-style tools in parpToolbox, PM4Tool, ADTPrefabTool, and WoWRollback
Python-side dataset or training scripts that should eventually become wow-viewer-owned orchestration or manifest surfaces instead of permanent standalone owners

Non-Negotiable Constraints

CLI and GUI must call the same first-party shared services.
Panel code must not own file parsing, conversion, or export logic.
CLI tools must not become second-class wrappers around hidden GUI behavior.
Batch/headless workflows must remain possible for converter/export/audit operations.
Long-running operations should have service boundaries that work in both interactive and non-interactive hosts.
Bring Your Own Data constraints must hold across both surfaces; the tool should not depend on shipping copyrighted corpora, trained models, or proprietary model outputs.
Training or inference orchestration should be driven by shared configs and service boundaries, not separate ad-hoc GUI-only or CLI-only launch code.
Do not assume CUDA-only execution in the long-range design. Backend-specific runners should plug into the same shared orchestration seams.

What The Plan Must Produce

The shared service boundary for dual-surface tooling.
The CLI command families.
The GUI panel families.
Which tool capabilities should be CLI-only, GUI-only, or dual-surface.
Progress/reporting/cancellation design across both surfaces.
The first dual-surface workflow to build.
The migration risks if surfaces stay duplicated.
Which training or explorer capabilities should remain local-only and non-distributable.
Where backend-runner abstraction belongs.

Deliverables

Return all items:

service-layer breakdown
CLI command tree
GUI panel tree
dual-surface mapping by tool family
cancellation/progress/reporting design
first workflow to implement in both surfaces
duplication risks still remaining

First Output

Start with:

the tool families that most need dual-surface support
the shared services they should sit on
which capabilities should stay CLI-only or GUI-only for now
the first end-to-end workflow you would implement both ways

Install wow-viewer CLI GUI Surface Plan and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

Design the dual-surface tool plan for `wow-viewer` so the reformed tool suite can expose both CLI commands and GUI panels without duplicating format logic or workflow code. ## Read First 1. `gillijimproject_refactor/memory-bank/activeContext.md` 2. `gillijimproject_refactor/memory-bank/progress.md` 3. `gillijimproject_refactor/src/MdxViewer/memory-bank/activeContext.md` 4. `AGENTS.md` 5. `gillijimproject_refactor/plans/v0_5_0_wow_viewer_bootstrap_and_migration_draft_2026-03-25.md` ## Goal Define how the new tool suite exposes the same shared capability through both CLI and GUI surfaces, using one service layer instead of separate implementations for panels, commands, and one-off executables. ## Existing GUI/Interactive Inputs To Account For - `MdxViewer` sidebars, inspectors, exporters, previewers, and conversion panels - asset-catalog and screenshot workflows - PM4 and WDL utilities - terrain import/export and related panel-driven workflows - dataset explorer and supervision or curation workflows - training-review or launch workflows that need local-only reproducibility without bundled proprietary outputs ## Existing CLI/Headless Inputs To Account For - `WoWMapConverter.Cli` - `AlphaWdtAnalyzer.Cli` - `Pm4Research.Cli` - `WlAnalyzer` - any old console-style tools in `parpToolbox`, `PM4Tool`, `ADTPrefabTool`, and `WoWRollback` - Python-side dataset or training scripts that should eventually become wow-viewer-owned orchestration or manifest surfaces instead of permanent standalone owners ## Non-Negotiable Constraints - CLI and GUI must call the same first-party shared services. - Panel code must not own file parsing, conversion, or export logic. - CLI tools must not become second-class wrappers around hidden GUI behavior. - Batch/headless workflows must remain possible for converter/export/audit operations. - Long-running operations should have service boundaries that work in both interactive and non-interactive hosts. - Bring Your Own Data constraints must hold across both surfaces; the tool should not depend on shipping copyrighted corpora, trained models, or proprietary model outputs. - Training or inference orchestration should be driven by shared configs and service boundaries, not separate ad-hoc GUI-only or CLI-only launch code. - Do not assume CUDA-only execution in the long-range design. Backend-specific runners should plug into the same shared orchestration seams. ## What The Plan Must Produce 1. The shared service boundary for dual-surface tooling. 2. The CLI command families. 3. The GUI panel families. 4. Which tool capabilities should be CLI-only, GUI-only, or dual-surface. 5. Progress/reporting/cancellation design across both surfaces. 6. The first dual-surface workflow to build. 7. The migration risks if surfaces stay duplicated. 8. Which training or explorer capabilities should remain local-only and non-distributable. 9. Where backend-runner abstraction belongs. ## Deliverables Return all items: 1. service-layer breakdown 2. CLI command tree 3. GUI panel tree 4. dual-surface mapping by tool family 5. cancellation/progress/reporting design 6. first workflow to implement in both surfaces 7. duplication risks still remaining ## First Output Start with: 1. the tool families that most need dual-surface support 2. the shared services they should sit on 3. which capabilities should stay CLI-only or GUI-only for now 4. the first end-to-end workflow you would implement both ways

{ "prompt": "Design the dual-surface tool plan for `wow-viewer` so the reformed tool suite can expose both CLI commands and GUI panels without duplicating format logic or workflow code.\n\n## Read First\n\n1. `gillijimproject_refactor/memory-bank/activeContext.md`\n2. `gillijimproject_refactor/memory-bank/progress.md`\n3. `gillijimproject_refactor/src/MdxViewer/memory-bank/activeContext.md`\n4. `AGENTS.md`\n5. `gillijimproject_refactor/plans/v0_5_0_wow_viewer_bootstrap_and_migration_draft_2026-03-25.md`\n\n## Goal\n\nDefine how the new tool suite exposes the same shared capability through both CLI and GUI surfaces, using one service layer instead of separate implementations for panels, commands, and one-off executables.\n\n## Existing GUI/Interactive Inputs To Account For\n\n- `MdxViewer` sidebars, inspectors, exporters, previewers, and conversion panels\n- asset-catalog and screenshot workflows\n- PM4 and WDL utilities\n- terrain import/export and related panel-driven workflows\n- dataset explorer and supervision or curation workflows\n- training-review or launch workflows that need local-only reproducibility without bundled proprietary outputs\n\n## Existing CLI/Headless Inputs To Account For\n\n- `WoWMapConverter.Cli`\n- `AlphaWdtAnalyzer.Cli`\n- `Pm4Research.Cli`\n- `WlAnalyzer`\n- any old console-style tools in `parpToolbox`, `PM4Tool`, `ADTPrefabTool`, and `WoWRollback`\n- Python-side dataset or training scripts that should eventually become wow-viewer-owned orchestration or manifest surfaces instead of permanent standalone owners\n\n## Non-Negotiable Constraints\n\n- CLI and GUI must call the same first-party shared services.\n- Panel code must not own file parsing, conversion, or export logic.\n- CLI tools must not become second-class wrappers around hidden GUI behavior.\n- Batch/headless workflows must remain possible for converter/export/audit operations.\n- Long-running operations should have service boundaries that work in both interactive and non-interactive hosts.\n- Bring Your Own Data constraints must hold across both surfaces; the tool should not depend on shipping copyrighted corpora, trained models, or proprietary model outputs.\n- Training or inference orchestration should be driven by shared configs and service boundaries, not separate ad-hoc GUI-only or CLI-only launch code.\n- Do not assume CUDA-only execution in the long-range design. Backend-specific runners should plug into the same shared orchestration seams.\n\n## What The Plan Must Produce\n\n1. The shared service boundary for dual-surface tooling.\n2. The CLI command families.\n3. The GUI panel families.\n4. Which tool capabilities should be CLI-only, GUI-only, or dual-surface.\n5. Progress/reporting/cancellation design across both surfaces.\n6. The first dual-surface workflow to build.\n7. The migration risks if surfaces stay duplicated.\n8. Which training or explorer capabilities should remain local-only and non-distributable.\n9. Where backend-runner abstraction belongs.\n\n## Deliverables\n\nReturn all items:\n\n1. service-layer breakdown\n2. CLI command tree\n3. GUI panel tree\n4. dual-surface mapping by tool family\n5. cancellation/progress/reporting design\n6. first workflow to implement in both surfaces\n7. duplication risks still remaining\n\n## First Output\n\nStart with:\n\n1. the tool families that most need dual-surface support\n2. the shared services they should sit on\n3. which capabilities should stay CLI-only or GUI-only for now\n4. the first end-to-end workflow you would implement both ways", "variables": [], "notes": "Plan how wow-viewer tools should exist both as CLI commands and GUI panels over the same shared services. Use when refactoring old tools into dual-surface workflows instead of duplicated apps. Arguments: Optional tool family, panel, command, or workflow to prioritize.", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/akspa0/parp-tools", "path": ".codex/prompts/wow-viewer-cli-gui-surface-plan.md", "ref": "4f7fb94cfad6bf6348c55c28ae9361c2d2fd9cb7", "url": "https://github.com/akspa0/parp-tools/blob/4f7fb94cfad6bf6348c55c28ae9361c2d2fd9cb7/.codex/prompts/wow-viewer-cli-gui-surface-plan.md", "key": "akspa0/parp-tools/.codex/prompts/wow-viewer-cli-gui-surface-plan.md" } } }

wow-viewer CLI GUI Surface Plan

About

Read First

Goal

Existing GUI/Interactive Inputs To Account For

Existing CLI/Headless Inputs To Account For

Non-Negotiable Constraints

What The Plan Must Produce

Deliverables

First Output

Install wow-viewer CLI GUI Surface Plan and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews