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 Dataset Builder Plan - Prompt

Name: wow-viewer Dataset Builder Plan
Author: akspa0

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

Design the first-class wow-viewer dataset and supervised-training tool stack and the shared-library cutover it depends on.

Read First

gillijimproject_refactor/memory-bank/activeContext.md
gillijimproject_refactor/memory-bank/progress.md
gillijimproject_refactor/plans/wow_viewer_shared_io_library_plan_2026-03-26.md
gillijimproject_refactor/plans/wow_viewer_dataset_builder_tool_plan_2026-04-14.md
wow-viewer/README.md
AGENTS.md
.codex/prompts/wow-viewer-tool-inventory-cutover-plan.md
.codex/prompts/wow-viewer-shared-io-library-plan.md

Goal

Define the wow-viewer-owned dataset-builder stack so dataset export, terrain-supervision artifacts, dataset exploration, and supervised training orchestration stop depending on WoWMapConverter or MdxViewer as long-term owners.

Non-Negotiable Constraints

Do not keep adding new shared dataset/export logic to gillijimproject_refactor/src/WoWMapConverter/WoWMapConverter.Core/VLM when the ask is architectural cleanup or new capability.
Shared data contracts and artifact builders must live in wow-viewer/src/core/WowViewer.Core and wow-viewer/src/core/WowViewer.Core.IO before a tool surface claims ownership.
The dataset-builder should be a dedicated wow-viewer tool over shared services, not another legacy sidecar.
WoWMapConverter, MdxViewer, parpToolbox, and older scripts are extraction or compatibility references only unless the user explicitly asks for a bounded legacy hotfix.
ML training and inference scripts are downstream consumers; they do not own format decode, artifact packing, or manifest semantics.
The long-range user-facing surfaces should be explicit: shared library, CLI, viewer/editor workflows, dataset explorer, and supervised training tooling.
The workflow must be Bring Your Own Data. Do not assume the tool can ship copyrighted source data, harvested corpora, trained models, or model outputs.
Prefer reproducible local-run configs and metadata over redistributed outputs.
Do not assume CUDA is the only long-range backend. Call out where backend seams should stay open for Vulkan or OpenCL or MLX or other local runners.

Shared Surfaces To Classify Explicitly

ADT and WDT and WDL access and tile discovery
split ADT companion ownership (_tex0.adt, _obj0.adt, _lod.adt)
heightmaps, normalmaps, MCCV, alpha and shadow, liquid, and object or PM4 mask artifacts
minimap cleanup variants such as no-liquid, no-MCCV, no-object, and terrain-only outputs
archive-backed versus loose override resolution
dataset JSON contracts, manifests, metadata rows, and harvest packaging
corpus batch orchestration and resumable tile-map jobs
dataset explorer indexing, preview, filtering, and provenance surfaces
supervised labels, training manifests, experiment configs, and local launch metadata
backend-runner abstraction for local training or inference orchestration

What The Plan Must Produce

The target module tree in wow-viewer.
The boundary between shared libraries and the new CLI or viewer/editor or explorer or training-tool surfaces.
The artifact ownership matrix.
The absorb vs rewrite vs reference-only map for legacy exporter code.
The first vertical slice that proves the cutover is real.
The validation plan using real fixed client roots and dataset outputs.
What not to port or not to deepen in the legacy repo.
The BYOD and no-model-distribution policy surface.
The backend portability seams for local training or inference.

Deliverables

Return all items:

target wow-viewer module or tool layout
shared-contract ownership matrix
legacy exporter cutover map
first migration wave
highest-risk artifact seams
real-data validation plan
explicit no-go list for legacy ownership
BYOD and redistribution policy notes
backend portability strategy

First Output

Start with:

the exact dataset-builder problem you think the user is trying to solve
the shared data seams that must move first
the proposed wow-viewer tool boundary across CLI or viewer/editor or explorer or training surfaces
the legacy exporter code that should become reference-only first

