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 Shared I/O Library Plan - Prompt

Name: wow-viewer Shared I/O Library Plan
Author: akspa0

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

Design the owned shared library plan for wow-viewer so there is one first-party codebase for reading and writing the file types we currently handle across the old repo.

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
gillijimproject_refactor/src/MdxViewer
gillijimproject_refactor/src/WoWMapConverter/WoWMapConverter.Core
gillijimproject_refactor/src/gillijimproject-csharp

Goal

Define one owned library stack that becomes the source of truth for file-format reading, writing, conversion, and shared domain contracts instead of leaving that truth scattered across MdxViewer, WoWMapConverter.Core, gillijimproject-csharp, DBCTool.V2, AlphaLkToAlphaStandalone, parpToolbox, PM4Tool, and other historical tool roots.

Current Validated State To Build On

wow-viewer/src/core/WowViewer.Core and wow-viewer/src/core/WowViewer.Core.IO now already contain:
- FourCC, ChunkHeader, and ChunkHeaderReader
- ChunkedFileReader
- WDT or ADT top-level summary contracts and MapFileSummaryReader
- shared WowFileKind, WowFileDetection, and WowFileDetector
WowViewer.Tool.Inspect now consumes that shared surface through map inspect.
WowViewer.Tool.Converter now consumes that shared surface through detect.
If the ask is to implement the next narrow shared-format slice instead of planning ownership, use wow-viewer-shared-io-implementation.md instead of this broader planning prompt.

File-Type Families To Cover Explicitly

Alpha and standard ADT / WDT
terrain chunk families and placement chunks
M2 / MDX / MDL
WMO including version seams such as v14, v16, and v17
PM4
WDL
DBC and related table access seams used by tools/viewer runtime
BLP
export/import surfaces already split across viewer and converter tools

Non-Negotiable Constraints

Do not keep multiple first-party parser/writer stacks alive as peers in the new repo.
Do not confuse upstream dependency reuse with first-party format ownership.
Preserve readable FourCC handling internally and only reverse at I/O boundaries.
Keep Alpha and standard terrain handling explicitly separated where the format boundary is real.
Distinguish canonical readers/writers from partial, speculative, or research-only handlers.
Treat runtime ingestion helpers and file-format ownership as related but separate seams.

What The Plan Must Produce

The target shared-library breakdown.
A format ownership matrix by file family.
The source-root mapping for code to absorb, rewrite, wrap, or discard.
The writer/read-roundtrip risk matrix.
The migration order for file families.
The first file-family slice that proves the shared library is real.
Validation expectations using real data.

Source Roots To Inventory Explicitly

gillijimproject_refactor/src/MdxViewer
gillijimproject_refactor/src/WoWMapConverter/WoWMapConverter.Core
gillijimproject_refactor/src/gillijimproject-csharp
gillijimproject_refactor/DBCTool.V2
gillijimproject_refactor/AlphaLkToAlphaStandalone
parpToolbox
PM4Tool
ADTPrefabTool

Deliverables

Return all items:

target library/module tree
file-family ownership matrix
absorb vs rewrite vs wrap vs discard map
canonical read/write authority list
highest-risk format seams
first vertical slice
real-data validation plan

First Output

Start with:

the worst source-of-truth duplication seams in the current repo
which file families should become canonical first
which old code roots should be absorbed first versus treated as archaeology/reference
what writer/read path must not stay split in the new repo