Install wow-viewer Dataset Builder 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 first-class `wow-viewer` dataset and supervised-training tool stack and the shared-library cutover it depends on. ## Read First 1. `gillijimproject_refactor/memory-bank/activeContext.md` 2. `gillijimproject_refactor/memory-bank/progress.md` 3. `gillijimproject_refactor/plans/wow_viewer_shared_io_library_plan_2026-03-26.md` 4. `gillijimproject_refactor/plans/wow_viewer_dataset_builder_tool_plan_2026-04-14.md` 5. `wow-viewer/README.md` 6. `AGENTS.md` 7. `.codex/prompts/wow-viewer-tool-inventory-cutover-plan.md` 8. `.codex/prompts/wow-viewer-shared-io-library-plan.md` ## Goal Define the `wow-viewer`-owned dataset-builder stack so dataset export, terrain-supervision artifacts, dataset exploration, and supervised training orchestration stop depending on `WoWMapConverter` or `MdxViewer` as long-term owners. ## Non-Negotiable Constraints - Do not keep adding new shared dataset/export logic to `gillijimproject_refactor/src/WoWMapConverter/WoWMapConverter.Core/VLM` when the ask is architectural cleanup or new capability. - Shared data contracts and artifact builders must live in `wow-viewer/src/core/WowViewer.Core` and `wow-viewer/src/core/WowViewer.Core.IO` before a tool surface claims ownership. - The dataset-builder should be a dedicated `wow-viewer` tool over shared services, not another legacy sidecar. - `WoWMapConverter`, `MdxViewer`, `parpToolbox`, and older scripts are extraction or compatibility references only unless the user explicitly asks for a bounded legacy hotfix. - ML training and inference scripts are downstream consumers; they do not own format decode, artifact packing, or manifest semantics. - The long-range user-facing surfaces should be explicit: shared library, CLI, viewer/editor workflows, dataset explorer, and supervised training tooling. - The workflow must be Bring Your Own Data. Do not assume the tool can ship copyrighted source data, harvested corpora, trained models, or model outputs. - Prefer reproducible local-run configs and metadata over redistributed outputs. - Do not assume CUDA is the only long-range backend. Call out where backend seams should stay open for Vulkan or OpenCL or MLX or other local runners. ## Shared Surfaces To Classify Explicitly - ADT and WDT and WDL access and tile discovery - split ADT companion ownership (`_tex0.adt`, `_obj0.adt`, `_lod.adt`) - heightmaps, normalmaps, MCCV, alpha and shadow, liquid, and object or PM4 mask artifacts - minimap cleanup variants such as no-liquid, no-MCCV, no-object, and terrain-only outputs - archive-backed versus loose override resolution - dataset JSON contracts, manifests, metadata rows, and harvest packaging - corpus batch orchestration and resumable tile-map jobs - dataset explorer indexing, preview, filtering, and provenance surfaces - supervised labels, training manifests, experiment configs, and local launch metadata - backend-runner abstraction for local training or inference orchestration ## What The Plan Must Produce 1. The target module tree in `wow-viewer`. 2. The boundary between shared libraries and the new CLI or viewer/editor or explorer or training-tool surfaces. 3. The artifact ownership matrix. 4. The absorb vs rewrite vs reference-only map for legacy exporter code. 5. The first vertical slice that proves the cutover is real. 6. The validation plan using real fixed client roots and dataset outputs. 7. What not to port or not to deepen in the legacy repo. 8. The BYOD and no-model-distribution policy surface. 9. The backend portability seams for local training or inference. ## Deliverables Return all items: 1. target `wow-viewer` module or tool layout 2. shared-contract ownership matrix 3. legacy exporter cutover map 4. first migration wave 5. highest-risk artifact seams 6. real-data validation plan 7. explicit no-go list for legacy ownership 8. BYOD and redistribution policy notes 9. backend portability strategy ## First Output Start with: 1. the exact dataset-builder problem you think the user is trying to solve 2. the shared data seams that must move first 3. the proposed `wow-viewer` tool boundary across CLI or viewer/editor or explorer or training surfaces 4. the legacy exporter code that should become reference-only first