Install wow-viewer Shared I/O Library 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 owned shared library plan for `wow-viewer` so there is one first-party codebase for reading and writing the file types we currently handle across the old repo. ## 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` 6. `gillijimproject_refactor/src/MdxViewer` 7. `gillijimproject_refactor/src/WoWMapConverter/WoWMapConverter.Core` 8. `gillijimproject_refactor/src/gillijimproject-csharp` ## Goal Define one owned library stack that becomes the source of truth for file-format reading, writing, conversion, and shared domain contracts instead of leaving that truth scattered across `MdxViewer`, `WoWMapConverter.Core`, `gillijimproject-csharp`, `DBCTool.V2`, `AlphaLkToAlphaStandalone`, `parpToolbox`, `PM4Tool`, and other historical tool roots. ## Current Validated State To Build On - `wow-viewer/src/core/WowViewer.Core` and `wow-viewer/src/core/WowViewer.Core.IO` now already contain: - `FourCC`, `ChunkHeader`, and `ChunkHeaderReader` - `ChunkedFileReader` - WDT or ADT top-level summary contracts and `MapFileSummaryReader` - shared `WowFileKind`, `WowFileDetection`, and `WowFileDetector` - `WowViewer.Tool.Inspect` now consumes that shared surface through `map inspect`. - `WowViewer.Tool.Converter` now consumes that shared surface through `detect`. - If the ask is to implement the next narrow shared-format slice instead of planning ownership, use `wow-viewer-shared-io-implementation.md` instead of this broader planning prompt. ## File-Type Families To Cover Explicitly - Alpha and standard `ADT` / `WDT` - terrain chunk families and placement chunks - `M2` / `MDX` / `MDL` - `WMO` including version seams such as `v14`, `v16`, and `v17` - `PM4` - `WDL` - `DBC` and related table access seams used by tools/viewer runtime - `BLP` - export/import surfaces already split across viewer and converter tools ## Non-Negotiable Constraints - Do not keep multiple first-party parser/writer stacks alive as peers in the new repo. - Do not confuse upstream dependency reuse with first-party format ownership. - Preserve readable FourCC handling internally and only reverse at I/O boundaries. - Keep Alpha and standard terrain handling explicitly separated where the format boundary is real. - Distinguish canonical readers/writers from partial, speculative, or research-only handlers. - Treat runtime ingestion helpers and file-format ownership as related but separate seams. ## What The Plan Must Produce 1. The target shared-library breakdown. 2. A format ownership matrix by file family. 3. The source-root mapping for code to absorb, rewrite, wrap, or discard. 4. The writer/read-roundtrip risk matrix. 5. The migration order for file families. 6. The first file-family slice that proves the shared library is real. 7. Validation expectations using real data. ## Source Roots To Inventory Explicitly - `gillijimproject_refactor/src/MdxViewer` - `gillijimproject_refactor/src/WoWMapConverter/WoWMapConverter.Core` - `gillijimproject_refactor/src/gillijimproject-csharp` - `gillijimproject_refactor/DBCTool.V2` - `gillijimproject_refactor/AlphaLkToAlphaStandalone` - `parpToolbox` - `PM4Tool` - `ADTPrefabTool` ## Deliverables Return all items: 1. target library/module tree 2. file-family ownership matrix 3. absorb vs rewrite vs wrap vs discard map 4. canonical read/write authority list 5. highest-risk format seams 6. first vertical slice 7. real-data validation plan ## First Output Start with: 1. the worst source-of-truth duplication seams in the current repo 2. which file families should become canonical first 3. which old code roots should be absorbed first versus treated as archaeology/reference 4. what writer/read path must not stay split in the new repo

{ "prompt": "Design the owned shared library plan for `wow-viewer` so there is one first-party codebase for reading and writing the file types we currently handle across the old repo.\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`\n6. `gillijimproject_refactor/src/MdxViewer`\n7. `gillijimproject_refactor/src/WoWMapConverter/WoWMapConverter.Core`\n8. `gillijimproject_refactor/src/gillijimproject-csharp`\n\n## Goal\n\nDefine one owned library stack that becomes the source of truth for file-format reading, writing, conversion, and shared domain contracts instead of leaving that truth scattered across `MdxViewer`, `WoWMapConverter.Core`, `gillijimproject-csharp`, `DBCTool.V2`, `AlphaLkToAlphaStandalone`, `parpToolbox`, `PM4Tool`, and other historical tool roots.\n\n## Current Validated State To Build On\n\n- `wow-viewer/src/core/WowViewer.Core` and `wow-viewer/src/core/WowViewer.Core.IO` now already contain:\n\t- `FourCC`, `ChunkHeader`, and `ChunkHeaderReader`\n\t- `ChunkedFileReader`\n\t- WDT or ADT top-level summary contracts and `MapFileSummaryReader`\n\t- shared `WowFileKind`, `WowFileDetection`, and `WowFileDetector`\n- `WowViewer.Tool.Inspect` now consumes that shared surface through `map inspect`.\n- `WowViewer.Tool.Converter` now consumes that shared surface through `detect`.\n- If the ask is to implement the next narrow shared-format slice instead of planning ownership, use `wow-viewer-shared-io-implementation.md` instead of this broader planning prompt.\n\n## File-Type Families To Cover Explicitly\n\n- Alpha and standard `ADT` / `WDT`\n- terrain chunk families and placement chunks\n- `M2` / `MDX` / `MDL`\n- `WMO` including version seams such as `v14`, `v16`, and `v17`\n- `PM4`\n- `WDL`\n- `DBC` and related table access seams used by tools/viewer runtime\n- `BLP`\n- export/import surfaces already split across viewer and converter tools\n\n## Non-Negotiable Constraints\n\n- Do not keep multiple first-party parser/writer stacks alive as peers in the new repo.\n- Do not confuse upstream dependency reuse with first-party format ownership.\n- Preserve readable FourCC handling internally and only reverse at I/O boundaries.\n- Keep Alpha and standard terrain handling explicitly separated where the format boundary is real.\n- Distinguish canonical readers/writers from partial, speculative, or research-only handlers.\n- Treat runtime ingestion helpers and file-format ownership as related but separate seams.\n\n## What The Plan Must Produce\n\n1. The target shared-library breakdown.\n2. A format ownership matrix by file family.\n3. The source-root mapping for code to absorb, rewrite, wrap, or discard.\n4. The writer/read-roundtrip risk matrix.\n5. The migration order for file families.\n6. The first file-family slice that proves the shared library is real.\n7. Validation expectations using real data.\n\n## Source Roots To Inventory Explicitly\n\n- `gillijimproject_refactor/src/MdxViewer`\n- `gillijimproject_refactor/src/WoWMapConverter/WoWMapConverter.Core`\n- `gillijimproject_refactor/src/gillijimproject-csharp`\n- `gillijimproject_refactor/DBCTool.V2`\n- `gillijimproject_refactor/AlphaLkToAlphaStandalone`\n- `parpToolbox`\n- `PM4Tool`\n- `ADTPrefabTool`\n\n## Deliverables\n\nReturn all items:\n\n1. target library/module tree\n2. file-family ownership matrix\n3. absorb vs rewrite vs wrap vs discard map\n4. canonical read/write authority list\n5. highest-risk format seams\n6. first vertical slice\n7. real-data validation plan\n\n## First Output\n\nStart with:\n\n1. the worst source-of-truth duplication seams in the current repo\n2. which file families should become canonical first\n3. which old code roots should be absorbed first versus treated as archaeology/reference\n4. what writer/read path must not stay split in the new repo", "variables": [], "notes": "Define the broader shared wow-viewer library plan for reading and writing supported file types. Use when planning ownership, source-root consolidation, or migration order across viewer, converter, toolbox, and legacy tools. Arguments: Optional file family, chunk type, or old tool to prioritize.", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/akspa0/parp-tools", "path": ".codex/prompts/wow-viewer-shared-io-library-plan.md", "ref": "4f7fb94cfad6bf6348c55c28ae9361c2d2fd9cb7", "url": "https://github.com/akspa0/parp-tools/blob/4f7fb94cfad6bf6348c55c28ae9361c2d2fd9cb7/.codex/prompts/wow-viewer-shared-io-library-plan.md", "key": "akspa0/parp-tools/.codex/prompts/wow-viewer-shared-io-library-plan.md" } } }

wow-viewer Shared I/O Library Plan

About

Read First

Goal

Current Validated State To Build On

File-Type Families To Cover Explicitly

Non-Negotiable Constraints

What The Plan Must Produce

Source Roots To Inventory Explicitly

Deliverables

First Output

Install wow-viewer Shared I/O Library 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