{ "prompt": "Design the first-class `wow-viewer` dataset and supervised-training tool stack and the shared-library cutover it depends on.\n\n## Read First\n\n1. `gillijimproject_refactor/memory-bank/activeContext.md`\n2. `gillijimproject_refactor/memory-bank/progress.md`\n3. `gillijimproject_refactor/plans/wow_viewer_shared_io_library_plan_2026-03-26.md`\n4. `gillijimproject_refactor/plans/wow_viewer_dataset_builder_tool_plan_2026-04-14.md`\n5. `wow-viewer/README.md`\n6. `AGENTS.md`\n7. `.codex/prompts/wow-viewer-tool-inventory-cutover-plan.md`\n8. `.codex/prompts/wow-viewer-shared-io-library-plan.md`\n\n## Goal\n\nDefine the `wow-viewer`-owned dataset-builder stack so dataset export, terrain-supervision artifacts, dataset exploration, and supervised training orchestration stop depending on `WoWMapConverter` or `MdxViewer` as long-term owners.\n\n## Non-Negotiable Constraints\n\n- Do not keep adding new shared dataset/export logic to `gillijimproject_refactor/src/WoWMapConverter/WoWMapConverter.Core/VLM` when the ask is architectural cleanup or new capability.\n- Shared data contracts and artifact builders must live in `wow-viewer/src/core/WowViewer.Core` and `wow-viewer/src/core/WowViewer.Core.IO` before a tool surface claims ownership.\n- The dataset-builder should be a dedicated `wow-viewer` tool over shared services, not another legacy sidecar.\n- `WoWMapConverter`, `MdxViewer`, `parpToolbox`, and older scripts are extraction or compatibility references only unless the user explicitly asks for a bounded legacy hotfix.\n- ML training and inference scripts are downstream consumers; they do not own format decode, artifact packing, or manifest semantics.\n- The long-range user-facing surfaces should be explicit: shared library, CLI, viewer/editor workflows, dataset explorer, and supervised training tooling.\n- The workflow must be Bring Your Own Data. Do not assume the tool can ship copyrighted source data, harvested corpora, trained models, or model outputs.\n- Prefer reproducible local-run configs and metadata over redistributed outputs.\n- Do not assume CUDA is the only long-range backend. Call out where backend seams should stay open for Vulkan or OpenCL or MLX or other local runners.\n\n## Shared Surfaces To Classify Explicitly\n\n- ADT and WDT and WDL access and tile discovery\n- split ADT companion ownership (`_tex0.adt`, `_obj0.adt`, `_lod.adt`)\n- heightmaps, normalmaps, MCCV, alpha and shadow, liquid, and object or PM4 mask artifacts\n- minimap cleanup variants such as no-liquid, no-MCCV, no-object, and terrain-only outputs\n- archive-backed versus loose override resolution\n- dataset JSON contracts, manifests, metadata rows, and harvest packaging\n- corpus batch orchestration and resumable tile-map jobs\n- dataset explorer indexing, preview, filtering, and provenance surfaces\n- supervised labels, training manifests, experiment configs, and local launch metadata\n- backend-runner abstraction for local training or inference orchestration\n\n## What The Plan Must Produce\n\n1. The target module tree in `wow-viewer`.\n2. The boundary between shared libraries and the new CLI or viewer/editor or explorer or training-tool surfaces.\n3. The artifact ownership matrix.\n4. The absorb vs rewrite vs reference-only map for legacy exporter code.\n5. The first vertical slice that proves the cutover is real.\n6. The validation plan using real fixed client roots and dataset outputs.\n7. What not to port or not to deepen in the legacy repo.\n8. The BYOD and no-model-distribution policy surface.\n9. The backend portability seams for local training or inference.\n\n## Deliverables\n\nReturn all items:\n\n1. target `wow-viewer` module or tool layout\n2. shared-contract ownership matrix\n3. legacy exporter cutover map\n4. first migration wave\n5. highest-risk artifact seams\n6. real-data validation plan\n7. explicit no-go list for legacy ownership\n8. BYOD and redistribution policy notes\n9. backend portability strategy\n\n## First Output\n\nStart with:\n\n1. the exact dataset-builder problem you think the user is trying to solve\n2. the shared data seams that must move first\n3. the proposed `wow-viewer` tool boundary across CLI or viewer/editor or explorer or training surfaces\n4. the legacy exporter code that should become reference-only first", "variables": [], "notes": "Plan the new wow-viewer dataset-builder tool and the cutover of shared dataset/export and supervised-training logic out of legacy tooling. Use when the task is ML corpus export ownership, terrain-supervision artifact generation, dataset explorer design, supervised training-tooling ownership, dataset manifest or harvest cutover, minimap cleanup or mask-stitch semantics, BYOD distribution policy, or deciding what shared data contracts must move into wow-viewer before replacing WoWMapConverter VLM tooling. Arguments: Describe the dataset-builder seam, artifact family, or legacy exporter path to converge.", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/akspa0/parp-tools", "path": ".codex/prompts/wow-viewer-dataset-builder-plan.md", "ref": "4f7fb94cfad6bf6348c55c28ae9361c2d2fd9cb7", "url": "https://github.com/akspa0/parp-tools/blob/4f7fb94cfad6bf6348c55c28ae9361c2d2fd9cb7/.codex/prompts/wow-viewer-dataset-builder-plan.md", "key": "akspa0/parp-tools/.codex/prompts/wow-viewer-dataset-builder-plan.md" } } }

wow-viewer Dataset Builder Plan

About

Read First

Goal

Non-Negotiable Constraints

Shared Surfaces To Classify Explicitly

What The Plan Must Produce

Deliverables

First Output

Install wow-viewer Dataset Builder 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